It really depends on what you're doing. 6 years seems like a happy medium to me, but then again I'm not the one supporting it. I expect the kernel devs would be singing a different tune if people were willing to pay for that extended support.
https://upload.wikimedia.org/wikipedia/en/timeline/276jjn0uo...
They're just legacy now IMO and their long term support requirements are a result of this, companies that haven't gotten rid of them by now aren't likely to do it any time soon.
I hate seeing them go. I wasn't such a fan of Solaris but I was of HP-UX. But its days are over. It doesn't even run on x86 or x64 and HP has been paying Intel huge money to keep itanium on life support, which is running out now if it hasn't already.
At least Solaris had an Intel port but it too is very rare now.
Outside of tech focused companies, 10+ year old systems really are the norm.
It's because outside of tech companies, nobody cares about new features. They care about things continuing to work. Companies don't buy software for the fun of exploring new versions, especially frustratingly pointless cosmetic changes that keep hitting their training budgets.
Many companies would be happy with RHEL5 or Windows XP today from a feature standpoint, if it weren't a security vulnerability.
CentOS/RHEL 6 was already pretty long in the tooth, but being the contrarian I am, I was not looking forward to the impending systemd nonsense.
Today at work, we finally got the OK to stop supporting CentOS 7, for new releases.
Old systems are stable, but there’s a fine line between that and stagnation. Tread carefully.
Most of our .NET workloads are still for .NET Framework, and only now we are starting to have Java 17 for new projects, and only thanks to projects like Spring pushing for it.
Ah, and C++ will most likely be a mix of C++14 and C++17, for new projects.
so likely <5 years since release of the hardware in the US
likely <4 years since release of hardware outside of the US
likely <3 years since you bought the hardware
and if you buy older phones having only a year or so of proper security updates is not that unlikely
So for phones you would need more something like a 8 or 10 year LTS, or well, proper driver updates for proprietary hardware. In which case 2 years can be just fine because in general/normally only drivers are affected by kernel updates.
sadly it's not rare that some phone hardware proprietary drivers are basically written once and then hardly maintained and in turn only work for a small number of Linux kernel versions.
so for some hardware it might mean that when it gets released you only have noticeable less then 6 years of kernel support
then between starting to build a phone and releasing it 2 years might easily pass
so that means from release you can provide _at most_ 4 years of kernel security patches etc.
but dates tend to not align that grate so maybe it's just 3 years
but then you sell your phone for more then one year, right?
in which case less then 2 years can be between the customer buying your product and you no longer providing kernel updates
that is a huge issue
I mean think about it if someone is a bit thigh on money and buy a slightly older phone they probably aren't aware that their phone stops getting security updates in a year or so (3 years software support since release but it's a 2 year old phone) at which point using it is a liability.
EDIT: The answer is in my opinion not to have even longer LTS but to proper maintain drivers and in turn being able to do full kernel updates
These manufacturers should be punished by the lack of LTS and need to upgrade precisely because of that lazyness and incompetence.
You don't see Windows driver developers having their drivers broken by updates every few months.
At the cost of Windows kernel development being a huge PITA because effectively everything in the driver development kit becomes an ossified API that can't ever change, no matter if there are bugs or there are more efficient ways to get something done.
The Linux kernel developers can do whatever they want to get the best (most performant, most energy saving, ...) system because they don't need to worry about breaking someone else's proprietary code. Device manufacturers can always do the right thing and provide well-written modules to upstream - but many don't because (rightfully) the Linux kernel team demands good code quality which is expensive AF. Just look at the state of most non-Pixel/Samsung code dumps, if you're dedicated enough you'll find tons of vulnerabilities and code smell.
Stability is worth it. After 30 years of development the kernel developers should be able to come up with a solid design for a stable api for drivers that they don't expect to radically change in a way they can't support.
Most linux kernel changes are limited enough so that updating a driver is not an issue, IFF you have the source code.
That is how a huge number of drivers are maintained in-tree, if they had to do major changes to all the drivers every time anything changes they wouldn't really get anything done.
Only if you don't have the source code is driver breakage an issue.
But Linux approach to proprietary drivers was always that there is no official support when there is no source code.
People don't want you to break their code.
What an uninformed take.
The Linux kernel has a strict "don't break userspace" policy, because they know that userspace is not released in lock step with the kernel. Having this policy is certainly a burden on them to get things right, but they've decided the trade offs make it worth it.
They have also chosen that the trade offs involved in having a stable driver API are not worth it.
> People don't want you to break their code.
Then maybe "people" (in this case device manufacturers who write crap drivers) should pony up the money and time to get their drivers mainlined so they don't have to worry about this problem. The Linux kernel team doesn't owe them anything.
They also know out of tree drivers are not released lock step with the kernel.
>They have also chosen that the trade offs involved in having a stable driver API are not worth it.
It sucks for driver developers to not have a stable API regardless if they think its worth it or not.
>should pony up the money and time to get their drivers mainlined so they don't have to worry about this problem.
They don't want to reveal their trade secrets.
>The Linux kernel team doesn't owe them anything.
Which is why Google ended up offering the stable API to driver developers.
The solution to all this is pretty simple: release the source to these drivers. I guarantee members of the community -- or, hell, companies who rely on these drivers in their end-products -- will maintain the more popular/generally-useful ones, and will update them to work with newer kernels.
Certainly the ideal would be to mainline these drivers in the first place, but that's a long, difficult process and I frankly don't blame the chipset manufacturers for not caring to go through it.
Also, real classy to call the people who design and build the kernel that runs on billions of devices around the world "lazy and incompetent". Methinks you just don't know what you're talking about.
>Also, real classy to call the people who design and build the kernel that runs on billions of devices around the world "lazy and incompetent"
I never did that. The parent comment did call manufacters that and I suggested that the kernel developers are at some fault.
The downside can be painful though: sourcing components with such properties is hard. You basically have to cherry-pick them from all over the world because they're so few and far between.
That's one of the reasons why the Librem 5 is so thick and consumes so much energy.
vendor A sells a part with a driver in the mainline kernel.
vendor B doesnt, so on top of the part you have to spend time bodging together an untested driver into a custom kernel.
as a buyer why would you go for the second?
Slapping together a half-working out-of-tree kernel module and calling it a day is not only much cheaper; it also buys you the time you need to write the new driver for next year's hot shit SoC that smartphone vendors demand.
What would you want as a buyer. A driver that has already demonstrated that it is good enough to be included in the kernel, or one of unknown quality that may need extra work to integrate with the kernel.
I get why suppliers don't want to do the work. I just don't understand why there isn't enough value add for buyers to justify the premium for the benefits of a mainline driver, and/or why sellers don't try and capture that premium
Also consider the cultural context. The culture of hardware manufacturers is much different than that of software vendors. They don't view software as a product, but more a necessary evil to make their hardware work with existing software infrastructure. They want to spend as little time on it as possible and then move onto the next thing.
I'm not endorsing this status quo, merely trying to explain it.
many consumers are not aware about the danger a unmaintained/non-updatable software stack introduces or that their (mainly) phone is unmaintained
so phone vendor buys from B because A is often just not an option (not available for the hardware you need) and then dumps the problem subtle and mostly unnoticeable on the user
there are some exceptions, e.g. Fairphone is committed to quite long term software support so they try to use vendor As or vendor Bs which have contractual long term commitment for driver maintaince
but in the space of phones (and implicit IoT using phone parts) sadly sometimes (often) the only available option for the hardware you need is vendor B where any long term diver maintenance commitment contracts are just not affordable if you are not operating on a scale of a larger phone vendor
E.g. as far as I remember Fairphone had to do some reserve engineering/patching to continue support for the FP3 until today (and well I think another 2 or so years), and I vaguely remember that they where somewhat lucky that some open source driver work for some parts was already ongoing and getting some support with some of the vendors. For the FP5 they manage to have a more close cooperation with Qualcomm allowing them to provide a 5 year extended warranty and target software support for 8 years (since release of phone).
So without phone producer either being legally forced to have a certain amount of software support (e.g. 3 years after last first party selling) or at least be largely visible transparent about the amount of software support they do provide upfront and also inform their user when the software isn't supported anymore I don't expect to see any larger industry wide changes there.
Through some countries are considering laws like that.
1. Hit to the BOM (i.e. cost); and chip
2. Suppliability (i.e., can we get enough pieces, by the time we need them, preferably from fewer suppliers).
In the product I was involved in building (full OS, from bootloader to apps), I was lucky that the hardware team (separate company) was willing to base their decisions on my inputs. The hardware company would bear the full brunt of BOM costs, but without software the hardware was DOA and wouldn't even go to manufacturing. This symbiotic relationship, I think, is what made it necessary for them to listen to our inputs.
Even so, I agreed software support wasn't a super strong input because:
1. There's more room for both compromises and making up for compromises, in software; and
2. Estimating level of software support and quality is more nuanced than just a "Has mainline drivers?" checkbox.
For example, RPi 3B vs. Freescale iMX6. The latter had complete mainline support (for our needs) but the former was still out-of-tree for major subsystems. The RPi was cheaper. A lot cheaper.
I okayed RPi for our base board because:
1. Its out-of-tree kernel was kept up-to-date with mainline with a small delay, and would have supported the next LTS kernel by the time our development was expected to finish (a year);
2. Its out-of-tree code was quite easy (almost straightforward) to integrate into the Gentoo-based stack I wanted to build the OS on; and
3. I was already up-and-running with a prototype on RPi with ArchLinuxARM while we were waiting for iMX6 devkits to be sourced. If ArchLinuxARM could support this board natively, I figured it wouldn't be hard to port it to Gentoo; turned out Gentoo already had built-in support for its out-of-tree code.
Of course, not every sourcing decision was as easy as that. I did have to write a driver for an audio chip because its mainline driver did not support the full range of features the hardware did. But even in that case, the decision to go ahead with that chip was only made after I was certain that we could write and maintain said driver.
Your Raspberry Pi example is IMO even more illustrative than you let on. I'll reiterate that even that platform is not open and doesn't have a full set of mainlined drivers, after a decade of incredibly active development, by a team that is much more dedicated to openness than most other device manufacturers. Granted, they picked a base (ugh, Broadcom) that is among the worst when it comes to documentation and open source, but I think that also proves a point: device manufacturers don't have a ton of choice, and need to strike a balance between openness and practical considerations. The Raspberry Pi folks had price and capability targets to go with their openness needs, and they couldn't always get everything they wanted.
Caring about long-term maintenance isn't what most buyers do. Going SIM-only on your data plan is out of the ordinary.
Also in my experience people largely pick their phones based on the surface level hardware rather than the long-term reliability. Hence why Apple keeps putting fancier cameras into every iPhone even though I'm pretty sure a good chunk of customers don't need a fancy camera. Heck, just getting a phone that fits in my hand was a struggle because buyers somehow got convinced that bigger phone = better phone and now most smartphones on the market are just half-size tablets.
That trend at least seems to be somewhat reversing though.
And most vendors are like vendor B because they're leading the pack in terms of performance, power consumption, and die size (among other things) and have the market power to avoid having to do everything their customers want them to do.
Still, some headway has been made: Google and Samsung have been gradually getting some manufacturers (mainly Qualcomm) to support their chips for longer. It's been a slow process, though.
As for mainlining: it's a long, difficult process, and the vendor-B types just don't care, and mostly don't need to care.
The worst part of all of this is: Google could go and mandate that the situation improves by using the Google Play Store license - only grant it if the full source code for the BSP is made available and the manufacturer commits to upstreaming the drivers to the Linux kernel. But they haven't, and so the SoC vendors don't feel any pressure to move to sustainable development models.
Google has tried to improve the situation, and has made some headway: that's why they were able to get longer support for at least security patches for the Pixel line. Now that they own development of their own SoC, they're able to push that even farther. But consider how that's panned out: they essentially hit a wall with Qualcomm, and had to take ownership of the chipset (based off of Samsung's Exynos chip; they didn't start from scratch) in order to actually get what they want when it comes to long-term support. This should give you an idea of the outsized amount of power Qualcomm has in this situation.
Not many companies have the resources to do what Google is doing here! Even Samsung, who designed their own chipset, still uses Qualcomm for a lot of their products, because building a high-performance SoC with good power consumption numbers is really hard. Good luck to most/all of the smaller Android manufacturers who want more control over their hardware.
(Granted, I'm sure Google didn't decide to build Tensor on their own solely because of the long-term support issues; I bet there were other considerations too.)
Or they could just upgrade the kernel to a newer version. There's no rule that says that the phone needs to run the same major kernel version for its entire lifetime. The issue is that if you buy a sub €100 phone, how exactly is the manufacturer supposes to finance the development and testing of never versions of the operating system? It might be cheap enough to just apply security fixes to an LTS kernel, but moving and re-validating drivers for hardware that may not even be manufactured quickly becomes unjustifiable expensive for anything but flagship phones.
proprietary drivers for phone parts are often not updated to support newer kernels
Do you jump LTS releases. So one you are on is ending and there is brand new available? Or do you go to one before and have possibly only 2 or 4 years left...
2 years on the other hand seems incredibly short? Am I wrong?