Android, like many other operating systems, uses the open-source Linux kernel. There are several different types of Linux kernel releases, but the type that’s most important to Android is the long-term support (LTS) one, as they’re updated regularly with important bug fixes and security patches. Starting in 2017, the support lifetime of LTS releases of Linux was extended from two years to six years, but early last year, this extension was reversed. Fortunately, Google has announced that moving forward, they’ll support their own LTS kernel releases for four years. Here’s why that’s important for the security of Android devices.
↫ Mishaal Rahman at Android Authority
I fully support the Linux kernel maintainers dropping the LTS window from six to two years. The only places where such old kernels were being used were embedded devices and things like smartphones vendors refused to update to newer Android releases, and it makes no sense for kernel maintainers to be worrying about that sort of stuff. If an OEM wants to keep using such outdated kernels, the burden should be on that OEM to support that kernel, or to update affected devices to a newer, supported kernel.
It seems Google, probably wisely, realised that most OEMs weren’t going to properly upgrade their devices and the kernels that run on them, and as such, the search giant decided to simply create their own LTS releases instead, which will be supported for four years. Google already maintains various Android-specific Linux kernel branches anyway, so it fits right into their existing development model for the Android Linux kernel.
Some of the more popular OEMs, like Google itself or Samsung, have promised longer support life cycles for new Android versions on their devices, so even with this new Android-specific LTS policy, there’s still going to be cases where an OEM will have to perform a kernel upgrade where they didn’t have to before with the six year LTS policy. I wonder if this is going to impact any support promises made in recent years.
Doesn’t this only mean Google (as an OEM) are doing what every OEM is being forced to do?
I doubt this will benefit any other OEM much unless they use the same hardware as Google in the Pixels
We have generic computers that can be supported by generic operating systems for well over ten years (and without the manufactures involvement, yay!). The reason mobiles fail at support is because the support model is terrible. Rather than having to support old/ancient kernels, it would be much better to have mainline drivers such that the user doesn’t have to be stuck on an old kernel. This approach has a proven track record on PCs. Alas too many mobile devices are crippled by manufacturer dependencies. To a manufacturer EOL is not a problem that warrants fixing, planned obsolescence and short lifespan are a feature 🙁
This is why, decades after we’ve identified the issues and talked to death about how to fix them, we’re still suffering the same forever-problems on mobile. The corporate profit motives don’t align with consumer interests on this. Our throwaway gadget trajectory has no end in sight.
There’s some hope that RISCV devices will fix these problematic support issues, but I’m afraid that if we give manufacturers too long a leash they could ruin that as well by repeating ARM’s failures.
100%
I think this might slowly be coming to an end though.
Just as the race for moar-faster! pcs ended with consumers not caring any more about the cpu/ram they get, as it’s always more than enough anyway (and in recent times even accepting smaller and smaller ssd, having bought in in the cloud-is-your-storage model), so it is happening with smartphones. I just bought the same previous-gen Galaxy I had bought last year, after it got stolen, as its current-gen sibling has no discernible improvements and actually removes one feature I need. We are at the inflection point where the majority of phones gets replaced when either their battery has degraded too much, or they get lost/stolen/dropped-in-water.
gggeek,
I agree with your point: for many of us the need for the latest and greatest is marginal. I don’t think it addresses the long term hardware support issues though. An old phone might have perfectly good specs and be in good condition, but if if the software can’t be updated that’s a problem. Our acceptance of old hardware doesn’t negate the need for new & up to date software.
Agreed on the cpu, but RAM? I can never have enough. 32GB is my minimum. Which some people see as extreme, but they don’t run multiple IDEs & VM’s. Maybe the cloud would be cheaper one day, I thought it would but cloud prices have stopped decreasing.
Bill Shooter of Bul,
I thought we were talking about phones.
My computers have 64GB for similar reasons as you. I tend to provision VMs with more ram than they strictly need. The disc caching helps and the ram also keeps them from having to swap and reduces network delays.
I have a work provided laptop for visual studio with 16GB ram and to be honest that’s just not enough to run it smoothly anymore. IMHO it should be enough, but with the amount of bloat these days it could use more to avoid thrashing..
Terenie aren’t mainline drivers on PC. They work because Old drivers work on new systems/kernels. God, once driver from XP dated on 2002 worked on Windows 10 and that’s cool.
Marshal Jim Raynor,
I have no idea what “terenie” is.
If you’re talking about a stable ABI, I agree that’s definitely another aspect of the problem. Having mainline FOSS drivers would be best, and barring that having a stable ABI would at least let us keep using old drivers. But when we have neither mainline drivers nor a stable ABI to load old drivers this sets the stage for unsupportable hardware 🙁
I don’t get it. Firefox providing support to a Windows version that is 14 years old is good. The linux maintainers moving from 6 to 2 years is also good? I think is horrible that we cannot have a system for at least 5 years.
There is always a bit of double-think when it comes to Windows.
I never understood how it is easier to maintain a old kernel than just bump it.
C5523,
I agree. Torvalds once pointed out the linux versions are highly arbitrary. All else being equal there’s not much reason to favor an old kernel. At least on x86, you can typically install a new kernel (and it’s modules) on an ancient distro and will work just fine and there’s not much reason for an LTS to exist.
On mobile there’s a more thorny issue about important drivers not being mainlined. Since there’s no ABI, we now get an artificial dependency on a specific linux kernel. This necessitates the continued use of a single kernel and potentially would be a justification for kernels to have a long term support window. However I argue this outcome is just terrible for us as users. We should avoid getting stuck on old kernels at all costs. We need to be making things as easy and friction free as possible to just upgrade the kernel.
Google it’s time to start supporting your own line of devices with FOSS and upstream device drivers instead of having a serious NIH syndrome with some dead end projects. Once you start doing that extending support to 10 years of software updates, or more, becomes a matter of arbitrary decision. And even when officially dropping the support i am sure that other will maintain it for years to come. So time to stop acting wonky and just do your shit.
Given the accusatory tone, I’ll remind you that we, the linux community are also guilty of holding up progress by refusing to allow an ABI which would help solve many of the current problems. 🙁
Too many people are quick to blame others but never their own.
Please don’t be ignorant, by choice. Only when upstream FOSS device drivers for a line of Google devices will be provided, only then you will easily get 10+ years of support in terms of operating system updates. No other option will ever allow or provide that. This has already been proven in the past 30 years or so of computing.
Geck,
Please don’t defer to ad hominem attacks. You’re not attacking a random windows fanboy but an informed linux kernel developer. Obviously there are pros and cons and you are entitled to an opinion that weighs them differently than I do, but whether you admit it or not the lack of ABI stability does create some development and support chaos. The linux community is fully deserving of the blame for this. I’m not happy to say it about my own community, but it is true.
I am not attacking you i am just telling you are wrong and history of computing backs my claim. So again, only when Google will provide FOSS and upstream device drivers for GNU/Linux, for a line of their devices. Only then it will become possible to easily support such devices 10+ years, likely up to 20 years for some popular devices. Your solution, on the other hand, is based on ideology and even if it would be implemented it would never provide that. In real world you would never be able to run latest kernel with binary device drivers from 20 years ago. Said that we already had this discussions, that is binary device driver provider has access to source code and as such has no technical limitations, on why it wouldn’t be possible to support some device 20+ years. That is when it comes to newest GNU/Linux kernels. This things come down to commercial reasons and planned obsolescence and have nothing to do with technical limitations, such as lack of or availability of “stable ABI”. You can already provide support indefinitely if you chose so.
Geck,
I consider calling people ignorant a personal attack, please don’t.
Also it’s not wrong and I stand behind what I said. the lack of ABI stability has factually creates problems for support. This has been especially true on ARM, but even for kernel devs working on x86. Keep in mind that not everything gets accepted into mainline.
My distro used AUFS (of knoppix fame) and the lack of an ABI stability was extremely annoying. As a developer I was able to fix the incompatibilities, but the point is when I download the latest AUFS drivers and the latest linux kernel, the AUFS developer had a life outside of his free work and couldn’t support every kernel release. So there was a high chance that the nonstable ABI would make things incompatible. The breakages that result from unstable ABIs causes problems whether you admit it or not.
Of course you are entitled to not care, but the problems are still real.
I called you ignorant, by choice, because you were educated and i know you know better. I know that you know, that nothings comes close to having something like GNU/Linux with upstream device drivers and willing maintainers. This is more or less the only recipe to have 10 or 20 years of support for something as a general purpose consumer desktop/mobile/IoT/… device. So called “stable ABI” for binary device drivers doesn’t provide that. It’s basically a short term hack, for obsolete device drivers. Even if device drivers would keep running, on 10 years newer kernels, they would still be considered an obsolete and exploitable hack without the utilization of anything modern in the newest kernels. From the general purpose device point of view, like a mobile phone. So Google, among all relevant companies, stop with this shit and do what is expected from you. A line of devices on where device drivers are available upstream in GNU/Linux. For gods sake even Qualcomm went ahead and upstreamed device drivers for the Snapdragon X Elite hardware. All while Google engineers still are developing some “stable ABI” in basement? Grow up. Just use the work other people have done, if you don’t want to do it. The future is known and it’s not what Google is pushing for with their failed attempts. It’s what they actually use, to still be relevant, and that is GNU/Linux.
Geck,
I will speak for myself.
You say this as though non-stable don’t cause their own problems, but they do and they always have. When linux was young and immature I think this was more forgivable, but as things mature and time goes on, the costs of instability keep accumulating. Like I said there are pros and cons, but only focusing on the pros while being in denial about the cons is not a balanced view point.
I don’t think it’s all or nothing either. I know a much better balance can be achieved, but being in denial about the problems is never going to get us to a solution. 🙁
Stay on point. You’re not convincing anyone of anything by resorting to these kinds of taunts.
The thing is, andorid is more popular than any other linux distros.
In my opinion you are just being unreasonable in your expectations. As the history teaches us, there is one example of a general purpose operating system out there, claiming to have stable kernel ABI for device driver development, Microsoft Windows. Now Windows doesn’t come in verity, it’s a single product produced by a single company, there are multiple Windows versions, though. Latest being Windows 11. So although Windows claims and is perceived as having stable kernel ABI, for device driver development, what that doesn’t mean is you will be able to use device drivers from one Windows version on another. Microsoft is not able to support that, due to difficulties involved. And you expect what, for GNU/Linux to add a stable kernel ABI for device driver development and to do what with it? Keep advertising and maintaining it for decades and in all future kernel versions? Something Windows never achieved, due to that being too difficult and lets no even mention the toll that takes on future development in term of hampering it. You can always target something like a specific Ubuntu LTS release, with your binary driver, and you will in practice have similar thing then targeting one version of Windows. But why, if now even companies like Qualcomm are upstreaming device drivers for their latest hardware, no stable kernel ABI can ever top the benefits you get with that. For example, 20 years from now, you can even fix a security bug in the device driver, imagine that, and getting that through software updater. What i am trying to say is your initial remark, that started the debate, it’s just unfounded. It’s not true that refusal of introducing a stable ABI for device drivers development is holding progress back, it’s on what is actually pushing it forward.
Geck,
I think most operating system kernel ABIs are more stable than linux though. Take macos, while apple do deprecate some features from time to time (and IMHO it is OK to do this with care), users can generally expect 3rd party kext drivers to continue to work on a supported architecture at least for a reasonable period of time. IIRC freebsd has ABI stability too.
Linux kernel ABI instability is fairly extreme compared to other operating systems. If apple did what linux does, 3rd party drivers could break any time the kernel got updated.
Truth be told as a developer it’s not only the lack of kernel ABI stability that’s a problem, but the lack of kernel API stability as well.
I’ve shared some examples of what you are say on osnews before, device driver compatibility is not 100%. But I gotta be honest those were the exception. By and large the windows kernel ABI is quite stable and it is disingenuous to suggest it either isn’t stable or that microsoft cannot support it. It IS stable and microsoft DO support it. At least some of that would like to have these benefits on linux for pragmatic reasons.
No actually, but I’m glad you ask. I DO NOT think an ABI needs to be kept for decades. Stability within major versions is obviously desirable. 5 years would be ok, certainly better than an unstable ABI that could break at any time.
For long term driver support, in particular for drivers that are no longer being updated, I think we could look at doing something like this…
https://wiki.debian.org/NdisWrapper
Instead of windows drivers, we’d be using linux drivers and moreover we could do it better than windows since our drivers could be designed to support wrappers that let us use obsolete drivers indefinitely. Given that the hardware is no longer supported, I think being able to run it this way is a good compromise and as a side benefit operating systems like FreeBSD could even support them.
The stable ABI would also let us address linux kernel bloating. Rather than polluting the linux kernel project with all the drivers that have exist going decades back, we’d have the opportunity to clean out the kernel and create dedicated projects to support legacy drivers. This would save so much work versus unstable ABIs that are continuously breaking stuff.
You’re still ignoring the issues that come with unstable ABI. But in the real world it’s been causing pain points for a long time.
Microsoft more or less only supports it for each Windows version and has difficulties in doing that, they go to great lengths to make that happen. OK, so now we are already down to 5 years of support, as you say, and after we would already be down to more hacky wrappers. For what? Vendors have access to source code and providing 5 years of updates is an non issue. For enthusiasts? To do exactly what, use hackery to support some device past its EOL, licences likely not even allowing for redistribution of years old blobs. Contrary to GNU/Linux, on where you see it as bloat, reality being it’s the only working solution in the history of computing, for general purpose usage, that actually demonstrates it is working. An example from a while back on where i read an article on how R600 driver is getting modernized in the latest GNU/Linux kernel. That is almost 20 years since such hardware became available on the market. Your solution doesn’t top that, not remotely. You would get 5 years of support from vendor, after you would likely lose access to the blob or licence wouldn’t allow redistribution. If you would still somehow circumstance that you would be relying on further wrappers, as nobody would update the blob to work against newer kernel. Who in their right mind would want to have anything to do with that? Maintaining that and for free? The idea of a micro kernel with stable ABI for binary device drivers, it’s not a bad idea, it can work, just in the case of some specialized purpose. For general purpose computing, there it stands little chance, unless you are prepared to give up on progress or if you limit it to as you say a couple of years of support. And that is basically about trying to solve an non issue, due to vendors having access to source code for the duration of some device life expectancy. So if they do want to fix security holes or use modern features from new kernels, and things like that, through updates, that is a breeze, when it comes to GNU/Linux. If they don’t want to do that, then “stable ABI” doesn’t help you much here. At best you might extend device life for a year or two, by not using anything more modern from the new kernel, hence no real sense in using it, and by knowing your driver is a security risk, due to known reports.
Geck
What are you even talking about? Each major version of windows goes around ten years and many drivers continue working across versions. The reason you are being critical is because of your agenda, not because it doesn’t work. Linux can improve, but if we are too proud to do it then I find that to be unfortunate outcome for linux.
Great, you can still have that.. But this dogmatic view that the world has to be black and white and it can only be all or nothing is not good. That couldn’t be further from the truth. You are guilty of collapsing an entire spectrum of possibilities down to two extremes. This choice between polar extremes really does hold back progress for FOSS. In order to find better solutions we need to be open to exploring new grounds and not trapping our brains with false choices.
You need different versions of device drivers depending on which version of Windows you use, that is on how Windows works. I gave you an example in regards to upstream R600 driver, on where it still works with the latest GNU/Linux kernel, hence the same can be said about underlying hardware and on top of that R600 driver was even modernized a while back, to take advantage of more modern kernel features. Compared to Windows on where it was supported up to and including Windows 7. So spare me the agenda and extremism nonsense.
Geck,
There are different driver models in windows, some of which go back decades spanning several versions of windows others don’t. What’s your point? None of that contradicts anything I am saying.
And? The fact that hardware can be supported for a long time in linux does not contradict the fact that it could still be supported for a long time with stable ABIs with less work.
Please reflect on our discussion, you’ve only considered things at the extremes. Linux has no stability even for minor versions, which puts it at the extreme. Staying there means linux will always have the cons of instability. As operating systems mature, stability becomes more important than instability. Even if you are adamant that linux ABIs should stay at the unstable extreme forever, don’t pretend that there are no negatives for users and developers.
Maturity is something GNU/Linux reached long time ago, still in the sense of it being finished, no need to develop it further, then “stable ABI” would be the only natural consequence. Some sort of snapshot in time to be used for decades to come, no real progress needed. This would only be possible if developed for some specialized purposes. Otherwise, as you say, we are quickly down to more realistic 5 years, with much hassle involved, or at one version of Windows, before things break again. Obviously progress taking a toll and being slow the natural consequence. As for you saying R600 example proved nothing. For sure it did, it made you say it out loud, that GNU/Linux indeed does provide extremely long lifetime cycles, for the underlying hardware. Nothing comes remotely close to that in sense of general purpose computing. As for you arguing it would take less work, if during this 20 years, people would rather invest time in maintaining a stable ABI for five years and making wrappers around newer kernels, for additional 15 years. Good luck with that, on top of that no security patches possible, for 15 years old blobs and no porting to modern kernel features involved. Doing it like that, any sign of progress would die off in lets say 3 to 4 irritations, like we have seen with Windows. On where in the past decade or so no real progress has been made, maintaining legacy code or better a dinosaur is more or less it. On where GNU/Linux is still flourishing in terms of progress being made, each day. Anyway, enough about this. I know what i am getting with GNU/Linux model and no way am i giving that up. If some people feel otherwise, fork it and do your own thing. And lets see on how that ends up stacking against the upstream approach in years to come.
Geck,
I think mature operating systems should become more stable if only to reduce the workload and inefficiency, It does not mean giving up on progress altogether.
I agree 5 years is realistic, but it was just a number I threw out there as an example. If it turns out that network driver ABI is mature and doesn’t need to change in an incompatible way, then there’s no reason to purposefully break it. My point is for us to be pragmatic and considerate.
YOU DON’T HAVE TO LOOSE THAT!!!! Just because the ABI changes less frequently doesn’t mean the developers who’ve been supporting your FOSS drivers must stop supporting them, they’d just have to do it much less often!!! ABI instability leads to having to update driver code over and over again ad infinitum. Like I said earlier “Obviously there are pros and cons and you are entitled to an opinion that weighs them differently than I do, but whether you admit it or not the lack of ABI stability does create some development and support chaos.”
Developers actually do want to change things, change often, and they can in GNU/Linux, it’s maintainers that don’t want to change things, extra work. That is on why GNU/Linux is still thriving, when it comes to progress being made and on why Windows is in a maintenance mode, past decade or so. They rather support legacy on where, as seen with R600 driver example, it’s not even considered a legacy in GNU/Linux, it’s still being developed. And although Windows is invested in supporting legacy, the R600 hardware driver isn’t available for Windows any more. So, if Google is serious, long term support for a line of their or other vendors devices. There is only one solution in existence that can enable them to achieve that and to compete and beat Apple at it. Considering their relevance in mobile space is deeply tied to GNU/Linux, without Linux they are simply not relevant, it’s a bit strange, isn’t it? Inventing all this hot water and sliced bread, claiming they extended support, on where they don’t come remotely close, compared to if they would actually done it the Linux way. It’s like saying yes we use Linux, and although without it we wouldn’t be relevant, still, we know better. We will invent a whole new OS and it will offer five years of support, for hardware. Imagine that. They should indeed get some sort of reward for trying to do that and good luck with it. But talking to you, do you feel that the underlaying issue is similar, to our discussion? For this to be a cultural clash? Google engineers being caught up with the same logic, you have, not really catching up yet, on Linux, believing they need to somehow fix Linux instead of accepting the proper solution? And that is to do it the GNU/Linux way. The arguments and history backing that up. Anyway, lets see if Google ever connects the dots, otherwise some other company will instead.
Geck,
You’re totally off the mark here. We don’t want to change drivers constantly for the sake of an unstable ABI, trust me I should know, it is a huge waste of resources.
This dogma is very tiresome. I’ve already pointed out that your “R600 driver evidence” does NOT prove what you are saying. It’s false that developers would have to stop supporting hardware without a continuously changing ABI. There are more optimal solutions for linux, but your agenda keeps you from admitting it.
You dislike google, fine, but you should still acknowledge that fact that they are not the market failure you portray them to be. Android is more popular with consumers than any other linux distro/os that has ever existed by a wide margin.
It has nothing to do with liking or disliking Google i am just telling it like it is. Google dependant on Linux, to even be relevant, acting stupid. That is they seem to took a position they need to fix Linux or to replace it altogether, with something better, failing miserably at it, just stop with this crap. For sure the R600 device driver example proves that, just like Snapdragon X Elite device driver will over the next 20 years or so. No, vendors don’t have much issues with updating their device drivers blobs, when it comes to GNU/Linux. They have access to source code and whenever preparing updates, for device, it’s a breeze, to take care of that, on top of everything else. Vendors that are not interested in providing updates, there you get whatever is installed on device at that point and that is that. Just like when Windows drops support and not much you can do about it, other then to migrate to something offering longer device life, by design, like GNU/Linux. Anyway, enough from my side for now.
One additional thought from my side. If Google would instead invest the resources they had invested in Fuchsia, their basement pet project, into GNU/Linux, the solution they actually use and it keeps them relevant, they would already be offering longer Android device life expectancy then Apple ever will, by design. Lets see on what their next attempt will be, will they ever catch up?
Geck,
You’re often blaming google for trends that were not google’s doing. For the most part google aren’t the ones creating the hardware or drivers. The fact is that unstable ABI continue to cause negative consequences for consumers. Everybody hopes it gets better, but after decades frankly you do not get the benefit of saying the unstable ABI has worked for long term support because it has not. The insistence on unstable ABI is partially responsible for billions of devices ending up in landfills. This is something that having a stable ABI can realistically help. On the one hand I want to respect your personal opinion, you don’t have to agree with me. But on the other hand when you keep promoting your personal ideology over pragmatism. It does cause not only development inefficiencies but also such serious environmental problems. We should be embracing solutions instead of sticking our heads in the sand and being part of the problem. So yes, your opinion that linux should never change course does hold back progress for linux 🙁
I think Google could have done this successfully. Obviously android customers aren’t particular about the underlying OS, but management seems to have decided that two projects competing for the same customers was not worthwhile.
GNU/Linux for sure isn’t responsible for the choices this companies make, regarding e-waste. It’s a solution to this problem, though, that much is true. Nothing is holding Google back, to produce a proper GNU/Linux device, they are perfectly capable in doing it, it’s their choice, not to do so. Instead they rather invest in dead end projects. So of course i am going to blame them, it’s their decision, responsibility and fault. So get your act together Google, produce a GNU/Linux device having 20+ years life span. Stop wasting our time with some alternative visions nobody asked for or needs. It’s Linux that made you who you are and it’s time to give something back, a proper GNU/Linux device.
Geck,
You are assuming that drivers are Google’s to maintain/support, but usually it’s the hardware maker rather than the OS maker who is responsible for drivers. Even on x86 the drivers are written by the manufacturers and it’s thanks to stable ABIs that hardware can continue to be used long term.
To the extent that the linux community are willing and able to support hardware by reverse engineering it, that’s great. But it’s important to note this is not an inherent advantage for unstable ABI, driver reverse engineering work can proceed indefinitely with more stable ABIs too. There’s no problem there and there’s less churn. All the other benefits of stable ABIs that we covered are true. The con of having to support a stable API indefinitely is a valid criticism but this is largely mitigated by not limiting ourselves to only consider the extremely ends of the stability spectrum, It’s NOT all or nothing and nobody who cares about progress should be framing things that way.
If they choose so Google can have a GNU/Linux device on the market tomorrow. Rest assured.
Geck,
Google could create a GNU/linux phone it because it’s got the market share, but all the Linux phones other than android have been commercial flops. Personally I would have preferred a more standard linux environment to android for developing, but GNU/linux isn’t something that normal consumers care about. It’s just us geeks that care about it. :-/
I agree that in general, consumers, couldn’t care less about what you or i advocated for in this discussion. So i guess we need to be smarter, we the vocal ones. I am OK with you forcing Google to provide you with a Fuchsia based mobile phone, to get your “stable ABI” the thing you so much desire and for being able to use blobs from 2025 in 2045 on such device, latest Zircon and all. That is as long as i get GNU/Linux one. Must be flagship material, though, not some cheap shit. So we both can then chose and so can the rest of the consumers, that is standard Android or maybe your or mine option to persuade them too, who knows. I know what i am after and as long as it is on the market i am good. Currently it is not.