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. throwaway2037 · 1790419792 · 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. pianopatrick · 1790444303 · focus · HN ↗

         Wasn't there some idea that went like "if something has been around for x years, it will likely be around for x more years"?

         Maybe follow that. It's 2026 right now. What way of writing code would have worked 50 years ago (1976) that still works today?

         Well, C, SQL and Lisp were all around 50 years ago and still exist today.

         In terms of hardware, 50 years ago there was intel 8080. apparently code for that can still work via emulation today.

         So if you wrote C for low level, Lisp for high level, and compiled the software to run in an Intel 8080 emulator, that combo would likely still work in 50 years.

         1. veqq · 1790446152 · focus · HN ↗

            Lindy effect
         2. OCTAGRAM · 1790463009 · focus · HN ↗

            C is very different C. There is C where programmer rushes to call fork(), just because he likes the idea of entering room once and exiting room twice. And this program has got excuse for his behavior. He has fork() in POSIX standard. So programming is using fork() here and there even if not strictly needed. Using fork()/exec() instead of more portable posix_spawn(). Using fork()/accept() instead of multithreading.

            Then it becomes impossible to introduce database connection pool. Well, probably possible, but in single-process multithread server this is BSc grade job, and in multi-process server this is PhD grade job. libmysqlserver and others maintain some context near to the socket, in opaque way. Hard to pass context between processes. At least, hard to return used connection back to pool in main process. Proxy is also not an easy walk.

            On client side although Windows NT had POSIX layer, and XP/2003 still had Interix SFU. But Windows Vista broke SFU. But then Vista has got SUA. But SUA was not binary compatible, required recompilation. And as of Windows 10 there was surely no SUA. Was it dropped in Windows 8? Windows 10 has got WSL eventually, but there was a gap between SUA and WSL. And deploying Windows application with SFU, SUA or WSL part is not easy walk. Writing installer is MSc grade job.

            Then comes iPhone OS and Android. They are POSIX OSes. Kind of. But spawning external processes is prohibited or not desirable. This is what was blocking LaTeX adoption on mobiles.

            1. pianopatrick · 1790464967 · focus · HN ↗

               Well I think if you were doing the 1976 way you might not even have multi processing or multi threading. Just a single process with a single thread. And so you don't have a database connection pool, you just have a single database connection and do one query at a time maybe.

               That may not work for network connected software with lots of requests per second. But such software did not exist too much in 1976 either as there was not very much networking going on.

               1. jasomill · 1790471047 · focus · HN ↗

                  There were absolutely multiuser computer systems processing transactions from thousands of users in 1976.

                  As for networking, both the ARPANET and Ethernet predate 1976, though neither were ubiqutitous and most high-volume networking would have been mainframes and related hardware connected via leased lines.

Unofficial Hacker News client; not affiliated with Y Combinator.