Personally I think it would be of great benefit if Enterprise vendors just stopped doing that extremely long term support. It just enables the people who want to pretend they can stop the world around them and those people are bad for everyone, especially in a security context but also because they pretend that “stability” is achieved by using old versions.
I hope that the community at large can wrestle kernel livepatching away from the commercial distros. No reason the big names should have a monopoly on that.
Even where those are concerned, it’s not a silver bullet for seamlessly jumping major kernel versions, but it’s a start.
I feel it was a direct reply to the comment above.
Dinosaurs don’t want to give up their extended LTS kernels because upgrading is a hassle and often requires rebooting, occasionally to a bad state.
So how can you bring your userbase forward so you don’t have to keep slapping security patches onto an ancient kernel?
I feel it was a direct reply to the comment above.
At no point did it mention livepatching.
Dinosaurs don’t want to give up their extended LTS kernels because upgrading is a hassle and often requires rebooting, occasionally to a bad state.
No, Dinosaurs want LTS because it’s stable; it’s in the name.
You can’t have your proprietary shitware kernel module in any kernel other than the ABI it’s made for. You can’t run your proprietary legacy service heap of crap on newer kernels where the kernel APIs function slightly differently.
how can you bring your userbase forward so you don’t have to keep slapping security patches onto an ancient kernel?
No, Dinosaurs want LTS because it’s stable; it’s in the name.
Mostly they want LTS because if they never upgrade nobody can blame them for the failures that are happening because “not doing things” is seen as less blame-worthy than “doing things”. Actual stability is not achieved by running ancient version numbers with backported fixes. Nor is it achieved by never rebooting and then wondering why nothing works when you are inevitably forced to reboot by some unpreventable external circumstance. Actual stability is achieved by testing updates before applying them and doing so frequently so increments are small and causes of problems thus easily identifiable and fixable.
I think Arch has FOSS support kernel live patching
Nixos also has an open issue where they seem to be discussing an implementation they might consider.
With upstream support and kpatch being FOSS I think the willingness is just low to maintain patches at a distro level and announcing it as a thing you can do yourself has limited audience.
I agree its super cool though and with containers and some of systems work for system level reboots and portable services I see a lot of potential for high uptime systems (like my laptop lol).
Personally I think it would be of great benefit if Enterprise vendors just stopped doing that extremely long term support. It just enables the people who want to pretend they can stop the world around them and those people are bad for everyone, especially in a security context but also because they pretend that “stability” is achieved by using old versions.
This is how I know you need to learn more about the Enterprise, about long-term support, and stability. Everything you wrote sounds like “Smoke detectors and seat belts are for chumps”
I know a lot more about those topics than I ever wished I would.
Stability doesn’t magically appear because you leave the version number unchanged. Stability is the result of qualified people (hint: people backporting patches in 100s of projects they barely know aren’t very qualified in comparison to the main developers of those projects) making well-informed changes to a project and then testing them.
Old versions with backports are still new versions, just new versions with a smaller user base and less testing.
Stability is also much harder to achieve if you do certain tasks rarely, e.g. only every 10 years, since nobody will remember how to do them.
Upstream supports those old releases only begrudgingly because every feature that needs support across all versions in use is held back by those extremely long term support versions.
I am not objecting to the goal of stability, I am objecting to the snakeoil that pretends you can achieve it by using the same version number all the time basically with a forked branch of the code that contains cherry-picked changes.
Agreed at a certain point supporting an old enough ABI is just a practice in preservation and shouldn’t be where any serious work is done on.
There are still companies that treat software development as if they craving stone for future generations instead of living collections of logic, idioms, and ideas (that reasonbly should be expected to adapted or replaced as conditions change!)
Personally I think it would be of great benefit if Enterprise vendors just stopped doing that extremely long term support. It just enables the people who want to pretend they can stop the world around them and those people are bad for everyone, especially in a security context but also because they pretend that “stability” is achieved by using old versions.
I hope that the community at large can wrestle kernel livepatching away from the commercial distros. No reason the big names should have a monopoly on that.
Even where those are concerned, it’s not a silver bullet for seamlessly jumping major kernel versions, but it’s a start.
Kernel livepatching is super niche and I don’t see what it has to do with the topic at hand.
I feel it was a direct reply to the comment above.
Dinosaurs don’t want to give up their extended LTS kernels because upgrading is a hassle and often requires rebooting, occasionally to a bad state.
So how can you bring your userbase forward so you don’t have to keep slapping security patches onto an ancient kernel?
At no point did it mention livepatching.
No, Dinosaurs want LTS because it’s stable; it’s in the name.
You can’t have your proprietary shitware kernel module in any kernel other than the ABI it’s made for. You can’t run your proprietary legacy service heap of crap on newer kernels where the kernel APIs function slightly differently.
That still has nothing to do with livepatching.
Mostly they want LTS because if they never upgrade nobody can blame them for the failures that are happening because “not doing things” is seen as less blame-worthy than “doing things”. Actual stability is not achieved by running ancient version numbers with backported fixes. Nor is it achieved by never rebooting and then wondering why nothing works when you are inevitably forced to reboot by some unpreventable external circumstance. Actual stability is achieved by testing updates before applying them and doing so frequently so increments are small and causes of problems thus easily identifiable and fixable.
Amen.
I think Arch has FOSS support kernel live patching Nixos also has an open issue where they seem to be discussing an implementation they might consider.
With upstream support and kpatch being FOSS I think the willingness is just low to maintain patches at a distro level and announcing it as a thing you can do yourself has limited audience.
I agree its super cool though and with containers and some of systems work for system level reboots and portable services I see a lot of potential for high uptime systems (like my laptop lol).
This is how I know you need to learn more about the Enterprise, about long-term support, and stability. Everything you wrote sounds like “Smoke detectors and seat belts are for chumps”
I know a lot more about those topics than I ever wished I would.
Stability doesn’t magically appear because you leave the version number unchanged. Stability is the result of qualified people (hint: people backporting patches in 100s of projects they barely know aren’t very qualified in comparison to the main developers of those projects) making well-informed changes to a project and then testing them.
Old versions with backports are still new versions, just new versions with a smaller user base and less testing.
Stability is also much harder to achieve if you do certain tasks rarely, e.g. only every 10 years, since nobody will remember how to do them.
Upstream supports those old releases only begrudgingly because every feature that needs support across all versions in use is held back by those extremely long term support versions.
I am not objecting to the goal of stability, I am objecting to the snakeoil that pretends you can achieve it by using the same version number all the time basically with a forked branch of the code that contains cherry-picked changes.
Agreed at a certain point supporting an old enough ABI is just a practice in preservation and shouldn’t be where any serious work is done on.
There are still companies that treat software development as if they craving stone for future generations instead of living collections of logic, idioms, and ideas (that reasonbly should be expected to adapted or replaced as conditions change!)