6 ms·

> In Linux, ext2 was incredibly sloppy about how it handled write ordering --- it didn't do anything at all. But as a consequence we developed tools that were

• harshreality 4y ago
  As he mentions, unless you disabled the hdd's write-back cache, you had to deal with the same class of write-ordering problems anyway.
  • j1elo 4y ago
    Yeah it seems that the kind of brute force or less than ideal software-engineering style of ext2 was a perfect match for the kind of hardware qualities (i.e. very low ones) that were the target! In the end everything ended up working better, even if due to completely accidental reasons.
    • tankenmate 4y ago
      Or maybe the decisions were a form of emergent behaviour; the developers that succeeded were the ones whose behaviour best matched the environment. The accidents ARE the reason it worked; i.e. evolution.
      • lifeisstillgood 4y ago
        Thank you - insightful :-) Perhaps that's the reason why a market succeeds under schumpeter but a planned economy (ie inside a large company) often fails
        • fidgewidge 4y ago
          Yeah once you start thinking in evolutionary terms you see it everywhere. Like why do we have this discussion via interactive documents? The web has a sort of evolutionary fitness that lucked its way into being a popular app platform.
• kqr 4y ago
  "Worse is better" has a very specific (counter-intuitive) meaning. It does not purport to be better in the sense you're thinking about it. The "better" is in the sense of "has an easier time gaining widespread adoption because the few things it does promise to do it does very reliably and it is quick to go to market".
  • moloch-hai 4y ago
    "Worse is better" never had such a defensibly coherent meaning. There were gestures toward one, enough to fool people, but it mainly amounted to dressed-up sour grapes: "We would have won if not for those meddling kids!" The fact is, Unix (and then Linux) was strictly better at the things people wanted to do, full stop.
• ajross 4y ago
  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.