[liquid_thyme]

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

[ElectricalUnion]

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

[liquid_thyme]

>And rely on the things the things they have built upon to not be rugpulled from under them at random.

So 10 years from now, all popular distros should support versions of Facade 1.0, 1.2, 1.42 through Facade 10.2?

Now do you see the problem?

[ElectricalUnion]

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.

[liquid_thyme]

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.

Out of curiosity, have you asked customers to run your software in a VM? How did that conversation go?

[ElectricalUnion]

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