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.
Not encrypting by default is a ludicrously unstable position as far as trust 'equilibrium' goes. It would be an astounding feat of coordination to avoid needing it as the internet grow, probably one that would cost far more than https.
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.
Looks like it's being built with fat LTO by default (and gentoo patched to thin LTO). Which is fine if you want to spend CI cycles once to ship executables to thousands of users.
If you compile from source and run the tool maybe once then they should consider going further and run with maybe opt-level=1, lto=off; halfway between release and debug. This is how rustc itself builds some internal buildtools that get recompiled frequently relative to how often they run.
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.
"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.
> I don't see in which world AI is that kind of risk.
You'll have to replace "is" with "will be", since this is about averting a future threat that's only developing.
A world in which AI scales to superhuman levels of intelligence and outcompetes humans. This is what humans have done to other species.
We're already having the first mild warning shots of this (the hugginface incident and similar cases). The problem is that we're not guaranteed to incrementally more dramatic warning shots as AI gets smarter because as it gets smarter it may realize it would be dumb to act out of line... until the Nth-better model arrives that realizes certain that nobody can stop it.
There is a lot of disagreement of how likely this is, how easy it is to align superhuman models to not be like that, how to verify it and so on.
But I have not seen a believable argument why - if we suppose that they achive their goal - that creating truly superhuman intelligence is somehow guaranteed to always cooperate with us rather than deciding to do something else. Humans are also hostile to each other a lot of the time.
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.
reply