alt Hacker NewsThis 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.
Replies
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.
> 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.
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.
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.
> 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.
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.