Works well, in my experience. Sometimes the agent does weird stuff that you have to rewrite, but I get the sense that this happens in any language.

Maybe Haskell’s training set is not large enough, but it seems to work despite the smaller training set.

The way I would go is by saying that you multiply the number of objects by AFR, and that’s close to the actual losses on most years. You can then exclude WW3 and the late holocene extinction event from your consideration. Or simple bankruptcy, for that matter. If your employer is gone, you don’t care about its data any more.

Durability is a knob. If you have enough data, or turn the knob too far in the direction of durability, you will simply bankrupt yourself or maybe drown your service in latency. It makes sense that you would have storage services that provide different levels of durability.

AFRs and discussions about different failure scenarios are the bare minimum. The bare minimum for scenarios is disk loss, total machine loss, and data center loss. This is just my take on things. I don’t care if something is on disk or not. I do care what happens when a sector on disk goes bad, when a faulty power supply destroys all the disks in a machine, or when a data center floods.

That forces you to think about things like whether you want to turn on synchronous replication.

Even if you just look at hardware failure rates, you get unrecoverable I/O errors (data corruption) at about one in 10^15 bits, disk failures at a rate of about 1% per year, etc. People usually like to have better guarantees than those numbers give you with just a plain fsync anyway; so you are probably forced to do an analysis of the whole system if you want to provide good durability guarantees and be able to explain where the guarantees come from.

> In talking to engineering management across tech industry heavy-weights, it's apparent that software engineering is starting to split people into two nebulous groups:

> The first group will use A.I. to remove drudgery, move faster, and spend more time on the parts of the job that actually matter i.e. framing problems, making tradeoffs, spotting risks, creating clarity, and producing original insight.

My guess is that significantly fewer people use drugs than would have used drugs if they were not banned.

> "The Crime Survey for England and Wales (CSEW) estimated that 8.7% of people aged 16 to 59 years (around 2.9 million people) reported using any drug in the last 12 months for the year ending (YE) March 2025; there was no statistically significant change compared with YE March 2024"

Are there some significant changes to policy during that time period? I don’t see how this factoid is related to whatever argument you are trying to make.

I may be a little out of touch here, because the last time I did this, we used a wholly custom package manager.

I don’t mind being somewhat behind, but it seems like there are a lot of packages that don’t get regular updates. It’s okay to have packages that aren’t updated, but those packages should be clearly distinguishable.

NOT how demos work in Quake. It’s more like Quake uses a client/server architecture, and the demo is a capture of the messages.

https://www.gamers.org/dEngine/quake/Qdem/dem-1.0.2.html

I’ve been at a couple companies where somebody tried putting an S3 interface in front of an NFS cluster. In practice, the semantics of S3 and NFS are different enough that I’ve had to then deal with software failures. Software designed to work with S3 is designed to work with S3 semantics and S3 performance. Hook it up to an S3 API on what is otherwise an NFS server and you can get problems.

“You can get replication with RAID” is technically true, but it’s just not good enough in most NFS systems. S3 style replication keeps files available in spite of multiple node failures.

The problems I’m talking about arise because when you use an S3-compatible API on your NFS system, it’s often true that you’re rolling the dice with three different vendors—you have the storage appliance vendor, you have the vendor for the software talking to S3, and you have Amazon who wrote the S3 client libraries. It’s kind of a nightmare of compatibility problems in my experience. Amazon changes how the S3 client library works, the change wasn’t tested against the storage vendor’s implementation, and boom, things stop working. But your first call is to the application vendor, and they are completely unfamiliar with your storage appliance. :-(

There are usually some fixed costs involved and you need cash flow. Without cash flow, your business can shut down pretty damn fast. With cash flow, your business can stay around longer, maybe long enough for the economics to shift.

This sort of thing happens with oil. There are oil producers which sell at a loss. There was even a brief moment when the price of an oil barrel went negative, which meant that if you gave somebody a barrel of oil, you had to pay them for the privilege of taking that oil off your hands. Oil producers did not all shut down when that happened.

I am a little doubtful of the $19k figure anyway.

> It would actually make more sense to sell all their bitcoin, flood the market with coins to do the price, wait for large miners to collapse and then restart mining at hopefully lower prices.

This kind of market manipulation is not so straightforward.

I think I want this at the bottom of the article, “Words are my own; spell checking and grammar tools probably had AI.”

I do wonder what the exact reasons were. Maybe the PPC (complete systems) could be made cheaper? Maybe Apple was worried about relying on a single vendor? I am kind of skeptical of the “corporate dealmaking” angle, because it seems like there are valid technical reasons to NOT choose the 88K. Namely, that it requires companion chips, and the whole system (board + chips) ends up being complicated and expensive.