[HN Gopher] Vague Standards Are Trouble
       ___________________________________________________________________
        
       Vague Standards Are Trouble
        
       Author : kencausey
       Score  : 59 points
       Date   : 2022-04-08 16:30 UTC (2 days ago)
        
 (HTM) web link (www.os2museum.com)
 (TXT) w3m dump (www.os2museum.com)
        
       | jchw wrote:
       | I believe I may have run into this issue trying to get an old IDE
       | hard drive from a NEC PC-9800 computer to load elsewhere.
       | Truthfully, I had more issues than just the capacity being
       | terribly wrong, but I bet that does explain how that happened.
       | 
       | I wonder if then, there is a particularly good IDE controller for
       | this use...
        
       | RedShift1 wrote:
       | I don't think the standard was vague... It just didn't describe
       | how to transfer a double word. So instead of the standard being
       | vague, I see it as the drives violating the at that time current
       | ATA spec.
        
         | Kwpolska wrote:
         | > I see it as the drives violating the at that time current ATA
         | spec.
         | 
         | How are they violating the spec if
         | 
         | > It just didn't describe how to transfer a double word.
         | 
         | The standard was vague, because it specified (a) there is a
         | double-word value, and (b) communication goes over a single-
         | word data bus, but not (c) how to transfer the double-word
         | value over the single-word data bus, leading to drive
         | manufacturers pick the way they liked the most.
        
       | rep_lodsb wrote:
       | The IDENTIFY command also returns some strings for the
       | manufacturer/drive id, which are defined as having the first/even
       | character in bits 15:8. Stored in memory on a little-endian
       | system, "TOSHIBA " becomes "OTHSBI A".
       | 
       | So it kind of made sense to think IDE was big-endian, because
       | that would at least be consistent.
        
       | prionassembly wrote:
       | Postel's law etc. etc.
        
         | marcosdumay wrote:
         | And all the problems it creates.
         | 
         | But then, if your standard is broken, living with the problems
         | caused by Postel's law is much easier than with the problems
         | caused by not following it.
        
         | Findecanor wrote:
         | In the case of binary formats, the application of Postel's
         | "Law" is in practice only a workaround, used when there existed
         | multiple different interpretations of a vague standard. If the
         | standard had been defined properly in the first place,
         | workarounds wouldn't have been needed.
         | 
         | I've seen Postel's Law being made official recommendation even
         | -- in an addendum document to a standard. The addendum got
         | published only because the situation had become a mess.
        
         | pmarreck wrote:
         | which has had some backlash of late? it seems that one should
         | not be liberal in any capacity because it results in undetected
         | corner-cases
         | 
         | https://ardalis.com/postels-law-robustness-principle/
         | 
         | https://tools.ietf.org/id/draft-thomson-postel-was-wrong-03....
        
           | l0b0 wrote:
           | Postel's law is for when it's hopeless to get to a sane
           | standard in the near-to-mid term, as with HTML and JS back in
           | the day. Browsers had to implement ridiculously lenient
           | parsing to provide a reasonable user experience on top of
           | terrible markup and scripts.
        
       | h2odragon wrote:
       | I don't recall how long it was; but there was a period there
       | where we avoided "IDE" as too new and not standardized yet. I
       | wanna say 80MB drives to about 500MB, thereabouts. The last
       | period of time when people bought copies of "SpinRite"
        
       ___________________________________________________________________
       (page generated 2022-04-10 23:02 UTC)