
Writing Software to Last 50 Years - signa11
https://bytes.yingw787.com/posts/2020/01/13/50years/
======
grumpy-cowboy
Text files are king! I store every single byte I can in text files. Examples:

    
    
      - Tabular data     : TSV   (almost all Un*x/GNU tools handle this out of the box)
      - Simple "records" : GNU Recutils format (https://www.gnu.org/software/recutils/)
      - Formatted texts  : Markdown, LaTeX, ...
      - ...
    

If I need some hierarchical kind of information, I use a folder structure to
handle this.

I know that not everything can be stored as text. But I try to use open, well
documented and future proof formats. Examples:

    
    
      - Images : PNG
      - Music  : FLAC, Ogg, ...
      - If I really need to preserve orignal format/design of a web page: PDF
    

Nothing's perfect but stay away from any closed/obscure/proprietary formats.

~~~
dijit
How do you feel about things like systemd’s journal binary logging system?

Is this an acceptable case of non-text format? And if it is, what makes it
different?

~~~
ohazi
Does anyone need to keep system logs for fifty years?

Practically speaking, I'm fine with a constraint where the systemd database
format + tools need to be roughly kept in sync. I can't think of a realistic
example where this wouldn't be the case. Most of the logs in this database are
supposed to be ephemeral.

If you're in banking or medicine or something and are required to keep certain
logs for a decade+, you should figure out what you actually want to keep and
put it in a format that would be reasonable to access on that kind of
timeline.

~~~
marcosdumay
> Practically speaking, I'm fine with a constraint where the systemd database
> format + tools need to be roughly kept in sync. I can't think of a realistic
> example where this wouldn't be the case.

That can only happen in practice if you take the logger and tools from the
same group of developers. Yet another case of forced lock-in from Systemd.

------
WalterBright
I still use utilities I wrote in the 1980s. My text editor dates back to 1985
or so. The dmd D compiler back end dates back to 1982 (undergoing continuous
improvements since then).

I've had my daily driver for about 30 years now. My stereo is 40 years old (I
use it all day every day).

Modern cars are all run by a computer. I bet this will be really hard on
anyone in the future who wants to restore one - there's just too much highly
specialized technology in them. Most parts for my '72 Dodge can be made by a
competent machinist or metalworker if necessary.

I see this in airplanes, too. People resurrect or replicate airplanes right up
to the jets. But the jets? Sigh. You can't make a jet engine in a machine
shop. So any that survive are static museum pieces, while the WW2 "warbirds"
buzz around outside.

~~~
userbinator
I have a bunch of utilities I wrote from the late 80s/early 90s and use them
regularly too; many of them are Win32 binaries which haven't been changed
since they were first created and used in Win95, and still run on Win10.

Incidentally my car is also nearly 50 years old and doesn't need a computer to
run, although it's received some powertrain and suspension upgrades over the
years as well as computers in the form of GPS, cameras, and proximity sensors.

I recently finished restoring a refrigerator from the late 1930s. With new
insulation and seals it uses less power than a lot of the "smart" fridges
today, and doesn't need a computer to function either. It would probably last
another 80 years.

~~~
Diederich
Re: a 50 year old car with proximity sensors

That's pretty fascinating; I'd love to hear more about this.

~~~
userbinator
No, they're not original equipment but an add-on. Search "parking aid radar
distance sensor DIY" at the usual online stores. Really helps with getting a
full-sized car squeezed into tight parking spots, and general maneuvering in
cramped spaces.

------
dekhn
I wrote a simple cgi-bin food ordering app in ~2000. Python and MySQL. The
program continues to run, 20 years later (I have moved on to a new job, but I
talk to the old team). The python version was updated, the MySQL server was
updated, and they did a data change when they moved to a new food caterer.

I think the main attributes of the program that contributed to the longevity
were: \- no ORM or other complex library to interact with SQL. Just the basic
SQL client.

\- cgi-bin and HTML only, no javascript. Basic HTML renders more or less the
same after 20 years.

\- used a very simple schema

\- documented everything in the system in comments

------
aprdm
I work in a company with over 40 years old and is incredible to see some very
old software still functioning :), lots of orphaned projects that keep rocking
forever.

Some engineers who have been in the company for decades usually say how a lot
of our legacy codebase was cutting edge at one point and how a lot of their
peers would have written it differently if they knew the software would still
be in use decades to come. Safer, proven, simpler constructs with minimum
dependencies seems to be the way.

How would you write your code today if you knew it would of been your last
commit and still in use in 30 years ?

~~~
AnimalMuppet
Archive your build chain - the version of the compiler, linker, libraries, and
any other tools that you use to produce the executable. Archive the version of
the OS they run on, too.

~~~
imhoguy
Just keep bootable OS drive image for every project (set of projects) which
builds offline. Make sure to also download platform docs, dependency sources,
manuals - git clone, javadocs, ruby ri/rdoc so on. Even keep IDE set up there.

I keep that habit currently by separating work with virtual machines. Storage
is cheap and I can come back to my project tomorrow or in 2050 with amd64
emulator. It is also easy to backup or archive it - just rsync the image to
NAS or burn it on DVD.

~~~
einpoklum
> Just keep bootable OS drive image for every project (set of projects) which
> builds offline.

Those images don't stay bootable, for different reasons:

* Media changes - Try booting from your tape, or your floppy disk set. * Unsupported new hardware - Remember how your Linux boot partition needed to be at the beginning of the HDD? Or how Windows setup would not recognize SATA drives unless you added drivers from a special floppy disk? * It boots, then gets stuck or goes blank on you - display driver issues being a common cause of this.

~~~
imhoguy
You are right. Solution: keep your boots simple and documented. Try them from
time to time too.

I assume some common formats do not change, but it is good to keep some side-
notes how to run the thing and what hardware to emulate.

I use Linux because it is open source and boots with broadest hardware range
possible - I am sure it will run on emulator of 2010-most popular PC platform
in few decades.

------
mekane8
I definitely relate to this. Just recently I had need of a printer and I was
thankful I had stashed an old Canon inkjet printer in the attic. It
technically is new enough to have wifi, but it was one of the first of that
generation so it's a real hassle to get it connected. I was very happy that it
has basically no other "smart" features so it can't phone home or report on my
activity or anything like that.

I foresee that in the coming years I too will long for "old" technology and
devices that just do what they are advertised to do, unencumbered by data
harvesting and loads of hidden "features" that are not really there for my
benefit. I can already relate to the farmers wanting old school tractors that
just do the job.

~~~
frosted-flakes
I like old cars because of their limited software and extreme modularity. By
"old", I mean early 2000s. I currently drive a 2003 VW Jetta. The car has a
computer (obviously), but it's been running the same software since it drove
off the factory floor, and its reach is limited. It controls the engine
timing, power locks and windows, and other basic features, but that's it[1].
No fancy features that break or are obsolete in three years (my car is almost
17 years old, and the only obsolete thing on it is the tape player, which I
still use—I doubt the same will be true of today's cars in 17 years).

This model works well, and if something breaks it's trivial to fix. Also, it
means non-modal physical controls for absolutely everything. I've driven newer
cars, and there's nothing in them that I miss when I go back to my own car.[2]

\--

[1] A lot of functions are controlled by separate hardware modules. The turn
signal relays and clicker, for example, are contained inside the emergency
flasher button, and swapping it out takes less than a minute. Same for the
windshield wipers (relay box under the steering wheel), radio (standard
double-DIN), rear-window heater (relay and timer inside the dashboard button),
window and lock controller (part of each window motor), and the headlight
switch (switch on the dash that physically switches the light circuits).

[2] Not even Apple CarPlay, which I see as largely useless, because my
windshield-mounted Garmin GPS unit and a magnetic smartphone mount with a
Bluetooth-enabled stock radio does everything CarPlay does, but better.

------
Cymen
One of my summer intern jobs during college was testing old DOS programs to
make sure they would run on Windows. This was for a factory that could no
longer deploy DOS so they had to go to Windows for support. Most were fine but
some used platforms/languagues like Clipper which had a timing loop
calculation on startup and of course, as you might be guessing, that loop
ended up being a divide by zero. Enough old DOS games had that problem that
people had come up with workarounds like having a batch file that kicked off a
program that consumed as much CPU as possible, delaying a short while and then
starting the problematic program. Due to the other CPU hogging program slowing
things down, the timing calculation on startup would take longer and no more
divide by zero. I don't know if they actually shipped our solution in the
end... The Clipper programs were all in house but apparently they had lost the
source code for many of them.

~~~
jacobush
First I thought, this can't be right, DOS didn't have multitasking. But then
again, a DOS program adding a timer interrupt could have hogged enough CPU I
guess.

~~~
dunham
It’s been a while, but I remember the name DoubleDOS. Something that let you
run two programs at once my preallocating half of memory in a device driver.

------
zwieback
Very good post but unfortunately, sometimes bad SW lasts a long time too. I
was recently called down to our proto line to help out with a 20 year old
machine vision app. All the HW was obsolete and the SW was unmaintainable. I
know that for sure because I wrote it. The whole manufacturing line was
shipped overseas a couple times and returned to us a little while ago but the
engineers just kept it running as-is. In this case the cameras, framegrabbers
and light sources were all still working, which is impressive.

However, SW is closed source and the licenses can't be renewed, in the end
that's what's making it unmaintainable.

------
downerending
GNU emacs has been in continuous production for something like 35 years, and
it's somewhat difficult to imagine it ever going away.

Is there an older piece of software that we still routinely use?

~~~
nathell
Maxima, the computer algebra system that is still actively maintained, started
out as Macsyma in 1968.

~~~
downerending
Didn't even know it had been renamed. Now I really feel old...

~~~
nathell
Not exactly renamed, just forked in 1982 and open-sourced.

------
LeoPanthera
HN on most days seems to really hate the concept of shell scripts but I have a
lot more confidence that a bash script will still work in 50 years than a
Python program will.

~~~
carlmr
In 50 years anybody that speaks English will still be able to understand the
python script though. Bash? Not so sure if it went out of style.

~~~
CJefferson
If you wrote a python script a few years ago in Python 2 it isn't supported
today, never mind in 50 years. When Python 4 rolls around some time in the
next 20 years, all your Python 3 code will break.

~~~
lmm
> If you wrote a python script a few years ago in Python 2 it isn't supported
> today, never mind in 50 years.

But I'd sooner port a Python 2 script from a few years ago to Python 3 than
try to understand a Bash script from a few years ago.

~~~
einpoklum
1\. But you won't need to port the bash script, it'll likely just work.

2\. Bash is not that complex of a language; it mostly just has somewhat arcane
shorthands, like `$@` and `-n` and such. So, yes, you need the manual, but
it's not a lot of mental effort.

~~~
lmm
> 1\. But you won't need to port the bash script, it'll likely just work.

Well, Python 2 code will likely just work too.

> 2\. Bash is not that complex of a language; it mostly just has somewhat
> arcane shorthands, like `$@` and `-n` and such. So, yes, you need the
> manual, but it's not a lot of mental effort.

If you're only counting bash qua bash then yes, but in practice most of the
logic of a "bash script" will be in (non-standardised) commands that are
invoked from it rather than the script itself.

------
metalliqaz
It's strange how he describes grep as "a set of dynamically linked libraries"
as a more accurate replacement of "a standalone executable".

It's a dynamically linked executable, just like so many other programs.

    
    
        $ file /usr/bin/grep
        /usr/bin/grep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
    

Such an odd choice of language.

~~~
beckingz
What is an executable?

A miserable pile of libraries!

~~~
marcosdumay
Plus some metadata that creates an entry point.

------
FisherGuy44
I agree with this post.

This mentality is the reason I chose the most compatible and time-proven
formats as the base of my project: Text files, and PGP. For glue, I chose
SQLite, Perl, and HTML.

For a simulation of the first 20+ years of use, I made it compatible with
older browsers: Mosaic 1.0 for now, and I plan to test on older platforms in
the future.

------
fefe23
Not quite sure what the take-away is here, and whom he is talking to.

Good software is good. Well, uh, yeah. Anything else?

Write software that people actually want? Well gosh darn, why didn't I think
of that!

Also, GNU grep is not antifragile. I learned that when I upgraded my PCRE to a
new major version and suddenly grep failed. grep is used by configure scripts,
so without a working grep you can't compile a new grep. To me that is the very
opposite of antifragility.

~~~
saagarjha
> Also, GNU grep is not antifragile. I learned that when I upgraded my PCRE to
> a new major version and suddenly grep failed. grep is used by configure
> scripts, so without a working grep you can't compile a new grep. To me that
> is the very opposite of antifragility.

Bootstrapping is a very common problem with basic tools.

------
beckingz
I grew up driving a 1996 Honda accord. Later graduated to a 1992 Honda
accord...

Those things were monstrously durable.

~~~
kgwxd
Now cars end up in a landfill when the encrypted wireless key fob falls in a
puddle because no one wants to pay $900 just for the right to open the door
and start the engine.

~~~
beckingz
The price we pay for shiny objects...

~~~
spookthesunset
You mean cars that you can walk away from after an accident? New cars are
much, much safer than older cars.

------
ihucos
For my personal project ([http://plash.io/](http://plash.io/)) I try to
archive something similar by:

* Only use technology that already exists for at least 10 years and is widely used: bash python3 C and Linux

* No external libraries, only the python standard library and the C standard library

* No monolithic design, it's a mix of about 30 standalone utilities that I can rewrite gradually if for example ever python3 becomes out of fashion.

* Keep the line count low

* Rely on proven abstractions like processes, files, pipes, the environment list, etc

------
peterwwillis
Software doesn't have to last 50 years, but if you want it to, first build
hardware that'll last 50 years, and make it upgradeable. Otherwise you'll be
trying to get an emulator to work to fake out the software to think it's still
running the same platform. And that's to say nothing of networking and
application standards changing, or, say, a lack of mirrors, and tons of
runtime dependencies.

Linux-packaged software will survive, because it's based on a system of lots
of mirrors. But most new software isn't packaged, it's just available as
source modules on one or two sites, or in GitHub releases. Who's mirroring all
that?

~~~
pkalinowski
Didn't Github just launch open source projects storage inside literal glacier?

------
jffhn
>I want to build something once, and ideally use it for the rest of my life
(or maybe 20-50 years to start off) without having to worry about having to
update something or other or risk losing something important down the line.

I can't be willing to build personal stuffs on unstable or proprietary grounds
either. To me it's like building your house on an iceberg or in a prison.

For server side software we already have some relatively safe grounds in that
regard, but for GUI I only know of frameworks with no clean API to abstract
away their implementations, and which come with much dependencies and
idiosyncrasies that can be hard to implement efficiently on top of other
libraries. OpenGL is an API, but it's complex (designed for efficient 3D) and
doesn't cover everything (windowing, mouse/keyboard events, basic primitives,
text, images, etc.).

That's why I designed BWD:
[https://github.com/jeffhain/jolikit/blob/master/README-
BWD.m...](https://github.com/jeffhain/jolikit/blob/master/README-BWD.md)

Currently I'm building a toolkit on top of it (BWD just has a graphics
(canvas), it doesn't have "components").

~~~
fock
use Tk. I regularly stumble upon old tcl-utilites which "just work"

~~~
jffhn
Tk is great indeed. I actually started programming with it, and loved it (I
don't remember encountering any glitch with it, things just worked as you
say). But it has its limits.

I want something more powerful (in a typed programming language capable of
efficient data manipulations, rather than a text-based scripting language) and
flexible (a basic API with the least constraints, not a toolkit with fixed
design and implementation choices), etc.

------
moralsupply
One of the pieces of currently existing software that most likely will survive
50 years of continuous operation is Bitcoin core.

~~~
jacobr1
Maybe. I can absolutely the protocol still living ... but perhaps the core
code has been rewritten ... and even if it took 30 years and painful Python3
like evolution ... all clients running the version of core rewritten in "Rust
'32" or something.

------
hyperpallium
> One thing I know I can't do for my personal projects is constantly dedicate
> time to working on it after I've “shipped”.

Very appealing, but long-lasting software --- grep, SQL, java --- is
maintained long after "shipped".

The thing that makes it easy for you to create better software, also makes it
easy for someone else to do the same to you.

They can take your idea, with a slightly different perspective, that makes it
better for more people (even if "worse" in terms of what you aimed at). Which
is probably what you did to someone else in the first place.

aka "progress"

------
lordleft
Great article. It explains a lot of the psychological appeal of old school,
Unix-y software. That sense that no one can take functionality from you, or
from your own ability to extend what already exists.

------
dekhn
When I joined a team of seasoned BSD developers in 2000, they proudly pointed
at some 10+ year old binaries that still ran (from their old DEC Ultrix
machines) on Tru64 alpha (binary compatibility).

I have a Mathematica binary for Linux from 2000 that still runs mostly-OK.
It's statically linked, and can't find fonts (because the distributions moved
the location).

------
jefurii
My oldest code has been in use for about twenty years. Not because it's any
good but because it does a job and the organization cannot be bothered to
spend the minimal amount of money it would take to replace it with something
better. I cringe every time I hear about this code.

