This has almost nothing to do with proprietary vs. open source. A patch for the vulnerability exploited here had been available for months.
The real problem is that organisations had devices sufficiently connected to be vulnerable that had not the patch applied. That leads to questions about software update policies within those organisations, and that in turn leads to some quite difficult questions about regulated medical devices and how they are supplied and maintained.
I don't think Linux distributions from 2001 are receiving security updates today. The only thing going for a free(as in beer) OS is that upgrades are free, but the main reason that so many corporate systems are still on XP is compatibility, not the cost of the upgrade license which is peanuts for large orgs affected by this. And Linux distros from 2001 would still have the exact same problem.
Consider the fact that Windows has the best backward compatibility in the business, while even drivers break across relatively minor Linux kernel versions and compatibility is likely to be a bigger problem with Linux.
due to the nature of Linux being a Monolithic Kernel and open source, there tends to be less issue with backward compatibility issues with Linux making it easier to update systems that today companies refuse to update windows on because it is not compatible with older hardware/software
Infact Linux often has the reverse problem in that hardware support for new technology often lags behind because hardware vendors focus on Windows first.
>Consider the fact that Windows has the best backward compatibility in the business,
That is a complete and utter myth. Windows has terrible backwards compatibility, and changes to the Windows Driver model, and other changes require drivers and software to be completely rewritten between generations of windows.
>while even drivers break across relatively minor Linux kernel versions and compatibility is likely to be a bigger problem with Linux.
Where do you get this? Drivers are included in the Linux Kernel, it is impossible for a driver to "break" across minor version of Linux, if a driver breaks the kernel fails and is not released.
>Where do you get this? Drivers are included in the Linux Kernel, it is impossible for a driver to "break" across minor version of Linux, if a driver breaks the kernel fails and is not released.
Linux comes with a limited set of device drivers in the main source tree, just like Windows' bundled drivers. Most of this thread is about rare medical equipment or proprietary drivers/programs from companies that have gone out of business.
Also, the Linux kernel ABI routinely breaks drivers, unlike Windows which happens much more rarely.
I think it assuming you believe windows driver problems are rare. Every time I get a new model computer or hardware I have spend many many hours testing, finding, and packaging the drivers to make sure the new hardware plays nice with our system, deployment systems and does not break other shit.
I'd like to see the set of sysadmins that belong to both the group that is running a distro from 2001 and are willing to manually update the kernel on those systems to a later one.
Yes, the Linux kernel being what it is makes for good/great backwards compatibility.
But that's so far from the point it's not even funny. This is about update policies and internet security at the organisations involved.
It was reportedly available to those who were still officially supported, though, possibly as far back as February.
As others have suggested, Microsoft has historically offered support (in the sense of at least security patches) for each generation of Windows for much longer than any of the major FOSS operating systems. Obviously you don't get free, unlimited, eternal support with any version of any OS, but even then Microsoft has apparently made arrangements with those who really didn't want to update to a more recent one than XP to continue offering support in return for additional funding.
As I said before, the real problem here is how to deal with the conflict between wanting to keep connected systems up-to-date with security patches, while at the same time not breaking their essential functionality. Medical systems used in regulated environments where failures may literally be a matter of life or death are pretty much the ultimate example of this difficulty.
The real problem is that organisations had devices sufficiently connected to be vulnerable that had not the patch applied. That leads to questions about software update policies within those organisations, and that in turn leads to some quite difficult questions about regulated medical devices and how they are supplied and maintained.