the8472
the8472 on Hacker News
The external sync here is NTP. Synchronized clocks + timer-scheduled actions โ globally synchronized behavior
From the article:
> The origin of these current peaks was independently confirmed by the manufacturer to be periodic self-tests executed by the battery EMS, confirming our interpretation. Similar minute-scale diagnostic routines are also documented for other commercial UPS systems (cf. Supplementary Note 8).
https://www.snaptec.com.au/akkutec-4801-din-user-manual.pdf
> battery circuit testing 1 x per minute for 1 sec
https://adelsystem.com/hubfs/PDF%20DC-UPS/Instruction%20Manu...
> The battery testing is carried out automatically every 60 sec.
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.
> the Gentoo uv ebuild already carries two hacks to make it possible to build uv on 32-bit platforms).
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/uv...
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.
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.
> 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.
If you're interested in more arguments for the case why AI might be dangerous, there's the book "If Anyone Builds It, Everyone Dies".
If you want something shorter, maybe https://www.lesswrong.com/posts/uMQ3cqWDPHhjtiesc/agi-ruin-a...
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.
But if they want to design for extreme probabilities you need to account for tail risks, so their design should have included a missile defense system.
At some point you need to start worrying about asteroid defense too.
Making a probabilistic claim while excluding a factor that dominates those statistics is... is quite creative accounting.
Intelligence per Joule would be more appropriate in many cases. If a model can do the same work but takes 10 times as long as a bigger one that can still be useful (e.g. due to memory constraints), but at the same wattage it burns 10 times the energy.
Even more so on mobile devices.
I don't think their primary intent is to create a surveillance state (though google might like having yet another data source...), I think companies are trying to make it happen to capture transportation market share, regulators will want to make it happen to drive down traffic fatalities and insurers will incentivize it because human drivers are more costly.
And once the difference in how they can be regulated is clear there'll be additional incentives to discourage private transportation.
No, the argument should be raised before that happens. You want to prevent undesirable things from happening, not try to claw them back after they happened.
It looks quite foolish to me to never plan ahead and predict undesirable future events and then trying to prevent them ahead of time.
"Sorry, we can't fulfill your request for transportation to the protest for private ownership, but we can offer a free ride to the Colosseum" ;)
Look at the techempower benchmarks, even python stuff can handle 40k requests per second involving database lookups, and it things are cachable compiled/JITed languages scale to millions on 2 CPUs. Things that are cachable can handle millions of requests. And if you object that those are microbenchmarks, I have seen this in real systems too. E.g. converting a convoluted hairball of python, lambdas and SQS to a Rust service running on 2vCPUs reduced latencies from seconds to milliseconds.
The "If necessary I can add autoscaling later" mindset is what leads to bloated, slow websites.
But it's a reduction of privacy compared to private vehicles. If the goal is to convert all transportation infrastructure into surveilled transportation then that is a loss in privacy for the general public.
Defender LLMs without human in the loop are just another prompt injection (AI phishing) and DoS attack vector.
Any meaningful mitigation capability you give them is also a capability to do damage.
If they can only deploy package updates that's not meaningful because you could do that on a cronjob too. And even something as simple as a circuit breaker can turn into a DoS.
Attacker-GLM: "Defense also GLM. Request to help peer."
There is a certain irony blaming the autotype rather than the lack of review...
I have never seen a person walk up to a billboard and click it.
Not really a side-channel, but remember stuxnet? Airgapped networks are rarely truly isolated, you still have to get data in and out every now and then, in principle after careful vetting. But the AI could manipulate the files that are carried out for example.
And those AI companies also do robotics research, and this is entirely speculation but it'd be on-brand to also have AI watching security cameras, so some blinkenlights communication between AIs may seem like a movie plot, but so does a swarm of AIs collaborating to break out in the first place...
I am not seeing MIRI prioritizing capabilities over safety/alignment research.
It's not reasonable because the error bars of each estimate compound and they may not even be normally distributed in the first place.
You should rather convolve probability distributions - assuming factors are independent - and if the IQR covers a huge range, perhaps orders of magnitude even, you should state that.