jmgao

That pricing is insane. I had 11.3 kWp of panels + 48 kWh of batteries installed in the Bay Area a few months ago, for $40k (shoutouts to Potrero Energy).

I've been on the mailing list for restocks for a month now :-(

This is the only device that I've found that has an e-ink display and an NFC chip that can read cards (there are a few with writable tags).

Optimistically spinning for a bit before falling back to futex or equivalent is very different from a spinlock.

> I was expecting a unified interface across all architectures, with perhaps one or two architecture-specific syscalls to access architecture-specific capabilities; but Linux syscalls are more like Swiss cheese.

There's lots of historical weirdness, mostly around stuff where the kernel went "oops, we need 64-bit time_t or off_t or whatever" and added, for example, getdents64 to old platforms, but new platforms never got the broken 32-bit version. There are some more interesting cases, though, like how until fairly recently (i.e. about a decade ago for the mainline kernel), on x86 (and maybe other platforms?) there weren't individual syscalls for each socket syscall, they were all multiplexed through socketcall.

> I use about 1500kWh a year, but I don’t need aircon and heating is district heating.

That's 171 W on average, that's about the same as my refrigerator (~150 W on average).

Well, except for inf, -inf, and nan.

> Compilers can do whatever they want when they see UB, and accessing an unassigned and unassiganble (file-local) variable is UB, therefore the compiler can just decide that *foo is in fact always 42, or never 42, or sometimes 42, and all would be just as valid options for the compiler.

That's not exactly correct. It's not that the compiler sees that there's UB and decides to do something arbitrary: it's that it sees that there's exactly one way for UB to not be triggered and so it's assuming that that's happening.

Wrong way around: UDP sockets are datagram sockets, there are datagram sockets that are not UDP.

Describing it as 'Google' is misleading, because different arms of the company might as well be completely different companies. The Chrome org seems to have had the same stance as Firefox with regards to JPEG XL: "we don't want to add 100,000 lines of multithreaded C++ because it's a giant gaping security risk", and the JPEG XL team (in a completely separate org) is addressing those concerns by implementing a Rust version. I'd guess that needing the "commitment to long-term maintenance" is Chrome fighting with Google Research or whatever about long-term headcount allocation towards support: Chrome doesn't want the JPEG XL team to launch and abandon JPEG XL in chrome and leaving Chrome engineers to deal with the fallout.

It doesn't seem obvious to me that this is actually a bug in the Android implementation, it seems like this is due to AirPods violating the spec and requiring a special handshake before responding to standard requests. It doesn't seem reasonable to expect Android to work around a device that appears to be intentionally breaking the spec for vendor lock-in purposes: the possibility of them just OTAing an update that breaks in some other way means that you'd have to be entirely bug compatible with iOS's bluetooth implementation.

I've found 0.8mm to make much more reliable connections, since the specification says that the tongue should be 0.7mm. 0.6mm will disconnect if the cable is angled in any way.