Linux gives up on 6-year LTS kernels, says they’re too much work

https://arstechnica.com/gadgets/2023/09/linux-gives-up-on-6-year-lts-thats-fine-for-pcs-bad-for-android/

by rascul • 3 years ago

274 244 3 years ago

6 years seems like an incredibly long time to me. It's a bit of a shame, but looks like industry really didn't come out to support the idea.

2 years on the other hand seems incredibly short? Am I wrong?

LinuxBender• 3 years ago

That's 2 years of the upstream LTS kernel. I would expect that major Linux distributions such as Redhat RHEL and Canonical's Ubuntu would continue to do their extended patch cycles against one of the upstream snapshots as they have done in the past. I think 2 years for upstream LTS is probably fine if the vendor patching methodology remains true. This also assumes that the usage of smaller distributions such as Alpine are more commonly used in very agile environments such as K8's, Docker Swarm, etc... Perhaps that is a big assumption on my part.

inferiorhuman2• 3 years ago

6 years may seem like a long time, but check out what the competition is doing. Oracle is supporting Solaris 10 for 20 years, 11.4 for 16 years (23 years if you lump it in with 11.0). HP-UX 11i versions seem to get around 15 years of support.

It really depends on what you're doing, a lot of industries may not need such long-term support. 6 years seems like a happy medium to me, but then again I'm not the one supporting it. I expect the kernel devs would be singing a different tune if people were willing to pay for that extended support.

https://upload.wikimedia.org/wikipedia/en/timeline/276jjn0uo...

wkat42422• 3 years ago

Are those really competition anymore?

They're just legacy now IMO and their long term support requirements are a result of this, companies that haven't gotten rid of them by now aren't likely to do it any time soon.

I hate seeing them go. I wasn't such a fan of Solaris but I was of HP-UX. But its days are over. It doesn't even run on x86 or x64 and HP has been paying Intel huge money to keep itanium on life support, which is running out now if it hasn't already.

At least Solaris had an Intel port but it too is very rare now.

kube-system2• 3 years ago

Depends on where the computer is at, I guess. On a desk, 6 years is a pretty long time. In an industrial setting, 6 years is not very long of a lifecycle.

dathinab6• 3 years ago

consider that it's 6 years after release of the kernel version

so likely <5 years since release of the hardware in the US

likely <4 years since release of hardware outside of the US

likely <3 years since you bought the hardware

and if you buy older phones having only a year or so of proper security updates is not that unlikely

So for phones you would need more something like a 8 or 10 year LTS, or well, proper driver updates for proprietary hardware. In which case 2 years can be just fine because in general/normally only drivers are affected by kernel updates.

Gigachad• 3 years ago

What kind of breaking change would take longer than 2 years to deal with? The reality is that people wait out the entire 6 year period and then do the required months work at the end. If you make the support period 2 years they will just start working on it sooner.

Retric• 3 years ago

Many perhaps most projects don’t last 6 years, thus punting can save people a great deal of time.

dathinab6• 3 years ago

6 years is way to short for some use-cases, like phones

sadly it's not rare that some phone hardware proprietary drivers are basically written once and then hardly maintained and in turn only work for a small number of Linux kernel versions.

so for some hardware it might mean that when it gets released you only have noticeable less then 6 years of kernel support

then between starting to build a phone and releasing it 2 years might easily pass

so that means from release you can provide _at most_ 4 years of kernel security patches etc.

but dates tend to not align that grate so maybe it's just 3 years

but then you sell your phone for more then one year, right?

in which case less then 2 years can be between the customer buying your product and you no longer providing kernel updates

that is a huge issue

I mean think about it if someone is a bit thigh on money and buy a slightly older phone they probably aren't aware that their phone stops getting security updates in a year or so (3 years software support since release but it's a 2 year old phone) at which point using it is a liability.

EDIT: The answer is in my opinion not to have even longer LTS but to proper maintain drivers and in turn being able to do full kernel updates

xvilka2• 3 years ago

sadly it's not rare that some phone hardware proprietary drivers are basically written once and then hardly maintained and in turn only work for a small number of Linux kernel versions.

These manufacturers should be punished by the lack of LTS and need to upgrade precisely because of that lazyness and incompetence.

Hackbraten2• 3 years ago

That's one of the reasons Purism went out of their way to upstream all drivers for the Librem 5. The distribution can upgrade kernels pretty much whenever it wants.

The downside can be painful though: sourcing components with such properties is hard. You basically have to cherry-pick them from all over the world because they're so few and far between.

That's one of the reasons why the Librem 5 is so thick and consumes so much energy.

eimrine• 3 years ago

After your message I started to think about LTS with 6-years support but every 3 years a new LTS.

mschuster912• 3 years ago

sadly it's not rare that some phone hardware proprietary drivers are basically written once and then hardly maintained and in turn only work for a small number of Linux kernel versions.

The worst part of all of this is: Google could go and mandate that the situation improves by using the Google Play Store license - only grant it if the full source code for the BSP is made available and the manufacturer commits to upstreaming the drivers to the Linux kernel. But they haven't, and so the SoC vendors don't feel any pressure to move to sustainable development models.

mrweasel• 3 years ago

so for some hardware it might mean that when it gets released you only have noticeable less then 6 years of kernel support

Or they could just upgrade the kernel to a newer version. There's no rule that says that the phone needs to run the same major kernel version for its entire lifetime. The issue is that if you buy a sub €100 phone, how exactly is the manufacturer supposes to finance the development and testing of never versions of the operating system? It might be cheap enough to just apply security fixes to an LTS kernel, but moving and re-validating drivers for hardware that may not even be manufactured quickly becomes unjustifiable expensive for anything but flagship phones.

Ekaros• 3 years ago

All comes to cycle. When do you enter that 6 year LTS? Is there new LTS every year or every other year? If you enter 2 years in or even 4 years in. How much have you support left?

Do you jump LTS releases. So one you are on is ending and there is brand new available? Or do you go to one before and have possibly only 2 or 4 years left...

jauntywundrkind2• 3 years ago

Google showed up & offered to pay a huge amount of money to extend LTS support 3x, iirc.

At the time, Linux 4.14 was shipping I think.

Personally it made me a bit sad, because it created real permission for Android to never upgrade kernels. I'd hoped eventually Android would start upgrading kernels, thought the short LTS would surely force them to become a respectable ecosystem that takes maintenance seriously. Making Super LTS was a dodge; suddenly it was ok that 4.14 straggles along until 2024.

Also an interesting note, supposedly there's a "Civil Infrastructure Platform" that supposedly will have some support until 2029 for 4.14! The past never is gone, eh?

Supposedly Project Treble is a whole new driver abstraction in I think mostly userland (maybe?) whose intent is to allow kernel upgrades without having to rewrite drivers (not sure if that is the primary/express goal or was just often mentioned). I'm not sure if Android has yet shipped a kernel upgrade to any phones though; anyone know of an model running an upgraded kernel?

yjftsjthsd-h• 3 years ago

Personally it made me a bit sad, because it created real permission for Android to never upgrade kernels.

I would argue that it was still better than not doing that, because the vendors weren't going to properly keep up with kernels either way; the choice wasn't "support 3.x for longer or move to 4.x", it was "support 3.x for longer or watch Android devices stay on 3.x without patches".

jauntywundrkind2• 3 years ago

As the old adage goes, "chips without software is just expensive sand."

Yes what happened & happens is often monstrously unsupportable & terrible. For the past 6 years, Google rolling up with a dump truck full of bills has been justification to keep doing nothing, to keep letting kernel devices be bad.

Your history isn't even good or right. Old releases at the time didn't get official longer support. Canonical just opted to maintain a basically Super LTS 3.16 until 2020, regardless of the Google dump-truck-of-money thing going on here. Old phones got nothing directly from this payoff. Google was just paying for a way forward to keep doing nothing, to justify their ongoing delinquency & inactivity.

Which was unprincipled terrible and awful before, but which they basically bribed gregkh to suddenly make acceptable by at least paying for the privilege of being negligent do nothing delinquents on.

josephcsible5• 3 years ago

With the "never break userspace" guarantee, is there ever a reason to want to be on an LTS kernel instead of the latest stable one, other than proprietary kernel modules?

craftkiller5• 3 years ago

Yes, ZFS. When new, incompatible kernels are released the dkms build for the ZFS kernel modules will fail. By switching to an LTS kernel, I no longer have to worry because my kernel lags so far behind.

The alternative is using a pre-built package repo which will prevent the kernel from updating to an incompatible version using the package dependencies. I lived that way for years and it is an awful experience.

XorNot• 3 years ago

As a ZFS user, this really isn't a good enough reason IMO. Never break userspace really should be enough for most people.

phone8675309• 3 years ago

This wouldn't be a problem if OpenZFS didn't have a dogshit license.

kaylynb• 3 years ago

Sometimes breaking changes for ZFS are backported to LTS anyway.

raverbashing• 3 years ago

As opposed to what ZFS users think, very few people care about it

And in mobile, I'd say the amount goes to zero

Jhsto• 3 years ago

GPU applications are often less buggy on LTS (kernel, but also package sets)

josephcsible5• 3 years ago

Isn't the reason for kernel-related bugginess in GPU applications usually the out-of-tree proprietary GPU driver kernel module?

sambazi2• 3 years ago

came to say the same.

i absolutely despise breakage and random changes in my desktop environment

o11c• 3 years ago

Some kind of breakage is pretty common in random recent kernels. It might not affect you this time, but do you really want to risk it?

So yes - you do want to be on an LTS kernel. But you only need to stay there for about a year until the next one is released and you can test it for a bit before deploying.

josephcsible5• 3 years ago

do you really want to risk it?

That question applies to LTS kernels too. Do you really want to risk that a backport of an important fix won't introduce a problem that mainline didn't have? Do you really want to risk that there are no security vulnerabilities in old kernels that won't get noticed by maintainers since they were incidentally fixed by some non-security-related change in mainline?

xorcist3• 3 years ago

Lots of third party software hooks the kernel for various things, such as drivers for enterprise RAID or proprietary networking, and whatever it is Nvidia does these days. Those go far beyond the user space interface and are dependent on binaries staying unchanged. This is for them.

If you are running user space applications only on upstream supported hardware, there is no reason to stay with long time supported kernels, just follow the regular stable which is much easier for everyone.

blibble• 3 years ago

I figured that with the random bugs and policy changes (i.e. break ZFS again) that seem to appear in "LTS" mode on a regular basis

1970-01-01• 3 years ago

Going back to 2017, some of you knew this was not a tenable solution: https://news.ycombinator.com/item?id=15428340

zshrc• 3 years ago

They are a lot of work. And expensive to maintain. You’re not getting just 10 years of support from Red Hat, but 10 years of kernel support as well.

worthless-trash5• 3 years ago

14 years of RHEL 7 for ELS.

userbinator2• 3 years ago

It's really disturbing that software is the only thing whose stability seems to be decreasing very significantly over time, and dragging down everything that it's embedded in.

Who wants constant changes and breakage? Who wants software that's in constant need of updating? I'm pretty sure it's not the users.

titzer2• 3 years ago

There's always time to refactor and tinker with incomplete migration, always time to debug and patch and fuss with updates, but never time to sit down, gather all the requirements, redesign, and reimplement.

arcticbull• 3 years ago

Ultimately it's just a question of objectives. Usually software isn't written for its own sake. It's written to achieve a goal, meet a customer need, generate revenue, prove a market, etc. You can achieve those goals without gathering all the requirements, redesigning and re-implementing most of the time. Not in aerospace, or biomedical maybe, where we are willing to pay the outlandish velocity penalties. But most of the things we do aren't that.

Generally, if you want to build a pristine, perfect snowflake, a work of art, then you'll be the only one working on it, on your own time while listening to German electronica, in your house. [1] Nothing wrong with that - I have a few of those projects myself - but I think it's important to remember.

Linux is hoping to adjust the velocity-quality equilibrium a little closer to velocity, and a little further from quality. That's okay too. Linux doesn't have to be everything to everyone. It doesn't have to be flawless to meet the needs of any given person.

[1] https://www.stilldrinking.org/programming-sucks

userbinator2• 3 years ago

The software version of "There's always time to do it twice, but never time to do it right?"

gemstones• 3 years ago

If you think about the fact that higher level languages are largely a 1950s innovation, it helps.

Disciplines that are 70 years old are not likely to be stable.

jupp0r• 3 years ago

The point of LTS kernels is that they do get constant updates ie that security patches are backported. There is no world in which you can avoid updating frequently.

usr1106• 3 years ago

There are many more updates than security updates coming to LTS kernels all the time.

Kernel updates are more often than not even categorized in any way. Only for very prominent vulnerabilities the security impact is clear to a larger audience.

makeitdouble• 3 years ago

I understand the sentiment, while also looking at our computing devices' market where the fight for repairability is pretty harsh and far from a given.

Same for cars that are becoming less and less repairable and viable in the long term, medical devices are now vulnerable to external attack vectors to a point the field didn't predict, and I'd assume it's the same in so many other fields.

One could argue those are all the effect of software getting integrated into what where "dumb" devices, but that's also the march of progress the society is longing for...where to draw the line is more and more a tough decision, and the need for regulation kinda puts a lot of the potential improvements into the "when hell freezes" bucket. I hope I'm deeply mistaken.

imtringued2• 3 years ago

That is how C rolls. In theory you need to formally verify every single C program to ensure that it does not violate memory safety. Yes, that is akin to the same straightjacket that people complain about in that iron oxide language.

athrun2• 3 years ago

As an ex-Novell/SUSE employee this makes sense to me. Upstream is supposed to keep marching onwards.

Backporting is _so_ much work. And it's unfortunately not sexy work either, so it's always going to be hard attracting unpaid contributors for it.

If you need stability and long term support as a customer, you have companies like RedHat or SUSE whose entire point is providing 10+ years maintenance on these components.

structural2• 3 years ago

Unfortunately, none of these companies providing 10+ years of maintenance are doing so for most embedded devices. We either need to get SoC vendors to update their kernel baselines regularly This is hard, we've been trying for a decade and not seen much progress. Alternately, get them to backport fixes and patches (there's actually been quite a bit of progress here in getting them to actually take updates from the stable kernel at all! And that's getting thrown away now...)

worthless-trash5• 3 years ago

If they got their fixes upstream , they would be pulled into the same build tree that centos and rhel uses.

qznc• 3 years ago

The effect of EU’s Cyber Resilience Act will be interesting. It requires maintenance, at least for security fixes.

nudgeee• 3 years ago

Isn’t this what the Civil Infrastructure Platform (CIP) initiative [0] was also proposing? Maintenance of Linux kernels on the 10+ year horizon aimed at industrial use cases. Has backing from Toshiba, Hitachi, Bosch, Siemens, Renesas, etc, though a marked lack of chip vendors as members. Not really sure how well it is going though.

[0] https://wiki.linuxfoundation.org/civilinfrastructureplatform...

pxc• 3 years ago

Unfortunately, none of these companies providing 10+ years of maintenance are doing so for most embedded devices.

But why do these devices need special kernels anyway? Isn't that the real problem?

kelnos15• 3 years ago

Not sure who the "we" is that you refer to, but Google (and Samsung, and other Android manufacturers, as well as companies building other Linux-based embedded/IoT devices) could band together and create a "Corporate Embedded Linux Consortium", and pool some money together to pay developers to maintain old kernel versions.

If the mainline kernel devs are uncomfortable allowing those to be official kernel.org releases, that's fine: the CELC can host the new versions themselves and call the versions something like "5.10.95-celc" or whatever.

I don't get why this is so difficult for people to grasp: if you want long-term maintenance of something, then pay people to maintain it long-term. It's a frighteningly simple concept.

But yes, it'd be better for SoC vendors to track upstream more closely, and actually release updates for newer kernel versions, instead of the usual practice of locking each chip to whatever already-old kernel they choose from the start. Or, the golden ideal: SoC vendors should upstream their changes. But fat chance of that happening any time soon.

(there's actually been quite a bit of progress here in getting them to actually take updates from the stable kernel at all! And that's getting thrown away now...)

I found this statement kinda funny. If the original situation was that they wouldn't take updates from the stable kernels, then what were all those unpaid developers even maintaining them for? It's bad enough that it's (for most people) unrewarding work that they weren't getting paid for... but then few people were actually making use of it? Ouch. No wonder they're giving up, regardless of any progress made with the SoC vendors.

throwawaymqsh• 3 years ago

it's unfortunately not sexy work

What comprises sexy work in programming?

samtho• 3 years ago

New features, typically.

xnorswap2• 3 years ago

I don't know what the definition of "sexy work" is, but rewarding work in programming is solving interesting problems.

Backporting fixes isn't generally interesting problem solving.

esrauch2• 3 years ago

Are you flagging the word "sexy" or are you asking whether some important projects are fun and exciting and other important projects boring?

Surely maintaining 40 year old bank Cobol code is important but it's not considered fun and exciting. Rewriting half of skia from C++ into Rust is arguably not important at all but it's exciting to the point that it reasonably could make the front page of HN.

neurostimulant• 3 years ago

If you need stability and long term support as a customer, you have companies like RedHat or SUSE whose entire point is providing 10+ years maintenance on these components.

Is that even feasible for projects like the Android kernel that distributes their fork to vendors when RedHat forbid redistribution of their source code?

pmontra• 3 years ago

My phone is running a minor version of 4.4 from March 2023. Kernel 4.4 is originally from 2016. This means that they are still patching the kernel after 7 years even if it's not a LTS version.

brnt• 3 years ago

Is Google's Android Linux tree something distros could use as LTS?

phh• 3 years ago

Google pays gregkh to make LTS (not all LTS are made by him though), and he works mainline first, so it's already working that way

pjmlp3• 3 years ago

Hardly, given how the Linux kernel is an implementation detail, Linux drivers are considered legacy (all modern drivers should be in userspace since Treble, written in Java/C++/Rust), and the NDK doesn't expose Linux APIs as stable interface.

So not something to build GNU/Linux distributions on top of.

TowerTall• 3 years ago

Microsoft is famed for their backwards combability. How do they achieve this? By hard work and a lot of "if version == x" spread throughout the code? Or is because of their development process or do they plan and design for backwards combability from day one?

zik• 3 years ago

A friend who worked at MS tells me that there's a huge amount of "if version" in their code. Apparently it's at the level where it's a big maintenance headache.

somsak2• 3 years ago

maintenance burden has to be felt somewhere. it's nice when the vendor does it for you.

spondyl• 3 years ago

A running theory was that Windows 9 was skipped because of all the "if version contains 9" logic for 95, 98 etc

I don't think it was ever anything more than speculation though

13of40• 3 years ago

When I worked in Windows they had entire teams dedicated to backwards compatibility testing and "sustained engineering". At the end of every release cycle there would be a multi-month effort to pack up all of our test automation and hand it off to another team who owned running it for the next several years. Plus SLAs with giant companies that could get you camped out on the floor of a datacenter with a kernel debugger if you pushed out a broken update. It was never a totally perfect system, but they invested a lot of effort (and money) into it.

phendrenad22• 3 years ago

Microsoft ships an entire OS and apps too. Hard to break an API when the teams using it can walk down the hallway and yell at you.

t0mas88• 3 years ago

They go much further than that, checking and fixing compatibility with all kinds of third party software.

heavyset_go2• 3 years ago

There's a difference between backwards compatibility and backporting. For either, Microsoft can afford to pay engineers to maintain them.

But backwards compatibility isn't what kernel developers are maintaining, they're backporting things like security fixes to older versions of the kernel.

It would be like if a security fix is implemented in Windows 11, and Microsoft also chose to patch the same change in Windows 10. At some point Microsoft decides that older version of Windows won't get new updates, like how Windows 8.1 stopped receiving them this January.

What kernel developers are deciding is that sufficiently old enough kernel branches will stop receiving backports from newer kernels.

knallfrosch2• 3 years ago

Windows 8.1 was released in 2013, with suppport ending in 2023 - a 10 year support window (backporting security fixes.) And Linux cuts from 6 to 2?

I think you just stressed TowerTall's point.

runeks2• 3 years ago

They achieve it by paying developers to do it (instead of relying on unpaid volunteers).

caskstrength2• 3 years ago

Did you read the article? It has nothing to do with backward compatibility.

xorcist3• 3 years ago

Microsoft sunsets their stuff all the time. It's just that they're competing with Google and Apple now, so they're actively trying to push this line to differentiate where they can.

Try to use only a ten year old printer driver sometime. It's a pain. Linux executes 20 year old code with no problem, as long as you kept all the pieces. How do they do it? Never merge anything that breaks known user space. Easy in theory, hard work in practice.

If you want to run applications from the 90s, you're likely to have more success with dosbox or wine than with a plain Windows. Didn't Microsoft completely give up on backwards emulation a few years ago and started virtualizing it instead, with mixed success?

Of course, if you really want something famous for backwards compatibility, look at OS/400 and z/OS. It's all layers of emulation from the hardware up in order to guarantee that an investment in that platform is future proof. It's all expensive in the end of course, as someone has to pay for it, but they live well on the customers who value such things. Running 50 year old code there is commonplace.

rahen2• 3 years ago

IBM i is stellar in design, compatibility, quality, efficiency, reliability, consistency and security. x86 and Linux pale in comparison.

I wish IBM hadn't fenced it so much like a walled garden. Had they issued inexpensive or free licenses for OS/400 targeted to students and developers, maybe also an emulator to develop conveniently on x86, their i platform would probably be more commonplace now, with quite a bit more available software.

What is killing their platform is not the price but mostly the lack of skills and software. And it's probably too late now to change course.

justsomehnguy• 3 years ago

Didn't Microsoft completely give up on backwards emulation a few years ago

Bwahah! AppCompat traces to Windows 95.

romanovcode• 3 years ago

Not sure about printers but 20+ year old games run surprisingly fine on Windows 11

jeroenhd• 3 years ago

Microsoft dropped 16 bit support on 64 bit machines, but that was becomes 16 bit support on 32 bit was already using emulation/virtualisation, and so did 32 bit on 64 bit. Emulating a 16 bit emulator inside the 32 bit emulator would be too much, even for Microsoft.

Microsoft does drop backwards compatibility sometimes, usually because the backwards compatibility layer leaves a huge security risk.

tored• 3 years ago

Yes, old printer drivers yes for Windows can be a problem, often because of the 32 to 64 bit switch, I have that exact problem with an old printer that still works but can't get it to install on 64 bit.

20 year old software is rarely a problem, I'm running Office XP on Windows 10 without problems.

worksonmine2• 3 years ago

Are you really comparing a multibillion dollar company to an open source project?

Also this has nothing to do with backwards compatibility, it's about supporting older kernels with security fixes and similar. The decision is a pragmatic one to lessen the burden on the unpaid volunteers.

Like others have mentioned if a company needs a specific kernel pay up. Or use Windows.

Don't compare apples to oranges.

dathinab6• 3 years ago

in my opinion for anything internet connected not updating the kernel is a liability

security patches of an LTS kernel are as much updates as moving to a newer kernel version

custom non in-tree drivers are generally an anti-pattern

the kernel interface is quite stable

automated testing tools have come quite a way

===> you should fully update the kernel LTS isn't needed

the only offenders which makes this hard are certain hardware vendors mostly related to phones and IoT which provide proprietary drivers only and also do not update them

even with LTS kernels this has caused ton's of problems over time maybe 6-years LTS being absconded in combination with some legislatures starting to require security updates for devices for 2-5 years *after sold* (i.e > released) this will put enough pressure on to change this for a better approach (weather that are user land drivers, in-tree drivers or better driver support in general)

polskibus2• 3 years ago

Won’t the new right to repair regulations both in eu and us affect this stance?

ghaff5• 3 years ago

Why? You have the right to backport fixes yourself to your heart’s delight. Right to repair doesn’t require someone else to do the work for you for free.

diffeomorphism9• 3 years ago

Because. The "new right to repair regulations" aim to improve sustainability and that includes repair and support and upgrades, e.g. see

https://www.androidauthority.com/eu-smartphone-updates-rules...

Right to repair doesn’t require someone else to do the work for you for free.

The term maybe not, but the proposed legislation totally does. Same as warranties or customer protection or not using toxic materials or ... ; none of that is "for free" to the manufacturer, but it is mandatory if you want to be allowed to sell your product.

mrintegrity• 3 years ago

How? It's open source and Free Software, literally guaranteing the right to "repair" your code. Maybe I don't understand your question but it seems totally unrelated to the concept of an open source support cycle

diffeomorphism9• 3 years ago

https://www.androidauthority.com/eu-smartphone-updates-rules...

https://ec.europa.eu/info/law/better-regulation/have-your-sa...

Maybe I don't understand your question but it seems totally unrelated to

The discussion title is "Designing mobile phones and tablets to be sustainable" and lists the following aims:

- mobile phones and tablets are designed to be energy efficient and durable

- consumers can easily repair, upgrade and maintain them

- it is possible to reuse and recycle the devices.

This hence includes both repair and support and according to the linked article for N years. Seems very relevant.

caskstrength2• 3 years ago

Device manufacturers can provide support for kernel used by their products themselves, pay some distro vendor to do it for them or contract maintainers directly. You expect Linux or Greg to do it for free because EU says so or what?

polskibus2• 3 years ago

I didn't say for free. It can be factored in the initial price of the product.

vermaden2• 3 years ago

On the contrary the FreeBSD project offers stable 'LTS' release for 5 years each.

What I mean by that is each 'major' version with stable API/ABI has a life span of about 5 years - like 5 years of 12.x version, 5 years of 13.x version, etc.

... and all that with having about only 1/10 of the Linux people count (rough estimate).

pengaru2• 3 years ago

... and all that with having about only 1/10 of the Linux people count (rough estimate).

It's easy to offer a long LTS release cadence when your project is stagnant.

ktaylora• 3 years ago

It's pretty active, actually. Look at the release notes for FreeBSD major versions. Some folks think the release engineering team is too active and that major versions should be supported for more than ~5 years.

vermaden2• 3 years ago

If this [1] is stagnant then I do not know what is not ...

[1] https://cgit.freebsd.org/src/log/

ladyanita222• 3 years ago

Yeah FreeBSD is not happening, sorry.

Gud• 3 years ago

What do you mean? I've witnessed many exoduses in technology, the most obvious ones being MySQL > PostgreSQL. And from PHP to JS & Python.

I don't think it's too far fetched for people clinging to their favorite GNU/Linux distro to switch to FreeBSD, especially on the server side where in my opinion, FreeBSD is the superior choice.

I think the world is better off when there are choices and the Linux near mono culture is not good for the FOSS movement, in my opinion.

PedroBatista• 3 years ago

Good thing it already happened and keeps going.

phicoh• 3 years ago

A difference is that the FreeBSD has to maintain two versions most of the time and sometimes three versions.

At the moment there are 12.x and 13.x. 14.x is in beta, so soon there will be three. But 12.x is expected to be dropped at the end of this year, so in 2024 it will be back to two versions.

As far as I can tell there are a lot more Linux kernels in LTS at the moment.

throw0101b• 3 years ago

But 12.x is expected to be dropped […]

Not "expected", rather than that being the policy: five years is ending.

* https://www.freebsd.org/security/#sup

December 2018:

* https://www.freebsd.org/releases/12.0R/

* https://www.freebsd.org/releases/

kelnos15• 3 years ago

FreeBSD's major release cycle is much longer than that of the Linux kernel (which makes sense, since FBSD has to maintain the entire OS, not just the kernel). Right now they have two active major release series, and there's a new one every 2.5 years or so.

The Linux kernel has a new major release every two months, and it looks like LTS kernels are one out of every five or six major versions, so that's a new LTS kernel every 10-12 months; right now they have six LTS kernels to maintain.

Also I expect that the Linux kernel develops at a much more rapid pace than the FreeBSD kernel. That's not a knock on FreeBSD; that's just the likely reality. Is that development pace sufficient to support thousands of different embedded chips? Does the FreeBSD project even want to see the kind of change in their development process that an influx of new embedded developers would likely entail?

runeks2• 3 years ago

The other big problem is the burnout from maintainers, which are often unpaid and could use a lot more support from the billion-dollar companies that benefit from using Linux.

This is the crux of the issue: putting the maintenance burden on unpaid volunteers instead of having the burden be carried by the companies that profit from the 6-year LTS.

justincormack• 3 years ago

To be fair some companies do maintain LTS kernels like Red Hat but they choose different kernel versions than upstream LTS and backport different things so it doesn’t have much crossover with these ones now.

INTPenis2• 3 years ago

Spot on, I mean who wants 6 year LTS support? Must be big old slow enterprises and possibly banks, government agencies, so pay up.

cvwright• 3 years ago

In practice, that would require those companies to pay for a distro like RedHat, who supports a lot of the kernel dev work.

But unfortunately everyone would rather find a way to get RH packages for free, and RH/IBM has only made the situation worse by alienating people.

supertrope2• 3 years ago

Windows is supported for 10 years if you upgrade on day one. No special support contract needed.

rlpb2• 3 years ago

Canonical volunteered to maintain LTS kernels within the community, but upstream refuses to accept Canonical's contributions - ironically because apparently they "don't work within the community". Source: https://lwn.net/Articles/608917/

Canonical maintained them anyway, though, just not officially. Sources: https://lwn.net/Articles/618862/ https://lwn.net/Articles/667925/ https://lkml.org/lkml/2015/12/15/538. I don't see more recent announcements; I don't know if they stopped because of continuous rejection of their community contributions from upstream, or if they are continuing anyway and I'm not aware.

Disclosure: I work for Canonical. I'm not authorised to speak for Canonical, expressed opinions here are my own. [Edit: I should add that I don't work on the kernel so I feel like I'm as much an outside observer as you probably are]. But I'm not sure I'm even expressing an opinion here - just citing some relevant, publicly verifiable facts.

pseg134• 3 years ago

It switched to your opinion when you said ironically and didn’t list the real reason the upstream patches were rejected.

gjvc• 3 years ago

canonical ceased to be relevant with the usability disaster that was the hype-driven unity desktop.

PH95VuimJjqBqy• 3 years ago

There's a difference between a company volunteering money/employees and a company taking over maintenance of the branch itself.

If Canonical was not willing to do the former, it implies the kernel developers were correct.

yummypaint• 3 years ago

This would be a good use case for government grants. The system to administer them is already there. It's beurocratic but it is free money that could support developers long term. It could probably be argued the DOE should offer funding due to the national security etc implications of open source maintenance.

mhitza• 3 years ago

The Linux Foundation "harvests" a couple hundred million dollars a year [1]. They could easily spend more on maintainers. I can't easily find exact number, but Torvalds is paid between 1-2 million dollars a year by The Linux Foundation. They could support other volunteer maintainers as well.

[1] https://lunduke.substack.com/p/linux-foundation-spends-just-...

infamouscow• 3 years ago

The Linux Foundation's 990 form for 2022 is available. Page 2.

https://projects.propublica.org/nonprofits/organizations/460...

5Qn8mNbc2FNCiVV• 3 years ago

I have zero issues with Linus being paid 1-2 million dollars per year

sylware2• 3 years ago

My opinion is that 6 years is not enough, I would target 10 years.

But I guess the core of the issue is planned obsolescence in linux internals. Namely the fear of missing out some features which require significant internal changes and which if linux is without could lower its attractiveness in some ways.

It all depends on Linus T.: arbitration of "internals breaking changes".

worksonmine2• 3 years ago

Do you have the resources to achieve that target and still move the project forward?

If I could ask anything from Linus it would be to be a little more relaxed about the "never break userspace" rule. Allow for some innovation and improvements. There are bugs in the kernel that have become documented features because some userspace program took advantage of that.

sylware2• 3 years ago

Arbitration, which is ulitmately in the hands of Linus T.

Where ABI stability is paramount for Linus T., ABI bugs will become features.

The glibc/libgcc/libstdc++ found a way around it... which did end up even worse: GNU symbol versioning.

Basically, "fixed" symbols get a new version, BUT sourceware binutils is always linking with the latest symbol version, which makes generating "broad glibc version spectrum compatibility" binaries an abomination (I am trying to stay polite)... because glibc/libgcc/libstdc++ devs are grossely abusing GNU symbol versioning. Game/game engine devs are hit super hard. It is actually a real mess, valve is trying technical mitigations, but there are all shabby and a pain to maintain.

Basically, they are killing native elf/linux gaming with this kind of abuse.

ralferoo• 3 years ago

Some comments are saying that the 6-year LTS is needed to support older Android devices. Also, in practice most vendors don't bother releasing updates to phones after the first 2 years, other than security updates.

One possible nice side-effect of not maintaining kernels for so long and allowing people to stay on out-of-date systems would be to encourage vendors to allow users to upgrade to the newer versions of Android for more than the current 2 year life span. They are then more likely to put pressure on their component vendors to get kernel support for their chipsets into mainline so they don't have the excuse that they can't provide updates because the hardware isn't support by modern firmware.

compiler-devel• 3 years ago

Could this be a reaction to RedHat’s latest position on RHEL rebuilders? Did kernel devs see RH as freeloading on the LTS kernels?

tuna742• 3 years ago

Absolutely, especially since RHEL never used the LTS Linux kernels. /s

dingi• 3 years ago

Good move! At least, this will push those pesky Android OEMs to make their drivers available upstream. Its time we have a standardized environment for mobile/embedded use cases like the one we have for PCs. All these stupid little devices filling the junk yards because some greedy OEM didn't want to update their drivers is ridiculous.

ksec• 3 years ago

And yet most of the Synology NAS are still running on 4.x kernel.

tuna742• 3 years ago

Mine runs on 5.10...

kashyapc• 3 years ago

(Disclaimer: I work for Red Hat, but I don't work on the kernel. I'm a user-land mammal, and sometimes work with kernel maintainers to debug issues.)

It makes total sense and I support this. I've met some of the upstream Linux maintainers at conferences over the years. Some (many?) of them are really oversubscribed and still plug away. They need relief from the drudgery of LTS stuff at some point.

Anyone here involved in backporting fixes to many stable branches in a user-land project will relate to the problem here. It's time-consuming and tedious work. This kind of work is what "Enterprise Linux" companies get paid for by customers.

phendrenad22• 3 years ago

This is why I like MINIX. They last LTS release was 9 years ago and it's still just as unsupported as ever!

Linux gives up on 6-year LTS kernels, says they’re too much work

Related Stories