Long-Term Support For Linux Kernel To Be Cut As Maintenance Remains Under Strain (zdnet.com) 106
Steven Vaughan-Nichols writes via ZDNet: BILBAO, Spain: At the Open Source Summit Europe, Jonathan Corbet, Linux kernel developer and executive editor of Linux Weekly News, caught everyone up with what's new in the Linux kernel and where it's going from here. Here's one major change coming down the road: Long-term support (LTS) for Linux kernels is being reduced from six to two years.
Currently, there are six LTS Linux kernels -- 6.1, 5.15, 5.10, 5.4, 4.19, and 4.14. Under the process to date, 4.14 would roll off in January 2024, and another kernel would be added. Going forward, though, when the 4.14 kernel and the next two drop off, they won't be replaced. Why? Simple, Corbet explained: "There's really no point to maintaining it for that long because people are not using them." I agree. While I'm sure someone out there is still running 4.14 in a production Linux system, there can't be many of them.
Another reason, and a far bigger problem than simply maintaining LTS, according to Corbet, is that Linux code maintainers are burning out. It's not that developers are a problem. The last few Linux releases have involved an average of more than 2,000 programmers -- including about 200 new developers coming on board -- working on each release. However, the maintainers -- the people who check the code to see if it fits and works properly -- are another matter.
Currently, there are six LTS Linux kernels -- 6.1, 5.15, 5.10, 5.4, 4.19, and 4.14. Under the process to date, 4.14 would roll off in January 2024, and another kernel would be added. Going forward, though, when the 4.14 kernel and the next two drop off, they won't be replaced. Why? Simple, Corbet explained: "There's really no point to maintaining it for that long because people are not using them." I agree. While I'm sure someone out there is still running 4.14 in a production Linux system, there can't be many of them.
Another reason, and a far bigger problem than simply maintaining LTS, according to Corbet, is that Linux code maintainers are burning out. It's not that developers are a problem. The last few Linux releases have involved an average of more than 2,000 programmers -- including about 200 new developers coming on board -- working on each release. However, the maintainers -- the people who check the code to see if it fits and works properly -- are another matter.
Support should be shorter (Score:4, Insightful)
Re:Support should be shorter (Score:5, Insightful)
How much did you pay to the kernel team for that 4 year support window? That's something everyone who is going to complain needs to think about.
Paying for stuff is OK within FSF / Linux doctine (Score:2)
I'm sure IBM/RedHat think this is a wonderful development.
Free software developers are under no obligation to provide anyone with long term support. Like features, long term support is something that users are free to pay for if they do not wish to do the development work themselves. It is entirely within FSF and Linux doctrine.
If there are not enough qualified volunteers to do some body of work then users should step up eighther with volunteering their time or with financial support. The people who gave you something for free are not obliged to continue giving
Re:Support should be shorter (Score:5, Interesting)
Re: (Score:2)
Running an old userland with a new kernel usually works without any issues. The problem are devices that require out-of-tree drivers or drivers that were removed from the mainline kernel.
Re:Support should be shorter (Score:4, Interesting)
I don't know about Mint specifically, but I know when I have to deal with Ubuntu LTS, practically speaking you have to use the 'HWE' kernel pretty quickly usually, which takes you out of LTS kernel versions.
LTS is of significantly reduced value when the kernel doesn't receive support for new hardware.
Incidentally, the kernel, while significant, is far from the only "important" open source component that would be covered by a distributions declared support lifetime. The vast majority of those upstreams don't even pretend to offer an 'LTS' lifecycle for the distribution to bank on.
For most people, the "LTS" value isn't there. RH lets folks pretend they are sticking with a stable old kernel while getting new drivers and features, but it's mostly just keeping the kernel version *looking* the same while updating it. Most everyone else gets told to update to newer version because the LTS kernel doesn't support their system.
Re: (Score:2)
Re: (Score:2)
At least for userspace, this is absolutely the case. The whole container strategy conspicuously presumes "kernel doesn't matter, as long as it's new enough" and no one thinks twice about kicking off an old ass container on a brand new kernel. The kernel prioritizes stable userspace interaction, it's all the pesky userspace projects that tend to break compatibility arbitrarily, and those are the projects that really need long term maintenance to bring the stability people desire, and most of them have no s
Re: (Score:2)
As an example, Android suffers greatly from this due to being dependent on out-of-tree proprietary drivers for hardware support. It's so bad that Google has been trying for years to develop their own kernel
Re: (Score:1)
Re: (Score:2)
There are people still running CentOS 6 in corporate environments with eg. kernel 3.16. This is common. CentOS 7 was still on 4.18.
Anything "corporate" and "enterprise ready" tends to lag behind significantly - detrimentally to everyone involved.
There's rarely a good reason to not be on the latest kernel tree, or second latest with a high number patchset. It's not like old hardware magically stops working.
Re:Support should be shorter (Score:5, Interesting)
The issue is appliances and IoT stuff. Everyone is using Linux and it's bad enough with a lack of your router not getting updates after a few months.
If the kernel goes obsolete after two years, realistically much less from the point the product is launched, it increases the cost of updating those old products.
I'm not saying that kernel updates should be free for 5 years, but also one of the advantages of using Linux over something like QNX or even Windows CE is that everyone benefits from the work done to maintain it. Perhaps companies using it should be obliged to pay into a maintenance fund that handles LTS releases.
Re: (Score:2)
The issue is appliances and IoT stuff. Everyone is using Linux and it's bad enough with a lack of your router not getting updates after a few months.
Routers shouldn't have their "own" software. They should run openwrt. But then someone else might benefit from your contributions, oh noes! I won't buy a router that doesn't come with openwrt new any more, and I won't buy a used router that doesn't run it either. I want to know support for it will be good up front.
Re: (Score:3)
Even openwrt isn't guaranteed to support old routers when the kernel updates. Drivers can become incompatible, for example.
Re:Support should be shorter (Score:4, Informative)
The trouble is even if its running openwrt, the drivers (or the ones that actually work right and enable all the hardware features like maybe a hardware nat engine) are out of tree.
The you won't be able to update the kernel unless you have the source to these and either it still builds because kernel internals haven't change or you can port/fix. OpenWrt isnt very useful if the kernel has no support for the DSA layer on the board..
Re: (Score:2)
I won't buy a router that doesn't come with openwrt new any more
Irrelevant. In the world of the modern internet you largely lack any choice or autonomy in what you run. Sure you can throw a router on your network, but for many cases ISPs will dictated the complex (and largely insecure) devices that are needed to connect to their network.
Re: (Score:2)
Err no. That really isn't the issue in the slightest. Regardless of the duration of kernel support the overwhelming mega majority of IoT appliances and routers and stuff are not updated. At ALL. It doesn't matter what the kernel team do if there is a combination of consumer and vendor apathy towards security updates downstream of them.
But all of that is still beside the point. Someone needs to be paid.
Re: (Score:2)
The issue is appliances and IoT stuff. Everyone is using Linux and it's bad enough with a lack of your router not getting updates after a few months.
If the kernel goes obsolete after two years, realistically much less from the point the product is launched, it increases the cost of updating those old products.
I'm not saying that kernel updates should be free for 5 years, but also one of the advantages of using Linux over something like QNX or even Windows CE is that everyone benefits from the work done to maintain it. Perhaps companies using it should be obliged to pay into a maintenance fund that handles LTS releases.
But those IoT devices don't get updated anyway, so whats the point in having longer term support for their kernels, or anything else?
Re: (Score:2)
In case anyone is wondering, The Linux Foundation is pulling in over $100m/yr. $$$ isn't the issue.
https://projects.propublica.or... [propublica.org]
Re: (Score:2)
Paying a bunch of idiots to sit around all day compiling code and debug testing it on every possible system that Linux supports is a gargantuan task. Just debug checking the x86 architecture alone would take entire data-centers worth of space and power to do so. Not to mention ARM. That reality is the entire reason that we have Linux distributions in the first place: To curate specific packages / builds and provide them to end-users as a "stable" and "
Re: (Score:2)
Payment means nothing here. Nor would it help matters.
So because a task is big and underfunded, you should fund it even less? I don't understand your post, possibly you don't either.
Re: (Score:2)
When you're a full-time sysadmin, maintaining a "high volume" site, then it is reasonable to replace the hardware and upgrade the OS every one or two years. But if you're "johnson & johnson hardware" who paid a nephew $1000 for a webserver and website a while back, then upgrading every 6 years is not even obvious.
Re: (Score:1)
Re: (Score:2)
Problem is, management will not provide an overflowing abundance of resources allowing for spare time to prep and do updates of systems at that rate. At many large companies, it's two years or more from investment decision based on an offer specifying the exact machine to the point where the machine is up and running in production. There is no way to keep a schedule of replacing two year old hardware.
Upgrading the OS is often done in a much more timely fashion, but even having the resources to prep, test on
Re: (Score:2)
Someone's going to have to pay for that.
The people who can afford to pay for it don't need it, they can afford to update their systems.
It's not fun work, so it's reasonable to have to pay.
End result, people are going to have to find a strategy that involves timely updates.
Re: Support should be shorter (Score:2)
Re: (Score:3)
Does that mean no embedded systems? Of course, those never get upgrades anyway.
Re: (Score:2, Insightful)
On the low-end consumer, embedded systems are a race to the bottom. The absolute minimal hardware needed to make the product viable. Support isn't an after thought - it isn't thought about at all.
On the industrial end, you don't want to be upgrading anything unless you absolutely have to along with the need for the systems to be air-gapped.
It's the gray middle where we get into trouble. Test equipment, TVs, cars, home automation, etc. You will get updates for a couple of years, then nothing. The produc
Re: (Score:2)
I think this is something that companies like IBM/Redhat and Canonical need to step up and work out. Pony up the money so the LTS maintainers can promote a few trusted liutenants each, train them up and hand over, WITH a respectable Salary and conditions conductive to not burning out courtesy of the big boys in the field.
Re: (Score:3)
RedHat already has their scheme, and it doesn't really care about the upstream LTS cadence. For example, 10 years of support for kernel 4.18, which isn't considered LTS by anyone. Same for 5.14, also not an LTS release outside of the context of RH.
Now to the extent that what you actually find in RHEL being fairly called '4.18' is certainly a question (chock full of backports and such, it's more an illusion of long term support for 4.18 while upgrading you to some hybrid kernel). The fact remains that the
Re: (Score:2)
Re: (Score:2)
This is something that should be thought of. IBM, Amazon, and many other companies have benefitted from Linux on the scale of many trillions of dollars. Even a tiny fraction of money to prop up the LTS maintainers and give them a decent salary so they can focus on this without worrying about day to day finances. At least give them the same salary of a senior developer, as the LTS maintainers are doing something useful that affects the entire ecosystem.
There are other programs as well that need some fundi
Re: (Score:2)
I am sure that a good part of those who use 2+ year old kernels don't update it at all. Maybe there isn't an update system at all. For these people, there is no need for continued support, kernels don't expire.
So long, long term support is for those who need a particular old version (ex: for proprietary drivers), but still need that version to be updated (ex: for security). So really, it is for unmaintained proprietary drivers, and I understand the reluctance of the linux kernel maintainers to work for the
Still running 4.14? Pah! (Score:3)
I've got a 25 year old machine still running 2.4. Well, I say running , it gets booted about twice a month in order to use it as a long term backing store then switched off again. Don't need anything up to date to do that.
Nobody is still running them. (Score:4, Interesting)
Ehh.... I hava 2.4.32 system still "in production". (Yes, its on the internet, No it doesn't have any ports exposed to the internet, no it doesn't have user accounts).
I'm working to replace it the coming weeks.
Re:Nobody is still running them. (Score:5, Insightful)
How would no user accounts be a security plus? Do you do everything as root?
Re: (Score:2)
How would no user accounts be a security plus? Do you do everything as root?
It sounds like they are discussing something that is effectively an appliance. I am uncertain how extra user accounts would help here as everything that needs to be done within the device is management related... which is a root level function.
Android (Score:3)
Some of the impetus for LTS kernels was that IoT makers would base their products around whatever obsolete version of Android the reference design they were using supported.
But, the article suggests that Google trying to establish better standards among their partners. I never got six years of updates on my phone, alas...
Re: (Score:2)
> I never got six years of updates on my phone, alas...
https://www.fairphone.com/en/ [fairphone.com] ? Fairphone 4 supported till 2026 (should get Android 13, hopefully supported till 2027) . Fairphone 5 is planned for up to Android 18 (aka 8-10 years) . And after that it might still get support through LineageOS or e/OS/
If you really want to go on a crazy spree: https://postmarketos.org/ [postmarketos.org] , pick a phone which has mainline kernel support.
Or Apple's iPhone, which averages around 5 years of updates.
Re: Android (Score:2)
The iPhone is not an Android the OP asked about but gets 7 years of OS support after last sale + 2 years security updates. iPhone 5S currently is still supported with security updates (10 years)
FairPhone has made the claim several times and canâ(TM)t seem to want to hire a developer to actually build an updated Android. They currently average about 3 years of support after the last sale, every time they claim longer they end up blogging an apology with a litany of reasons, pointing the finger at everyo
Re: (Score:2)
Or Apple's iPhone, which averages around 5 years of updates.
Samsung pledges 5 years of security updates as well. So does Google with Pixels.
Re: (Score:2)
Apple pledges 5 years of *updates*. And when those are done, two more years of security updates.
Only now they have gone to 7 + 2 instead. From when they last sold them as new.
Re:Android (Score:5, Interesting)
This is my concern too. The iOT vendors might, might put out an updated image for their stuff if the CVE and bug is severe enough and impacts their application.
They will however ONLY do that if its going from 4.14.300 to 4.14.325 and the out of tree driver modules for the sketchy Chinese SOC at the core of their product build without issue.
In practice I suspect this change will mean a lot of small cheap devices that already saw little post market support beyond 18months of release will see exactly none.
Re: Android (Score:2)
Ubuntu 16.04 LTS (Score:5, Interesting)
How do they know the older kernels are not used anymore? Even Ubuntu 16.04 LTS which runs on the Linux 4.4 Kernel is still in ESM support by Canonical until 2026, I guess it will still be used in some numbers.
Re: (Score:3)
Sure, but companies like Canonical and IBM are not entitled to have anyone else maintain LTS kernels for free -- they can, and I think do, pay people to do that. Maybe it's practical for them to do it in-house, maybe they could fund the Linux Foundation to hire people, maybe there are other solutions.
Re: (Score:3)
I wonder how much it matters to them. Clearly their customers do value long term support of older operating systems.
Microsoft supports operating systems for 10 years. Windows 10 is due to go EOL in January 2025. What's interesting is that there is no upgrade path for many, perhaps most computers. Windows 11 doesn't support them.
Re: (Score:1)
Go IBM if you want real LTS.
https://www.longpelaexpertise.... [longpelaexpertise.com.au]
Take our CICS example above. IBM stated that all new CICS functions would only be command level from CICS/VS 1.4 in 1978. Smart CICS users would have seen the writing on the wall, and started planning their migrations. The last CICS to support macros was CICS/MVS 2.1.2, released in 1987. So that's 9 years. Even nicer, IBM continued to support CICS/MVS 2.1.2 until around 1996: Another 9. So users had 18 years to convert over.
Some apps could be running unmodified for 5 decades.
If you think migrating your "skyscraper/factory/chip fab" to a new foundation every 18-24 months is insane/stupid and all those hipster frameworks, programming languages and OSes that regularly go incompatible every few years or less aren't for you, you might actually have to consider IBM.
Yes it's going to be expensive but if you're going to have zillions of lines of code; rewriting, retesting,
"nobody" is not a literal statement (Score:1)
Re: (Score:2)
How do they know the older kernels are not used anymore? Even Ubuntu 16.04 LTS which runs on the Linux 4.4 Kernel is still in ESM support by Canonical until 2026, I guess it will still be used in some numbers.
4.4?
RHEL 7.1 is still in production [wikipedia.org] and uses 3.10.0-1160.
RHEL 6 is in extended support and uses 2.6.32-754.
So the quote about no one using old kernels like 4.14 doesn't sit quite right. Desktop users always want the latest and greatest, but anyone using Linux to drive an application doesn't really care, as long as things are stable and secure they're as happy as clams. Heck, the Linode instance running my email server is centos 8 and 4.18.0-513.el8. And as long as its secure and keeps serving my email I hav
Re: (Score:2)
As far as kernel.org is concerned, '3.10' has been end of maintenance since 2017. "2.6.32" has been end of maintenance since 2016.
EL8 uses 4.18, which was never "long term" and has been end of maintenance since 2018.
EL9 uses 5.14, which was also never "long term" and has been end of maintenance since 2021.
Besides, 'RHEL" kernel barely resemble the version number advertised. If you look at an 'out of tree driver' you'll see lovely things like:
#if ((LINUX_VERSION_CODE KERNEL_VERSION(3,17,0)) && \
Re: (Score:2)
So then companies such as Canonical (and RedHat) should be organising, funding and contributing the LTS for the kernels they use. If the mainstream kernel maintainers can't cope with the workload, others must take some of the burden.
Re: (Score:2)
Is there a reason why the people who work at Canonical can't backport relevant security patches themselves?
Perhaps it's time to re-evaluate old kernels in LTS. That, to me, has been the biggest reason to not use them: old kernels.
Re: (Score:3)
These days it's just popular to say that "nobody" uses old stuff. It's easy to forget how big this industry is.
As an ex UI designers, I get really pissed when marketing people decide to remove features because the telemetry tells them less than 3% of people use those features. How many millions of people are "nobody?"
The main issue (Score:2)
Corbet suggests maintainers talk to their employers about paying them for their maintainer work.
Companies want free, so something had to give and instead of paying people what they are worth, we get this. No CEO wants to impact their yearly bonus with paying people.
But, I have to wonder, is this due to IBM's purchase of RHEL ? With what is in the press about how IBM treats their employees, this should not be a surprise. About four years IBM buys RHEL, who probably supplied most of the labor, now IBM seems to be pushing down their philosophy. So people are getting burned out. The same thing happen
Re: (Score:2)
I am sure there are people here saying "what is Lotus ?".
There are certainly people here saying "Lotus? Ugh."
Notes was a perfect match for IBM because it was terrible.
Re: The main issue (Score:1)
I have a feeling that LTS of more than 2 years will come back eventually. RedHat was the main Linux contributor, LTS benchmark and I am considering all the apps and services plenty of distros use which they contribute to. When they restricted access to source code one has to assume everything they touch will be affected. When the other contributors pick up the slack things will begin to swing back the other way.
Re: (Score:2)
There are also a lot of IoT or embedded devices which are not easily updated. There was a time, decades ago, when once a device was put out, it would never, ever get upgrades in its service life, and that service could be for many years, such as CNC machines.
There needs to be some thought on devices which cannot be easily upgraded, do not connect to the Internet, and are not easily communicated with, such as some microcontrollers, or some items used for embedded use, such as a well pump controller. For th
Re: (Score:2)
IBM didnt do anything great with Notes.
However, people who don't like Lotus Notes fall into two categories.
1) They only used it for e-mail; and often don't realize it even does so so much more than that.
2) They don't understand frankly nothing short if ingenious architecture that allowed Notes to be an effective collaboration and process tool in a world intermittent networks.
Nothing screams ignorance like someone in an IT or IT adjacent industry dumping on Notes.
I dont care about the kernel version (Score:5, Insightful)
I prefer it if my LTS distribution of choice makes plans to upgrade the kernel version (potentially with a suitable config) at times when the old LTS kernel ends. There are very few userland things which break or require change if you update the kernel.
If you are *so* specific in the kernel version (e.g. embedded HW with specific non-mainline drivers or devices in which you are mandated under change control (medical, aerospace etc.) then you have to do your own thing anyway.
Re: (Score:2)
This is realistically the right perspective.
The kernel has been *very* good about preserving userspace compatibility. This has been largely explicitly been embraced in the "container" mindset where the kernel doesn't matter to "blind mate" as long as the base kernel keeps modern, and all the messy picky inter dependency is among userspace components.
The only things that are really screwed with are things that live in kernel space like drivers and such. Realistically speaking, LTS can't support those oddbal
Re: (Score:2)
Re: (Score:2)
I prefer it if my LTS distribution of choice makes plans to upgrade the kernel version (potentially with a suitable config) at times when the old LTS kernel ends.
The whole point of LTS is to *not* make major version upgrades of critical system components. I'd rather manage security externally or procedurally than have my software break.
Re: (Score:2)
That's the theory, but in practice, it's not something you can directly bank on anyway. The "longterm maintenance" has never been a hard promise and the likelihood of a backport for an issue depends on how hard it would be, how severe the problem, and how old the kernel in question is.
RedHat has been the only one to seemingly reliably support an 'old' kernel for years, and they do it by basically making the version number lie about what you are running to make you feel better. Turns out that going to new
Re: (Score:2)
I prefer it if my LTS distribution of choice makes plans to upgrade the kernel version (potentially with a suitable config) at times when the old LTS kernel ends. There are very few userland things which break or require change if you update the kernel.
This isn't really my area of expertise but I don't understand the benefit.
AFAIK the only things that a new kernel really affects is supported hardware (core stuff like motherboards) and drivers, some minor performance changes, and enabling new user-land stuff.
But if the userland isn't changing then you get none of that benefit. What's the use-case, the old motherboard dies and yank the drives and stick them in a fancy new computer?
And remember, the idea of LTS is for the computer as an appliance where it ca
Re: (Score:2)
The benefit would be that in practice, the long term maintenance isn't a nice hard promise *anyway* and in practice the distributions are moving on from those kernels for the vast vast majority of the userbase. So you may take solace that a lot of folks out there are running a kernel from 2018 because Ubuntu 18.04 is still widely deployed, but a lot of those deployments have new 'major' kernels, because frankly the kernel LTS doesn't promise much at its best.
It's a matter of reconciling the rosy theory (he
Re: (Score:2)
The benefit would be that in practice, the long term maintenance isn't a nice hard promise *anyway* and in practice the distributions are moving on from those kernels for the vast vast majority of the userbase. So you may take solace that a lot of folks out there are running a kernel from 2018 because Ubuntu 18.04 is still widely deployed, but a lot of those deployments have new 'major' kernels, because frankly the kernel LTS doesn't promise much at its best.
The benefit is stability. If I'm not LTS I want my stuff to keep working. That means bug fixes but nothing that might break the system.
It's a matter of reconciling the rosy theory (hey this kernel will show all restraint on new features, and I'll never want a new feature, *but* receive all the bugfixes and security fixes I could possibly want) versus the reality (kernel may or may not receive a fix, depending on hand wavy feelings of maintainers, and I'll also get frustrated when I can't deploy my stack new because the "stable" kernel declines to support my hardware, or I decide I really want one of those features that I swore I'd never need).
Then upgrade to a newer LTS release (or non-LTS if you really care).
But I don't see this scenario are you thinking of where you're planning to install a 2+ year out of date LTS release on a new hardware stack (or upgrading an existing system with some weird new hardware) but aren't willing to upgrade new a current release.
The old userland is going to stop you long before the
Re: (Score:2)
I suppose I'm not quite clear on your stance.
If your stance is that expecting kernel.org kernel LTS to last a long time and the users should be 'willing to upgrade new a current release", then I agree.
If your stance is that LTS means stability, but with updates, then we agree in theory, but in practice LTS is not so thoroughly bugfixed as we dream, so I think it's better to stop pretending that long term maintenance in kernel.org actually exists when in reality it doesn't live up to the expectations.
Re: (Score:2)
I suppose I'm not quite clear on your stance.
If your stance is that expecting kernel.org kernel LTS to last a long time and the users should be 'willing to upgrade new a current release", then I agree.
If your stance is that LTS means stability, but with updates, then we agree in theory, but in practice LTS is not so thoroughly bugfixed as we dream, so I think it's better to stop pretending that long term maintenance in kernel.org actually exists when in reality it doesn't live up to the expectations.
I'm talking about the distros. They get paid to support their old kernels and I think they probably do a decent job.
I don't think kernel.org has much reason to support LTS kernels since if anyone is using LTS it's customers for distros.
Re: (Score:2)
The thing I've personally seen break was a touchpad settings app. Kernel driver changes, then that version of the touchpad settings app doesn't do anything at all. Got to go to terminal, got to edit config files, got to restart a daemon to apply the changed configuration. Fine for an advanced user and nobody else.
Oh..that Market (Score:1)
Re: (Score:2)
It is a miracle we have Linux at all. Were it not for forward-looking people, we would still be paying $500 for a copy of an OS for a PC, $1500 for a compiler, $1000 for a word processor, and with inflation and subscriptions, those prices would be cheap. OS upgrade? $250 please. Want to add a new drive? Pay $250 for a high capacity drive license.
I can't think of any company that has not benefited from the Linux ecosystem. Even Mom and Pop's Vend-A-Goat shop likely has a web page sitting on a Linux ser
Russian bot masters will love this (Score:2)
Re: (Score:2)
Those cheap iOT devices were already ignoring any update efforts. If they were running a kernel version that was technically long term maintenance, it was a coincidence rather than plan.
Re: (Score:2)
Churning LTSs like churros (Score:4, Interesting)
I remember a few years back Greg boasted about having 2 (or more) LTSs per year, and supporting them "6 or more" years. A the time I tought "the maintainers will burn out, this will not last long". I was right on the first part, but wrong (and pleasantly surprised) about the second.
Hats of to the LTS kerenel maintainers for keeping the LTS graavy train going so long.
Having said that, two years is to short time. A better compromise wouls be a new LTS every 18 months, supported for longer, or other somesuch.
JM2C, YMMV
Re: (Score:2)
They release so many kernels, I'm honestly surprised they don't decrease the frequency of the 'stable' kernels. Back in the day, odd-numbered minor versions (eg. 2.3) would be considered "not stable" kernels. You could run them, they were often fine...
Now that they're primarily incrementing on the major release number, why not make all odd "major" releases "testing" releases where they've not done as much maintenance?
2 year LTS support is not realistic for govt (Score:1)
Why not just have TWO long term support versions plus the current version. One for every 3 years. So, currently have a 2020 LTS version and a 2017 LTS version and by then end of this year, decide on the new LTS 2023 version. When the 2023 version gets set, support the 2017 version only until they post the next Kernel build either at the end of 2023 or the first build in 2024. At that point, 2017 is dropped. And just move forward with two 3 year LTS versions going forward in a similar manner.
Places like
Re: (Score:2)
Re: (Score:2)
But will it though?
What exactly was Linux promising and to whom? The kernel doesn't offer 'support' in any formal capacity, it was promising to sometimes backport fixes to longterm maintenance. Note also that 'sometimes', and the likelihood of applying the backport already was a bit hand wavy, does it seem important enough? Is the kernel too old to 'bother' fixing, even if ostensibly under the lifetime advertised? The bug becomes less important if the kernel is 4 years old, because they already didn't wa
Re: (Score:2)
If you need an ATO certification, you pay for support, and this will have no impact at all on what you do. And if you need ATO, you already do this. None of the free distros would qualify for ATO anyway.
Re: (Score:2)
Maybe this should be a revenue stream. Offer LTS support for 10-20 years, but charge for it, which would fund the 6 year LTS support and 2 year markers.
Re: (Score:2)
That's pretty much what RedHat does. Having LTS support for only the kernel is pointless though. The whole software stack needs to be supported.
Nah... (Score:3)
2 years is a long-term rash. It's not long-term support.
4 years isn't enough better, either. This just enforces the update treadmill, and with it the effect of forcing multiple other segments to do the work. What segments?
PHP. Various database engines. Just two.
10 years is more appropriate (Score:1)
For anything with embedded systems, you want 10 years of support for the entire system, which includes bug-fixes for the core operating system.
Now, the issue is, who is going to pay for that level of support?
Now I feel guilty for not volunteering my time as a kernel maintainer.
Slight errata Re:10 years is more appropriate (Score:1)
"10 years" is just a good round number. For some systems, it's measured in decades, for others, it's less than 10 years.
But I'm willing to say anyone with a business (non-hobbyist) need over 10 years should be dealing with a vendor/partner who will support the kernel for the life of their products even without "official Linux support."
The retro-computing and other "I need to run an old kernel" hobbyists have the their own community who can keep legacy kernels "supported enough" for their needs for the next
Re: (Score:2)
For embedded systems, you are likely somehow stuck with a 'weird' kernel anyway, and some supplier is the only one credibly capable of supporting what they gave you. The kernel.org support has no meaning for you.
If you are blessed with a bill of materials well supported by the mainstream kernel, then you can happily expect to have updates available even 10 years out.... Though you'll have to actually go to new functional releases.
Hmmmm...... (Score:2)
No one may be using 4.14 but I do know for certain that the Android 12 installed on my phone uses version 4.19. My phone is a 2022 model so I suspect that Motorola will continue to update it for at least another two or three years. D
Re: Hmmmm...... (Score:2)
That depends on if Motorola supports your phone after that period. Theoretically, they could support your phone as long as your hardware is supported by the kernel. If motorola says "Hey, we're supporting your phone for 8 years", then they would keep updating the phone with a (hopefully) modern kernel. What kernels they support won't change whether or not your phone is updated. However, it does increase the maintenance burden.
Ultimately, it will probably end up with phones having shorter support cycles,
Just for comparison.... (Score:3)
Apple "does not haz" an LTSC, nor "does they haz" a formal policy, but it seems that their Kernel (Along with the rest of the OS/Distro) is supported for 3 Years.
Windows on Desktop has a formal policy of 5 years of support for Kernel+OS/Distro (Previously, it was 10) for version designated as LTSC, 18 months for others.
Windows Serves has 10 Years of support for Kernel and OS/Distro.
FreeBSD supports each major release for 5 years, each minor for 3 months.
Linux (the Kernel) has gone from 6 years to two, which in turn will have implications for both Desktop Distros and Server Distros...
We will see how this pans out, and more importantly, how distros and gadget makers (IoT, Industrial, embeded, consumer) adapt...
This favors Redhat and clones (Score:3)
If you don't like it, then contribute. (Score:2)
If your organization needs 6-year support, then perhaps reach out to them with your needs, and either contribute code or money to get it done.