[lolinder]

While you are technically correct, that turns it into a bit of an apples to oranges comparison with Windows because most of what we consider to be the Windows operating system would in the Linux world live in userspace. Which means that when we're comparing the user's experience of an average Linux distribution with Windows it's definitely fair to say that Linux doesn't prioritize backwards compatibility.

[fbdab103]

Just yesterday, I purchased a game from GOG where the Linux build cannot start, owing to who knows what expected platform profile. Maybe, technically, I could have fixed the problem. The Windows build worked without issue in Wine.

[Wowfunhappy]

However, because the kernel doesn't break userspace, you can use stuff like chroot to run old apps without a performance loss.

I do wish the tooling to make this seamless was better.

[worewood]

Assuming you can go through the dependency hell, because you can't use old packages on a new distro - so in most cases you have to compile by source... I've tried to run XMMS and suffered a lot.

[Wowfunhappy]

This should be a nonissue if you use chroot.

[jasomill]

Better yet, use a container.

Distrobox[1] automates the process of installing popular distros released in the past decade or so in containers.

For games in particular, Proton[2] (a game-specific Wine fork) or one of the Steam container runtimes[3] (for native Linux games) might also be worth a try.

For a non-Steam game:

1. Install and run the Linux Steam client (Steam account required).

2. Add the game to the Steam library: "Add a Game" → "Add a Non-Steam Game…", choose game executable.

3. Right click on the game, choose "Properties" → "Compatibility" → "Force the use of a specific Steam Play compatibility tool", and choose a version of Proton or container runtime (the most recent non-experimental version is probably a sane default).

4. Make sure the selected Proton or container runtime version is installed. These should be available for installation from the Steam library by default. If you can't find them, click the dropdown above the search box in the Steam library, make sure "Tools" is checked, and make sure the "Show only ready to play games" option ("play" arrow in a circle icon to the right of the same dropdown) is disabled.

5. Launch the game from the Steam library.

[1] https://distrobox.it/compatibility/#containers-distros

[2] https://github.com/ValveSoftware/Proton

[3] https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/b...

[freedomben]

Why was this downvoted? IMHO containers, especially now that distrobox is here, are a great way to solve this problem. I use it all the time and it's wonderful!

[heavyset_go]

If you haven't already checked it out, systemd-nspawn is invaluable if you find yourself needing to use chroot.

Combine it with QEMU's usermode emulation + binfmt-misc and you can run chroots for other architectures, too.

[LeFantome]

It depends. First, I think the kernel point is a powerful one.

Second, until Wayland, X11 also created crazy backwards compatibility. You can take run X apps that are decades old.

Where backwards compatibility is poor is in the desktop libraries like those in the GNOME and KDE ecosystems.

Even there though, the old libraries still work. You can keep them around if you want.

[freedomben]

Indeed, and with tools like Distrobox nowadays, it really is realistic to have a Fedora 40 host system running apps compiled for Fedora 17. In related news, being stuck with RHEL on the host has gotten a lot less painful. Desktops are finally really benefitting from containers (including flatpak)!