> Porting all of that to support ipv6 can easily be a multi-year project.
FWIW, as someone who has done exactly this in a megacorp (sloshing through homebrew technical debt with 32-bit assumptions baked in), the initial wave to get the most important systems working was measured in person-months. The long tail was a slog, of course, but it's not an all-or-nothing proposition.
Yeah, “Purely Functional Data Structures” came out in 1996! I read most of it recently, when I needed a C++ copy-on-write hash map. It was still fairly relevant (although the “obvious” solution of a HAMT was also the one we decided on).
Good thing all disks these days have data checksums, then!
(50TB+ on ext4 and xfs, and no, no bit rot. Yes, I've checked most of it against separate sha256sum files now and then. As long as you have ECC RAM, disks just magically corrupting your data is largely a myth.)
Less mythic on SSDs than spinning rust, in my experience.
Not particularly frequent either way, but I have absolutely had models of SSDs where it became clear after a few months of use that a significant fraction of them appeared to be corrupting their internal state and serving incorrect data back to the host, leading to errors and panics.
(_usually_ this was accompanied by read or write errors. But _usually_ is notable when you've spent some time trying to figure out if the times it didn't were a different problem or the same problem but silent.)
There was also the notorious case with certain Samsung spinning rust and dropping data in their write cache if you issued SMART requests...
I remember moving there, hearing talks about how international Zurich was, and then realizing most of those foreigners were German. :-) It's diverse on paper (and probably to the Swiss), but it's not like it's a cosmopolitan melting pot.
Most immigration happens between neighboring countries e.g. the biggest immigrant group in Los Angeles are Mexicans.
If you exclude neighboring countries Zurich has a foreign born population share of 27% (compared to 18% of Los Angeles). If you only look at the last 10 years Zurich has foreign born non neighboring immigration of 10% (compared to 4% for Los Angeles).
If you only look at intercontinental migration then Los Angeles wins with 14% (compared to 8% of Zurich).
So yes Zurich is less cosmopolitan then LA, but most of it is just because the US has more diverse neighbors.
I don't have my stuff on GitHub, but git push will send me email with a patch. I actually get real, useful patches out of it (more than before I had only email); not huge stuff, but scratching people's itches and bugs; stuff I can mostly just apply right away. I never get pure junk (e.g. the “I'm sure you want to switch to My Favorite Build System” patches, or AI slop). So somehow, for me, this is pretty much the perfect level of friction, it seems.
I find Meson's --help fairly useful, at least compared to the disaster that is CMake's. (Try to find out, as a user not experienced with either, how you'd make a debug build.) I agree that configure --help is more useful for surfacing project-specific options, though.
At least they know who to cite, even if they don't. I like to have a diffusion model generate an image of my desired subject in whatever media I choose then look at it as make something close but not quite the same. I'm copying tons of people I don't even know. But I am also just practicing and don't try to pass it off as my own creation.
> if there are problems, they will eventually come to light anyway
Not necessarily; before Kyle started this one-man crusade against data loss, database vendors would claim generally whatever and it would go unchallenged for decades. (You might get the occasional bug report, which you could handwave away as “hardware” or “you're holding it wrong” or just ignore it.) Now you're _slightly_ less likely to succeed, but only as long as e.g. your product is sufficiently uninteresting or hard enough to set up that he doesn't test it. :-)
xz is generally slower-but-more-dense; it's not meant to be a full gzip replacement. Zstd, on the other hand, aims to be a “better gzip”, in that it's compresses about as fast as gzip but packs somewhat denser (and decompresses faster).
FWIW, as someone who has done exactly this in a megacorp (sloshing through homebrew technical debt with 32-bit assumptions baked in), the initial wave to get the most important systems working was measured in person-months. The long tail was a slog, of course, but it's not an all-or-nothing proposition.
reply