4 ms·

> If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Li

> If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there? Yes. If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities, doubly so when that hardware is attached to any kind of network, and triply so when the software talks to some kind of cloud services. For most products, the customer should have the power decide when that hardware reaches EOL. In other words, it should be illegal (and severely punished) to disable or downgrade devices remotely, whether by abdicating the responsibility to maintain their software or by shutting down network services that those devices require to operate fully. At the very least, that would prevent the proliferation of pervasive networking features that have no business communicating with anyone except their owners.

civilitty 3y ago
> If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities, doubly so when that hardware is attached to any kind of network, and triply so when the software talks to some kind of cloud services. Talk to Qualcomm and NXP and MediaTek and Broadcom and STMicroelectronics and.... Seriously, most of this is completely out of the product engineers' control. We can't update the hardware because our vendors (ALL of our vendors) control the kernel selection, almost never upstream, and never keep the board support packages up to date. Never. IME the only exceptions to that rule are RaspberryPi (kinda sorta), AMD, and Intel. I only recently managed to finally extricate all my projects from Linux 2.6 which I considered a minor miracle. In 2023.
- fsflover 3y ago
  One more exception is NXP i.MX 8M Quad, which is used in a Librem 5 phone.
ThrowawayR2 3y ago
Doesn't matter if the manufacturer provides updates for embedded software if the customer doesn't want to install those updates because they'd have to incur the cost and downtime of retesting and updating their upstream software to address any incompatibilities caused by those fixes. It's more common than you'd think.
dijit 3y ago
> Yes. If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities Ok, I'll be the unpopular person here. Some bugs, even security ones: are ok. I know that a very significant amount of software is mature these days, but sometimes upgrading causes different bugs, which are either harder to diagnose or even potentially more deadly. I work in gamedev though, releases are tradeoffs with which bugs we accept. It is very frequently the case that fixing one bug will incur several other bugs, it's just a case of understanding if they're worse or not. For example: I don't care that my TV will have a 1/100 crash when launching the settings. I will just launch settings again- Coincidentally: having everything constantly updating and internet connected is counter-intuitive. I used to spend entire evenings waiting for my PS4 to install new software on itself, but the PS2 (which contained many bugs!) worked much more often.
- bandrami 3y ago
  A known bug beats an unknown update in a whole lot of enterprise use cases. This drives devs insane but it is true.
  - elcritch 3y ago
    It’s a limitation in SemVer too. Fixing a bug in a point release (e.g. keeping the api the same) could still result in undesired changes.
  - kierank 3y ago
    Yes, there's substantial value in being able to have a specific bugfix and not have to upgrade an application and a ton of dependencies.
    - bandrami 3y ago
      Or not even a fix. A known bug can be mitigated or worked around. Predictable is better.
- happymellon 3y ago
pessimizer 3y ago
> For most products, the customer should have the power decide when that hardware reaches EOL. In other words, it should be illegal (and severely punished) to disable or downgrade devices remotely, whether by abdicating the responsibility to maintain their software or by shutting down network services that those devices require to operate fully. I mostly agree, but the severe punishment for not keeping software or services updated and running should be to release as much of the software as you own and a full hardware spec, well before you turn off the lights. People have to be allowed to get out of a business.
mbreese 3y ago
> whether by abdicating the responsibility to maintain their software If you bought a product and the vendor said it will be supported for X years with updates — that’s all you get — X years. If you want to keep using a product for X+1 years, that’s fine, but that’s on you. I agree with your sentiment that hardware shouldn’t be disabled, but I don’t expect security updates past EOL. You can’t expect a business to keep supporting a product longer than they originally said they would (without compensation). But these are enterprise products… support contracts last a long time. More than enough time to migrate (or past the time when you should be migrating). That’s part of why the long term support exists in the first place.

civilitty 3y ago

> If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities, doubly so when that hardware is attached to any kind of network, and triply so when the software talks to some kind of cloud services. Talk to Qualcomm and NXP and MediaTek and Broadcom and STMicroelectronics and.... Seriously, most of this is completely out of the product engineers' control. We can't update the hardware because our vendors (ALL of our vendors) control the kernel selection, almost never upstream, and never keep the board support packages up to date. Never. IME the only exceptions to that rule are RaspberryPi (kinda sorta), AMD, and Intel. I only recently managed to finally extricate all my projects from Linux 2.6 which I considered a minor miracle. In 2023.

fsflover 3y ago
One more exception is NXP i.MX 8M Quad, which is used in a Librem 5 phone.

ThrowawayR2 3y ago

Doesn't matter if the manufacturer provides updates for embedded software if the customer doesn't want to install those updates because they'd have to incur the cost and downtime of retesting and updating their upstream software to address any incompatibilities caused by those fixes. It's more common than you'd think.

dijit 3y ago

> Yes. If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities Ok, I'll be the unpopular person here. Some bugs, even security ones: are ok. I know that a very significant amount of software is mature these days, but sometimes upgrading causes different bugs, which are either harder to diagnose or even potentially more deadly. I work in gamedev though, releases are tradeoffs with which bugs we accept. It is very frequently the case that fixing one bug will incur several other bugs, it's just a case of understanding if they're worse or not. For example: I don't care that my TV will have a 1/100 crash when launching the settings. I will just launch settings again- Coincidentally: having everything constantly updating and internet connected is counter-intuitive. I used to spend entire evenings waiting for my PS4 to install new software on itself, but the PS2 (which contained many bugs!) worked much more often.

bandrami 3y ago
A known bug beats an unknown update in a whole lot of enterprise use cases. This drives devs insane but it is true.
- elcritch 3y ago
  It’s a limitation in SemVer too. Fixing a bug in a point release (e.g. keeping the api the same) could still result in undesired changes.
- kierank 3y ago
  Yes, there's substantial value in being able to have a specific bugfix and not have to upgrade an application and a ton of dependencies.
  - bandrami 3y ago
    Or not even a fix. A known bug can be mitigated or worked around. Predictable is better.
happymellon 3y ago

pessimizer 3y ago

> For most products, the customer should have the power decide when that hardware reaches EOL. In other words, it should be illegal (and severely punished) to disable or downgrade devices remotely, whether by abdicating the responsibility to maintain their software or by shutting down network services that those devices require to operate fully. I mostly agree, but the severe punishment for not keeping software or services updated and running should be to release as much of the software as you own and a full hardware spec, well before you turn off the lights. People have to be allowed to get out of a business.

mbreese 3y ago

> whether by abdicating the responsibility to maintain their software If you bought a product and the vendor said it will be supported for X years with updates — that’s all you get — X years. If you want to keep using a product for X+1 years, that’s fine, but that’s on you. I agree with your sentiment that hardware shouldn’t be disabled, but I don’t expect security updates past EOL. You can’t expect a business to keep supporting a product longer than they originally said they would (without compensation). But these are enterprise products… support contracts last a long time. More than enough time to migrate (or past the time when you should be migrating). That’s part of why the long term support exists in the first place.