Holy resurrected 90's USENET wars, Batman! It's important that people realize here that the software we're talking about is not "Linux" as it exists in the tre

Holy resurrected 90's USENET wars, Batman! It's important that people realize here that the software we're talking about is not "Linux" as it exists in the tree today, or even any time over the last 20 years. It's Linux of the mid-90's, when the Zeitgeist of the system was a mad rush to reach feature parity with commercial unix on commodity PC hardware that failed all the time anyway[1]. No one wants to hold up ext2 as a paragon of software quality. But in practice in the mid-90's, it worked just as well as its competitors on the hardware where it was deployed, and quite frankly was much faster. It won for some pretty obvious reasons, and was compatibly replaced over the years with evolved versions that have all the features anyone wanted. [1] Notably here: at that point it was routine to find IDE drives with large multi-track buffers. Almost none of this hardware did any of the write ordering magic[2] internally, nor did the protocol provide a way to distinguish "on disk" from "in drive RAM". The problem wasn't solvable in the regime where the software was being deployed. [2] Which IMHO was oversold by the BSD people even at the time. Contrary to the way it's presented, the Berkeley Fast File System was absolutely not reliable in the face of power loss in the way that modern journaled filesystems are. It had to fsck on boot and deal with metadata corruption too, it was just much better about it.