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?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?
That still has nothing to do with livepatching.
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.
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).
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!)
So 90% of the Android devices can still get custom kernel updates? Nice
Brave of you to assume this gets backported to custom vendor kernel packages.
vendors: we’ve back ported the kernel by allowing you to purchase a new phone!
I do like the point about encouraging the major distros to combine their efforts on kernel versions. Everyone would benefit from that (which is why they don’t do it, not when they’re making money off of extended LTS services)
This is the best summary I could come up with:
This support extension is good news for anyone still running older kernels in production, but also, in context, slightly puzzling.
OpenELA came together in August 2023 as a cooperation between Oracle, SUSE, and Rocky Linux backers CIQ.
The thing is, though, that kernel 4.14 is not used by any of the obvious candidate distros from Red Hat or RHEL derivatives.
After OpenELA contacted us to tell us about the announcement, we asked why this particular version, and if there was any connection with AWS or Amazon Linux 2, but although we gave them a few working days, at the time of writing we have had not heard from them.
Currently, each of the the bigger distro vendors maintain their own kernel versions, and they all work separately.
Our feeling is that it would be beneficial for the greater Linux world if more of the enterprise vendors could agree to work together on the LTS kernels, for instance by ensuring that long-term supported distros used the upstream long-term supported kernel versions.
The original article contains 616 words, the summary contains 169 words. Saved 73%. I’m a bot and I’m open source!
Speaking of OpenELA, when are we going to hear about a distro release?
