So the user must install a newer, less tested, distro. But the goal was not to be "on the bleeding edge" for its own sake; it's playing the game, and there's no other (easy) way.
Of course, NixOS also has atomic upgrades and rollback, so there's not much risk just running unstable everywhere
It's also how the Linux Standard Base worked. It was intended to be a stable well-defined backwards-compatible set of libraries common across distributions. Of course the LSB had its share of problems but they had the right idea to bring stability to Linux as a platform for binary apps.
Might be possible soon, now that building Linux with clang is supported.
Edit: Oh, and Darling runs Darwin binaries on Linux, which isn't quite a BSD but is non-Linux
I fear my Linux example may have led people down the wrong rabbit hole. Linux is irrelevant in this context.
I could have used Windows. Sometimes, in the history of videogames, you needed a newer version of Windows. If you wanted to play the game, you needed to install this version.
Or DirectX, or whatever lib. Pick your poison. Nitpicking particular examples is missing the point.
uh... yes, you do, all the time. Lightroom currently requires Windows 10 1903, a 2 years old OS. Most likely in very few years it'll require Win11.
Not just OSes, everything. You want a feature or bug fix that doesn't exist in the old stable version, you need the next one, so you upgrade.
If there ends up being a problem with libstdc++ and LLVM, it's not hard to statically link those, if it's not being done already.
Yes, the freedesktop runtimes ship extensions with newer versions of Mesa and its dependencies. This doesn't entirely solve the problem. For one thing, libstdc++ before GCC 5 did not maintain a backwards-compatible ABI, so if the app was compiled too long ago it won't work with a new libstdc++. Steam is now working around this problem by using dlmopen() namespaces to load different version of libstdc++ into the same process. Flatpak is not there yet.
For another, NVidia drivers complicate this even more. The NVidia client-side library must exactly match the version of the loaded kernel module which Flatpak can't control. So NVidia drivers are broken out into yet another runtime extension, and it can't package these drivers due to licensing issues so it will dynamically download NVidia drivers to generate an extension on the fly. NVidia drivers also depend on libstdc++ by the way, another reason why static linking doesn't magically solve the problem.
On top of all this is just the massive complexity and maintenance burden of keeping all this working. All these runtimes with all their extensions, somebody has to keep updating these, and when a runtime is deprecated all of the software that was built for it is defunct. All of this can be solved just by keeping libraries backwards compatible and building for native Linux, not Flatpak or anything else.
I hope you can see that "keep libraries backwards compatible forever" is not really a good option either and is probably orders of magnitude more work than just doing all the things you said. In some situations, it is also impossible: if there are bugs in the API contract then it has to be broken eventually.
> I hope you can see that "keep libraries backwards compatible forever" is not really a good option
??? Why would I be able to see that? You've given zero explanation or evidence for why that would be the case. I see a whole lot of people in this thread in addition to the article explaining why backwards compatibility is good. Nobody is giving valid reasons as to why it's bad.
Microsoft has managed to keep the whole Win32 API compatible "forever". GUI apps built for Windows 95 still work out of the box on Windows 10. Backwards compatibility is a major part of why they are still the dominant platform: businesses actually care about this. They use ancient proprietary software that is critical to their business whose source code has long been lost to the sands of time. A platform that breaks their software is no platform at all.
> probably orders of magnitude more work than just doing all the things you said.
Really? How hard is it to not break things?
It's sometimes more work to add new features or support new hardware without breaking the ABI but clearly it's feasible. glibc 2.1 was released in 1999 and the maintainers decided at that point that they would preserve backwards compatibility forever. We're now at 22 years without a major ABI break. There have been some hiccups of course (the memcpy() fiasco) but they've been fixed.
The GCC team have decided to follow in their footsteps. Since version 5 they've decided they're not going to break the libstdc++ ABI anymore. The culture of backwards compatibility is finally growing on the Linux desktop. This is a far better solution than Flatpak.
Glibc isn't really a good example, that has a ton of unfortunate broken APIs that should probably be removed entirely (the most notorious example probably being gets) but never will be, and I suspect they will continue to be a source of bugs as long as applications use them and aren't patched. I mean the whole reason musl exists is to get away from some of these maintenance issues in glibc.
The difference is that Windows applications historically shipped with the appropriate version of the C++ runtime bundled in (and there wa no guarantee that one was provided by the OS), while Linux app usually rely on the system .so.
Sure about that? I was sure I’ve run Docker containers with GPU stuff compiled for different versions than my driver. Like their nbody container image runs every time I set up the nv container runtime with Docker, regardless of driver version.
https://docs.nvidia.com/datacenter/cloud-native/container-to...
If my Linux example misled you, let me rephrase: can you run modern AAA Windows games using good old Windows XP? If you can't, you've hit exactly the problem I describe.
It's a problem of software in general, and flatpak doesn't solve it. Flatpak itself may be subject to it!