Readit News[Edit: yeah, yeah, forgot the Tom Hanks movie, sue me. I do wish folks would respond to the much more important point below, which isn't invalidated by a single data point though.]
Constructing solutions for multiple-mode failures like this is a bad engineering smell. Almost always the solution isn't actually helping anything, and often makes things worse in whatever metric you're looking at. In the example here, having four engines makes the chances of total thrust loss lower, but it doubles the chance of a single engine failure. And the literature is filled with incidents of theoretically-survivable single engine failures that led to hull loss as a proximate cause (generally by confusing or panicking the crew).
Basically 99% of the time, card corruption has nothing to do with the microSD card in question and more to do with the quality of your power supply.
My personal feeling is the write patterns of Linux distros and filesystems are way more punishing to the card when compared to write patterns done other use cases. For example most writes done by digital cameras are fairly big and sequential, and done on FAT/exFAT where there is no journalling.
They way they're trying to solve it is very similar to this article, by doing the USB-PD negotiation during U-boot bootloader stage:
- https://gitlab.collabora.com/hardware-enablement/rockchip-35...
- https://lore.kernel.org/u-boot/20241015152719.88678-1-sebast...
Come back when you have millions of lines of code, written over decades by hundreds (or thousands) of full time developers.
Let's take for example a service 'foobar' that depends on in-house library 'libfoo'. And now you need to add a feature to foobar that needs some changes to libfoo at same time (and for extra fun let's say those changes will break some other users of libfoo). Of course during development you want to run pipelines for both libfoo and foobar.
In such 'super module' system it gets pretty annoying to push changes for testing in CI when every change to either libfoo or foobar needs to be followed by a commit to the super repo.
In a monorepo that's just another Tuesday.