For datacenters specifically I've never understood what specifically consumes the water. Arent the water-cooling loops closed, so the water just cycles around and around and around?
At the datacenter side, it depends on the method of cooling. You can chill the air or the chips directly (or both), doesn't matter, you still need to cool, and that still needs water. The question is, where is the water being used?
- If they use either evaporative cooling or a liquid-cooled heat exchanger, that uses tons of water consistently. This requires less energy (it's mostly passive) so you use more water.
- If they use closed-loop water cooling and/or heat pumps/electric chillers, that uses much less water - at the DC. But it does require more energy to circulate the water, run fans, etc. If you are using more energy, where is the energy coming from? It's coming from power plants, which require... you guessed it... more water (e.g. thermoelectric, hydroelectric, geothermal, concentrated solar). They need water in order to generate the power, and lots of it. Coal, natural gas, nuclear, and concentrated solar, all use steam to generate energy. Nuclear also uses water to cool the reactor. And water is used extensively to extract coal, oil, and natural gas. Geothermal uses water in the ground.
You can't not use a ton of water in one fashion or another. It just depends what method, and on what end the water is used. And the crazy thing is, most new datacenters are being built in places with extremely little water. Guess how that's gonna work out as the planet gets hotter?
I don't know why I got downvoted to hell for stating facts every datacenter architect knows. HN be HN'in.
The system which runs coolant over the chips can be closed but the part which uses an evaporative system to cool that is still open loop and vents water into the air, no?
Evaporated water is condensed, and in the process transfers its heat into another place that removes it. Another simple example is a pot of boiling water with a lid on it.
That's the problem, removing heat at a sufficient rate. Of course it can be done, but the most efficient way (in terms of cost) is just open loop evaporation.
I'm not a datacenter engineer, but I used to work in the ski industry. Snowmaking systems use vast quantities of compressed air. It works better if that air is cool. Blowing hot compressed air out of a snow cannon means the air temperature (wet bulb to be specific) needs to be colder to make snow.
Anyways, most air compression stations use water to cool the air, and then evaporative coolers to cool the water. The water is reused, but a ton (not sure of the percentage) is lost into the air. It's more or less a tower with a big fan on top, and water percolates down from the top, being cooled by the air as it goes. The water is then collected and pumped through the system again (but of course has to be always topped up to counteract what was lost to evaporation).
Anyways, long story short is it's most cost effective to just spray water into the air to cool water, as long as water is free/cheap.
Oh like one of those scenic cone towers like on a nuclear power plant?
Iiuc youre saying: its more cost-efficient to waste water using evaporative cooling so thats what we'll get, not that a closed loop with a heat exchanger is technically infeasible?
Closed loop is of course feasible, and closed loop with an evaporation step is also feasible, but open loop evaporative is the most efficient in terms of total energy usage (cost) and most cost effective in general, so that's what we mostly get right now.
You are adding an extra step though. Use a closed loop coolant and remove the heat from that coolant with the heat exchanger. Why would evaporation in between be more efficient?
I consider 'acceptable speed' to be around 150t/s. Why? Well, this is generally what it takes to keep me engaged with the output, rather than immediately switching to other tasks and checking back later. When I check back later, I have more catch-up to do at once, and I haven't been following the process. So I have to recall it, familiarize myself with the new progress, and sort of get back into focus with it, which is a lot of mental work (even if it happens quickly in real-time). I prefer not to have to do this because of how much work it is, so I prefer to watch the agent in real-time and try to follow its reasoning. That also lets me interrupt it quickly when I see it about to make a mistake, or see an important detail I left out.
Interesting, for anything more than side chats/projects I usually am watching the output generate and thinking about the problem. I have the same issue with switching back, takes a while to recall and page everything back into my context, so I try not to alt-tab away.
Worth distinguishing knowledge/task benchmarks from IF / agentic. It doesn't seem out of the question that you can have a small model thats generally good at instruction following and long-horizon agentic, as usually in those cases any requisite knowledge is in the context.
Most of the benchmark improvements afaict are in agentic and instruction following benchmarks.
Architecture thread! Afaict they continue to use gated attention + delta net, which was also adopted+adapted by K3, but im surprised theres no improvements to the residual stream (deepseek are using manifold hyper-connections, kimi have attention residuals) ?
I went clicking through to see if I could find the prompt they fed the AI to locate the issue / write the test suite.
I couldn't find it, so its unclear if the prompt was completely "make a test suite" or was lead towards finding it in the first place, which wouldn't be a fair test.
The closest I mention of the prompt I could find was:
> Then I asked it to write a simple workload which exercised the WAL insert and checkpoint code. Notably, this is a completely generic workload.
Hey, author here! Good question. The prompt was to use the Antithesis skills[1] to write a workload that exercises SQLite's insertion and checkpoint machinery across multiple processes using a specific version of SQLite (3.51.2). The agent who did the work was aware of the bug and knew I wanted to see if Antithesis could reproduce it. However, I specifically designed the workload the same way we approach testing other WAL checkpoint-style systems: by putting them under stress. The workload itself does not know about the bug.
My goal, which I believe I accomplished, was to determine if Antithesis would have found this bug if we had put the SQLite WAL under test.
Which is: "Given the knowledge of a kind of bug that can happen in one Raft implementation, can a similar workload find similar bugs in other Raft implementations?" Turns out it can.
Yeah 100%! And I'm sorry if I sound a little more critical and less eager, its just thats theres a world of difference between a priori finding the bug, and reproducing it, and the impression of the article (from my read) was the former.
But please keep writing, I know its super hard to put yourself out there and make content!
Their founder guy says[1] they found some other bugs while doing this that they will report soon, so if that is true, seems more plausibly like a pretty generic thing.
Looking forward to seeing the other bugs they found.
Idk if its accurate to rote project the policies of OpenBSD to OpenSSH, yes technically its a subproject but in practice stewardship and thus effective policy is pretty much all damien.
If they disagreed about something so fundamental as the attribution of copyright, it would be a serious schism, from my outside perspective it seems along the lines of something that would lead to a fork or separation between the projects.
I also just read more context on the thread and it seems like Damien Miller is in there saying much the same thing as Theo. He wrote:
> ... use of AI-written code now [will] expose us to legal risk.
This was in the context of a contribution to add (IIRC) ext4 filesystem support to OpenBSD. In this case, I was worried that the AI was just regurgitating code that was in its training corpus because how many ext4 implementations are there?
I think AI generated bugfixes and smaller features that don't duplicate fairly unique pieces of work in other projects are much less problematic from a copyright perspective at least.
Was really cool to see yous use Engrams to cut down compute!
Given its basically an O(1) lookup with disk space being the main constraint, I was curious if you've tried ablating engram layers and sizes across your setup?
reply