4 ms·

6 years is way to short for some use-cases, like phones sadly it's not rare that some phone hardware proprietary drivers are basically written once and then ha

6 years is way to short for some use-cases, like phones 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

xvilka 3y ago
> 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. These manufacturers should be punished by the lack of LTS and need to upgrade precisely because of that lazyness and incompetence.
- charcircuit 3y ago
  Why not blame the kernel developers for being lazy and incompetent for not offering a stable API for driver developers to use? You don't see Windows driver developers having their drivers broken by updates every few months.
  - mschuster91 3y ago
    > 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.
    - charcircuit 3y ago
      >no matter if there are bugs or there are more efficient ways to get something done. 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.
      - kelnos 3y ago
        Stability is worth it to you. Others can hold different opinions and make different decisions, and until and unless you -- or someone like minded -- becomes the leader of a major open source kernel project used in billions of devices, the opinions of those others will rule the day.
        charcircuit 3y ago
        All developers love stability of the platform they are building on. Good platforms recognize this.
  - dathinab 3y ago
    It's less kernel developers then a certain subset of companies providing proprietary drivers only. 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.
    - charcircuit 3y ago
      Why stop at kernel space. You might as well break all of user space every so often. If everything is open source it shouldn't be an issue to fix all broken Linux software right? People don't want you to break their code.
      - xvilka 3y ago
        It happens all the time with Glibc, Glib, GTK, Qt, etc
        charcircuit 3y ago
        Those breaking changes often are years apart which I sn much better than what the kernel currently offers.
      - kelnos 3y ago
        > You might as well break all of user space every so often. If everything is open source it shouldn't be an issue to fix all broken Linux software right? 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.
  - kelnos 3y ago
    Because the kernel developers are not beholden to chipset manufacturers who want to spend the shortest possible time writing a close-source driver and then forgetting about it. They're there to work on whatever they enjoy, as well as whatever their (paying) stakeholders care about. 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.
    - charcircuit 3y ago
      Chipset providers are not interested in showing off their trade secrets to the entire world. >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.
Hackbraten 3y ago
That's one of the reasons Purism went out of their way to upstream all drivers for the Librem 5. The distribution can upgrade kernels pretty much whenever it wants. 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.
- benj111 3y ago
  i dont really get how this continues. 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?
  - charcircuit 3y ago
    Not a lot of software requires a bleeding edge kernel. If vendor B has a superior chip at a viable price it makes sense to go with them.
  - Hackbraten 3y ago
    Contributing a driver to mainline Linux takes significant time and effort up front. You can't just throw anything over the Linux fence and expect that already-overworked kernel maintainers keep tending for it for the next decades. 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.
    - benj111 3y ago
      Precisely. 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
eimrine 3y ago
After your message I started to think about LTS with 6-years support but every 3 years a new LTS.
mschuster91 3y ago
> 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. 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.
- kelnos 3y ago
  Google realistically can't do this. "The SoC vendors" is basically Qualcomm (yes, I know there are others, but if Qualcomm doesn't play ball, none of it matters). 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.)
mrweasel 3y ago
> so for some hardware it might mean that when it gets released you only have noticeable less then 6 years of kernel support 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.
- dathinab 3y ago
  they often can't proprietary drivers for phone parts are often not updated to support newer kernels
  - kelnos 3y ago
    That's the point: these drivers should get updated. Obviously the low-level component manufacturers don't want to do this, but perhaps we need to find a way to incentivize them to do so. And if that fails, to legally force them.

xvilka 3y ago

charcircuit 3y ago
Why not blame the kernel developers for being lazy and incompetent for not offering a stable API for driver developers to use? You don't see Windows driver developers having their drivers broken by updates every few months.
- mschuster91 3y ago
  > 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.
  - charcircuit 3y ago
    >no matter if there are bugs or there are more efficient ways to get something done. 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.
    - kelnos 3y ago
      Stability is worth it to you. Others can hold different opinions and make different decisions, and until and unless you -- or someone like minded -- becomes the leader of a major open source kernel project used in billions of devices, the opinions of those others will rule the day.
      - charcircuit 3y ago
        All developers love stability of the platform they are building on. Good platforms recognize this.
- dathinab 3y ago
  It's less kernel developers then a certain subset of companies providing proprietary drivers only. 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.
  - charcircuit 3y ago
    Why stop at kernel space. You might as well break all of user space every so often. If everything is open source it shouldn't be an issue to fix all broken Linux software right? People don't want you to break their code.
    - xvilka 3y ago
      It happens all the time with Glibc, Glib, GTK, Qt, etc
      - charcircuit 3y ago
        Those breaking changes often are years apart which I sn much better than what the kernel currently offers.
    - kelnos 3y ago
      > You might as well break all of user space every so often. If everything is open source it shouldn't be an issue to fix all broken Linux software right? 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.
- kelnos 3y ago
  Because the kernel developers are not beholden to chipset manufacturers who want to spend the shortest possible time writing a close-source driver and then forgetting about it. They're there to work on whatever they enjoy, as well as whatever their (paying) stakeholders care about. 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.
  - charcircuit 3y ago
    Chipset providers are not interested in showing off their trade secrets to the entire world. >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.

Hackbraten 3y ago

That's one of the reasons Purism went out of their way to upstream all drivers for the Librem 5. The distribution can upgrade kernels pretty much whenever it wants. 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.

benj111 3y ago
i dont really get how this continues. 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?
- charcircuit 3y ago
  Not a lot of software requires a bleeding edge kernel. If vendor B has a superior chip at a viable price it makes sense to go with them.
- Hackbraten 3y ago
  Contributing a driver to mainline Linux takes significant time and effort up front. You can't just throw anything over the Linux fence and expect that already-overworked kernel maintainers keep tending for it for the next decades. 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.
  - benj111 3y ago
    Precisely. 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

eimrine 3y ago

After your message I started to think about LTS with 6-years support but every 3 years a new LTS.

mschuster91 3y ago

> 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. 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.

kelnos 3y ago
Google realistically can't do this. "The SoC vendors" is basically Qualcomm (yes, I know there are others, but if Qualcomm doesn't play ball, none of it matters). 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.)

mrweasel 3y ago

> so for some hardware it might mean that when it gets released you only have noticeable less then 6 years of kernel support 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.

dathinab 3y ago
they often can't proprietary drivers for phone parts are often not updated to support newer kernels
- kelnos 3y ago
  That's the point: these drivers should get updated. Obviously the low-level component manufacturers don't want to do this, but perhaps we need to find a way to incentivize them to do so. And if that fails, to legally force them.