pjdesno

To translate to Rust, it would have been "we missed a single line Rust check"...

This is a bug involving intersecting concerns and a deficit of cross-domain knowledge. It probably would have been the same in Lisp or assembly language.

Most people don't plant an alfalfa field in the desert and then try to use the local municipal water supply for irrigation.

Some of the folks looking to build datacenters to cash in on the AI craze aren't as bright as that.

It's near Springfield, Massachusetts.

My point is not that evaporative cooling is necessary - it's that it's efficient, and therefore common. I found some 10-year-old info from our datacenter, and it looks like mid-summer months add an extra 20% in power consumption for cooling, in large part due to running the chillers, which are industrial-scale active A/C units to raise the exhaust heat temperature. Average outdoor temp (24-hr average) during those months was 70-75F.

It's a pretty small datacenter, so getting rid of the evaporative cooler would probably "only" cost us a couple of megawatts or so in additional power consumption. (and maybe 15 million pounds of carbon emissions - our power is hydro, but electricity is fungible, so every kWh we use probably results in an additional kWh of fossil fuel generation somewhere in the grid)

There aren't many heavy industries that dissipate 100MW of thermal energy, never mind a GW.

Those that do - power generating facilities, large smelters, etc. - have very significant environmental footprints.

    Historically, cooling alone has accounted for up to 40% of a data center’s electricity consumption

Water use isn't a myth.

Our data center is mostly air-cooled, with 100F hot aisles and chilled water going to heat exchangers in every third rack position, although some of our newer GPU racks use chilled water directly. For most of the year that means we don't need chillers - the warm water return is sufficiently hotter than outdoor temp that heat "flows downhill" with a bit of pumping.

But we use an evaporative cooler to carry that heat away outside, because it's more efficient. If you look up the heat of vaporization of water, that means we evaporate about 10,000 gallons of water per day per megawatt of power dissipated. We're on canal off a large river, and we don't dissipate all that many megawatts, so I believe the water use isn't significant.

Using air as the working fluid to draw heat from your machines has a limitation - humans have to breathe that air whenever they work on the equipment, so the temperature is limited. Once the exterior temperature nears your hot aisle air temp, you either need active A/C to create a heat source hotter than ambient, or an evaporative cooler to lower the "effective" ambient temp to the dew point.

Liquid cooling lets you run your working fluid a lot hotter without killing folks like me who go into the data center, although honestly 45C sounds like an incremental improvement over the 100F places like ours are already running. (although to be fair, the warm water return from the heat exchangers is no doubt somewhat less than 100F) It also lets you run your "cold" side a lot hotter - if you "chill" your water down to 100F (38C) on a hot day, it's still cold enough to carry away a lot of heat at 45C.

(I'm skipping over the fact that there are multiple heat exchanger loops involved - e.g. any system with an evaporative cooler needs a heat exchanger to keep leaves and bird shit outside the building where it belongs)

Note that for the businesses mentioned in the article, the service is the product.

I don't care about service at a gas station - I want to fill my tank, pay, and get out. It's different when I take it to the mechanic - it's a rather old car, and I appreciate them talking intelligently about what the options are and what repairs they would suggest.

Note that there are a fair number of native speakers of English in Nigeria - more than in all but 3 or 4 US states.

In addition, "non-native" English speakers in India (and Nigeria?) typically study English from the first grade, and in many cases attended elementary schools where English was the language of instruction.

I think the differences between US English and both Indian and Nigerian English have more to do with divergent evolution of the educational systems. British English has a lot of differences, too, but we don't notice it as much unless we run across things like "whilst", probably because there's more media crossover. (if you find yourself reading Thomas the Tank Engine to kids it jumps out at you, though - the entire vocabulary for railroads evolved during a period when US and British English were diverging)

They overstate their results in the headline.

In section 2, 34% of cases are found to have "substantive" disagreements differing by 2 or more buckets - True + Misleading, Mostly True + False, or True + False.

This is probably a better measure than the headline one. It's still a concerning fraction, although some fraction is no doubt due to forcing "I don't know" cases to return an answer anyway.

If you run "make" in the papers/IBIC2013 directory you'll get this paper: https://cds.cern.ch/record/1743073/files/thbl2.pdf

It's quite interesting - this isn't ethernet as we know it. Instead of each NIC using its own free-running clock, all the physical layers are sync'ed to each other at layer 1. (note that gigabit ethernet, which is what it uses, sends data at all times - when idle it sends the idle symbol)

"I wonder if this is actually true in the long-term though. If they were to flood the market with lots of high capacity memory, then I think our programs would start using more memory too. As a result we might end up needing more memory faster compared to if they keep demand unmet."

It's a gambler's ruin problem. Future profits are worth zero if you go out of business first.

Jatin Malek on Twitter had perhaps the best explanation of the DRAM crunch:

"The reason why RAM has become four times more expensive is that a huge amount of RAM that has not yet been produced was purchased with non-existent money to be installed in GPUs that also have not yet been produced, in order to place them in data centers that have not yet been built, powered by infrastructure that may never appear, to satisfy demand that does not actually exist and to obtain profit that is mathematically impossible."

I’m curious what the performance of this implementation is

Almost certainly crap.

As the author states, it's a simple fork-on-request server, which was state-of-the-art in about 1996. But that's not the point.

Also note “Disks are like snowflakes - no two are alike”, Krevat, Tucker & Ganger, HotOS 2011. The number of tracks and bit density is not the same on different surfaces within the same disk, or across disks of the same model.

https://www.usenix.org/legacy/event/hotos11/tech/final_files...

Read this paper: “ Revisiting HDD Rules of Thumb: 1/3 Is Not (Quite) the Average Seek Distance”, MSST 2024. https://www.msstconference.org/MSST-history/2024/Papers/msst...

It has a very good approximation for seek time based on the track radius delta, with experimental validation on a modern drive.

Why should Backblaze back up their competitors’ data? And what use is it to you for it to do so?

Interesting.

My only experience with Veracrypt is via a law firm I was consulting with, who used it to protect some files they were sharing with me. Law firm and their end client are both big, prestigious companies.

It's a soda bottle - it fits in your water bottle holder, and you can replace it for a couple of bucks if it fails. 80 psi is pretty low pressure (typical narrow tires are 100-120) and the bottle itself is very low mass, so the fabric around the bottle should ensure safety if it bursts.

IIRC these came out in the early-mid 90s; a bike messenger trick at the time was to fasten the horn to your handlebars with velcro, so you could take it off and hold it near a car window when triggering it.

Look up the Osborne 1, the first "portable" (i.e. luggable) computer. They went out of business not only because they lost money on each unit, but because of how many they sold. Then they pre-announced their next model, which killed all demand for the existing one, and they were toast.

I don't actually get your point.

You dismissed the standard lock-guarded data structure as a "bogus comparison", despite it being the way every programmer is taught to write multi-threaded code.

Now the more you write, the more you seem to make the case that (a) normal programmers shouldn't be writing code like this, and (b) there are significant speedups possible if someone who knows what they're doing *does* write a highly tuned lock-free library.

It's not a "bogus and misleading baseline".

It's precisely the way we teach people how to build thread-safe systems. And we teach them to do it that way because we've learned from experience that letting them code up their own custom synchronization primitives leads to immense woe and suffering.

(and it's not slow because of the C++ mutex implementation, either - I tested a C/pthreads version, and it was the same speed as the C++ version)

What's not guaranteed for "normal" loads and stores on many architectures is the order in which writes become visible to other CPU cores.

That's what "lock-free" means. You still need to use the hardware mechanisms provided for atomicity.

The whole point of lock-free data structures and algorithms is that sometimes you can do better by using these atomic operations inside your own code, rather than using a one-size-fits-all mutex based on those same atomic operations.

(Note that I say "sometimes". Too many people believe that lock-free structures are always faster; as always, your mileage may vary. In this case it's a huge win, to the point where I would bet it almost always moves the bottleneck to the code actually using the ring buffer.)

I would point out that most products are useless, and either fail or replace other products which weren't any worse. None of which prevented me from cashing my paychecks for the first half of my career when I worked in private industry.

Most scientific research represents about the same amount of improvement over the state of the art as the shitty web app or whatever that you're working on right now. It's not zero, but very few are going to be groundbreaking. And since the rules are that we all have to publish papers[*], the scientific literature (at least in my field, CS) looks less like a carefully curated library of works by geniuses, and more like an Amazon or Etsy marketplace of ideas, where most are crappy.

[* just like software engineers have to write code, even if the product ends up being shitty or ultimately gets canceled]

Neither of us are going to be changing how the system works, so my advice is to deal with it.

Are there any factual allegations on that page? All I could find was "the method described in the paper is not the method the authors actually used", without any elaboration.

I'll add that the reaction of most of academia will be "It's in a management journal - of course it's nonsense."

90% of the power in our academic data center goes 13.8kV 3-phase -> 400v 3-phase, and then the machines run directly from one leg to neutral (230v). One transformer step, no UPS losses, and the server power supplies are more efficient at EU voltages.

But what about availability? If you ask most of our users whether they’d prefer 4 9s of availability or 10% more money to spend on CPUs, they choose the CPUs. We asked them.

There are a lot of availability-insensitive workloads in the commercial world, as well, like AI training. What matters in those cases is how much computing you get done by the end of the month, and for a fixed budget a UPS reduces this number.

I remember ordering parts from Digi-Key in 1980 or so when I was in high school. The catalog was less than 1/4 inch thick, and listed various surplus things on the back.

It was cool to see them grow into a real competitor for the big distributors.

Perhaps relevant to this - if you go to this global ranking of publications:

  https://traditional.leidenranking.com/ranking/2025/list

My Chinese colleagues have heard of it, but never considered it a top-ranked school, and a quick inspection of their CS faculty pages shows a distinct lack of PhDs from top-ranked Chinese or US schools. It's possible their math faculty is amazing, but I think it's more likely that something underhanded is going on...

If you're writing code professionally, then you're not in college anymore and your programs aren't simple things that run from the start of main() through to the end and then exit.

If you're providing a service that needs to keep running, you need a strategy for handling unexpected errors. It can be as simple as "fail the request" or "reboot the system", or more complicated. But you need to consider system requirements and the recovery strategy for meeting them when you're writing your code.

Long, long ago I worked with some engineers who thought it was just fine that our big piece of (prototype) telecom equipment took half an hour to boot because of poor choices on their part. Target availability for the device was 5 9s, which is 5 minutes of downtime per year. They didn't seem to realize the contradiction.

https://retractionwatch.com/2026/01/08/finance-professor-bri...

I've boycotted reviewing for Elsevier for years, but it's easy for me - I'm in CS, where ACM, USENIX and IEEE offer higher-status publication venues and Elsevier journals are decidedly second-tier.