Comment by freeli
1 day ago
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.
To me the funny part of this story is that they used to show you this warning as part of the EULA when installing Windows NT 4, which I remember joking about:
NOTE ON JAVA SUPPORT. THE PRODUCT MAY CONTAIN SUPPORT FOR PROGRAMS WRITTEN IN JAVA. JAVA TECHNOLOGY IS NOT FAULT TOLERANT AND IS NOT DESIGNED, MANUFACTURED, OR INTENDED FOR USE OR RESALE AS ONLINE CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF JAVA TECHNOLOGY COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE. Sun Microsystems, Inc. has contractually obligated Microsoft to make this disclaimer.
Also:
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.
It would take a whole lot more context to make this somehow comforting. :D
> It would take a whole lot more context to make this somehow comforting. :D
This is this fascinating 6 part documentary about the Chernobyl incident explaining how it was caused by bad control rods. But the main point is that control rods prevent the facility from going boom, so be glad it’s not the AmigaOS emulator on a NT machine handling it.
LOL at “Chernobyl accident was caused by bad control rods”. This seems to imply other control mechanisms worked, when in fact plant engineers could not even monitor the plant operations. They had malfunctioning Geiger counters. Also - plant engineers had no idea how much water was flowing through the nuclear core cooler. Monitors for the temperature of before mentioned water did not exist even on a whiteboard.
A friend works for an airline as a flight simulator tech. Their entire software stack, including the compiler and OS, is FAA-certified.
Then their ancient Honeywell(?) mainframes reached end-of-life they scouted for compatible hardware, of which there was none. The cost of certifying new software, plus the time involved, was astronomical. So, after consulting with the FAA, they paid a hardware company to clone the ancient mainframes in modern silicon. The FAA signed off on it, and they had all-new computers - much smaller than the originals - running the old stack.
It's _very_ hard to believe some company to simply "clone the mainframe" into chip. Mind sharing any link to this effort?
IBM released the PC XT/370[1], built around a pair of 68000s and an 8087 with custom microcode to emulate System/370 instructions, in 1983.
It's not hard to imagine a similar system fabricated around an open or licensed processor core today being well within the budget of a major airline today.
Software emulation would no doubt be less expensive, but there could have been regulatory reasons for building plug-compatible hardware.
[1] https://en.wikipedia.org/wiki/PC-based_IBM_mainframe-compati...
Custom chips aren't as expensive as you think. About a few million dollars for the design and a hundred thousand chips, way out of reach for a hobbyist, but accessible to large enough companies. Just because it's opaque to us software people doesn't mean it's not a real industry you can buy things from.
5 replies →
When Xerox established PARC, they asked the assembled scientists what computer they wanted. The majority view was a DEC PDP-10 KA10, with the BBN memory management unit that let it run Tenex (the ancestor of DEC TOPS-20). Xerox couldn't really buy a competitor's mainframe, so they built MAXC (maximum access computer), which was a complete emulation of the Tenex machines.
2 replies →
It could be an FPGA. Given enough gates, and the know-how to program them, you can make an FPGA emulate anything. Speed and efficiency could be better or worse, but if you're targeting old hardware, better is likely.
I mean...there's some precedent. The XKL TOAD ("Ten On A Desk") implements the PDP-10 instruction set, and will happily run TOPS-10/TOPS-20. LCM had one doing just that.
https://www.computerhistory.org/collections/catalog/10277383... https://www.twenex.org/?network
2 replies →
Meh, old architectures are relatively simple and you can get 95% of those via fpga softcores (some freely available, some paid) and run them on fpga. The rest can be implemented by a proper ee team.
That's interesting. That means there are fewer checks for hardware than software?
Hardware is more amenable to static analysis than running programs which may receive an arbitrary number of inputs and express an arbitrary number of possible intermediate states.
I am interested in how firmware is treated, since perhaps in the case of these old machines it's small enough to be analyzable or at least cloned bit-for-bit.
Software "engineers" like to abstract things. This doesn't pay well e with reliability.
1 reply →
>Then their ancient Honeywell(?) mainframes...
https://en.wikipedia.org/wiki/GE-600_series from the 36-bit era which turned out to be a sweet-spot for Lisp; also "famous" for running Multics (old joke flipped: "which was many of whatever unix is one of")
GE sold it's division to Honeywell, and from there to Group Bull (French) and then to NEC (Japan)
Also immortalized as the name of the "gecos" field in the UNIX passwd(5) file, described in the v7 man page[1] as "GCOS job number, box number, optional GCOS user-id" (GCOS = GECOS after the Honeywell acquisition).
[1] https://man.freebsd.org/cgi/man.cgi?query=passwd&apropos=0&s...
Moltix would have been a better name than OpenClaw.
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.
Even if VMs do not, whole-system emulators surely will.
But Windows 95 would be a poor choice, as you'd be stuck emulating a bunch of very specific aspects of both Windows (non-Unicode APIs, 16-bit application support, etc.) and the PC archictecture (BIOS, A20 gate, etc.) that exist only to maintain backwards compatibility.
If Windows is a requirement, you'd be better off building against something like the subset of Win32 APIs that has been stable since Windows Server 2003 and ideally testing against Wine, contributing patches as necessary.
If it were me, though, and it was something that required a general-purpose, non-realtime OS, and wasn't so performance-sensitive as to require deep integration with platform-specific APIs, my first thought is to target a Linux-compatible subset of FreeBSD, which should be enough to get you most of POSIX and then some, plus a full-featured GUI if necessary, portable between two open-source OSes that run on a wide variety of hardware.
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.
What is this industry, if I may ask?
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.
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 reply →
Lindy effect
> 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?
Some ideas:
Write it in a popular language/ecosystem, stick rigidly to well-defined APIs, use commodity hardware, flatten out any malignant cleverness, maintain documentation on why every part does the thing it does, and make the source code readily available.
This is based on working with some very old systems, and each point above is the opposite of something that made life harder.
Unfortunately, “popular language/ecosystem” includes JavaScript and PHP.
I’d go for “universal and timeless”, which has meant C for several decades now. There is, I’d concede, a reasonable chance that Rust obtains that label in our lifetimes.
2 replies →
The Amiga was a popular ecosystem.
4 replies →
Perl was popular
DOS emulation is available more widely than Win32 emulation, and there is HX DOS Extender. I would try sticking to Win32 dlls runnable in HX DOS Extender. rundll32 or some other exe host. HX DOS Extender has no paging support and has problem loading multiple exe having no relocation info to the very same 4Mb base address they all usually pretend. DLL should have relocation.
I thought "but what is the problem to generate EXE with relocation?" and tried GCC GNAT (from 2017), and GCC said no. EXE and DLL formats are very much the same, but GCC is completely unable to generate relocatable EXE. A very suprising discovery. More recent toolkits became aware that adding relocation to EXE is not a rocket science, just do the same like in DLL. But these recent toolkits may call APIs that HX DOS Extender does not support yet.
run for ~50 years where the hardware will need to be replaced
If it needs to run for fifty years, specify hardware that has a long support cycle such as Mil-Spec.
That’s why the Z80 was around for so long and why so many companies in the 80’s and 90’s still deigned around it. (1)
If you let programmers drive system design, winding up with an “Amiga” in your certified design is a more probable outcome…
(1) there’s a moderate chance that new hardware that can run Z80 code will be around fifty years from now.
> 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?
Make it open-source, or don't buy without source.
It's interesting to think about this in the context of parent poster's story about the Amiga emulator in the nuclear power plant.
Or, more broadly, in the context of any situation where the software is closely coupled to a specific operating system and/or hardware.
Having the source code would have helped tremendously, but might not have been sufficient because of the hardware story and the regulatory approval factor.
You don't need source anymore. Have Claude Code look at the binary and write a new program.
1 reply →
This was one of the promises of Java. You write your application and then you get a virtual machine (JVM). As time goes on you only maintain the virtual machine while the application remains the same.
The funny thing happened and verified this promise. There were several architects working on IBM System Object Model (SOM). In 1996-1997 many good things ended, and SOM was terminated. But the work was so good that two architects did not stop and wrote the book: Putting Metaclasses to Work (1998). That book has got reference implementation in Java. So we have IBM SOM as closed source binary and we have Java source codes.
IBM SOM executes on Windows 10. I have checked Visual Age for C++ Direct2SOM extensions, OpenDoc for Windows. Very good. 32-bit i386, but otherwise runnable, usable.
And Java is hard to build, hard to execute on modern Java toolkit. Java seemingly had no List, and authors made their own List, but when Java also got its List, that breaks the build. When building problems are resolved, runtime problems come. Original Java was seemingly fine with Property key being object, but modern Java only wants strings. And Property-based dictionaries are all around. PMtW is about building VMT, and there is multiple class inheritance in PMtW model, not matching Java's comparably limited OOP. So PMtW is building dictionaries for methods to support what is described in book, and foundational Java class is malfunctioning.
I did not finish this road, don't know so what does it take after all to run Java code from 1998 on modern Java toolkit. So far looks pathetic compared to Win32 programming.
> How does someone write software that needs to run for ~50 years
You in a lot of ways have to respect the ability to have done this in the first place, compared to todays slopware which manages to break within 1-2 mandatory OS update cycles.
Write it in C or Fortran.
I'd recommend not having it so dependent on the hardware and choose an OS that is relatively hardware agnostic (e.g. Linux). Also, ensure that the software is open source and if compiled, has an open source toolchain to do so.
Though people often decry it (due to the many, many footguns), writing something in Shell/BASH will make it trivial to move to newer machines.
Having worked on nuclear plants (as a reactor operator) around that time this doesn't surprise me in the least.
Thats far more advanced than the systems I worked with, one of which reported rod position via resistance measurement on a brushed cylinder (one for angular and one for depth).
Cleaning and calibrating those was a constant maintenance item every time the reactor was shut down.
I grew up in a little post soviet republic, in a small town with a big nuclear power plant.
Coincidently, that's where my father was working as a programmer until the shutdown of the plant.
Anyways, he was maintaining a bunch of systems related to collecting data from environment monitoring sensors around the plant. In mid 2000s or so he showed me some data collecting machines using what looked like DOS text UI that mentioned being written in Leningrad, 1989 or 1988.
The software was running in an emulator on Linux, which my father used to replace original x86-compatible machines runninh dos.
Pretty sure thr whole thing was running for quite a while since my family moved elsewhere.
Did they not need NRC recertification when they moved from a physical machine running AmigaOS to an AmigaOS emulator?
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.
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)
7 replies →
It is wild to me that you would use any GPOS for something like this instead of dedicated firmware for the task. This is evoking similar reactions to when I read articles about infrastructure being hacked remotely: Something must have taken a wrong turn with the architecture design for this to happen!
This reminds me of the apocryphal story of the IBM System/360 running a 1410 emulator that ran an IBM 705 simulator that ran a business-critical application.
Not wholly apocryphal. The U.K.'s air traffic control ran, and possibly still is running, on an IBM 4381 substituting for an IBM 9020.
* https://news.ycombinator.com/item?id=49763972
They've reportedly already tried, and failed, to replace it with a more modern system.
Which is why we should target VMs directly. Then that VM can be brought forward to new platforms rather than emulating the entire machine, not that emulating the entire machine is bad. One could argue that the emulation stack you outline was made possible by putting in the work to make simple, fully specified and documented hardware.
> A certain nuclear power plant had a Windows NT 4.0 machine running as late as 2007.
To put this in perspective, NT 4 was released in 1996, 11 years before 2007. That’s roughly the same as someone running Windows 10 today, which a lot of people still do. The Pentium 1 was only 14 years old at most. These parts of the system shouldn’t be surprising.
The AmigaOS and software from the 80s are of course the older more interesting bits, but for critical infrastructure and safety, shouldn’t we expect and design for our hardware and software to last a long time, and not try to keep up with tech fads every decade? I feel like the main problem isn’t hardware or software that’s old, but that there wasn’t a longevity plan.
It’s always been an interesting question how to write software that will last a hundred years. Maybe with AI this is the first time in history that planning to port & upgrade to new hardware every 5-10 years seems totally reasonable.
> That’s roughly the same as someone running Windows 10 today
While true the situation is different. Hardware and software moved a lot faster in the 90's and early 2000's. Everything has matured, is far more standardized, and moves more slowly now. Hardware from 11 years ago when Win10 was released isn't that different from today's hardware. Same goes for Win10 and Win11.
There might be a seed of truth there, but FWIW, I’m not very convinced by that. CPU speed development has slowed down a bit for sure, but software development is going faster than ever. GitHub and NPM and Python 3 and Rust all didn’t exist in 2007. CUDA was first released that year. LLMs weren’t being used. At the start of 2007, the latest Windows version was Windows 5, one more than Windows 4. Almost same as today. There isn’t a Windows 12 yet, while Windows 6 was released in 2007. So the pace of major Windows versions might be slightly slower. OTOH, the OS is much bigger than it used to be and it gets more frequent updates and point releases now than it did in 2007.
2 replies →
"Windows NT 4.0 machine running as late as 2007"
lol. I know a ... factory, that had a BBC model B (with a rather complicated wiring loom) still doing a job around that time.
The IT supplier at the same factory went to a museum in Cambs. around late '90s, early '00s to ask if they could buy an exhibit because something had failed locally. The museum gave them the part.
That was just aerospace and nothing fancy like your nuke plant!
NT4.0 in 2007? That wasn't even very late. I was replacing NT4 servers into the early 10s. Car dealerships were terrible for keeping that crap around.
I find it deeply upsetting that anything important for a nuclear power plant is using an OS without protected memory.
You don't need protected memory if your program is the only thing running. Plenty of microcontrollers have no protected memory and get used in safety critical applications.
Protected against what?
Bit flips from cosmic radiation. Pretty common.
1 reply →
Just another program poking memory it’s not supposed to. Not even necessarily maliciously.
3 replies →
Was this status indicator simple vertical bars that were black and white and displayed on an old CRT Monitor? Almost looks like black and white terminal vertical bars (like Alsamixer)?
Nothing wrong with this.
If it ain't broke, don't 'fix' it.
Just make sure that its well isolated from the Internet!!
I'm curious, how did the hardware present itself? It couldn't have been an Amiga Zorro card since it would've been impossible to get that into a PC. Did it connect over a serial or parallel port?
I recall it being some custom ISA card with connectors on the back. The emulation software had drivers that interfaced directly with the card.
Interesting! So they were able to port the hardware but not the software for whatever reason?
1 reply →
If it's still running I wonder what they are going to do about the year 2038.
Set the date back to 1980 and sticky tape over the corner of the screen where the date is displayed.
I wonder if there is push in the public sector for open source software/hardware for cases like this.
I completely get the decisions over time here, but it's unsettling having a relevant piece of software (reports are important too!) working on with parts from ebay, in 50 years time they might be gone.
I've dreamt of governments hiring devs with promises of full time OSS work. It _might_ get some people over the lower salaries of government work. But I overheard a state CIO once say "We configure, we don't create".
That's to say nothing about opinions of open source that rival early 2000s Microsoft.
For old ass critical software and hardware, the org can always have a backlog of hardware and contingency plans (paying someone to fix the hardware, paying someone to create a fully certified and modern solution..) for when they start running out of parts.
How on earth are these massive pieces of infrastructure relying on software they don't have the code to? i'm just utterly confused how these things happen.
>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.
Vernor Vinge's A Deepness in the Sky depicts a human society thousands of years in the future, in which pretty much all software has already been written; it's just a matter of finding it. So programmer-archaeologists search archives and run code on emulators in emulators in emulators as far back as needed. <https://web.archive.org/web/20231114211656/http://www.gareth...>
(Heck, recently I migrated a VM to its third hypervisor. It began as a physical machine a quarter century ago.)
This is crazy. Why on earth wouldn’t the respective government spend money to modernize a critical infrastructure like a nuclear power plant?
This is how we would end up with nuclear disasters, not because the technology is bad, but purely because of mismanagement and human negligence.
This is crazy. Why on earth wouldn’t the respective government spend money to modernize a critical infrastructure like a nuclear power plant?
Safety and reliability come from understanding the system. Something that's old but that you know everything about is far safer than something new. This risk is that the people who know move on, or the sources of replacement parts stop working, or that other things around the system change. Then the risk curve inverts and you find the old system more of a liability than a asset.
Almost always people choose to update things either too early or too late. Knowing when to do something is hard.
That’s pure negligence. It’s not like the people that have the know how disappear suddenly . It’s the responsibility of the management to make sure the knowledge transferred to new generation.
I guess that kind of thinking is what led to the collapse of ancient civilisations like why even bother to improve anything and let everything decay and die out
4 replies →
> This is how we would end up with nuclear disasters, not because the technology is bad, but purely because of mismanagement and human negligence.
I'm pretty sure constant upgrading would be more likely to cause disasters.
I can only imagine how much less reliable a modern JavaScript Electron app would be in this role...
If it's not broken, don't fix it.
Same reason why MTA in NYC still operates subway using 100 y/o signaling hardware on most of the lines.
In a way, your comment and the responses you get is a perfect allegory to inexperienced vs experienced engineering.
Their 100 y/o hardware is built from stuff that's still produced though. We still make relays (not identical ones but ones that perform the same function), wires, and mechanical levers. The system's behavior is not encoded in the relays but in the connections between them. If you had a CPU made of separate transistors you could replace burned out transistors with any future transistors but if you had one made of chips you'd need those exact chips that were out of production.
Replacing the relays in old telephone switches is a problem because they use so many weirdly specific types of relays - but those systems are only found in museums now. I believe track control uses fairly ordinary DPDT, etc., relay designs.
But similar reasoning is why Canadian trams are worse than other countries, and it's not "good experienced engineering". In this nearly hour long rant by NotJustBikes[1] the section I've linked is about the technology and how the transit authority will not move on from 100 year old track technology which makes everything worse for customers. There are junctions where tram drivers have to stop and look at the track to make sure the junction is correctly set because the single-point switching is less reliable than modern designs. Or the driver has to stop the tram and get out to use a stick to move the track and change the junction because they aren't electrified. And then pass through junctions as slowly as 10km/h because the old track design has higher risk of derailment than modern designs.
The designs for the electrified track switches were made by one company which was sold, re-sold, and then burned down and the designs lost, and there isn't anywhere else to buy them because nowhere else uses such old track design anymore, so not only is Toronto struggling to buy parts to continue electrifying the manual junctions, it's struggling to custom-make enough replacement parts to keep the aging electric switches working faster than they fail.
And they were using trolley poles to connect to the overhead power lines instead of Pantographs until 2017, 50-100 years after everywhere else, which meant a) they couldn't get enough power through them to run air conditioning, and b) they are more likely to fall off the power line and the tram stops and the driver has to get out and reconnect them, and c) their newer trams now have to have custom dual-power connections to go through older parts of the network, and d) the carbon shoes on the trolley poles wear out quicker which means the trams are dirtier and taken out of service for maintenance more often in the wet which is when people want to use trams more.
[1] https://youtu.be/HhQxNHrD6fA?t=2311
1 reply →
> If it's not broken, don't fix it.
I understand that way of thinking for a small business computer system. Not for a critical infrastructure. Also if people actually thought about like that we would still be in stone age, like why invent something new or use a new technology? Keep on using rocks to crack nuts and kill animals
2 replies →
A friend discovered that one of the more modern pieces of equipment instrumenting those old signals was an ancient WYSE terminal from the late 90s that had been bricked over during a station project.
They moved a booth or something and the compartment it was stuffed in was missed during the cleanout. The thing was working for at least 20 years and may still be there!
I worked with a client that had a cash disbursement system working on an ancient dBase 16-bit application. They had a very difficult to change process that required multiple transactions because the system couldn't represent the dollar amounts appropriately.
Lindy's law:
For non-perishable things - i.e technologies, ideas, books, institutions - the expected remaining lifespan is roughly proportional to how long they have already survived
Time acts as a filter: what has already withstood a long stretch of disorder is more robust, so the longer it lasts, the longer it is expected to last.
The old nuclear software running on mainframes have passed the test of time. The new software, has yet to.
Nassim Taleb talks about this at length in his book, Antifragile.
> Why on earth wouldn’t the respective government spend money to modernize a critical infrastructure like a nuclear power plant?
Same reason they don't modernize health care infrastructure. It's too expensive, people die if they get it wrong and they get voted out of office for their troubles.
Now you know why "nuclear power may have been dangerous in the past, but with modern technology it's completely safe and Chernobyl will never happen again" is not a good argument.
Chernobyl didn’t happen because of technological blunder or even human negligence. It happened because poverty caused by communism in Soviet Union had to use old outdated (not the modern nuclear technology at that time) graphite tips in carbon rods because it was cheap and also kept it as a secret from the facility operators giving them a false sense of trust on the kill switch.
Chernobyl is the perfect example to not use outdated old technology. Had they used the modern western technology at that time to upgrade their nuclear reactors the kill switch would have prevented the whole disaster instead of increasing the neutrons make the core a nuclear bomb.
Next time educate yourself with facts before making a fool out of yourself
4 replies →
Now you know why making arguments from 20 year old anecdata makes you look foolish
There is no reason a more modern system would be better in any aspect.
That must have been a crazy moment for you when you first saw it and a big sigh moment for whomever had to explain it to you the first time. Thanks for sharing this; it made me smile!