New Linux Kernel LTS Policy

All --

Interesting news About Linux LTS Kernels

Starting with 4.4.x and continuing with 4.14, support will be maintained for six years rather than two years.

-- kjh

This is great news, but I wonder if they're biting off more than they can chew. I would think it would make more sense to keep the normal release schedule and then mark one LTS kernel every 2-3 releases as an extended release. If the current plan were retroactively set, there would be 10 active LTS kernels right now:

3.2
3.4
3.10
3.12
3.14
3.18
4.1
4.4
4.9
4.14 (soon)

3.0 would've just been EOLd in July. Now, if they decided to do every 3 kernels, it could only be:

3.10
3.18
4.9
etc

That seems like something that is a lot more manageable. But then, I'm not Greg Kroah-Hartman, and maybe he can easily support 10 LTS kernels in addition to his other work. Or maybe someone else is going to jump in to help...

No matter the outcome, it's great they're working to provide longer support time, since many distros provide longer support for their releases than the kernels in them.

bassmadrigal --

The way I understand the Article on Phoronix, only 4.4, 4.14 and future LTS Kernels will get the six year support.

-- kjh

Originally Posted by kjhambrick The way I understand the Article on Phoronix, only 4.4, 4.14 and future LTS Kernels will get the six year support.

It said in the article:

But moving forward, Linux LTS releases will now be maintained for six years.

and

Beginning with the current Linux 4.4 LTS cycle will be extended for six years.

To me, this reads that any LTS release (starting with 4.4) is now supported for 6 years. But you are right, there isn't enough clarification yet to know for sure. I even found another article on arstechnica that still seemed to imply it is all LTS releases (from 4.4 on).

When asked if this six-year LTS would be available to everyone, Malchev added, "LTS is LTS. Greg Kroah-Hartman, the LTS maintainer, is committing to do [a six-year LTS]. Not because of Google or Android or Treble, but because everything is on LTS; it's not on upstream."

and

Malchev, during his presentation, dropped the news of the Linux kernel tripling the lifecycle of its LTS releases, saying, "Greg Kroah-Hartman has given me permission to announce this here: He will extend LTS to six years, starting with kernel 4.4."

It really sounds like it's a shift in LTS support terms from the 4.4 series on. But I suppose we'll need to wait for more details to know for sure. Keep your eyes peeled on the kernel.org releases page to see which dates change when they update it (which hasn't been updated yet).

Here is an official update on The Linux Kernel Archives Releases Page.

Note that 4.4 is now being supported until Feb 2022 ( yesterday it said Feb 2018 ).

-- kjh

Originally Posted by kjhambrick Here is an official update on The Linux Kernel Archives Releases Page. Note that 4.4 is now being supported until Feb 2022 ( yesterday it said Feb 2018 ). -- kjh

Interesting. I wonder how they'll determine what will be LTS and what will be Extended LTS or if there's even supposed to be a difference? The articles made it look like all LTS will be Extended LTS. Maybe Greg Kroah-Hartman will go longer between LTS releases (I hope not) or maybe there will still be LTS and Extended LTS (which makes a lot more sense to me).

Originally Posted by bassmadrigal Maybe Greg Kroah-Hartman will go longer between LTS releases

That was my expectation on hearing about this, as it's going to make a lot of extra work for him otherwise. I guess we'll see.

I've long since given up on LTS branches. Unless I hit a specific problem that forces me to revert I'll continue to follow the most recent stable branch here.

as long as Google is not the sole entity responsible for the extra LTS then I am all for it...this has been needed for a long time.

Since it appears there will not be a 3.10.108 release to incorporate patches for the most recent crop of CVEs, but 4.4.x will continue receiving bugfixes / security patches for years, I'm inclined to restandardize my systems to Slackware 14.2 (from 14.1).

It makes sense to me to use the oldest supported kernel because kernel devs will have touched the code less, and thus introduced fewer bugs into it. Fewer bugs to start with, and ongoing patches to fix bugs as they are discovered, poses a least-incorrect kernel.

I looked at rolling my own patched 3.10.107 (since all of the CVEs relevant to it have upstream patches), but do I really want to keep doing that for years to come? The prospect nudged me over the edge to accept 14.2 going forward.

Originally Posted by ttk Since it appears there will not be a 3.10.108 release to incorporate patches for the most recent crop of CVEs, but 4.4.x will continue receiving bugfixes / security patches for years, I'm inclined to restandardize my systems to Slackware 14.2 (from 14.1). It makes sense to me to use the oldest supported kernel because kernel devs will have touched the code less, and thus introduced fewer bugs into it. Fewer bugs to start with, and ongoing patches to fix bugs as they are discovered, poses a least-incorrect kernel. I looked at rolling my own patched 3.10.107 (since all of the CVEs relevant to it have upstream patches), but do I really want to keep doing that for years to come? The prospect nudged me over the edge to accept 14.2 going forward.

I will tell you that 4.4 and 4.9 kernels have been running flawlessly on my 14.1 system. So, if you aren't inclined to move the whole system over, you could just upgrade the kernels.

Originally Posted by bassmadrigal I will tell you that 4.4 and 4.9 kernels have been running flawlessly on my 14.1 system. So, if you aren't inclined to move the whole system over, you could just upgrade the kernels.

Thank you! I will try this with one of my servers which would be a bear to migrate (I just recently finished migrating it off 13.1!!).

I'm still inclined to migrate the easy ones to 14.2, though, just because that's the system the rest of the Slackware-using community is using with 4.4.x, which makes undiscovered incompatibilities less likely.