[DaiPlusPlus]

> If it would be "easily quantifiable", you would not see in 2021 still bank ATM running damn Windows XP or nuclear power plant under Win2000 with some old deprecated crap supervisor tools.

> It is a common drama with proprietary solutions, they are seducing to install and a nightmare to maintain.

The fact the software is "proprietary" or not is largely irrelevant to whether or not the systems-integrator who made those ATMs and Nuclear Power plants is acting responsibly. Had they chosen Linux then that ATM would still be sitting there with just-an-outdated version of some embedded Linux distro.

There is an argument that if they used a GPLv3 or other anti-Tivo license that the end owner or operator of the machine would be able to upgrade the host OS software themselves, however in both of those cases (ATMs and power-plants) what makes-the-thing-run is not the OS but the application software (BankAtm.exe and NuclearReactorMonitor.exe) which will have their own dependencies and (knowing most software) will just break when running on an updated OS - and it'd be even worse on Linux because Linux does not have a stable applications ABI between major releases: the software would need to be recompiled.

Now if the application software itself were also open-source, then I agree: that does help, but I'm not convinced that's a solution either because I can assure you that companies like banks and infrastructure operators are not going to be happy having to do patch-tuesday and recompiling their software on a regular basis for hardware they'd really prefer to leave alone and stable. Hence why they're air-gapped (or at least meant to be air-gapped).

Being non-proprietary is not a panacea.

[adev_]

> Had they chosen Linux then that ATM would still be sitting there with just-an-outdated version of some embedded Linux distro.

That's wrong, they would have been in a position to update / maintain themselves their own distro or dedicate that to a third party company that has the knowhow to do so. This for more than 20 years without problems. Because they would DO have the code for it if they want it.

With proprietary solutions in the embedded system world, this is impossible to do. If your providers refuses to support your OS anymore, you're fucked and that's it. And if he wants to increase the cost of your support maintenance program per 10x because it's legacy, you're fucked too, just in an other way.

> Linux because Linux does not have a stable applications ABI between major releases: the software would need to be recompiled.

I disagre and for two reasons:

- first, if it's your software stack recompiling should not be a problem

- second, it is not true. Kernel ABI is stable (mostly). And running statically compiled binary between major kernel releases never have been a problem.

> infrastructure operators are not going to be happy having to do patch-tuesday and recompiling their software on a regular basis for hardware they'd really prefer to leave alone and stable.

Do they ? Even on ATM, client software evolves and is updated. In their case, they just do it with the pain of a legacy system without being able to touch to the platform itself because they have no control on it.