the8472

A lot of those are datacenter GPU racks which will be difficult to operate for most people, even for smaller companies that don't have watercooling setups.

Conversely, exploiting the the lack of encryption would also be an unstable position because the world then shifts to encryption, voiding your access. So you're trading a one-time benefit to yourself against permanent ongoing costs for the whole world.

I know that humans are poorly equipped to solve these kinds problems, but it still is lamentable.

Adding HTTPS everywhere was not "a good thing", it's coping with a civilizational coordination failure that shifted us to a lower trust equilibrium. We're paying the price for that in an endless update treadmill for clients and even for read-only webservers. And more compute-cycles and latency spent on the encryption handshake. We also lost caching HTTP proxies. This is bad actors creating a negative-sum outcome.

They're tools. I expect BM 085232, not the Book of Kells.

I don't think that's firefox doing it? I'd guess it's some CDNs doing the conversion. Or the URL says .jpg but when you look at the mimetype sent by the server it's actually webp. Extentions are meaningless for browsers.

Swap latency explodes when you get into a swap storm where tasks continuously touch different pages and fight to get things paged in and out, forming a queue waiting for swap IO. The other thing causing multi-second pauses is approaching OOM and the system attempting some last-ditch efforts before unleashing the OOM reaper, but that's not strictly swapping, it'd also happen on a swapless system.

If it's only a single fault I'd expect it to be to be dominated by IO latency, which is pretty good on NVMe. As the article shows those 40ms were accumulated over hundreds of pagefaults. The problem there was that there was a stop-the-world pause stalled by all those pagefaults together.

A fully-concurrent and swap-friendly GC you could maybe define that it only increases the active working-set by x GB on top of what the application itself (and the rest of the system) is actively using and will only page-in y GB per second. And it'd do so on GC threads, not the application threads. Whether that would be sufficient to not cause a swap storm would still depend on all the other stuff happening besides the GC.

A region-based collector like Hotspot's G1 combined with madvise could probably operate in a manner that's more swap-friendly by focusing on a smaller working-set at any given moment and announcing its intent to switch the working set to the OS ahead of time.

They can sell the AI products to write memory-optimized software to replace React apps.

"So far" is a statement about the present and past. "This fear" is primarily about the future, though a few jobs already have been affected. So it's not like there is zero evidence.

Those are basically two separate areas of risk.

The short-term consequences of moderately human-comparable AI (jobs etc.). Yeah, don't put them in charge of the nukes and work on societal issues we should be fine.

The other one looking further out when they scale to superhuman levels, which is the professed goal of the AI labs. Further out may mean just a few additional years if we get to recursive self-improvement. At that point the issue isn't "we put it in charge of the nukes" but "it's an intelligence with goals and we don't know which path it'll take to work around us to accomplish its goals". Humans regularly bulldoze other species to accomplish goals. And it's not like it'll be locked up in some secure box as people were arguing in the past. We're already seeing AIs being integrated into everything, so whatever access they'll want they might already conveniently have, though the argument goes that this isn't a necessary condition, just a thing that simplifies the argument-tree.

MRAM is 1T, non-volatile and supposedly has nanosecond-scale write times so it naively seems like it'd be an ideal SRAM replacement. But I guess shrinking MTJ is more difficult than other components or there are some other limitations.

Seems like begging the question to me. You can't blend the numbers because amazon didn't blend the numbers. If they did and miraculously still arrived at 11 9s then that would also cover things such as wars and natural catastrophes, e.g. because they do offsite backups internally.

I'm saying that if you have eliminated more mundane failures like dying harddrives, cosmic rays and so on from your systems and your calculation ends up with 11 nines then actually those "force majeure" events are probable enough that they dominate whatever other residuals are supposedly hiding in those last 0.0000000001%.

The region has seen a bunch of wars in the last 100 years, so the annual war-rate is > 1%. Even if we generously add the assumption that only 1 in 100 wars affects a datacenter you can see that wars become a major source of correlated hardware failures that they need to solve to actually deliver that kind of reliability.