Linux LTS Kernels To Now Be Maintained For Six Years (phoronix.com)

An anonymous reader writes: In a bid to help Android smartphone vendors the Linux LTS (Long Term Support) kernels will now be maintained for a period of six years. The Linux LTS initiative backed by the Linux Foundation has supported annual LTS kernels for two years worth of updates, but that is being changed for Linux 4.4+ at the request of Google and their Project Treble. This means the Linux 4.4 LTS kernel will be maintained through 2022 and the upcoming Linux 4.14 LTS through 2023 for security/bug fixes in order to last a complete "device lifecycle."

Comments

Galaxy S7 still on 3.18.14

[fred6666]

My Galaxy S7 is still on 3.18.14. That's the oldest kernel I'm running on any of my devices.

Re:Galaxy S7 still on 3.18.14

[WaxParadigm]

Was your S7 made in 2015? No OS updates?

Re:Galaxy S7 still on 3.18.14

[fred6666]

they update the OS, and even the kernel (the build date is August 2017). But they stay on the 3.18 branch for some reasons, (if it's not broken, laziness)

Re:Galaxy S7 still on 3.18.14

[fred6666]

my router is on 4.4.50 (LEDE 17.01) and my server is on 4.9.30 (debian stable)

I haven't checked my toaster however.

Re:Galaxy S7 still on 3.18.14

[lactose99]

IIRC 3.18 was the last of the 3-series kernels tagged as LTS. My 2017 phone also uses 3.18 (3.18.31 specifically)

Re:Galaxy S7 still on 3.18.14

[Doctor Memory]

FWIW, my S8+ is on 4.4.16. Wonder if we'll get an update to 4.9 or 4.12 within a year. Not holding my breath, but....

Terrible practice.

[iCEBaLM]

Huge waste of resources backporting when it would be easier to just upgrade to the latest kernels. Either way you have to test them, so why bother backporting?

Re:Terrible practice.

[EndlessNameless]

Because in the commercial world, there are a lot of "finished" products. (Talking about both software packages and embedded/firmware.)

Updating the original kernel with security patches is much more likely to succeed compared to upgrading to a newer kernel. Either way it will need testing, but a new kernel is more likely to require significant developer time.

Why the difference? Several reasons: The available documentation and expertise may be insufficient. The original devs are no longer available, so the work will have to be done by new guys. Upgrading kernels or frameworks can start a waterfall of changes due to other modules that must also be updated; diagnosing problems is much harder when half of the underlying platform has been modified.

To put it simply: if Linux is not your primary business, but you do build things on top of Linux---then you want minimal changes during the lifespan of your product. Having separate long-term branches is the best way to balance the need for progress and the need for a stable platform.

Four years is still too short for a lot of equipment, but it's better than two years. As more corporate money seeps into Linux, I would expect to see LTS support extend further. Almost every business would benefit from 5+ years, and a decent number would probably benefit from 10. Microsoft supports Windows for ~10 years from its GA date, and their embedded presence is miniscule in comparison to Linux.

Re:Terrible practice.

[phantomfive]

The Linux kernel has such a strong commitment to backwards compatibility for user-land that they don't really need LTS. Upgrading the kernel should never break things.

However, these Android manufacturers are modifying the kernel source code, and often in sloppy ways. Because of that, it's more difficult for them to upgrade to a new kernel.

Obviously that's a poor design decision, but poor design decisions mean the code is also probably sloppy, meaning they've dug themselves into an even deeper hole.

Re:Terrible practice.

[ckatko]

I think the point is that the UPGRADE has been either so expensive, or so fault-ridden that nobody is doing it in practice. ala "If it works, don't fix it."

But, I don't know the entire corporate/political environment. Could it be a bunch of lazy companies? Maybe. Could it be the Linux foundation has no power so they're doing this because they feel screwed? Maybe... but I'd really need more data and insight into this matter before I can really condemn any party in this scenario.

Re:Terrible practice.

[Zappy]

And this is EXACTLY why there shouldn't be LTS kernels.

Hardware manufacturers should get with the program, work hard and get their driver included in mainline.

All problems solved.

Re:Terrible practice.

[thegarbz]

Sure on a desktop PC or a server I'd agree with you. But Linux dominates the embedded world where a simple kernel upgrade may break an untold amount of bespoke hardware. Providing an LTS version with only critical fixes being applied makes it easier for companies of custom hardware to keep supporting that hardware.

Re:Terrible practice.

[swillden]

Huge waste of resources backporting when it would be easier to just upgrade to the latest kernels. Either way you have to test them, so why bother backporting?

Because it's not easier to upgrade, obviously. You don't think this was done lightly, without serious analysis of the options, do you?

It's possible that it's easier to upgrade than backport in terms of total effort... but it's equally possible that it's not, because of the large number of non-mainlined patches applied to Android kernels. There's a tradeoff between porting the patches to every new kernel version or backporting security fixes. There are more fixes, but they tend to be small, so the tradeoff favors backporting up to some point, and it may well be that that point truly is closer to six years than two.

But even if total effort calculation would favor upgrading, there's a structural issue to consider. SoC vendors are the ones who define the supported kernel for each SoC iteration -- it's largely their patches that are applied. They don't want to do the work of customizing and validating every new kernel version on every SoC still in support. Worse, trying to make them do it will encourage them to further reduce the duration of their support for an SoC because it's a lot easier to validate 4.14 on the latest and greatest chip than do to it on the last three generations.

See, no one other than the SoC vendor is really in a position to get a new kernel version running on a given chip, but almost anyone can backport a security patch. In particular, Google can -- and does -- do that work. Google can fix problems and deliver security patches directly to OEMs, who can then apply and test (and then carriers will also test). Assuming all goes well, the SoC vendors don't have to get involved. In contrast, kernel version upgrades pretty much have to be done by the SoC vendor.

In addition to that, rightly or wrongly (and probably rightly), OEMs and carriers are more afraid of kernel upgrades than backported security fixes. They much prefer that it be possible to launch a device with a specific kernel image and vendor partition image (device-specific software) and then leave it all completely untouched for the life of the device, except for security fixes. Project Treble is about enabling the system image to be updated and it's tough enough to convince them to allow that. Being able to keep the bottom layers constant makes them much more comfortable -- and therefore much more likely to continue supporting devices with both system upgrades and security fixes, for a longer period of time.

Re:Terrible practice.

[_merlin]

Having drivers in mainline only guarantees they'll continue to compile, not that they'll actually continue to work. The Linux kernel team don't have every piece of esoteric hardware available for testing, or the resources to test every driver. Then there are whole classes of drivers that the Linux kernel developers are philosophically opposed to and would never include (for example Chelsio T4 TCP Offload Manager). It's nice not to have your kernel ripped out from under you.

Re:Terrible practice.

[CustomBuild]

The Linux kernel has such a strong commitment to backwards compatibility for user-land that they don't really need LTS. Upgrading the kernel should never break things..

OMG, thank for the good laugh. I haven't heard something as funny as this, in a quite a while.

Re:Terrible practice.

[phantomfive]

It would have been better if you'd actually given an example.

Re:Terrible practice.

[epyT-R]

At least if they compile there's a chance that someone will submit a bug report..or even submit a patch to get it working.

Re:Terrible practice.

[Anonymous Coward]

Yeah, the stupid and ignorant usually laugh a lot. It doesn't make them any smarter or knowledgeable though. The people in the know though, knows that breaking userland is actually one of the easiest ways to incur the wrath of the Linus.

Your retarded Nvidia drivers are not userland.

Re:Terrible practice.

[mcrbids]

At my company, we use Enterprise Edition OS (CentOS or RHEL) specifically because of the long, long term support. Think: a decade.

For our product, we used RHEL 4 for its entire duration, and then jumped to EL 6, where we are now. We will probably not use EL 7 but go to EL 8 if it's available at or before the EL 6 EOL.

How is six years a complete device lifecycle?

[RhettLivingston]

Most of my life, I've received 20 to 30 years of service out of appliance-class products such as televisions, refrigerators, stoves, microwaves, washing machines, and dryers. I have noticed a steep downtrend in those lifecycles, particularly in televisions, washing machines and dryers. But that reduction has been due to engineering choices in the machinery.

Now I'm interpreting this as an indication that devices with Android are targeting a six-year lifecycle!!! No way.

Android is in all of the above device types today and even in our cars. Android needs to be thinking in terms of how to at least maintain security updates for 30 years. Perhaps that may have to involve some standard pluggable module so that the hardware can be upgraded too, but it has to happen. The ever falling device lifetimes are soaking up both the piddling economic growth of the middle class and our resources.

Re:How is six years a complete device lifecycle?

[drinkypoo]

Android is in all of the above device types today and even in our cars. Android needs to be thinking in terms of how to at least maintain security updates for 30 years.

Instead, the industry is thinking about ways to replace your car after only ten years.

If they make cars last longer then sooner or later they'll make it easier to replace all that infotainment stuff. Then there will be an upgrade path, albeit an expensive one.

Re:How is six years a complete device lifecycle?

[DaveM753]

Agreed.

Sounds like Google is using this as an excuse to limit support on otherwise perfectly good hardware to an arbitrary six-year limit as defined by a vendor. Never mind that fact that devices can very easily be upgraded to newer linux versions.

They've already ended product support for their "Do no evil" mantra.

Re:How is six years a complete device lifecycle?

[RhettLivingston]

My current vehicle is 11 years old and with only 90K miles likely has another 10 on it. The infotainment unit is indeed one of the most dating elements. I am looking to replace the vehicle now because it is not mainstream enough and has high maintenance costs. My next choice will be in the Camry / Accord / Prius type class just to get into a higher volume solution in hopes that it can be my last car.

But, I am used to replacing cars after 10-12 years. They are one of the few things that seem to have made an improvement in life expectancy over the last 20 years.

I am not used to replacing household appliances in less than 20 years. My current washer and dryer is 25 years old. The oven/stove is 30 years old. The refrigerator is at least 20. My thermostat is 30 years old.

All of these and many other elements in my home are coming up for replacement soon, and I would like to make the jump to a fully-connected home. But, I am very concerned that, in doing so, I am guaranteeing that this will not be my last appliance upgrade in my lifetime as it should be.

Re:How is six years a complete device lifecycle?

[EndlessNameless]

Now I'm interpreting this as an indication that devices with Android are targeting a six-year lifecycle!!! No way.

Software updates, which are primarily required for security, are only essential for network-connected devices. If your fridge is going to sit quietly in your kitchen and not talk to anybody else, it doesn't really matter if it's running decades-old code.

The ever falling device lifetimes are soaking up both the piddling economic growth of the middle class and our resources.

Smart devices (of any kind) put you on the network-connected upgrade treadmill. As long as compute capacity continues to grow, very few people and businesses will be interested in designing and maintaining long-lived smart devices; everything will become increasingly disposable.

There may be a way to modularize the smartness of the device, but that will involve a lot of work. There is no standard module, and any code running on a removable smart module would need to handle an enormous range of equipment. Both of those things take a tremendous amount of time effort to implement, and there is no financial incentive to do it.

Normally this would be a job for government regulation, but if the lobbyists are all paid by companies with no financial incentive to standardize and modularize... well, I'll just say my expectations are fairly low.

Re:How is six years a complete device lifecycle?

[amorsen]

Samsung advertised TVs with an "Evolution Kit" slot, making it possible to upgrade the smart functions of the TV year after year.

Certain TVs had upgrades come out for two years, but most only managed one. Then they cancelled the whole thing.

Luckily upgrading through plugging in various devices in the HDMI slots works absolutely fine, of course.

Re:How is six years a complete device lifecycle?

[ckatko]

I love how you feel, but I think on a practical level that's impossible. LONGER, sure. But 20-30 years is impossible:

Most companies that write the software we use don't even last 30 years. Who takes it over after they die? Even Chrysler and GM tried to weasel out of their warranty claims and "killed by daughter" ignition switch lawsuits by saying "that was the old version of the company! ...even though we still make the exact same car..." /scumbags

And what kind of support are you talking about? Software or hardware? 30 years ago (almost to the DAY), my Compaq Portable was built. It weighs ~40 lbs, and has an 8088 CPU. Are you suggesting someone from Compaq should show up at my door with the new 8-bit ISA floppy driver card I need?

And the thing is, I actually AGREE that "significant SaaS services" should be regulated by law as utilities. What happens when Steam, Facebook, Twitter, World of Warcraft, etc go out of business or are bought out? What happens to all that content of yours that you legally owned up until the point the company changed hands? What happens when the servers get shut down? The people should have the right to either 1) get all their data before the servers close, and 2) build a replacement service (open source API's?) if the dying company or new owner refuses to build a comparable product to continue existing users. The web is getting more and more integral to our lives and yet software companies go tits up just about as often as they used to. What happens in the future when all of your work is through web apps (like Google Docs) and they go away or simply remove their old product?

Now, reasonable companies keep their consumers happy by helping them migrate. But that's a RARE quality. And companies that are going out of business give two craps about their consumers. Their company is dying, they have "more important [to them]" things to worry about. But while companies like GOG have stated openly they'll help everyone get their data in case of a buyout/closing, do you think all those scumbags at Universal, Sony Pictures, and other record companies, would care equally about consumers? Inbetween infecting all their CDs with rootkits, somehow, I don't think they'd give a shit.

SaaS is ticking time bomb (like data breaches we're finally getting congress to care about) and current legislation / regulation / corporate-culture is doing nothing to stop the train from barreling down the tracks toward the missing bridge. Once one big ticket company falls, we HOPE, everything will change. But whose data (and money!) is gonna be lost before that happens? Wait a couple more years while the world rotates the jack-in-the-box another few turns.

Re:How is six years a complete device lifecycle?

[RhettLivingston]

You were obviously smart enough not to buy plasma. That is good.

But I am currently sitting in front of a two-year-old 32" LCD that has very notable shadowy areas across the white field. I know that is because I didn't get a TV (which I use as my monitor) with LED backlighting. The tubes lighting it are aging though they probably only have about 10K hours of usage in two years (about 14 hours a day). The question now is whether I will become too annoyed by the uneven field first or the fluorescent backlighting will fail first.

Re:How is six years a complete device lifecycle?

[RhettLivingston]

I agree with all that you said. And, as an engineer, I believe that this is an area where we are not meeting our responsibilities. We should be creating solutions, not problems. An engineer has a responsibility to society.

In this case, we need to be pointing out the problem and demanding regulation, not to stop the trend, but to minimize the long-term costs so that the economy can expand by creating more different things, not by creating the same thing more often. This kind of regulation helps to explode diversity of solutions by freeing up consumer resources currently spent on repeating a cycle to fuel the next big thing.

As I pointed out in another post above, I believe these issues are solvable by deploying dumber connected devices with smarter centralized controls. The centralized controls can then be upgraded independently of the connected devices.

We standardized electricity many years ago so that devices could be plugged in anywhere nationwide and flourish. We need to standardize home intelligence as an infrastructure to the same degree towards the same ends. The industry is too competitive to choose to do this on their own.

Re:How is six years a complete device lifecycle?

[swillden]

Now I'm interpreting this as an indication that devices with Android are targeting a six-year lifecycle!!

Well, currently, few devices have support for more than a year or two, so six years is a big improvement. Even Google -- one of very, very few device makers who actually provides a committed support lifetime -- only promises three years. For that matter, although Apple tends in practice to update devices for 4-5 years, AFAICT they make no commitment to support devices beyond the one-year warranty period.

Android needs to be thinking in terms of how to at least maintain security updates for 30 years.

That's ridiculous. There is NO consumer electronic device that is expected to continue functioning correctly for that long. Just think about what sort of PC you'd have bought 30 years ago -- 1987 is when IBM introduced the PS/2, running PC DOS 3.3 -- and phones age faster than PCs.

Re:How is six years a complete device lifecycle?

[swillden]

Sounds like Google is using this as an excuse to limit support on otherwise perfectly good hardware to an arbitrary six-year limit as defined by a vendor.

Well, given that no vendor out there provides six years now, that's an improvement.

Never mind that fact that devices can very easily be upgraded to newer linux versions.

"easily". Heh. You don't know what you're talking about.

They've already ended product support for their "Do no evil" mantra.

It was "Don't be evil", and it's still used as a guiding principle.

Re:How is six years a complete device lifecycle?

[dj245]

Most of my life, I've received 20 to 30 years of service out of appliance-class products such as televisions, refrigerators, stoves, microwaves, washing machines, and dryers. I have noticed a steep downtrend in those lifecycles, particularly in televisions, washing machines and dryers. But that reduction has been due to engineering choices in the machinery.

Now I'm interpreting this as an indication that devices with Android are targeting a six-year lifecycle!!! No way.

Android is in all of the above device types today and even in our cars. Android needs to be thinking in terms of how to at least maintain security updates for 30 years. Perhaps that may have to involve some standard pluggable module so that the hardware can be upgraded too, but it has to happen. The ever falling device lifetimes are soaking up both the piddling economic growth of the middle class and our resources.

That's capitalism and the free market for you. The people want the new shiny. Anything capable of lasting and being maintainable for 30 years generally looks dated, usually costs significantly more, and is therefore slowly being choked out of the mass market.

Re:How is six years a complete device lifecycle?

[RhettLivingston]

The point is that every device is now an electronic device. Android is available in every kitchen device I can think of from refrigerators to coffee makers. And they are all being networked to facilitate home and life automation.

Re:How is six years a complete device lifecycle?

[swillden]

Standard Android is not a good fit for long-lived appliances. They need an entirely different approach. Google has a team working on that, the Android Things project. But that's not what this article is about, and the dynamics of that ecosystem are entirely different. That's not to say no one will put standard Android in such devices, but they shouldn't... and you shouldn't buy one.

Re:How is six years a complete device lifecycle?

[Threni]

I don't know what you're talking about. Nobody has a device for 30 years. This announcement is just an advert for Project Treble, so people can pretend they'll be using the same phone in 6 years instead of the usual 2 or 3.

Re:How is six years a complete device lifecycle?

[RhettLivingston]

au contraire. As a device engineer, I can attest the word, and the relevance of this article, covers far more than you're thinking.

Devices that I'd expect to last decades have been running Linux kernels and even Android for quite some time now. Here's a refrigerator introduced in January 2013. The more recent Samsung refrigerators are much fancier than this with massive screens.

In addition, every major appliance manufacturer now has WiFi-enabled appliances of every variety I can think of. Even dishwashers are WiFi connected now.

This article was about Linux kernel support, not just Android, and I'd bet the majority of the WiFi-enabled appliances have a Linux kernel.

Re:How is six years a complete device lifecycle?

[RhettLivingston]

This article was about long-term Linux kernel support which Android happens to benefit from. Just because Google asked for it and may be helping it to occur doesn't mean that they are the only ones needing it or who will benefit from it. Any device manufacturer using a Linux kernel to create a smart connected device should be interested in this.

Re:How is six years a complete device lifecycle?

[swillden]

This article was about long-term Linux kernel support which Android happens to benefit from. Just because Google asked for it and may be helping it to occur doesn't mean that they are the only ones needing it or who will benefit from it. Any device manufacturer using a Linux kernel to create a smart connected device should be interested in this.

Only if they need to stick with a kernel for a long period of time. Android Things doesn't need to do that.

Re:A step forward...

[ichthus]

Yeah, you're right. Maybe Windows should be in smartphones. *snicker*

Re:Device Lifecycle

[freeze128]

Also, what happened to project Fuchsia?

Re: A step forward...

[Zero__Kelvin]

Absolutely... When is the Linux kernel going to get a web browser!

Re: A step forward...

[Zero__Kelvin]

The Windows kernel version you are running today is unlikely to be supported next year. If Linus declared that every kernel version from here on would be version 10 then he could claim to have the same kind of LTS support as Windows.

Android

[thegreatbob]

Do we really think most manufacturers would actually use this opportunity to ease the difficulty of providing long term updates for their platforms, versus just dropping them and churning out new e-waste?

Galaxy S7 still on 3.18.31

[crow]

Mine is on 3.18.31. I just checked, and I had a system software update pending, so I installed it, but it didn't change kernels. A quick search indicates that 3.18.48 was the last kernel in that series, and that support has ended, so they should certainly update to .48, and probably migrate to a newer kernel.

Completely different strategies

[DrYak]

Linux LTS kernels are mostly useful for Android smartphone (specially the older letters).

The main problem is that the hardware manufacturer that build the base PCB that are used by phone manufacturer to build the smartphone rely heavily on binary drivers (Intel being one of the few exceptions).
Usually, they'll fork whatever is the current version of the kernel in the Android letter-du-jour, slap binary GPU (and a few other special chips, like sensors) drivers, and ship that in the devkits they give to smartphone manufacturer.

End result : it's 2017, the current kernel is 4.14, but your smartphone is stuck at running some ancient 3.2.xxx kernel because that's what Android Jelly Bean was running back when Qualcomm designed this chipset, and they haven't bothered to make any upgrade since.

By making extremely long LTS release cycles, it means that, even if current crop of android kernel is stuck to kernel 4.14 because of Android Oreo, in 6 years, there will be still patches and bugfixes publilshed for this kernel, and LineageOS would be able to ship some hack of Android K(akao ?) running on kernel version 4.14.986 with all the latest security fixes.

---------------

The strategy of Fuschia is different.

It's supposed to be a micro-kernel architecture :
- The kernel is only a very low-level hardware abstraction layer.
- Everything else are user-land server.

That could in theory enable Anroid Y/Z to use binary proprietary user-land server for the chip-set specific drivers written by the hardware manufacturer,
but upgrade the other servers to the latest security corrections.

Re:A step forward...

[Billly Gates]

Yeah, you're right. Maybe Windows should be in smartphones. *snicker*

Laugh all you want but Windows8 is far superior to Android in terms of speed, reliability, and support. I hated going back to Android.

My Windows Phone with 1 gig of ram was faster than my $700 Nexus6P with 4 gigs of RAM. I bought my mother a $60 Nokia 640 and it lasts for days with battery life and is snappy with 1 gig of ram.

This is not possible on an Android device for those specs

Re: A step forward...

[Zero__Kelvin]

Revision is a subset of version. For each new revision you have a new version. Sorry to disappoint you.

Re: A step forward...

[Zero__Kelvin]

Systemd doesn't provide services, it managed them, and is not part of the kernel. In order for a joke to be funny it has to have an element of truth to it. Comedy 101.

Microkernels

[DrYak]

See also - Minix 3.

Basically, yes.

Except that minix is only ARM, whereas current trend in smartphones chips tend to be AArch64.
And Minix is Tannenbaum's creation, not something that Google controls.

Also, I don't know to which point Minix's API between userland driver-daemons is specially designed to allow ABI stability for the bits that are likely to end up as binary proprietary daemons.
(Like it's the case currently with the drivers on various versions of Windows, leaving a little bit of wiggle room to install across several OS versions)
(And completely unlike Linux, where ABI and API breakage is expected to happen as new better cool features are introduced into the kernel (e.g.: GPU support for kernel mode setting, atomic, tearfree, etc.) but at the cost that proprietary binary drivers are pretty much married to an exact kernel version - see headaches of trying to use Nvidia's blob on a rolling distro with modern kernels, see android kernel where your smartphone will never ever move beyond 3.10)
(You can bet that Google is devoting resources to explicitly avoid these problems in Fuschia).