10 ms·

As an ex-Novell/SUSE employee this makes sense to me. Upstream is supposed to keep marching onwards. Backporting is _so_ much work. And it's unfortunately not

by athrun 3y ago

As an ex-Novell/SUSE employee this makes sense to me. Upstream is supposed to keep marching onwards. Backporting is _so_ much work. And it's unfortunately not sexy work either, so it's always going to be hard attracting unpaid contributors for it. If you need stability and long term support as a customer, you have companies like RedHat or SUSE whose entire point is providing 10+ years maintenance on these components.

structural 3y ago
Unfortunately, none of these companies providing 10+ years of maintenance are doing so for most embedded devices. We either need to get SoC vendors to update their kernel baselines regularly This is hard, we've been trying for a decade and not seen much progress. Alternately, get them to backport fixes and patches (there's actually been quite a bit of progress here in getting them to actually take updates from the stable kernel at all! And that's getting thrown away now...)
- worthless-trash 3y ago
  If they got their fixes upstream , they would be pulled into the same build tree that centos and rhel uses.
  - dcow 3y ago
    Which really makes you understand why the lgpl was a defeat.
    - tremon 3y ago
      What do you mean? The Linux kernel isn't licensed under the LGPL.
- qznc 3y ago
  The effect of EU’s Cyber Resilience Act will be interesting. It requires maintenance, at least for security fixes.
  - athrun 3y ago
    Exactly. It sounds like currently there's no money to be made supporting old embedded devices (in the consumer space at least), because no one is on the hook for long term maintenance. Regulations _could_ change the incentives, and create a market for long term servicing. Regulations are hard to get right though...
    - WJW 3y ago
      Old devices getting support from the Linux team is only one of the ways this can play out though. Some other ways I can think of: - Old devices are phased out sooner. - Moving away from linux towards proprietary embedded OSes that do provide support. - No doubt some companies will try just ignoring the regulations
      - microtonal 3y ago
        Or maybe vendors will be incentivized to actually upstream kernel patches, plus stop making 10 different models every year for weird market segmentation reasons.
      - ladyanita22 3y ago
        Nobody will move out of Linux, and old devices won't be phased out sooner, at least not in s significant manner.
      - robertlagrant 3y ago
        They could also provide the devices without an OS, and point you at the recommended open source ISO to download.
        TheLoafOfBread 3y ago
        If it is not standard x86, then good luck.
      - bee_rider 3y ago
        “Old devices are phased out sooner” seems like an OK solution with some caveats. It is nice that it makes the cost of not supporting things visible to the users. Assuming “phased out” means the device will actually stop operating; “Company X’s devices have a short lifetime” is an easy thing for people to understand. I suspect consumers will look for brands that don’t have this reputation, which should give those well behaved brands a boost. Although, if it does turn out that just letting devices die is the common solution, maybe something will need to be done to account for the additional e-waste that is generated. Moving toward proprietary OSes; hey, if it solves the problem… although, I don’t see why they’d have an advantage in keeping things up to date. It is possible that companies will just break the law but then, that’s true of any law.
- nudgeee 3y ago
  Isn’t this what the Civil Infrastructure Platform (CIP) initiative [0] was also proposing? Maintenance of Linux kernels on the 10+ year horizon aimed at industrial use cases. Has backing from Toshiba, Hitachi, Bosch, Siemens, Renesas, etc, though a marked lack of chip vendors as members. Not really sure how well it is going though. [0] https://wiki.linuxfoundation.org/civilinfrastructureplatform/start https://wiki.linuxfoundation.org/civilinfrastructureplatform...
- pxc 3y ago
  > Unfortunately, none of these companies providing 10+ years of maintenance are doing so for most embedded devices. But why do these devices need special kernels anyway? Isn't that the real problem?
  - Const-me 3y ago
    Linux kernel doesn't have ABI for device drivers. The device manufacturers either can't or won't publish the drivers as a part of Linux kernel, that's why they fork Linux instead.
- kelnos 3y ago
  Not sure who the "we" is that you refer to, but Google (and Samsung, and other Android manufacturers, as well as companies building other Linux-based embedded/IoT devices) could band together and create a "Corporate Embedded Linux Consortium", and pool some money together to pay developers to maintain old kernel versions. If the mainline kernel devs are uncomfortable allowing those to be official kernel.org releases, that's fine: the CELC can host the new versions themselves and call the versions something like "5.10.95-celc" or whatever. I don't get why this is so difficult for people to grasp: if you want long-term maintenance of something, then pay people to maintain it long-term. It's a frighteningly simple concept. But yes, it'd be better for SoC vendors to track upstream more closely, and actually release updates for newer kernel versions, instead of the usual practice of locking each chip to whatever already-old kernel they choose from the start. Or, the golden ideal: SoC vendors should upstream their changes. But fat chance of that happening any time soon. > (there's actually been quite a bit of progress here in getting them to actually take updates from the stable kernel at all! And that's getting thrown away now...) I found this statement kinda funny. If the original situation was that they wouldn't take updates from the stable kernels, then what were all those unpaid developers even maintaining them for? It's bad enough that it's (for most people) unrewarding work that they weren't getting paid for... but then few people were actually making use of it? Ouch. No wonder they're giving up, regardless of any progress made with the SoC vendors.
  - leonheld 3y ago
    >SoC vendors should upstream their changes. But fat chance of that happening any time soon I honestly do not understand why SoC vendors don't put the extra 1% effort in upstreaming their stuff. I've seen (and worked with) software that is lagging 3 to 4 years behind upstream developed by these vendors and if you diff it against upstream it's like 10 small commits, granted, these commits are generally hot garbage.
throwawaymqsh 3y ago
> it's unfortunately not sexy work What comprises sexy work in programming?
- samtho 3y ago
  New features, typically.
- xnorswap 3y ago
  I don't know what the definition of "sexy work" is, but rewarding work in programming is solving interesting problems. Backporting fixes isn't generally interesting problem solving.
  - rkta 3y ago
    And so everyone has his own kink. I'd love to backport patches maintaining some legacy code base.
  - UncleMeat 3y ago
    This is the root of so much of our software quality problem. “I want to work on something shiny” outweighs “I have pride in this software and want to keep it healthy.”
    - xnorswap 3y ago
      Personally I love working on legacy software, I actually dislike greenfield projects, but even in the context of legacy software and system maintenance, backporting fixes would still not rate highly or provide much in the way of interesting work for me.
    - tremon 3y ago
      I'd say there's enough software developers that enjoy doing the latter. It's mostly the external motivation (both in community standing and in payments) that push people to shiny new things.
- esrauch 3y ago
deleted 3y ago
[deleted]
neurostimulant 3y ago
> If you need stability and long term support as a customer, you have companies like RedHat or SUSE whose entire point is providing 10+ years maintenance on these components. Is that even feasible for projects like the Android kernel that distributes their fork to vendors when RedHat forbid redistribution of their source code?

by athrun 3y ago

structural 3y ago

Unfortunately, none of these companies providing 10+ years of maintenance are doing so for most embedded devices. We either need to get SoC vendors to update their kernel baselines regularly This is hard, we've been trying for a decade and not seen much progress. Alternately, get them to backport fixes and patches (there's actually been quite a bit of progress here in getting them to actually take updates from the stable kernel at all! And that's getting thrown away now...)

worthless-trash 3y ago
If they got their fixes upstream , they would be pulled into the same build tree that centos and rhel uses.
- dcow 3y ago
  Which really makes you understand why the lgpl was a defeat.
  - tremon 3y ago
    What do you mean? The Linux kernel isn't licensed under the LGPL.
qznc 3y ago
The effect of EU’s Cyber Resilience Act will be interesting. It requires maintenance, at least for security fixes.
- athrun 3y ago
  Exactly. It sounds like currently there's no money to be made supporting old embedded devices (in the consumer space at least), because no one is on the hook for long term maintenance. Regulations _could_ change the incentives, and create a market for long term servicing. Regulations are hard to get right though...
  - WJW 3y ago
    Old devices getting support from the Linux team is only one of the ways this can play out though. Some other ways I can think of: - Old devices are phased out sooner. - Moving away from linux towards proprietary embedded OSes that do provide support. - No doubt some companies will try just ignoring the regulations
    - microtonal 3y ago
      Or maybe vendors will be incentivized to actually upstream kernel patches, plus stop making 10 different models every year for weird market segmentation reasons.
    - ladyanita22 3y ago
      Nobody will move out of Linux, and old devices won't be phased out sooner, at least not in s significant manner.
    - robertlagrant 3y ago
      They could also provide the devices without an OS, and point you at the recommended open source ISO to download.
      - TheLoafOfBread 3y ago
        If it is not standard x86, then good luck.
    - bee_rider 3y ago
      “Old devices are phased out sooner” seems like an OK solution with some caveats. It is nice that it makes the cost of not supporting things visible to the users. Assuming “phased out” means the device will actually stop operating; “Company X’s devices have a short lifetime” is an easy thing for people to understand. I suspect consumers will look for brands that don’t have this reputation, which should give those well behaved brands a boost. Although, if it does turn out that just letting devices die is the common solution, maybe something will need to be done to account for the additional e-waste that is generated. Moving toward proprietary OSes; hey, if it solves the problem… although, I don’t see why they’d have an advantage in keeping things up to date. It is possible that companies will just break the law but then, that’s true of any law.
nudgeee 3y ago
Isn’t this what the Civil Infrastructure Platform (CIP) initiative [0] was also proposing? Maintenance of Linux kernels on the 10+ year horizon aimed at industrial use cases. Has backing from Toshiba, Hitachi, Bosch, Siemens, Renesas, etc, though a marked lack of chip vendors as members. Not really sure how well it is going though. [0] https://wiki.linuxfoundation.org/civilinfrastructureplatform/start https://wiki.linuxfoundation.org/civilinfrastructureplatform...
pxc 3y ago
> Unfortunately, none of these companies providing 10+ years of maintenance are doing so for most embedded devices. But why do these devices need special kernels anyway? Isn't that the real problem?
- Const-me 3y ago
  Linux kernel doesn't have ABI for device drivers. The device manufacturers either can't or won't publish the drivers as a part of Linux kernel, that's why they fork Linux instead.
kelnos 3y ago
Not sure who the "we" is that you refer to, but Google (and Samsung, and other Android manufacturers, as well as companies building other Linux-based embedded/IoT devices) could band together and create a "Corporate Embedded Linux Consortium", and pool some money together to pay developers to maintain old kernel versions. If the mainline kernel devs are uncomfortable allowing those to be official kernel.org releases, that's fine: the CELC can host the new versions themselves and call the versions something like "5.10.95-celc" or whatever. I don't get why this is so difficult for people to grasp: if you want long-term maintenance of something, then pay people to maintain it long-term. It's a frighteningly simple concept. But yes, it'd be better for SoC vendors to track upstream more closely, and actually release updates for newer kernel versions, instead of the usual practice of locking each chip to whatever already-old kernel they choose from the start. Or, the golden ideal: SoC vendors should upstream their changes. But fat chance of that happening any time soon. > (there's actually been quite a bit of progress here in getting them to actually take updates from the stable kernel at all! And that's getting thrown away now...) I found this statement kinda funny. If the original situation was that they wouldn't take updates from the stable kernels, then what were all those unpaid developers even maintaining them for? It's bad enough that it's (for most people) unrewarding work that they weren't getting paid for... but then few people were actually making use of it? Ouch. No wonder they're giving up, regardless of any progress made with the SoC vendors.
- leonheld 3y ago
  >SoC vendors should upstream their changes. But fat chance of that happening any time soon I honestly do not understand why SoC vendors don't put the extra 1% effort in upstreaming their stuff. I've seen (and worked with) software that is lagging 3 to 4 years behind upstream developed by these vendors and if you diff it against upstream it's like 10 small commits, granted, these commits are generally hot garbage.

throwawaymqsh 3y ago

> it's unfortunately not sexy work What comprises sexy work in programming?

samtho 3y ago
New features, typically.
xnorswap 3y ago
I don't know what the definition of "sexy work" is, but rewarding work in programming is solving interesting problems. Backporting fixes isn't generally interesting problem solving.
- rkta 3y ago
  And so everyone has his own kink. I'd love to backport patches maintaining some legacy code base.
- UncleMeat 3y ago
  This is the root of so much of our software quality problem. “I want to work on something shiny” outweighs “I have pride in this software and want to keep it healthy.”
  - xnorswap 3y ago
    Personally I love working on legacy software, I actually dislike greenfield projects, but even in the context of legacy software and system maintenance, backporting fixes would still not rate highly or provide much in the way of interesting work for me.
  - tremon 3y ago
    I'd say there's enough software developers that enjoy doing the latter. It's mostly the external motivation (both in community standing and in payments) that push people to shiny new things.
esrauch 3y ago

deleted 3y ago

[deleted]

neurostimulant 3y ago

> If you need stability and long term support as a customer, you have companies like RedHat or SUSE whose entire point is providing 10+ years maintenance on these components. Is that even feasible for projects like the Android kernel that distributes their fork to vendors when RedHat forbid redistribution of their source code?