Some Linux LTS Kernels Will Be Supported Even Longer, Announces Greg Kroah-Hartman (itsfoss.com) 24
An anonymous reader shared this report from the blogIt's FOSS:
Greg Kroah-Hartman has updated the projected end-of-life (EOL) dates for several active longterm support kernels via a commit. The provided reasoning? It was done "based on lots of discussions with different companies and groups and the other stable kernel maintainer." The other maintainer is Sasha Levin, who co-maintains these Linux kernel releases alongside Greg. Now, the updated support schedule for the currently active LTS kernels looks like this:
— Linux 6.6 now EOLs Dec 2027 (was Dec 2026), giving it a 4-year support window.
— Linux 6.12 now EOLs Dec 2028 (was Dec 2026), also a 4-year window.
— Linux 6.18 now EOLs Dec 2028 (was Dec 2027), at least 3 years of support.
Worth noting above is that Linux 5.10 and 5.15 are both hitting EOL this year in December, so if your distro is still running either of these, now is a good time to start thinking about a move.
— Linux 6.6 now EOLs Dec 2027 (was Dec 2026), giving it a 4-year support window.
— Linux 6.12 now EOLs Dec 2028 (was Dec 2026), also a 4-year window.
— Linux 6.18 now EOLs Dec 2028 (was Dec 2027), at least 3 years of support.
Worth noting above is that Linux 5.10 and 5.15 are both hitting EOL this year in December, so if your distro is still running either of these, now is a good time to start thinking about a move.
Kernel support (Score:1)
Distros like RHEL and Ubuntu have kernel specialists in house and incorporate patches into the kernel on their own schedule, independent of whatever the guys at kernel.org are doing.
Re: (Score:3, Informative)
Red Hat and Canonical both have very long LTS support cycles, a lot longer than what upstream kernel.org offers. RHEL you get 10 years out of the box plus an ELS addon that gives you like ~5 more years. I think with Ubuntu it's 5 years out of the box (free) plus 5 years if you buy Ubuntu Pro and maybe longer if you keep paying. All of this keeps you on the same kernel branch that the distro started out with.
Those distros go through a careful QA process and each kernel patch is vetted to (hopefully) make sur
Re: (Score:2)
Yep, especially for embedded this is really important. It's a shame that Raspberry Pi don't do nice long term support options, because their Compute Module is quite decent otherwise.
Re: (Score:3)
Red Hat and Canonical both have very long LTS support cycles, a lot longer than what upstream kernel.org offers. RHEL you get 10 years out of the box plus an ELS addon that gives you like ~5 more years. I think with Ubuntu it's 5 years out of the box (free) plus 5 years if you buy Ubuntu Pro and maybe longer if you keep paying. All of this keeps you on the same kernel branch that the distro started out with.
Those distros go through a careful QA process and each kernel patch is vetted to (hopefully) make sure it doesn't break something.
That's why.
It's worth noting that if you're a significant target for attack staying close to current releases is better than using an LTS release.
The reason is that while LTS releases are assiduously patched to fix identified vulnerabilities, those are only identified vulnerabilities. Finding 0days in the Linux codebase is a lot of work, and most researchers -- white hat and black hat both -- find it much easier to mine the commit logs than to scan the source directly (though fuzzing is also quite productive). Thi
Re: (Score:2)
If you're just running a home server, no one cares enough to spend 0days on you, so LTS is fine. If you're a valuable target, however, LTS is easier but riskier.
I should point out that's just from a system security perspective. From an organizational perspective, the best way to cover your ass is likely to be to use LTS releases from a reputable source and maintain logs proving that you applied all of the updates they provided. If Red Hat's kernel gets popped no one can blame you.
Re:Kernel support (Score:5, Informative)
A kernel.org release or stable release is not considered to be a "one size fits all" solution. For example, there is a kernel defconfig file that distributions will adapt to best match the requirements of their users.Such as running on ARM64 instead of x86-64. Additionally, distributions may provide extra kernel drivers that are not in the kernel.org tree such as drivers specific to chipsets that are not supported in kernel.org.
You are correct in saying that application software running in userland is mostly independent of the kernel version but application software is dependent on libraries that interact with the kernel. Therefore, there is some wiggle room to have a mix and match approach between kernel, library and application versions before breakage occurs.
Also, end users can build their own custom kernel and deploy it. This is particularly necessary when resolving kernel bugs in the community and for sending proposed fixes to the kernel.org mailing lists.
If a distribution adapts the kernel then these adaptions need to be incorporated on top of the next LTS. This prevents an immediate switch over to a new LTS kernel.
It should also be noted that a LTS kernel release may have deleted an API or removed a feature that the distribution was using. This can also delay upgrading to a new LTS kernel release as time is needed to find a solution.
Re: (Score:2)
I'm not sure why the ultimate (anonymous) parent of this thread hasn't been modded up. But basically as has been at least implied in responses - the last paragraph of TFS is largely incorrect. Enterprise distributions typically stay on the same kernel for the life of the distro, and they backport any relevant security patches to that kernel for the duration. They follow this same approach for much / most of the supported software that's included in their releases, actually - apache, openssl, etc.
Re: (Score:2)
Which seems like a huge waste of effort. Why not just migrate to the next LTS when it's known and let the kernel people do the work. What keeps distros so tied to specific kernel versions? Most software doesn't give a rat's ass what kernel its on.
Along with other reasons, the kernel does not have a stable API, and some customers require staying on the same (validated) kernel due to various custom solutions (including drivers (including from 3rd parties that might even be in binary form) that may required a specific API), and regulatory requirements. The enterprise distros are responsive to their paying customers, and "if it ain't broke, don't f... with it" is what those customers want. There are often ancillary repositories (often supported by maj
Re: (Score:2)
Which seems like a huge waste of effort. Why not just migrate to the next LTS when it's known and let the kernel people do the work. What keeps distros so tied to specific kernel versions? Most software doesn't give a rat's ass what kernel its on.
Along with other reasons, the kernel does not have a stable API, and some customers require staying on the same (validated) kernel due to various custom solutions (including drivers (including from 3rd parties that might even be in binary form) that may required a specific API), and regulatory requirements. The enterprise distros are responsive to their paying customers, and "if it ain't broke, don't f... with it" is what those customers want. There are often ancillary repositories (often supported by major corporations) that do provide more recent (usually LTS) kernels, but they are not officially supported by the distros themselves. It should be noted that the enterprise distros will, sometimes, backport specific fixes (that may not even be in an LTS kernel) that address a pain point by their customers.
107% agree with you, but: The Big-unn paying distros (in particular Red Hat and Android) do not use LTS kernels as their main kernels (although they give said kernels as options), let alone use CIP kernels (supported for 10 years).
I wish they did, but they do not. Why? I suspect it is more of "when we started development of the next version this was the 1st kernel that had everythig we needed" and less of "Let's NOT use an LTS kernel so that customers depend on us for backporting and patches".
Devuan is right up to date, too (Score:1)
6.18.5 is in backports. What a time to be alive!
Now if only Nvidia supported preempt. This is the first generation of hardware where I've regretted buying Nvidia. Not that they will miss me, but I guess this is the last time I do that.
Re: (Score:1)
I never understood why Devuan if they are against systemd didn't just base their disto with something that didn't use it? I understand that some systemd libraries cannot be deleted from the base distro.
Because the people who did it like Debian.
I understand that some systemd libraries cannot be deleted from the base distro.
There are stubs and replacements for the daemons in Devuan. I think you do still get stuck with some of the libraries.
Re: Devuan is right up to date, too (Score:2)
Debian didn't used to use systemd. Over the year it has gotten harder to change the init system on Debian, but at some points you could choose from multiple inits. Kind of a pain to maintain more than one now that users don't think hand editing rc scripts is acceptable.
Re: (Score:3)
Re: (Score:1)
I just tried to install the preempt version and nvidia driver dkms gave me an error about no compatibility. 590.48.01
Re: Devuan is right up to date, too (Score:2)
Weird down mod. Why are facts hated on slashdot now?
Re: (Score:2)
6.1.140 here, had Nvidia + Preempt for years, I am suprirsed this is somehow a problem now?
Re: (Score:2)
Re: (Score:2)
Did something change recently?
good news, everyone! (Score:2)
Linux will be supported well into World War 3.
(But seriously, great work everyone. It's my 31st year as a Linux user)
6.12 is the one to pay close attention to (Score:3)
6.12 was selected by the Linux Civin Ifrastructure Platform (CIP) to have a "Super LTS", accepting Limited patches for 10 years.
The fact that G.H-K will support it as LTS for 4 years means more time with "propper" patches and less time the CIP has to do the work with less funding and limited patches.
Many projects (most notably OpenWRT) use only CIP Kernels.
If I were a smallish distro, with limited number of voluntaires, I'd Aim to use CIP kernels in General, and 6.12 in particular, even If the project does not do LTSs.
Re: (Score:3)
CIP kernels are there because they're used in products that have a very long lifespan - a decade or more. You might not think it, but some devices are in use at least that long.
Some examples include a smart meter - that thing hangs outside your house in the elements, and in normal operation is installed and stays there for a decade or more. (Their mesh networks do allow minor software updates to be send down).
Another example would be the traffic light controller - those things were microcontroller based, bu