pjdesno

My take on hard drive economics is that the cost of an HDD is relatively constant, modulo the platter count, while capacity increases over time, as the components are pretty much the same in each generation.

There's one exception to this - HAMR added additional components, and a corresponding increase in BOM cost, but there's probably a learning curve on this.

However the recent AI data center boom is probably hitting HDDs in two ways - (a) general demand for anything datacenter-related, and (b) high DRAM prices, with most HDDs containing 256-512MB of DDR3. (I haven't physically examined the newest drives - they may be DDR4 and go beyond 512MB; also the 40TB supposedly includes NAND flash, adding yet more cost)

What kind of vehicle takes 10 quarts of oil for a single oil change?

I wonder if faster SSDs would help?

In particular you can still get used Optane SSDs on eBay, although they’re fairly pricey. (not the bogus m.2 ones that are slower than a halfway decent consumer NVMe)

What he said.

I was a VMware workstation user in the late 90s.

I worked on the VMware monitor team back in 2007-2008, which probably put my employee number way in the 1000s. Ole Agesen, Carl Waldspurger, and other early folks were still there.

Back then "kvm" meant a remote keyboard/video/mouse device. Linux kvm was announced in 2006, and released in 2007, and required hardware virtualization, which was first released with AMD Pacifica in 2006. Back then VMware's binary translation was locked up in patents, so in the free software world we had Xen, colinux, and other hacks.

There's an interesting comparison to HyperCard, which didn't have the intellectual scaffolding of Xanadu, but just worked, even on a typical Mac of the day with 1MB of RAM.

For those of us who have just been using Emacs, rather than following its recent evolution, "ts-mode" refers to a mode which uses tree-sitter for parsing, highlighting etc.

I think we're all talking about CEOs with business degrees, who subscribe to the Jack Welsh school of domain-knowledge-free corporate leadership.

and this is why you don't want tech people designing user interfaces...

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

The key word here is "historically". Modern data centers typically have a PUE lower than 1.2, with the .2 including not only energy spent on cooling but power distribution losses as well.

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.