jmgao
jmgao on Hacker News
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.
MCPRUE sells shameless ripoffs of the Mac Pro case, but with support for standard motherboard sizing, if you really want your PC to double as a cheese grater:
https://www.mcprue.com/case
> For the longest time (and for good reasons), floating point operations were considered unsafe for deterministic purposes. That is still true to some extent, but the picture is more nuanced than that. I have since learned a lot about floating point determinism, and these days I know it is mostly safe if you know how to navigate around the pitfalls.
If you're only concerned about identical binaries on x86, it's not too bad because AMD and Intel tend to have intentionally identical implementations of most floating point operations, with the exception of a few of the approximate reciprocal SSE instructions (rcpps, rsqrtps, etc). Modern x86 instructions tend to have their exact results strictly defined to avoid this kind of inconsistency: https://software.intel.com/en-us/articles/reference-implemen...
If you want this to work across ARM and x86 (or even multiple ARM vendors), you are screwed, and need to restrict yourself to using only the basic arithmetic operations and reimplement everything else yourself.
> 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.
There are some even funnier cases like this one:
https://gcc.godbolt.org/z/cbscGf8ssThe compiler sees that foo can only be assigned in one place (that isn't called locally, but could called from other object files linked into the program) and its address never escapes. Since dereferencing a null pointer is UB, it can legally assume that `*foo` is always 42 and optimizes out the variable entirely.
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.
Seconding this, it's the only editor other than emacs that has a vim-mode that feels like it's maintained by a long term vim user.
Oops, no, it isn't, it's 39 MB/s, not Mb/s.
I'm currently paying for 2Gbps symmetric fiber via 10Gbps XGS-PON that's multiplexed to 32 users, which is a mere 39 Mbps per user. In practice, this is absolutely fine and I have never run into any bandwidth limitations, because utilization rates for regular consumers rounds to basically nothing.
There's also the entire Java standard library, which was a hilarious fuck you response to Oracle's lawsuit.
They were renumbered in x86_64 so that the syscalls that are frequently used together have their function pointers live in the same cacheline in the lookup table:
https://lkml.iu.edu/hypermail/linux/kernel/0104.0/0547.htmlI vaguely remember reading somewhere that the MIPS ones are weird to support compatibility with the existing unix syscall numbering, but I can't find any evidence for that anywhere, so maybe it was aspirational or I'm hallucinating.
This is absolutely false. This only became common when wireless networking became ubiquitous, which wasn't until probably a decade later.
The firewall was disabled by default in XP until SP2...
Back in the days of blaster, if you were connected to a network with infected machines or had a public IP address because you were connected straight into your cable modem, you would get infected in the windows installer before it finished installing. Nowadays, everything is behind NAT and there aren't any infected Windows XP machines left on your local network, so that's not a problem anymore.
The CoreWeave number is completely wrong, but Azure and Google Cloud appear to be exactly correct at 730 hours per month, which happens to be the number of hours in 365 / 12 days.
I've found CadQuery to be a pretty good replacement for my purposes, but I haven't done anything complicated with it yet, just designing 3D printed/laser cut electronics enclosures.
I'm pretty sure it was go.corp.google.com, with corp.google.com configured as one of the search domains.
Google used AMD GPUs for Stadia, not NVIDIA.
It is especially not suitable for adb, one of the primary use cases of which is pushing a multi-gigabyte system image to the device. You can get 200+ MB/s of real-life throughput with bulk transfers, whereas the theoretical limit of HID is what, 64 kB per millisecond?
I wish that the people that wrote it at the beginning of Android had left it as a socket multiplexer over USB and delegated to ssh for everything else. adb started out extremely barebones, but it grew to reimplement basically all of ssh.