The data center side has largely been keep that water far away, and now that we have 500W chips, well, it's more appealing to bring the water in super close to the electronics.

I anticipate that a difference is that other fields have long been in the mode of designing precisely for the cooling, but on the datacenter side, it's a bit more of an afterthought in general. I also wonder if other disciplines have their organization more in order, whereas the datacenter guys tend to do stuff in the room without as much coordination with the facilities.

Whatever the case, the big facilities loop is pretty inconsistent and the server water loops are very picky about not being flexible with plumbing and demand little tiny liquid channels and such.

But I could easily imagine folks scoffing at those challenged over dissipating 75 kw of heat from a 0.75 square meter, and wondering why datacenter guys are being just so weird about it.

From when they did enjoy waning, but residual mobile device success, they used their money to buy QNX. That platform enjoys continued licensing revenue, even as that business, too, wanes over time as less popular than Linux based solutions in most segments (some segments stick by QNX).

So I work with people who largely stick to the "in-datacenter" portion, with facilities water being a "somebody else's problem", and as it is somebody else's problem. Since it is "somebody else's problem", they are very inconsistent customer to customer as to what to expect. So we have loops that cover a few cabinents that terminate in a liquid-liquid heat exchanger, with a goal of tolerating all sorts of facility water. Too cold, a bit warm, contaminants that can foul some valves over times (but the valves are easy enough to service on the facilities side).

Note that I know of their work, but technically other folks take point on the thermal engineering facet so I know about this stuff a bit more indirect.

There's a fair amount of relaxed air handling toward the end of nicer PUE numbers. Even with climate controlled datacenters, as an example, I see one right now with an air temp of 21.1C and humidity of 59.8% meaning a dewpoint of 13C. The incoming water to that exchanger is 8.5C.

Even a fairly aggressive dehumidification would land at 10C dewpoint. Very tough to keep sub-10C incoming water from wetting the plumbing.

Now in an ideal scenario, you plug in downstream of something that happens to be hot, or your natural water inlet is not that cold. But it's far from a given that facilities are diligent enough to ensure cold water is above dewpoint.

You have other non-thermal considerations. In the DIMM/CPU scenario, you have trace lengths and board density to consider.

If you are talking about liquid cooling of things like CRAHs, sure you can be focused on the needs of the plumbing and demanding tolerances with the water. But nowadays we are running plumbing between DIMMs, around EDSFF drives, and so on.

Yeah, the state of the "security" industry is pretty bad. Tons of people being patted on the back for crying wolf over nothing and it's just so tedious to recognize the actual threats among the sea of nothing.

Even with the relatively low bar of getting a CVE, there are companies that "add value" by tracking things so stupid that a CVE was denied or delisted and audit things for the "security issues that even MITRE isn't tracking".

I know the industry was too cavalier about security issues once upon a time, but the pendulum has swung too far the other way and it's just ridiculous.

He covered issues that automation doesn't even theoretically cover.

Think a pipe running between DIMMs in a server, very easy for stuff to foul the flow there or to otherwise degrade the tiny bit of piping with a tiny channel for flow. With the secondary exchanges, you can have nice big plumbing and not even have to think about the water messing things up over a very long period of time.

I don't understand your position here, it's still an issue if you had no liquid-liquid heat exchanger. A major tool in the industrial automation is the decoupling of liquids in that head exchanger.

If your water supply is below the dewpoint, and you have plumbing that will be in sensitive electronics, then your only control is to not flow the water at all, which means you can't cool. The components that need the cooling will not heat the plumbing that leads up to it, and even if you could assume that, still it's still going to be in parallel with components that aren't hot enough to raise the temperature above dew point. Maybe if you are running your water through pretty much guaranteed heat sources that can take condensation before you get to the sensitive parts you can be relatively confident, but I to this day see places where the water supply at hand would cause condensation if it were allowed to flow at any rate that would be adequate to also cool the circuitry.

As to your point about the additives, true, you are mainly addressing problems caused by the decision to recycle the water in the loop endlessly, but it's a tradeoff because you don't want the less well known stuff in your water supply going all over the place. The primary loop may be fouled by stuff in the secondary loop, while the secondary loop can be more robust or at least fewer maintenance items to care for.

Bumping up your credibility, *especially* if you manage to frame the purported issue as a "security" issue. Bonus points if you manage to get a CVE or other less rigorous security identifier number on it.

Even without LLM, it's been a pretty hideous mess of "non-issue" CVEs born out of people trying to pad their "security researcher resume". So I can imagine people pitching themselves as security researchers or even just "quality engineers" love the concept of generated slop to take credit for.

They like to put crap into the cooling pipes, to make sure nothing lives/grows in the water and such. They also like being more picky about the starting water in the loops that endlessly recycle the same water. So it's standard practice to have separate cooling loops with a heat exchanger.

Also, if you ran the secondary loop wide open, there's a chance of your pipes inside the more sensitive electronics going below the dew point, which would be a gigantic bad thing. Your secondary loop is generally in a situation where you can manage some condensation, should it happen, but your primary loop generally must avoid condensation at all costs. So you have valves that shut out the heat exchanger if the primary loop gets colder than you want.

He said "replace" not "get rid of", and I think there's a fair point there. You can still get that foreign labor, but if they are so valuable as to be an H1B holder, we should be more aggressive about that person getting longer term immigration status.

Not only that, but he is also in charge of Bing, and so his explanation for failings of Bing is that "well just all search engines suck, give me more stock options and while I failed to make Bing competitive, I will instead get to the 'beyond search' world before Google".

He is speaking in such buzzword heavy that it's hard to discern a precise point, which is likely the whole intention. But he suggests the 'UI will be generative', so at least in that part he seems to be indicated a more open ended interaction than text and voice.

So if I try to give him the benefit of the doubt, it's how a lot of google searches end up in some sort of UI tailored to the query. You ask a simple math problem, you get a calculator. You ask about a movie and it gives you a UI structured around movie pertinent data. So I suppose he could be implying that this would expand to all sorts of queries without a programmer first having to design how that UI works, ingests information, and how the user interacts with it to intelligently drill down or otherwise modify the query.

I'm not so sure whether this would have a ton of generic value, and it would be awfully frustrating for it to lock you into an incorrect UI (which is a common complaint of the google behavior, sometimes the chosen UI is not really catering to what you want). But I could see a way to interpret his words to not mean something as asinine as 'voice back and forth only'. That seems to be the summary, but that doesn't match the text of his interview.

"And don't make up function calls that don't exist"

"Don't create glaring security holes"

"Double check that the cited libraries are actually still usable"

"Please commit your suggestions to a library on github and maintain it properly so I don't have to rewrite my code"

I don't think LLMs can follow those instructions, and to the extent they could, why would those not be the default behaviors?

Also, at some point, trying to get an LLM codegen to do what I want is more trouble than just doing it.

Now I could see potential for LLM handily augmenting code completion, as it becomes more seamlessly integrated. Current code completion is pretty good, with the LSP implementations out there to help, but there are occasions where even a braindead person would know where a segment of typing is going beyond what current code completion can really help with, and that's an area I could believe in LLM providing value.

That is a fine example of two things:

a) Something that I fully believe is within the reach of LLM codegen solutions.

b) Something that has a ton of ready-to-go projects providing that already on github, and you don't need an LLM to generate it.

That has been my experience, that in experiments it *can* handle little demonstrations like you describe, but anything it can wrangle is readily offered in the very first link of an internet search.