Here's another research track: software permanence. Modern software bitrots quickly. You spend years creating a large program, maybe 50,000 lines. It becomes very popular for a niche audience. Then your goals change, you have very little time to maintain it, and all of your dependencies bit-rot. Your programming language bit-rots: features you depend on are deprecated and removed. Library dependencies bit-rot: no longer maintained, the old versions are insecure, aren't compatible with Wayland, won't compile with new compilers, and so on. New library versions are incompatible with your code, missing features you require that were dropped from the (e.g.) Wayland rewrite due to being too niche. If we are software revolutionaries, then how do we re-invent the software stack to support software that still runs and is still usable 100 years from now? It's a big topic.

guix is one part of the answer

A few answers: • Reproducible build (the world’s already getting towards there) • Modularity - when software isn’t a monolithic chunk of stuff then less parts of it break / need to change • Safer foundations (the dependencies will have less security problems when they are not implemented in a low level buffer overflows language)

WebAssembly as an "universal" compilation target has desirable properties to help achieve "software permanence". First of it is a web standard. A wasm binary will run as long as the browsers support the standard. Then it focuses on security (along with the incoming WASI).

This is a big topic in computational science. Search for "reproducible research". Unfortunately that community is mostly disconnected from the reproducible builds community, although the issues are mostly the same.

Minimum dependencies and statically compiling/linking are ways to ensure stuff can run. DOS program still run today, but good luck to run a Linux binary from the late 90s. From a language & tooling perspective if we had the ability to re-express/transpile/transform our programs using a fully introspectable program model then we could at least partially automate the porting/translation to a new platform.

@Konrad Hinsen guix would also freeze the bottom layer. it's true that it won't solve security problems

@Mariano Guerra Even Guix (more precisely GuixSD) has an external bottom layer: PC hardware plus BIOS. BTW, Guix also has an interesting mechanism for backwards compatibilty: it can run older copies of itself as a subprocess. Whether this will work on in real life remains to be seen, it's a pretty new feature (see https://www.gnu.org/software/guix/manual/en/html_node/Inferiors.html).

If the software is fully self-contained (the language, interpreter, and/or compiler is built-in). Like how a living cell contains all its own machinery and can sustain itself. Most software is more like a virus, which has instructions (RNA) that can be injected into & executed by a living entity, but is not itself a living entity. Such a "living" thing can endure through change, because rather than being part of a changing system, it is the changing system, and thus remains a single coherent whole through change. (Side note: this is what Christopher Alexander calls "unfolding wholeness" and "structure preserving transformations")