Yeah not feasible except for a tiny minority. I wonder if people would offer this as a service though. I presume the actual modules are cryptographically paired to the Mac so you can't just get entirely new modules.
I could totally imagine posting my module to someone else to upgrade though.
Any from reputable manufacturers?
Even that's ok. I couldn't find anything at all when I looked about a year ago. Only one model that the Thread people were still recommending despite it being discontinued.
I had another look and still couldn't find anything vendor neutral and cheap. Can you post some links?
Freeing home energy gear from vendor lock-in. Matter 1.4 adds some big, expensive gear to its list of device types and control powers, and not a moment too soon. Solar inverters and arrays, battery storage systems, heat pumps, and water heaters join the list.
Yeah I seriously doubt solar inverter providers will sign up to this. Here's what QCells said when I asked them about an API:
I’m sure it is possible and we’re in discussions with some providers over opening up to their requirements, but it’s not something we’d offer to individuals unfortunately.
They view control of their "virtual power plants" as a commercial asset and they don't want to give it away for free.
Don't buy a QCells solar inverter btw. I should have done more research! I believe GivEnergy are less stuck in the 80s but don't quote me on that.
Ugh, I was working on a DIY smart lock. "I'll use Matter!" I naively thought.
Ok you need a border router for Thread support. No problem, I'll buy one. Should be cheap right since an ESP32 can handle it. Nope! You pretty much can't buy a standalone border router. All the articles are "don't worry, you might have one already if you have a Nest Hub or a Home Hub or...". Well I don't have one.
Pretty lame. I guarantee if they make a vendor neutral border router dongle you can just plug into your router's ethernet port and sell it at cost price (like £5) they'll see triple the uptake.
PDF writing isn't too bad IMO, since you don't need to understand the whole spec. I've written a PDF writer for maps from scratch and it was fairly easy and not too much code.
PDF reading though... Yeah I'm happy to leave that to people with more time and use their libraries.
A modern format would be nice, but I don't think it would be anywhere near nice enough to give up how universal PDF is.
Eh, it practice it works extremely well. I can't remember a single instance where a PDF document rendered incorrectly.
The format is very old so it's not surprising it has picked up a few WTFs. I'm happy to keep those hidden below the abstraction.
Totally depends what you end up working on as a programmer. If it's web apps, you'll be totally fine. All you need is basic arithmetic. Writing a game engine? You'll need to know some basic to moderate matrix maths...
If you're doing formal verification using unbounded model checking... good fucking luck.
On average I would say most programming tasks need very little maths. If you can add and multiply you'll be fine. Definitely sounds like you'll be ok.
Nice work. Aren't wasm proc macros already prototyped in Watt though?
Why do you say it needs more time in the oven? I've had zero issues with it as a drop-in replacement for Pip in a large commercial project, which is an extremely impressive achievement. (And it was 10x faster.)
I tried Poetry once and it failed to resolve dependencies on the first thing I tried it on. If anything Poetry needs more time in the oven. It also wasn't 10x faster.
Is there any reason to use this now that Krita exists, sane name and all?
No, they were asking them to define the semantics of the filesystem APIs. Those semantics are not encoded in the C API but the Rust devs wanted to encode them in the Rust API to avoid making mistakes.
The C devs didn't want to, not because of concerns about binary drivers, but because the semantics are already broken. Apparently different filesystem drivers assume different semantics for the same functions and it's a whole mess. They don't want to face up to this and certainly don't want anyone pointing it out, so clearly it must be the Rust devs' fault for wanting APIs to have consistent semantics.
The rest of your comment is nonsense.