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