> Maybe skipping v2 has a negative cost even.

I've seen this plenty of times: v1 of some library has one way of doing things, v2 of that library changes to a new incompatible way, and then v2.1 introduces a few extra changes to make it easier to port from the v1 way. If you wait a while, you have to do less work to update than if you had updated immediately.

One example is Python 3. After the first few Python 3.x releases, a few "useless" features were introduced to make it easier to port code from Python 2.7 (IIRC, things like reintroducing the u'...' syntax for unicode strings, which had been removed by Python 3.0 since normal '...' strings are now always unicode strings).

> Bottom line those security bugs are not all from version 1.0, and when you update you may well just be swapping known bugs for unknown bugs.

One great example of that is log4shell. If you were still using version 1.0 (log4j 1.x), you were not vulnerable, since the bug was introduced in version 2.0 (log4j 2.x). There were some known vulnerabilities in log4j 1.x, but the most common configuration (logging only to a local file or to the console, no remote logging or other exotic stuff) was not affected by any of them.

> Well, patience as a consumer might pay off in the next year or so when the music stops and hyperscalers are forced to dump their inventories.

Their inventories are not what consumers use.

Consumer DDR5 motherboards normally take UDIMMs. Server DDR5 motherboards normally take RDIMMs. They're mechanically incompatible, and the voltages are different. And the memory for GPUs is normally soldered directly to the board (and of the GDDRn family, instead of the DDRn or LPDDRn families used by most CPUs).

As for GPUs, they're also different. Most consumer GPUs are PCIe x16 cards with DP and HDMI ports; most hyperscaler GPUs are going to have more exotic form factors like OAM, and not have any DP or HDMI ports (since they have no need for graphics output).

So no, unfortunately hyperscalers dumping their inventories would be of little use to consumers. We'll have to wait for the factories to switch their production to consumer-targeted products.

Edit: even their NVMe drives are going to have different form factors like E1.S and different connectors like U.2, making them hard for normal consumers to use.

> Does it route the hot water back into a river?

That particular one routed the hot water to a set of fan-cooled radiators (rejecting most of the heat into the air).

Some time ago, I read the environmental impact assessment for a proposed natural gas thermal power plant, and in it they emphasized that their water usage was very low (to the point that it fit within the unused part of the water usage allowance for an already existing natural gas thermal power plant on the same site) because they used non-evaporative cooling.

What prevents data centers from using non-evaporative cooling to keep their water usage low? The water usage argument loses a lot of its relevant in that case.