Perhaps I should amend my statement: "such that they would fall apart as soon as we stop putting energy into maintaining hardware and software dependencies"

Software assumes that there exists specific hardware, operating systems, and services underlying it to keep operating. If you try to turn on a 5-year old android phone, you will find that your apps probably don't work (because of service changes for example), but also can't be upgraded because the latest versions don't work with your old version of android, and your android can't be upgraded because the latest versions don't have device drivers for your phone hardware. You're SOL.

So, to have a 100-year software, you need commodity components from the top down, that continue to be maintained for the same length of time. And it all probably needs to be 100% open source. Otherwise, you have perishable software.

That depends on the abstractions you build on and who's maintaining them. If you have a stable abstraction to build on, it's due to having common standards at the OS and instruction set level, along with device drivers hiding the churn. At the hardware level, suppliers discontinue components all the time. I wonder if most cell phone manufacturers could even build one of their designs from four years ago due to parts that have been discontinued since then?

That is assuming that software is ever written 'correctly', which outside of (semi-) academic exercise is never the case (so far).

You can have a program with 1 purpose and no added features experience a variety of critical flaws over a period of 30 years. While there might not be a 'decay' as such, there definitely is new understanding and as such new attack vectors.

The same goes for the stuff the software runs on top of. Your program might be programmed just fine, but if the CPU it was programmed on no longer exists and the replacement CPU has new features that allow that program to be exploited in new ways, that is still a flaw of the software. It couldn't have been foreseen, but it still happens.

The concept dat the things we build are frozen in time never holds up. The difference with software vs 'other things' is that it doesn't degrade or get 'used up' (as you wrote yourself). But the things around it do and as you cannot write programs against all possible future contexts, it will need maintenance for as long as it is in use (from a software perspective - a business thinks differently about that, especially risk analysts).

Not really. There is literally precedent in this regard. TeX is stable. Very stable.

Has it been extended? Yes. And some extensions can be seen as borderline required. But I'm not unconvinced that one of the biggest factors in this is that he tried to make it stable. And showed great restraint in what requirements to go after.

Which TeX? Over the last 10 years, over 20 serious and critical vulnerabilities have been found in various TeX implementations. They were all fixed via... maintenance.

How many of those were extensions? Pdftex, as an example, is not TeX. There have been roughly, what, eight releases in TeX since version 3? Hence we are now at 3.14159265.

This is not to say things couldn't have been done better. But I love that all of my documents still compile just fine. Modern practices? Nope.

Coming back to this after a few days. I also can't help but take a double take at 20 vulnerabilities in 10 years being a serious criticism. Is the implicit claim that this is a bad record compared to other software legit? (Honest question.)

I have, since January, a "frozen" Windows 7 environment with WiFi/LAN switched off. I use it rarely, now on Ubuntu, but there is something about it that feels good where it didn't before. I think it is just it's feeling of permanence.

> The only reason software needs constant updates is because new features are constantly being added to stay competitive.

New features... or just a redesign of the UI to make it look "fresh"