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.

Shout out to HL7 and its bastard offspring, FHIR!

Here's an example of the problem: https://www.hl7.org/fhir/patient.html That's the FHIR Patient Object. Seems reasonable? Look at the cardinality. Almost everything in that object is optional.

Open some of the field types, like Identifier: https://www.hl7.org/fhir/datatypes.html#Identifier

Yep that's right, everything is optional there too.

{active: true}

That's a valid FHIR Patient Object.

Unrelated to disks, but welcome to the world of MIL-STD.

Dump a hundred million dollars on a standard that's effectively meaningless.

Ten, twenty, thirty years later, we still don't know what "The Standard" means, but the checks spend just as good as any other, and now you have this whole industry of Standard Priesthoods who can read the entrails and make pronouncements. Priesthood's a solid career track, and now you need priests to check on the priesthood.

The number of people incentivized to look under the carpet, realizing the entire methodology of the Standard is, at best, incomplete? Take a guess.

We'll be circling this drain for a while yet, I imagine, until the stuff actually goes into combat against someone with the same types of toys. I'm not filled with confidence.

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…

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"

SCSI was great, it's too bad it never overtook PATA.

> 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.

Postel's law etc. etc.

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....

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.

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.

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.