I can't imagine the logic involved in "this is implemented, let's toss it in the dumpster" for that.

[1] - https://vosen.github.io/ZLUDA/blog/zludas-third-life/

But that was the original logic.

I also would be curious to see benchmarks for them on FBSD and Linux, because FBSD and Linux (the platforms at large) diverged in how they handle "disks", with FBSD opting for only character devices (unbuffered) and Linux only block devices (buffered).

Drives sometimes are worse at their internal error detection than you might hope, and might return incorrect bytes.

You might have faulty hardware flipping bits between when you computed a checksum/parity/etc over your data and when you wrote it out, either in memory, or over the wire.

You might have a software bug or an interaction with a hardware erratum that causes the CPU to misbehave and mangle your bits in certain cases, maybe around switching from running code in a VM to not and back.

You might have had, say, the Samsung HD204UI hard drive, which loses data after it tells the OS that it's written because of a bug around its write cache, so you get no error back, but you go to read the data back later and it's actually whatever was there before you tried overwriting it.

SSDs, NVMe and otherwise, _can_ fail in ways that aren't just vanishing from the bus, it's just much less common than with mechanical drives, IME. I have sometimes seen SSDs return incorrect bytes inconsistently or consistently, or start spitting up read/write errors rather than entirely vanishing from the bus.

Each of the above examples is a real thing I saw happen. None of them is particularly likely, plenty of people never have dumb shit like any of that come up. But it's not never.

- serving a bunch of storage as a blob is a common use case for e.g. iSCSI exporting, and so, if you want to be able to zfs snapshot/send/rollback/etc on the level of "one logical disk", it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance

- avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage

Of course, in the era where you're sad that inline compression/checksum/etc are bottlenecking your 48 NVMe pool, that probably isn't where you'd reach for optimizing first...or second...

But just exposing the block storage is sufficiently useful that at least one of the original projects to port ZFS on Linux wasn't planning to implement the FS layer, they just wanted block storage for Lustre.

The comment in [1] also outlines a bunch of reasons it's extremely difficult to break into.

[1] - https://news.ycombinator.com/item?id=48452308

(3) the contrapositive, where you continued the flight, it really was someone stupid enough to name the broadcast name of a bomb "BOMB", it goes off, and now you have to explain to the press "we thought nobody would be stupid enough to really name it 'BOMB'"

So you assume it's a low risk event, and tell everyone onboard to turn off their devices to remove the chance it's just someone making a bad joke or a coincidence, and then you end up with the outcome of trying to avoid having to say that in a press conference where everyone is already primed to think you didn't do enough.

There's nuance, of course, with people who are worse off in America seeing some cracks in it, but that's how you get the idiom about "Americans vote like temporarily inconvenienced millionaires" - they are so convinced the game isn't rigged against them that they vote assuming they will win at the casino one day.

IOW, "there is probably very little stopping you except time from having written Coccinelle patches to mechanically do most of these transformations".

If you needed an old piece of code at $WORK, you probably already paid the tax of refreshing it or replacing it.

This sort of task is similar in nature to something like "I have a 25yo unmaintained Linux driver, let's refresh it for modern Linux" - a great demonstration of the efficacy of these tools if you have the right-shaped task, but not a task that comes up repeatedly in most people's days.

They exist in other formats too - blogs in the vein of "for exposure" cover the same premise, mostly.

Vibe coding has allowed them all to try and show everyone how right they were.

I've been trying to use it for a massive tree of ~250k files across ~500k folders, which only needs to live on one device at a time and sync to a backup in case it dies, and even if I tell it send-only/receive-only explicitly, it regularly seems to go cross-eyed at some change made in the folder structure and give up and rescan and hash everything, and if anything in the tree changes while that's happening, it gives up and just marks it a conflict to be manually resolved...or silently hangs until I restart it.

God knows if they'll end up scaling back their goals, but the vision isn't "just" a few custom integrations.

This also feels like the target market is people who said they dangled this off an RPi-alike to do something that the microcontroller simply did not have the processing to do.

You want to land a substantial amount of, ahem, shit in there, since don't just want it to colonize one portion of the gut, and it's got quite a lot of competition.

So you would be talking a truly astonishing number of pills, I think, to compare to the volume you can manage with a tube.

WP suggests that it's about 100g (or 100000mg) of actual feces then mixed in a larger volume of saline or milk, and you'd probably need to have additional volume for assumed losses and whatever coating you think would work.

That is a _huge_ amount to put in pills.

One of the most annoying ones combined these two properties, so depending on various internal races, typing a four letter word would either open one program, the folder that program was installed in (!?), or attempt to Bing the common word

If I hit Winkey and type a string, it should not be the case that I get different results from doing that 6 times in a row because it depends whether some background task which changes the results finishes first.

I understand this is more the primitive that you would build such a thing on top of, just that the first question I always have for novel compressors is "how do they do on these example streams of data".

I think the parent's assumption is that 16 is old enough for those problems to be largely avoided even if you gave them unfiltered access, which is what makes it not just kicking the can down the road.