Linux Kernel LTS release is now for 6 years instead of 2
arstechnica.com
arstechnica.com
From https://www.kernel.org/category/releases.html:
3.16 Ben Hutchings 2014-08-03 Apr, 2020
3.2 Ben Hutchings 2012-01-04 May, 2018
Edit: Digged here a bit more: https://en.wikipedia.org/wiki/Linux_kernel#Maintenance
2.6.32 December 2009 to March 2016 (6 years)
3.4 May 2012 to October 2016 (4.5 years)
3.10 June 2013 to October 2017 (4 years)Last year the announced commitment was just 2 years: https://www.linux.com/news/44-linux-kernel-long-term-support...
> The future dates you are quoting were recently updated to those dates
Nope, I see same dates there (except 4.4 which I didn't quote in my above comment contrary to what you seem to be claiming)
> also they're just from an unexplained column called "projected EOL
Just like the current page: https://www.kernel.org/category/releases.html
> Last year the announced commitment was just 2 years
My post quoted other kernels, not 4.4, which this news article is about. My point is that a kernel version doesn't get 6 year treatment for the first time thing as this PR/news piece paints it out.
About the substance, I think the public commitment for 6 years for 4.4 has more relevance than just PR.
OEMs will only pay to write custom drivers for a SoC once, and that means you’ll be stuck with one kernel (or any binary-compatible version). Every device requires entirely custom drivers for this, because ARM has no device enumeration.
Until Torvalds finally stops being so stubborn on this, Android and IoT devices will have such a short lifetime, and people will have to continue backporting fixes to ancient kernels.
EDIT: yes, some problems are now solved with Device Tree, but from my experience building Android ROMs, that doesn't solve half of the problems (as many SoCs have special custom hardware, too)
A more stable ABI would certainly help a lot.
[1] https://wiki.freebsd.org/Releng/ABI [2] https://wiki.freebsd.org/BinaryCompatibility [3] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd...
Userland ABI is much more stringent, pretty much any commercially used OS will maintain compatibility for old applications indefinitely, Linux and Free and Net BSD included.
Please provide evidence to back the claim of intent. This comes across as if you're implying malice, when it's far more likely interfaces change in the natural course of development where there are no restraints like abi/api stability commitments.
We have a situation today where nvidia works better on Linux than AMD, even though AMD open sourced their entire base driver, and only wants to provide a few modules as proprietary additions (such as an implementation of 3D screenshots as Ansel competitor), because the kernel maintainers refuse to allow any stable ABI in the kernel.
And this is just stubborn, and doesn’t help at all. If this mindset continues, we continue to be stuck with drivers being proprietary DKMS modules. Already today I have to build dozens of proprietary DKMS modules into my kernel all the time, and recompilation times are horrible.
Top of the line Nvidia hardware beats AMD hardware. As much as I hate to admit it, nvidia's cards perform better across all platforms leading me to believe that they have a real hardware advantage.
Nvidia's cards perform better on Linux than AMD, which I would argue is because Nvidia has more money to throw at the problem. If the issue was the non-stable kernel ABI, then Nvidia surely would be affected in exactly the same way.
AMD cards have more of the "Just Works" thing going for them that Dan mentioned in his article. In terms of ease of use I can't imagine it getting much easier than the driver you need being mainlined.
What I really liked about Dan's article was this bit:
In Linux, hardware support only gets better; it never gets worse.
AMDGPU with mesa on any distro I've tried leads to crashes in mesa, it leads to OpenGL not working, and nothing running. The mainline driver is useless, the average result is "the color of a television tuned to a dead channel".
AMDs AMDGPU-PRO proprietary solution at least works sometimes.
In contrast, NVIDIAs proprietary driver always simply works.
I don't know what edge-cases you are trying, but AMDGPU is working fine for most of us, and quickly improving over time.
Don't forget that AMDGPU is only two years old. It's steadily improving, and I have no doubt that within 5 years it will be at least on par with NVIDIA's driver.
> In contrast, NVIDIAs proprietary driver always simply works.
What about Wayland? KMS?
NVIDIA's driver works for the use cases they made it work for. You simply work inside those use cases, so you don't see the rough edges. Their driver team is quite good, which they have to be to swim upstream like they are. As long as they work against Linux instead of with it, open-source drivers like AMDGPU will always have an inherent advantage. In contrast, NVIDIAs proprietary driver always simply works.
Both of which cause AMDGPU on my system to crash, too. Or they cause the DE to crash.
In fact, I can’t even boot with KMS, because then I just get a black screen.
After all, the kernel maintainers suggested exactly that: They’d rather have everyone use only proprietary code, than any kind of modularity for drivers in Linux.
AMDGPU-pro is only necessary for features that AMDGPU does not provide, and for the proprietary implementations of Vulkan, OpenCL, HDMI/DP audio (I'm not sure if that has been fixed yet), OpenGL, etc. AMDGPU-pro has nothing to do with KMS or Wayland. It's also worth noting that AMDGPU provides competitive OpenGL and Vulkan performance, so you are better off using it instead of forcing yourself to run an outdated kernel and Xorg that support AMDGPU-pro.
> I’d rather use proprietary technology.
You are free to your own opinion there, but know that there are many of us who care a great deal about open drivers. I, for one, bought 4 AMD cards, partly because of price, but mostly because of the promise of open drivers.
I generally care more about open source, too, but when the Linux kernel maintainers tell me to "fuck off" and "just use proprietary drivers", then I’ll do exactly that.
> The fact that kernel devs are sticking to their guns does not mean that they are not working hard on AMDGPU, it just means they are not compromising to make it easier for AMD to provide the proprietary part (AMDGPU-pro).
Well, they are trying to make it harder to do that.
All that would be necessary would be a tiny abstraction layer to add driver extensions for functionality that can not be open source today (because it might be something where AMD is actively competing with NVIDIA).
Instead, I’m forced into running an outdated kernel, outdated Xorg, and proprietary versions of everything.
When have they ever done that?
Linus has famously told NVIDIA to "fuck off" because of issues caused by their proprietary drivers. These people want open drivers, possibly even more than I do.
> > The fact that kernel devs are sticking to their guns does not mean that they are not working hard on AMDGPU, it just means they are not compromising to make it easier for AMD to provide the proprietary part (AMDGPU-pro).
> Well, they are trying to make it harder to do that.
The Linux devs are not doing a singular thing to actively make AMD's life more difficult. AMD is begging them to do something that makes their life more difficult, and they are saying, "no".
> functionality that can not be open source today (because it might be something where AMD is actively competing with NVIDIA).
That is, always has been, and always will be, total bullshit. Whether or not you share that opinion, it is the opinion of those who put hard work into maintaining Linux.
> Instead, I’m forced into running an outdated kernel, outdated Xorg, and proprietary versions of everything.
That is the entire premise of Free Software. Only proprietary software forces users, and proprietary software begets proprietary software. Free Software begets Free Software.
If the Linux devs suddenly decide they will compromise to make proprietary software more convenient, then I, the user, will lose freedom. The stubbornness of the Linux team is not just for them, it is for me, for you, and for anyone who uses Linux.
During the AMD vs. Kernel maintainers mailing list slapfight?
It all was discussed there.
> The Linux devs are not doing a singular thing to actively make AMD's life more difficult. AMD is begging them to do something that makes their life more difficult, and they are saying, "no".
AMD has provided a fully working driver with abstraction layers fully implemented, and has offered to pay devs to continue to maintain it.
The maintainers would have had zero extra work.
> If the Linux devs suddenly decide they will compromise to make proprietary software more convenient, then I, the user, will lose freedom. The stubbornness of the Linux team is not just for them, it is for me, for you, and for anyone who uses Linux.
Yes, and that's why the Linux kernel's license is being enforced against OEMs that sell proprietary forks of the kernel and refuse to publish source code...
Oh wait, Torvalds actually support those OEMs. And complains about people who fight them.
> That is the entire premise of Free Software
What good is free software if it is broken?
As I mentioned before, AMD published a fully working solution under GPL, with all functionality there.
I could have much better functionality today, and better stability, and it would all be open.
Instead I have to use proprietary code, because the alternative is an unusable system.
This is ideology limiting my freedom.
* What GPU hardware?
* Which release of what distribution?
* What period in time?
* If you happen to recall, what versions of: Linux (kernel), Mesa, and Xorg?
I happen to be using Arch Linux (a rolling release distribution) on my main gaming workstation. Thus my R9 285 is supported by Linux 4.13.4, Mesa 17.2.2, and Xorg 1.19.3. My overall system stability appears to be either approximately as stable as, or possibly more so than, the same hardware on a Windows platform.
The only area of issues I run across these days are games that ship their own copies of libraries that /should/ be expected (and should be required) to be native libraries instead. A few games that should work have issues resulting from that general root cause and Steam doesn't always do the best job of utilizing the more up to date native libraries.
Things weren't as bright when I first bought the hardware, but they have improved vastly as support in the drivers caught up, and I am confident that it will not regress in the future, at least not until long past when it would make sense to buy newer hardware.
RX480, Reference Edition.
I’ve tried: Arch Linux, Ubuntu 16.04, 16.10, 17.04 (currently on 16.04), latest Fedora.
Time period: Bought GPU 11 days after official release, been switching distros about every one or two months since due to issues.
Only used distro-provided kernel, Mesa and Xorg.
With AMDGPU, no game works and OpenGL crashes, Wayland crashes, and nothing really works. In all cases.
With AMDGPU-PRO, everything works, except there’s a 50/50 chance on every boot that WebGL in Firefox will be broken.
________________
This is exactly why I criticize the stubborn decision to refuse to allow such a solution. If the DAL is not implemented, we’ll never get feature parity for proprietary functionality between the Windows, Linux and Mac versions. AMD is known to release all their tech openly as soon as possible, but while they’re competing with NVIDIA in a space, they obviously can’t keep it 100% open.
And it’s also obvious that if AMD wants the same functionality on Windows, Linux, Mac and Android, they either need a DAL, or they need to let the Linux maintainers control their drivers for all other platforms.
I was annoyed at the teething problems too, but the progress has been good enough that I stable API doesn't seem necessary. If they hadn't tried to work in their own abstractions then the progress might have been better.
Not really. You're still so stubborn about having no DAL.
How do you propose should AMD develop an additional driver functionality for Linux, Mac, Windows and Android, and release them on the same day, without writing code twice, without such a DAL?
You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes.
But that's not true for GPU drivers anymore.
GPU drivers have to get feature updates every few weeks, and add new functionality and new APIs on all platforms at the same time with the same APIs. Often APIs that are completely new.
You can't write all this functionality 5 times for every platform while staying competitive with NVIDIA. The only choice is having a stable ABI to write driver extensions that implement the same new functionality for all platforms, or you'll never get the functionality.
And, guess what, that's exactly what happened.
Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux.
AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality. They absolutely can not release new features every week for the mainlined driver in the official kernel and write them separately for every OS. The alternative is a DAL, or no functionality.
Thank you for driving more users to Windows.
That isn't necessary.
> without writing code twice
That isn't anywhere near as difficult as you make it out to be. Writing code is not difficult, or particularly time-consuming. Designing code is.
Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. to run incorrectly to optimize for a specific proprietary game engine. Those updates are to the OpenGL/etc. implementation itself, not the communication with the kernel, meaning those changes will be similar, if not exactly the same in each driver, without any extra abstraction. Also remember that most of these AAA title games do not have Linux support in the first place, and many of them only support DirectX, which will not be implemented in the Linux driver.
Here in Linux, we care about FPS in proprietary game engines much less than correct working drivers.
> You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes.
It's true that graphics APIs (especially Vulkan) are continually changing, and that those changes must be implemented in each driver. That still does not mean it is significantly easier to write one implementation for windows, and just copy it to the Linux driver. In fact, those who work on Linux itself believe the opposite. It's also worth noting that Vulkan is meant to be so low-level that its implementations will likely be quite different between Windows and Linux.
> AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality.
If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me.
> Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux.
You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for. That means you are relying on AMD alone to implement them, so I am entirely unable to help you. That is the situation we started with for the entire driver, and AMDGPU marks a significant improvement.
You may believe that Linux devs compromising to allow AMD to create a complicated layer in their mainline driver would help them, but I don't believe that to be the case, and neither do they.
The true reason that AMD wants a DAL in their driver is that they aren't willing to entirely discard their old habits, and instead insist on a driver that is, at least partially, closed source. As long as they do that, they require themselves to do wildly unnecessary work, and create entirely worthless incompatibilities, purely out of stubbornness. Stubbornness that will continue to be reciprocated by the Linux dev team.
I will continue to do what I can to support AMD, as long as they make strides toward Free drivers, but I know there are always politics involved, and that AMD won't change overnight.
Yes it is, if you care about your users.
> Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. t
Thanks to Vulkan that’s irrelevant anyway – I’m talking about stuff like shadowplay or similar functionality, and the APIs for that.
> It's true that graphics APIs (especially Vulkan) are continually changing
> You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for.
Stop being so stubborn, please. You still don’t get it. I’m not talking about the graphics APIs, which change on a scale of months to years.
I’m talking about exactly these additional functionalities, which are basically addons to the driver, hook into the driver, and for example dump the driver state at a moment (for 3D screenshots), or keep a memory buffer of the current videostream (for instant replay and share), or so on.
None of this functionality has to be closed source.
If you want to have this functionality open, the best solution is to work on a stable ABI for them, so that AMD builds many separate modules for each, and you can slowly clone each of them with an open version, or AMD can selectively open them.
> If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me.
You mean, developers that still don’t get the entire point of what I’ve been talking about, developers that suggest they’d rather have people use Windows than add a stable driver ABI into Linux, developers that want to force a release cycle of several years onto drivers?
Because that’s the reality of forcing drivers to be mainlined without a stable ABI.
The majority of users will be stuck on a several year old kernel.
How the hell do you propose adding functionality with a latency of a few days or weeks between design and release into a kernel that only does releases every half year, and LTS releases every few years?
I do. Believe me, I do.
> developers that still don’t get the entire point of what I’ve been talking about
They do too. They acutely understand all of the advantages and drawbacks of a HAL, and how it would effect the project that they work on, and have chosen explicitly not to allow one. I'd like you to understand why, because these are intelligent people, many of them dedicating time and expertise for nothing in return but the satisfaction of the contribution itself.
It sounds like a great idea to have an abstract interface for these things. That's what a microkernel is all about. Microkernels are great, but Linux is a monolithic kernel. That is the core of its design. Linux isn't going to adapt its core design to be more compatible with proprietary software. In fact, Linux should do nothing to be more compatible with proprietary software, because that would simply perpetuate the problem.
A monolithic kernel does have some advantages.
* The kernel can change without breaking drivers, because drivers are part of the kernel
* There is no layer between drivers and the kernel, meaning no overhead, no translation, but raw communication.
These advantages are fundamentally broken by introducing abstraction layers. Extra abstraction also introduces more maintenance work.
If AMD really wants a microkernel, it can start focusing on its FreeBSD driver.
> None of this functionality has to be closed source.
That is entirely my point.
> If you want to have this functionality open, the best solution is to work on a stable ABI for them, so that AMD builds many separate modules for each, and you can slowly clone each of them with an open version, or AMD can selectively open them.
That is a compromise. A compromise that kernel devs are not willing to make. Linux is Free Software. Free as in Freedom. Free software users do not have to deal with the problems that are caused by proprietary software, of which there are many.
> How the hell do you propose adding functionality with a latency of a few days or weeks between design and release into a kernel that only does releases every half year, and LTS releases every few years?
> The majority of users will be stuck on a several year old kernel.
The "majority of users" are running enterprise servers. That is the only reason to use a longterm kernel release. Users of a longterm kernel will not expect driver updates, in fact expecting the opposite. The vast majority of users similar to you will be running stable kernels.
> Stable kernel updates are released on as-needed basis, usually 2-3 a month. [1]
That is an entirely reasonable time-frame for updates. If users want a more bleeding-edge release, they will use prepatch (RC) kernels.
Okay, I had to seriously burst out in laugh there. You do know Torvalds opinion on the GPL, and how he has ridiculed people trying to enforce the GPL on companies that fork Linux and publish proprietary forks?
And you do know that Torvalds considers the best option to find a compromise with the company, and slowly work on that?
> The vast majority of users similar to you will be running stable kernels.
And yet, where is Ubuntu 16.04 now?
> I do. Believe me, I do.
And yet, you don't seem to.
> If users want a more bleeding-edge release, they will use prepatch (RC) kernels.
I want the in-kernel functionality to be stable and LTS, but additional user-space functionality to be the most recent.
That kind of modularity is only possible if you actually have a modular system.
Do you know how annoying it is to debug a kernel crash when you're writing a device driver, because the kernel devs again changed some random API slightly around? And how much nicer it is to do this in userland? If you've ever written drivers, you know. And do you know how much nicer it is to separate a driver into modular pieces for the base functionality, and additional modules for addon functionality, such as the macro functionality of my keyboard?
Yet, with Linux, users get worse software, later, with more breakages, and half their hardware doesn't work. Tanenbaum was right.
Monolithic kernels are broken by design.
Yet, the kernel dev team do not want this particular compromise. It would go against the design they prefer to work with.
> And yet, where is Ubuntu 16.04 now?
Why are we talking about Ubuntu 16.04? Oh, right, you are trying to run AMDGPU-pro, and that is the specific distro version that AMD chose to support. Are you mad at the Linux devs or mad at AMD?
> I want the in-kernel functionality to be stable and LTS, but additional user-space functionality to be the most recent.
> That kind of modularity is only possible if you actually have a modular system.
Those are entirely reasonable things to want, but you aren't likely to find them with Linux. Linux is monolithic. It sounds like what you want is FreeBSD, with the support from AMD that Linux is getting. Currently, FreeBSD isn't very popular, so AMD chooses to ignore it.
> Yet, with Linux, users get worse software, later, with more breakages, and half their hardware doesn't work.
That has not been my experience during the years I have spent using Linux. In fact, I have experienced better software, sooner, with fewer breakages (especially in NixOS), and the vast majority of my hardware works. The only hardware that doesn't work are sound cards or obscure wifi adapters that have only incompatible proprietary drivers (I actually ran out of those. All my wifi adapters currently work without effort.). So sound cards are the only issue I have left. That's it. I have a nice USB DAC anyway.
I'm running KDE Neon, which only exists as version based on Ubuntu 16.04
> Those are entirely reasonable things to want, but you aren't likely to find them with Linux. Linux is monolithic. It sounds like what you want is FreeBSD, with the support from AMD that Linux is getting. Currently, FreeBSD isn't very popular, so AMD chooses to ignore it.
My goal is this:
(a) 100% free software in my life
(b) no compromise on cost, or functionality.
The DAL is the only possible way I can get that.
I want 100% of the functionality, at the cheapest price, with entirely free software.
That's why I've been spending 4 years of my life to build a hacky copy of every single cloud service or proprietary software I might rely on. And that's why I want the same for the drivers, it's why I've been writing hundredthousands (!) of lines of code by now to replace software, cloud services, and android driver modules.
The DAL with an open source, but out-of-tree driver, is the only way I'd ever get close to this. Any other option leads to more proprietary code in my life. Therefore, your actions are the same for me as the actions of Google: they attack my freedoms.
Why not?
Even if you honestly believe that it is a good idea to hide superior driver code (which it is not), AMD doesn't have any. NVIDIA has had superior proprietary drivers since AMD acquired ATI.
AMD has to license code from other third parties, too (which is a common reason for proprietary code), and in some situations (as with the new tiled rasterizer of VEGA, which with its beta drivers gets 2x the performance of the open driver), it has significant advantages over what NVIDIA has.
AMD always has opened as much as possible, as soon as possible, but there’s situations where that’s not directly possible.
And it looks like we’ll end up with a significant (factor of 2 or worse) performance difference between Linux and Windows in the next years for AMD drivers due to that.
This is the problem with proprietary software. There are politics involved. Note that when I refer to AMD, I am referring to a group of people, not a single individual. Those at AMD and those third parties that they work with that insist on proprietary software have made my life miserable. The hours I have spent trying to find a stable configuration to run fglrx are a direct result of their belief in the need for proprietary software. I'm sick of their excuses. I'm happy to finally have a free driver for my RX480. It's not perfect, but it's a leap in the right direction.
> And it looks like we’ll end up with a significant (factor of 2 or worse) performance difference between Linux and Windows in the next years for AMD drivers due to that.
That is true. I see that as AMD's fault, not the Linux devs'.
And I disagree with that. AMD has said they'd publish it openly, but only in a version that relies on their abstraction layer.
Because implementing it the first time already is over budget and past deadline, implementing it twice would be impossible.
You can have a working, open source, version in a few weeks just by compiling AMDs kernel branch, and modules. But you'll never get it in mainline. And mainline will always be months or years behind.
Then if there is no licensing issue with the code they provide, someone is free to merge it to the mainline driver.
> implementing it twice would be impossible.
au contraire. Implementing anything twice is well within the realm of possibility, and porting the original implementation is even more likely. that is if the original implementation is open source.
If AMD had started releasing their Windows driver source, but refused to do any work with Linux, then the Linux dev team would be porting the entire driver. Fortunately, AMD has done better than that: they are working with Linux, at least for the most part, leaving the Linux dev team with much less to port, and us with a much better time-frame for feature-parity.
> And mainline will always be months or years behind.
I don't believe that. I believe that if AMD decides to start working with the kernel, as opposed to working with an abstraction layer, that we will start seeing these updates happen rather quickly and painlessly. Some at AMD may believe that working with mainline directly is too difficult, but I don't find that argument very compelling.
...then we wouldn't see any driver, or AMD would be dead.
AMD is months (!) to years (!) behind schedule already with a single platform to develop for.
How do you suggest they develop for two entirely different platforms, with the same budget, in less time?
> If AMD had started releasing their Windows driver source, but refused to do any work with Linux, then the Linux dev team would be porting the entire driver. Fortunately, AMD has done better than that: they are working with Linux, at least for the most part, leaving the Linux dev team with much less to port, and us with a much better time-frame for feature-parity.
Any time frame that isn't immediate is broken.
> Then if there is no licensing issue with the code they provide, someone is free to merge it to the mainline driver.
Yes, and the kernel maintainers refuse to do that, as they'd have to either maintain an entire separate driver, or continuously merge AMDs driver again, and again, and again.
________________________
They write one single driver for all platforms, and have already problems to do that development.
The alternatives are such:
(1) No AMD support on Linux at all.
(2) You personally pay the necessary billions to fund AMDs dev team
(3) An open AMD driver is continued, functionality is heavily limited and it is useless for any serious applications, so NVIDIA continues to dominate
(4) an open source driver is implemented for all platforms on top of a DAL
My goal is: A GPU with open source driver that is competitive with the best possible product on the market, and open.
The only scenario where this is possible is by either someone doubling AMD's budget, or with the DAL. Any action to prevent the DAL leads to more proprietary code in my life, therefore I consider it an attack on myself.
Manufacturers ought to support their products for their full lifecycle instead of behaving like e-waste factories. If they're not happy about unstable kernel ABIs, they can start making Windows devices.
They also just combine many chips into their systems, and also get precompiled driver blobs.
You're asking the entire tech industry to change how they're doing things.
The reason no one has left Linus['s repo] in the dust is because no one has taken the effort to put out and maintain a general purpose API-standardised fork instead of heavily-customised, specific-to-their-own-business codebases.
For example, back when I was working with Sheevaplugs, I found that, say, kernel whatever.13 worked really well, but whatever.14 and later would provide significant glitching in USB audio.
Each new kernel can require a lot of time configuring for the use case at hand, building, testing, etc. And then if a significant new subsystem is added (systemd-related features, for example) or internal kernel architecture changes, it would be incredibly time consuming to update the rest of the toolchain and on-device software to match the new kernel, and then validate the device performance again.
So it is better to have LTS versions with minimal changes. This makes security updates more likely on critical embedded devices, since manufacturers can updare the kernel without being forced to retool a ton of unrelated software.
It's few different factors, like: Smartphones are harder to reverse-engineer, because of the smaller parts and greater integration and fewer common interconnects. Smartphones are more diverse, and each SoC "architecture" is significantly changed or replaced after just a year or two.
There's never enough time and mindshare for third-parties or the vendor itself to write high-quality base system drivers for these things. There's just crappy vendor "BSP" code that's never good enough to maintain support for multiple generations in the same code tree. It's always "fork and add messy hacks until it works". There's never enough time and motivation to make any of this support code good enough to be reused.
Some kernel maintainers have tried for some time to convince "enterprise" linux distros to keep up with newer kernels, and apply more of their testing and validation effort to newer kernels, instead of just maintaining one old kernel on their own for most of a decade. This enables more sharing of this effort between multiple distros and other users of the linux kernel. To some extent they have succeeded. But where they have failed, at least the "enterprise" distros did maintain the old kernels they distribute.
But these smartphone SoC vendors don't even do that. They really give zero fucks about software quality. It seems to work, ship it, move on to the next iteration because it has to make it to market in X months to keep up with the competition. At that rate, third-parties can't even come close to keeping up and justifying the investment of effort in reverse-engineering (which has been done for a lot of desktop hardware).
Linus is also incapable of dealing with these companies in a way that they care about (see the middle finger to nVidia) so it's unlikely there's going to be any real progress. This is a fact: no company wants to spend resources chasing after every new kernel development if it doesn't specifically suit their needs. Windows solved this by having stable APIs that only rarely change. OS X solved this by making it basically unnecessary -- most of the hardware that needs drivers is either built-in or works over something generic like USB -- and even then has nice interfaces for drivers that are well documented and don't change that often.
Linux attempts to have the freedom of the former without any kernel developer burden, and the outcome is that no HW vendor cares much to contribute upstream since it requires a lot of time and effort that's mostly just a cost
You'll also find that there are devices that had decent drivers for Windows XP when they were released, but never had Vista or Windows 7 or later drivers made. Those devices worked well on linux a couple years after they worked on windows with reverse-engineered drivers, and then (ironically) kept working for a decade or more, whereas the windows drivers did not. This includes a variety of printers, sound cards, non-standard usb devices, and more.
It's definitely true that many hardware companies which have modeled their driver development and support around the windows model can't handle the linux model at all. But linux has other priorities than to cater to them, and has done better than windows in server and embedded use-cases as a result.
The ongoing efforts to drop anything GPL related on each new Android release shows where it is going.
You also gave a good example, OEMs want consumers to buy new devices, not to keep using existing ones.
Ostensibly any patches found in an LTS kernel, must first be proven in a mainline release. But it'll be interesting to see just exactly how old and crusty these kernels end up becoming.
> Today, it's on Google to maintain dead kernels that it is
> still supporting. The 2016 Google Pixel shipped with
> Linux kernel 3.18, which was first released in 2014 and
> hit end-of-life in January 2017.
What I'm getting at is that there's no stable driver API or ABI and we're forced to suffer through regressions caused by development to support new graphics stack features or new GPUs, while one's "old" GPU was fully supported and stable in earlier kernels. With more and of the desktop and applications using the GPU for compositing, it's very easy to hang your Wayland or Xorg session for seconds until the driver recovers. This is on top of the many DMAR issues.
I don't like using an LTS kernel but I do need stable drivers because without those I cannot use the computer and neither can industrial embedded machines. I admit that it's highly likely that the high churn in the graphics drivers is the cause and it can be singled out, because I don't remember any regression in other drivers. I say it's time to rethink the development model of Linux kernel drm drivers.
It almost never happens. A chip and device dies with the first and only kernel that were supported on them.
The focus of the industry should move to shipping up to date software in all devices, particularly in this infrastructure level software.
How can you expect embedded manufactures to do this when Intel can't even keep it's CPU line stable on recent kernels. I have an Bay Trail tablet that I put Linux on, but was forced to move it back on to the ancient Android kernel that shipped with it because of this bug[1].
And if you think, these bugs only happen to Atom/Celron CPUs, think again. My Intel i3 laptop just started hard freeing with the latest 4.13 Kernel in Arch.[2]
As a hobbyist, i can deal, but there is no way you can expect small manufactures to deal with the constant influx of bugs introduced by kernel updates.
Well then maybe they should not be in the business they are in.
As people so like to point out here, their inability to support the devices they make becomes an externality that all the users end up paying for, when they have to deal with security vulnerabilities that cannot be resolved.
If, as per the table below [1], they've already moved on to 4.10, then 6 years is a long time to support 4.9
[1] https://android.stackexchange.com/questions/51651/which-andr...