[darksaints]

The future of operating systems, at least from a non-GUI perspective, is going to look a lot like SeL4 + Nix. A rock-hard provably secure capabilities-oriented kernel, combined with reproducible declarative package management that can handle any combination of dependencies that you want.

Essentially this means that the idea of different distributions for LTS, stable, beta, alpha, bleeding edge, etc., goes away completely. You are never forced to update an old package, nor prevented from updating a new package. You get the best of all worlds.

And since the kernel is about as secure and performant as you can get, you essentially always have the latest kernel. Drivers get updated as necessary (defined by your policy, not the distribution's) in userspace, potentially as quickly as the moment they are released, with no downtime whatsoever.

[yjftsjthsd-h]

So there's 2 ideas here: kernel, and packages.

For the kernel, I'm curious how your suggestion is better than Linux is already. Linux, today, is already a performant, secure kernel with an incredibly stable userspace-facing ABI.

For packages, the problem isn't so much being able to install old and new packages (although that's certainly useful); the problem is maintaining a stable version while still fixing bugs and security issues. It's no good just having a packaging system that lets me run a 5-year-old glibc with a fresh-from-git application server if that ancient glibc has multiple known exploits in it. The work in an LTS system is carefully backporting fixes to your chosen old version while holding its ABI stable.

[darksaints]

The kernel isn't super secure. There are way too many CVEs, and the kernel now has 28 million lines of code. That is a massive surface area for bugs and exploits. Even with LTS kernels, you can still expect to update your kernel a couple times per year with security patches. Each time that happens, you're gonna need to reboot.

You're right that LTS work doesn't go away...bugfixes will still need to be backported to old software versions. But that work is actually quite a bit easier when it is not so tightly coupled to kernel versions and repositories that are unique for each distribution and release version and architecture.

That complexity is a combinatorial explosion. Instead of having a different codebase for each (PackageVersion,KernelVersion,Distribution,Release,Architecture) combination, you would only need to maintain a codebase for each (PackageVersion, Architecture) combo...and maybe for packages which are trivially cross-compiled, even fewer.

[pjmlp]

The CVE database and Linux Kernel Self Preservation project beg to differ in regard to security.

[m463]

I think it's going to be more like hypervisor + vms + containers.

A proper analogy is probably a city block in NYC. Lots of buildings of various eras with the only commonality being utilties in and out plus the ground they sit on.

Although periodically buildings are knocked down and rebuilt, this is an exceptional circumstance.

[mixmastamyk]

Sounds good, but unless there’s a developer and end-user product approaching the maturity of BlueHat or even Debian it doesn’t seem likely to happen.