5 ms·

Think of all the places Linux runs. Planes, trains, and automobiles. Medical equipment. So many other places. Many places that don't have readily available netw

by mfer 3y ago

Think of all the places Linux runs. Planes, trains, and automobiles. Medical equipment. So many other places. Many places that don't have readily available network access. Yet, many "enterprises" need support here. 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? Considering just the modern cloud environment really limits where enterprise Linux runs and is useful. And, where there are calls for really long support contracts.

voakbasda 3y ago
> 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.
samstave 3y ago
>>*Think of all the places Linux runs. """Planes, trains, and automobiles""". Medical equipment.* Where is your other embedded equipment??? I love that movie.
- nine_k 3y ago
  You can throw away an old router and put a completely new one in place, and it will work. A pretty easy way to upgrade. Usually you cannot do the same with a flight computer or a medical device controller.
mixmastamyk 3y ago
That's already handled in the automotive world. Either wait until entering the garage with wifi, or have a mobile modem installed.
kierank 3y ago
Absolutely spot on here, there's no reason for the obsession HN (and the wider internet) has with upgrades in these kinds of environments. These are not environments where you can tolerate unplanned downtime, this isn't a silly web app running in us-east.
- sam_lowry_ 3y ago
  Upgrades are a necessity if development goes on. And HN is full of developers. On a related note, the new EU Cyber Resilience Act will make upgrades a necessity even in the most constrained environments like pacemakers.
  - kierank 3y ago
    It's easier to do an update with a single security fix rather than an update that rolls in a ton of new functionality that ends up breaking your device. Seen this time and time again with OS/dependency update.

by mfer 3y ago

voakbasda 3y ago

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

samstave 3y ago

>>*Think of all the places Linux runs. """Planes, trains, and automobiles""". Medical equipment.* Where is your other embedded equipment??? I love that movie.

nine_k 3y ago
You can throw away an old router and put a completely new one in place, and it will work. A pretty easy way to upgrade. Usually you cannot do the same with a flight computer or a medical device controller.

mixmastamyk 3y ago

That's already handled in the automotive world. Either wait until entering the garage with wifi, or have a mobile modem installed.

kierank 3y ago

Absolutely spot on here, there's no reason for the obsession HN (and the wider internet) has with upgrades in these kinds of environments. These are not environments where you can tolerate unplanned downtime, this isn't a silly web app running in us-east.

sam_lowry_ 3y ago
Upgrades are a necessity if development goes on. And HN is full of developers. On a related note, the new EU Cyber Resilience Act will make upgrades a necessity even in the most constrained environments like pacemakers.
- kierank 3y ago
  It's easier to do an update with a single security fix rather than an update that rolls in a ton of new functionality that ends up breaking your device. Seen this time and time again with OS/dependency update.