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

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

I don't understand. Is your claim that ATMs are running Windows XP because Microsoft did get buried under a pile of ash in the early '00s and released no further OS upgrades, and therefore it would have been better for the ATM manufacturer to use an open-source OS because they, unlike Windows, survived to 2021?

Nobody in this thread is arguing that everything in the world is perfect. There are a lot of bad things in the world. (The fact that we haven't figured out a reliable, scalable way to develop major F/OSS projects without the backing of companies that either sell proprietary software or do far worse things is certainly one of them!)

The specific argument in this subthread is about whether it's okay to build your business on proprietary software or whether there's too much of a risk that the vendor will stop producing updates. If they aren't interested in updates when they actually happened, then clearly this wasn't a concern for them.

(Also, have you never seen people running extremely out-of-date versions of F/OSS operating systems?)

> The specific argument in this subthread is about whether it's okay to build your business on proprietary software or whether there's too much of a risk that the vendor will stop producing updates

It has everything to do with that and I think it's a way too narrow view.

In this case Microsoft indeed did not go bankrupt. They did however stopped to provide updates to solution "Windows XP", without giving an alternative compatible on the same legacy hardware (the old ATM hardware).

And that illustrates perfectly the problem with proprietary ecosystem. You do NOT need your provider to bankrupt to put yourself in shit, you just need him to have interests diverging of your interests.

Because at the end, he is the one controlling your software stack, not you.

> They did however stopped to provide updates to solution "Windows XP", without giving an alternative compatible on the same legacy hardware (the old ATM hardware).

Hang on there… Microsoft never did stop making updates to Windows XP Embedded - they kept it on super-extended support as “Windows POSReady” (I think the pun was intentional…) and it’s replacement in “Windows IoT” is reasonable.

Your argument is valid only if ATM manufacturers were being missold XP Embedded by Microsoft on the basis that the support lifecycle of XP Embedded would outlive the ATM hardware - but I put it to you that is not the case. The support lifeycle of MS products is (surprisingly) well-documented and transparent - and to my knowledge (and saying that as a former blue-badge myself) MS has never represented XP Embedded (or other NT-family OSes) as being suitable for a 20+ year lifespan. The blame lies squarely with the systems-integrator who built the ATMs.

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

Why would you not see that? The risk profile is well understood, and can be mitigated. Sandboxes, firewalls, app-containers, input sanitization, Virtual Machines, etc, etc, etc.

I don't quite understand exactly what you're disagreeing with?

> Why would you not see that? The risk profile is well understood, and can be mitigated.

So well understood that hacks on ATM happens every weeks :)

Which magical technology are you proposing that doesn't get hacked?