Why old architectures are sometimes important

Why old architectures are sometimes important

x32 isn't an old architecture in a meaningful sense, though. It was launched around 2012 - it necessarily postdates x86-64, and only works on x86-64 processors, which is to say, any x32 machine can run x86-64 binaries equally well (but with perhaps a few percent more memory consumption).

But I see this argument about old architectures for things that actually are old architectures, and I don't get why this has any bearing on new versions of OSes.

For point 1, the argument for reliability of remote systems argues in favor of not upgrading them to the latest kernel or latest OS - it's not like you need new features, and so the risk calculus weighs against making changes that you don't really need. Linux 2.4 (for example) works every bit as well as Linux 2.4 worked twenty years ago; it's still the same code. If support for something is "removed" from Linux, it's only removed from new releases; it's still just as functional as it was yesterday in the releases that existed yesterday.

If you're worried about vulnerabilities, either tell yourself that your architecture is so rare that people aren't going to explore it, or more usefully, isolate your system from the public internet; even if you upgrade to the latest version of everything, the fact that you're running an obscure architecture means that there aren't "many eyes" looking at your setup, people are unlikely to implement state-of-the-art mitigations as well, etc. (Not to mention that your own code, probably, hasn't been seriously analyzed since before we were as cognizant of security vulnerabilities as we are today.)

For point 2, the same argument applies if you really are leaning into the position of "it works, why change it?". Even if you're wrapping the old binaries with modern APIs, you'll still want the old binaries to run in the environment where you're confident they run well. And if you're wrapping them with modern APIs, that gives you plenty of room to put modern authorization controls on access to the legacy systems and not worry about vulnerabilities.

If you're doing ongoing development on legacy software - which is fairly common - then chances are you will want to keep up with the broader industry, and that argues in favor of investing in modernization. If the business decides it's excited about AI, you'll quickly find that nobody is figuring out how to compile PyTorch for VAX. Besides, there are significant efficiency improvements that mean you'll save more on power than you'll spend on the new hardware. (And I've also seen tax incentives for upgrading even just older x86-64 machines to newer ones.)

If we were talking about proprietary software that is no longer available, I would completely agree. My Nintendo 3DS, for instance, still works as well as it did when I bought it, and it's frustrating that the eShop is no longer available. But we do have the code of every version of Linux ever released, and of every major FOSS distro, and nothing can take that away. So it seems perfectly fine for people who need to use old hardware use the software that was best designed for that hardware, and let new software target new hardware.