[mfer]

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.

[kierank]

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_]

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]

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.

[voakbasda]

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

[dijit]

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

A known bug beats an unknown update in a whole lot of enterprise use cases. This drives devs insane but it is true.

[kierank]

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]

Or not even a fix. A known bug can be mitigated or worked around. Predictable is better.

[elcritch]

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.

[happymellon]

That brings flashbacks of my PS3. I had one, but I ended up not playing it because every time I switched it on there was a 2 hour mandatory download.

When you only have a couple of hours free time, spending it updating firmware means that I just don't update or use it.

[civilitty]

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

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

[pessimizer]

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

[ThrowawayR2]

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.

[mbreese]

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

>>*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]

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]

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