The issue on Linux is that the distro's package manager decides which versions of shared libraries exist system wide, and this works well when you install everything through the package manager. Windows SxS is specifically designed to allow multiple incompatible versions of the same shared component to coexist without forcing the entire Windows install to use it.
But okay, I accept your point. However I'd like to point out that "the OS allows you do something in multiple ways" is different from "this is the only way to do it"
> The issue on Linux is that the distro's package manager decides which versions of shared libraries exist system wide, and this works well when you install everything through the package manager.
Linux takes the lead: make code that depends directly on `kernel32.dll` exposed interfaces and you're in a world of hurt.
The problem pointed out is a distro, library compatiblity, packaging, or sand-boxing problem, not a Linux problem.
> Windows SxS
Now that's one very good Windows idea.
Nothing should prevent your favourite packaging/sandbox tool to present a facade that the file system has some specific files (your specific version of libraries) over some more generic files (say, Flatpak: freedesktop SDK, Steam Pressure Vessel: Steam Runtime) over some even more generic files (your actual distro libraries).
On the other hand, almost _nobody_ and _nothing_ should be touching "libraries" or "utilities" or whatever on my base system!
>The problem pointed out is a distro, library compatiblity, packaging, or sand-boxing problem, not a Linux problem.
Are you suggesting Windows users switch to Linux and not use a popular distro that can provide software they need? Otherwise, its simply a pedantic argument.
>Nothing should prevent your favourite packaging/sandbox tool to present a facade that the file system has some specific files (your specific version of libraries) over some more generic files (say, Flatpak: freedesktop SDK, Steam Pressure Vessel: Steam Runtime) over some even more generic files (your actual distro libraries).
If you introduce a new library in facade 2.0, its not going to work in facade 1.0. You can backport, but how many versions are you realistically going to support indefinitely? Its a good idea, but it doesn't solve the full problem.
> Are you suggesting Windows users switch to Linux and not use a popular distro that can provide software they need? Otherwise, its simply a pedantic argument.
If you use a distro that can provide the software they need, why not?
Or, thinking in a orthogonal way, using a distro that doesn't impose draconian library management requirements, and allows simultaneous use of ABI incompatible versions of a library? Why not? Nixos is out there and has more packages that most other distributions already.
> but how many versions are you realistically going to support indefinitely.
No versions. No indefinite support. And intentionally so. The previous layers just stay there.
The point is to intentionally provide a stable platform - with known bugs and security vulnerabilities frozen forever - something people can build their things upon. And rely on the things the things they have built upon to not be rugpulled from under them at random.
Every now and then, someone might fix a egregious security vulnerability in the platform; someone might fix a egregious usability problem in the platform; someone might implement modern features on a older platform; someone might implement compatibility tweaks - but that should not be considered a given.
I fully expect at minimum to run legacy software on a sandboxed "compatibility mode", if one values the overall safety of the rest of the system. And if you are not legacy software, someone recompiles the software every now and then to the newer platform.
No, they don't support it. Instead, you need to run it inside a compatibility mode, that probably sandbox or VMs the facade. But your software keeps running.
The current problem is that your software no longer runs. That's a 100% denial of service problem.
> I want to run a modern OS with modern features and still run any software that I already paid for 5, 10, 20 years ago.
I already have a bunch of software that I paid for more that 20 years ago and I can't use most of it outside of full VMs. Microsoft didn't ask me if I didn't use them anymore before removing Win16 support.
> Out of curiosity, have you asked customers to run your software in a VM? How did that conversation go?
Customers never got a choice "where to run your software" when all software I develop ends up hidden inside a SaaS service or being delivered via representational state transfer code on demand. They either run it on a browser sandbox or it doesn't run.
But okay, I accept your point. However I'd like to point out that "the OS allows you do something in multiple ways" is different from "this is the only way to do it"