[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.