Slashdot Mirror
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."
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.
Yeah, you're right. Maybe Windows should be in smartphones. *snicker*
sig: sauer
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.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
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.
"First they came for the slanderers and i said nothing."
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.
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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.
It would have been better if you'd actually given an example.
"First they came for the slanderers and i said nothing."