Thread

1. freeli · 1790375986 · focus · HN ↗

   A certain nuclear power plant had a Windows NT 4.0 machine running as late as 2007. The reason is interesting.

   The machine's purpose was to report status of the control rods that mitigate nuclear reactions. Basically, "are the rods inserted, and if so, how many / how far?". I want to emphasize that this was reporting only, NOT control.

   The original software was written back in the 80's, when the plant was originally commissioned, for AmigaOS. Of course, it's hard to buy Amigas anymore, and the original one died long ago (nobody remembers when).

   So in the mid '90s, the utility purchased an AmigaOS emulator that ran on Windows NT 4.0, which was current at the time. The emulator (IIRC) was developed by a firm in the UK. The firm went out of business sometime in the late '90s. The control rod monitoring software ran under this emulator on top of NT4.

   Windows NT 4.0 was the last OS to allow the emulation software direct access to the physical hardware that produced the status signal. Later versions of Windows abstracted the hardware access away, and the monitoring software broke. Because the emulation company had gone belly up, there was no way to fix the incompatibility.

   So the utility had a choice: get new hardware/software certified (by NRC?), or keep doing what they were doing with the software (and hardware) that they had. They chose the latter.

   So this is how, in 2007, during a tour of the facility, I stumbled across a Pentium 1 system running an AmigaOS emulator on Windows NT 4.0 that was responsible for displaying the status of the control rods of a nuclear power plant.

   Spare hardware for this setup was purchased off of eBay and stocked on an adjacent shelf.

   1. kccqzy · 1790376866 · focus · HN ↗

      Did they not need NRC recertification when they moved from a physical machine running AmigaOS to an AmigaOS emulator?

      1. freeli · 1790377146 · focus · HN ↗

         That is an advanced question best asked of the folks in charge of the plant. At the time I was just trying to figure out how to explain to the IT auditors why there was no antivirus software on this piece of crap.

         1. CursedSilicon · 1790384308 · focus · HN ↗

            Could you skirt around it and just remark "there are no viruses for AmigaOS"

            (Probably not literally true. But functionally true in the sense that they were likely transmitted via infected floppy disks, of which there'd be virtually none left in the wild in 2007)

            1. rcxdude · 1790422404 · focus · HN ↗

               Depends. A lot of these audits are quite prescriptive and don't leave much room for actually thinking about the problem. There is often some kind of mechanism for 'this is sufficiently segregated it doesn't matter that it's utterly out of date' but then usually some awkward rules develop that prevent some things from being put into that category. More subtly you can get whether the thing even exists as a thing that the audit cares about, and that often depends on the framing (embedded software is often invisible here but it needs to not look too much like a general-purpose OS even though it often is).

               (Also, in my experience, what the auditors think the rules are and what is written down can often be divergent and even contradictory)

               1. rrr_oh_man · 1790444719 · focus · HN ↗

                  > Also, in my experience, what the auditors think the rules are and what is written down can often be divergent and even contradictory

                  Sounds interesting, could you elaborate?

                  1. rcxdude · 1790474454 · focus · HN ↗

                     This is pretty universal in my experience any time you have inspectors/auditors intended to enforce a set of rules. The most common case is that they just miss some rule: they can be hard to properly map from what you're seeing to the rules reliably, so different auditors will miss different things (so you can get a sign off from one and then another highlights an actual contradiction).

                     The next level is that the rules are kind of vague or unclear and so different auditors will have different interpretation of it. You can try to fight it but ultimately the auditor is who needs to sign off on it. This is also why switching auditors can be a right pain.

                     Then you get interpretations which are flat out contradicted by the rules. Sometimes this is necessary to make the rules work (there's some blanket rule that's impractical to impossible to apply literally, so the auditors contort some interpretation that's more workable), sometimes it's just incompetence, and when it's wrong enough to matter sometimes it's easier to just go along with it than try to escalate the issue with the auditor.

                     You can also get situations where the auditor has their own pet rules, which aren't written down anywhere, but they will become much more adversarial if they are not followed (sometimes they'll outright tell you what they are, sometimes it's a guessing game).

Unofficial Hacker News client; not affiliated with Y Combinator.