Read your Microsoft licensing agreement. If you don't have one, read the EULA for OEM windows. The warranty, fitness for purpose and damages exclusion is not as extensive as what the grandparent cited, but it basically boils down to "as limited as legally possible, and the most damages you will get is your license fee back". You also won't get a binding requirements document anyways, so you don't even really know what the software microsoft sells you is fit for. At any point in time, there could be some knowledgebase article saying something like "oh, and btw, don't do this because it breaks", so per their warranty agreement you signed they are free from any responsibility simply by documenting the problem.

Really safety-critical stuff like ASIL-D, ISO26262, IEC61508 (and tons of other magic numbers) isn't something you can buy from microsoft. At best, you can sometimes get a reseller to sign something a little more binding, but with tons of restrictions that basically boil down to "use the microsoft stuff for the readout gauges, but the critical control part goes somewhere else".

▲

tinco 5 days ago | parent [-]

It's not about warranties, it's about having a stable ecosystem with some guaranteed measure of maintenance. The point is not that there's even more stable and expensive options than Microsoft. The point is that there's very little space for OSS here. Go to any hospital and count the amount of Windows devices and compare that to the amount of other operating systems you see. The second something becomes even a little safety oriented, there's going to be proprietary software.

So when these regulations that OP would start to take hold, would we get companies to sponsor random open source dependencies like libxml2? Or would they gather around some stable proprietary ecosystem like Microsoft's and maybe some big innovative solutions built on top of Microsoft?

▲

thyristan 5 days ago | parent [-]

Even the "guaranteed measure of maintenance" is not guaranteed. You don't get an SLA on patches or bugfixes from microsoft. You don't get an uptime SLA. Its all "best effort" or worse "when we feel like it". And the few SLAs they give you, e.g. on cloud stuff, are useless because it basically is "get your money back for that month". And the SLA measurement is done by their own downtime announcements, so a complete joke. Software lifetimes exist and are published, but guess what? Within that lifetime, you get "updates", but nowhere do you get any kind of guarantee about what is updated, what is fixed, how fast, if ever.

And no kind of safety-oriented anything will run windows or any microsoft software. There is no windows edition of therac-25. The stuff you see in a hospital is normal workstation PCs for non-safety-relevant data entry and display. As soon as it becomes safety-relevant like controlling your heart-lung-machine, auto-dosing your medications, controlling the x-ray beam, you are far away from anything microsoft.

And actually, OSS is used more often in those safety-relevant settings. Why? Not because the OSS maintainers themselves would themselves provide any support, SLA or warranty. But because the nature of OSS provides third parties the possibility to certify, maintain and guarantee for their special 'safety-relevant-libxml2-fork'. Sometimes this is done by the device vendors themselves, sometimes they buy this from others. But it happens, and it is growing in frequency.

https://www.codethink.co.uk/news/trustable-software.html (Linux) https://access.redhat.com/en/compliance/iso-26262-asil-b (Linux) https://www.lynx.com/case-studies/secure-linux-medical-devic... (Linux) https://developer.arm.com/Tools%20and%20Software/Arm%20Compi... (clang/llvm)

There is tons more. Basically any compiler for safety-relevant embedded stuff is either clang or gcc under the hood. Linux is frequently encountered when the real-time requirements aren't too strict. With Linux also comes the usual Linux ecosystem of OSS libs and services. It won't look like your normal desktop OS, but quite a lot in that area is OSS.

Nothing at all from microsoft (except a useless BS certification "you can use Azure Devops as a code repo to store you ASIL-D code...").

	▲	hobs 5 days ago \| parent [-]
		Don't forget that microsoft is the only cloud provider who regularly has so much downtime and eye popping exploits against its cloud infra.