‹ BackHN Continuity

Thread

Ask HN: Who's still keeping a DOS machine up because the business depends on it?

297 points · 304 comments · mlaux

  1. freeli · · 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. throwaway2037 · · focus · HN ↗
      This is a great post. How does someone write software that needs to run for ~50 years where the hardware will need to be replaced with non-equivalent, newer hardware? If I were facing this issue today, I might start with an OS that has excellent emulation. Example: Can I run 32-bit MS Windows 95 via emulation on a variety of current 64-bit OSes, like MS Windows, Linux, AIX, HP-UX, etc. If yes, then we can assume(?) this emulation will remain relatively stable even if we upgrade our hardware later. Maybe I am overthinking the whole problem: Can VMs do exactly what I want today? Will VMs running ancient OSes, such as 32-bit MS Windows 95, continue to be stable/viable in the future? I am unsure.
      1. ninalanyon · · focus · HN ↗
        Make sure that you have as thorough a specification of what the system is supposed to do as you can.

        Then define the version control system and the build process, specifying the dependencies, and so on.

        Think about any opaque blobs in the system and try to eliminate them so that you have plain text source code so that no tools are needed to read the code.

        Make sure that the build process runs entirely locally and never fetches anything from outside.

        Simplify everything, use only tools and languages that are well understood and supported.

        The real problems are not strictly technical but social: how do you prevent loss of the code, the tools, the specification, how do you maintain the expertise needed to maintain it. How do you ensure that all those things that are obvious to you now are written down in all their gory detail so that your great grandchildren will not apply their new and different preconceived ideas to the system?

        Document all this on paper as well as electronic storage, make sure that version ids are recorded on every page as well as being available to the user of the machine or program.

        In the industry in which I worked for the last thirty years of my career it was not uncommon to have things come back for repair after fifty years use and to be able to consult the original drawings and bill of materials so that exact replacement parts could be made.

        1. rrr_oh_man · · focus · HN ↗
          What is this industry, if I may ask?
          1. ninalanyon · · focus · HN ↗
            Electricity distribution, mainly transformers from 10 kVA to 500 MVA and more.

            It takes a long time to design and a lot of material to make a big transformer and they last for decades. They are critical infrastructure so when one fails you want it replaced or repaired quickly but they are too expensive (millions of dollars/pounds/euros) to keep a spare unit idle for decades and the lead time for a new large power transformer might be six months or even longer. So repair makes sense, especially if it can be done on site because moving a big metal box full of oil, steel, and copper that weighs hundreds of tonnes is a major logistical exercise.

            This isn't something that can be done by a company that 'moves fast and breaks things' and disappears next year.

            1. throwaway2037 · · focus · HN ↗
              Hat tip for the first hand details. I sound like a broken record at this point: Posts like make are the secret sauce of HN. It is the main reason why I come back time and time again.

              There must be some extremely salty machinists that get bizarre part requests after breakage for some transformer from 1950. That could make a very cool YouTube video series: Following these machinists and repair people as their repair very old transformers.

              1. ninalanyon · · focus · HN ↗
                Transformers are pretty simple machines, no moving parts so there aren't all that many complicated bits except in the tap changer. But what is there has to be just right and a lot of the critical details are made of paper.

                But of course many such transformers are connected to equally old generators and they are a bit more challenging as far as making replacement parts is concerned, huge turbines for instance.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.