5 ms·

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 th

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.
- graemep 3y ago
  Who is responsible for complying with it? If a Chinese or American manufacturer of an embedded device that does not have a presence in the EU fails to provide updates what happens? How many of the companies producing this stuff have the skills to fix kernel security bugs? It will end up being tickbox regulatory compliance and will create barriers to competition, especially from FOSS: https://pyfound.blogspot.com/2023/04/the-eus-proposed-cra-law-may-have.html https://pyfound.blogspot.com/2023/04/the-eus-proposed-cra-la...
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.

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.
graemep 3y ago
Who is responsible for complying with it? If a Chinese or American manufacturer of an embedded device that does not have a presence in the EU fails to provide updates what happens? How many of the companies producing this stuff have the skills to fix kernel security bugs? It will end up being tickbox regulatory compliance and will create barriers to competition, especially from FOSS: https://pyfound.blogspot.com/2023/04/the-eus-proposed-cra-law-may-have.html https://pyfound.blogspot.com/2023/04/the-eus-proposed-cra-la...

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.