Linux 4.9.337 Released To End Out The 2016 LTS Series

[phoronix]

Phoronix: Linux 4.9.337 Released To End Out The 2016 LTS Series

The Linux 4.9 kernel was released back in 2016 and Greg Kroah-Hartman today issued the final point release for that kernel series with the Long Term Support (LTS) period now expired...

https://www.phoronix.com/news/Linux-4.9.337-LTS-Over

[milkylainen]

I'm fine with the no more general bugfixing after 6 years.
But what about security fixes? They can't be that many?
Surely the number of security issues could be plugged up to a decade?
Just curious.

I mean, if we call upon vendors to keep their products safe,
one has to regard their cost of moving and rebuilding the platform?
So helping them maintaining security without forcing platforms to move must be a good thing?

I'd be in favor of a shorter "feature" fixing LTS and a longer "security" fixing LTS.
Like. 5 years general bugfixes. 10 years security fixes.

Anyone?

[Chugworth]

Note, this is the LAST 4.9.y kernel to be released.

This kernel is now END-OF-LIFE and you should move to 4.14.y at the least, 6.1.y is the better option.

He just told people who were relying on an old LTS kernel that that 6.1 is the better option. Does that not count as confirmation that 6.1 is an LTS kernel, or is there still a chance that people might move to that kernel only to find out that it's not LTS?

[avis]

He just told people who were relying on an old LTS kernel that that 6.1 is the better option. Does that not count as confirmation that 6.1 is an LTS kernel, or is there still a chance that people might move to that kernel only to find out that it's not LTS?

It would be insane to recommend a non-LTS kernel to those who's been on an LTS kernel for so many years.

[ClosedSource]

So basically the LTS kernel currently will the most support time left is 5.10

He just told people who were relying on an old LTS kernel that that 6.1 is the better option. Does that not count as confirmation that 6.1 is an LTS kernel, or is there still a chance that people might move to that kernel only to find out that it's not LTS?

He will likely announce at 6.2 release if 6.1 is adopted as LTS or not. It depends on what big companies want. It could be 6.0, 6.1, 6.2... we can't tell

[CochainComplex]

So basically the LTS kernel currently will the most support time left is 5.10


He will likely announce at 6.2 release if 6.1 is adopted as LTS or not. It depends on what big companies want. It could be 6.0, 6.1, 6.2... we can't tell

I would assume its once again the android devices guys so that they don't have to port their HAL to newer Kernels. Have a look how old the kernels are on new mobile (android) devices.

[AlanSMac]

I'm fine with the no more general bugfixing after 6 years.
But what about security fixes? They can't be that many?
Surely the number of security issues could be plugged up to a decade?
Just curious.

I mean, if we call upon vendors to keep their products safe,
one has to regard their cost of moving and rebuilding the platform?
So helping them maintaining security without forcing platforms to move must be a good thing?

I'd be in favor of a shorter "feature" fixing LTS and a longer "security" fixing LTS.
Like. 5 years general bugfixes. 10 years security fixes.

Anyone?

It's OSS so if you feel like you want to support it beyond the official maintainers then go for it by patching yourself. Otherwise accept these people have lives. Sure you might say there's not that many security fixes but:

1. You can't really predict
2. In the meantime theres more LTS versions to maintain over that decade that all add up to the total maintenance effort

The current state of play is based on how many versions the maintainers are willing to support. You're asking them to support more.

[sinepgib]

I'm fine with the no more general bugfixing after 6 years.
But what about security fixes? They can't be that many?
Surely the number of security issues could be plugged up to a decade?
Just curious.

I mean, if we call upon vendors to keep their products safe,
one has to regard their cost of moving and rebuilding the platform?
So helping them maintaining security without forcing platforms to move must be a good thing?

I'd be in favor of a shorter "feature" fixing LTS and a longer "security" fixing LTS.
Like. 5 years general bugfixes. 10 years security fixes.

Anyone?

There are many reasons why this is not as trivial as you make it sound.
In general you keep LTS working mostly by backporting fixes from newer kernels. The problem with this is that newer kernels will diverge more and more from the older ones. In turn, this means keeping something secure will necessarily imply working with it as if it was actually active, since you need to exercise that code, keep track of any new known exploits, audit it, etc. Say, folios and MGLRU will change deeply how much of the memory management works. SLABs and SLOBs are being removed. This means the LTS kernel becomes more and more unique compared to the live releases.
Besides, beggars can't be choosers. If you need longer term support than what upstream provides, either do it yourself, pay someone or lobby to your government so they fund it. There are no free meals and maintaining a kernel is a ton of work, let alone several diverging ones. And if vendors judge moving and rebuilding the platform is too expensive, then they can choose to save money by funding the maintenance of the older kernel themselves. They can always band up together.
On the two models of LTS, I'd say there should be only one flavour, which is security fixes. If you asked for stable then you asked for the least possible changes over its lifetime, and that's only security fixes.

[kozman]

I'm fine with the no more general bugfixing after 6 years.
I mean, if we call upon vendors to keep their products safe, one has to regard their cost of moving and rebuilding the platform?
So helping them maintaining security without forcing platforms to move must be a good thing?

I'd be in favor of a shorter "feature" fixing LTS and a longer "security" fixing LTS. Like. 5 years general bugfixes. 10 years security fixes.

Tough call. There always has to be someone who's willing to step up and be a maintainer for that extra 5 years, right? That's a long commitment. At best, I would say maintain for a year, maybe two, and only for *major* security fixes with the understanding that it will fully sunset in that year or two so it gives orgs and users plenty of time to migrate. As for serious major issue, I am meaning a one-click or zero-effort pwnage level security issue.

Human capital in IT has dwindled the past 5+ years and truly it's always better to put effort into the newer stuff since who knows what the % user base is for people running on 4.9 kernel and older. While 4.9.x is not old per se, it may hamper progress on work that the newer LTS kerrnel devs are working on. Or maybe it's easy enough to backport to old kernels. I don't know, I'm not having to bear the headache of maintaining such things. Again, human capital being thin lately, you don't want to incentivize not planning ahead. Even Microsoft and NVidia released some security fixes for old gen EOL hardware and Windows 7 last month since the issue was so bad and they knew there was still a percentage of people out there still running old hardware. For whatever reason, they cling on and accept the security risk and no one is pointing at gun at their head and telling them they must upgrade or else.

For the same reason they're looking for someone to be maintainer of the old x86 stuff and no one is tripping over themselves to be "it" is why I think it's better to dis-incentivize hanging on to old hardware even though we all know how much of a pain in the ass it is to start from scratch and set things up to one's liking when you've got a perfectly working setup even if it's running older kernels, tech, etc. While I am not any kind of Linux superninja, if better in-place OS upgrade paths were made to be bullet-proof and didn't completely mess everything up after an upgrade, it would help a lot of folks who might get stuck in that boat (assuming their distro has an upgrade path). Windows 10/11, love it or hate it, has a fairly decent in-place OS upgrade experience when going from Windows 7 > 10 > or Windows 10 > 11. For the most part, all your crap and apps are working after it upgrades.

When I had Mint 20 running on an old clunker HP for my kid to play around with, I didn't get to the point where I was able to try an upgrade from 20.2 to 21.0 but my experience with going from 20.0 > 20.1 > 20.2 was seamless and everything worked fine after a reboot. I don't know how many distro have that process nailed down *perfectly* but I've read enough horror stories here on Phoronix to know it doesn't always go off perfectly or without a hitch.

What has been most of your experiences in this arena? Has it gotten better in the past 5-10 years or it still needs work?

[NateHubbard]

Besides, beggars can't be choosers. If you need longer term support than what upstream provides, either do it yourself, pay someone or lobby to your government so they fund it.

At some point, it would be easier to just use a newer, supported kernel.