5 ms·

For personal use, here's the same thing again. Say a Linux user wants to play a game. The stable old version of their distro doesn't play well with the libs/dri

by the_af 5y ago

For personal use, here's the same thing again. Say a Linux user wants to play a game. The stable old version of their distro doesn't play well with the libs/drivers needed to play the game. 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.

AnIdiotOnTheNet 5y ago
This is a flaw in Linux Desktops' choice of application management paradigms, which insists that everything be tightly coupled and managed. It is entirely possible and reasonable to have a stable set of base system libraries everyone can depend on and otherwise applications must bring their own.
- torstenvl 5y ago
  Agreed whole-heartedly, and one of the reasons I love the FreeBSD model. My ideal Linux distro would be the inverse of Debian k/FreeBSD – a Linux kernel with FreeBSD kernel interfaces provided by loadable module and a FreeBSD-style userland. Might be possible soon, now that building Linux with clang is supported.
  - yjftsjthsd-h 5y ago
    Huh. There are already others implementing the Linux ABI, but I can only think of NetBSD rump kernels and some Plan 9 thing...vx9? going the other way. No reason it shouldn't work. Edit: Oh, and Darling runs Darwin binaries on Linux, which isn't quite a BSD but is non-Linux
- ludocode 5y ago
  It's not just possible and reasonable. It's how literally every other platform works. 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.
  - delusional 5y ago
    Eh, it doesn't really work for a volunteer based projects. It's already hard to find people that want to fix bugs in open software, it would be even harder to find someone willing to fix it in a version 10 years old and then have them verify it working in all possible cases without regression.
- assbuttbuttass 5y ago
  NixOS manages this, it's entirely possible to use the stable channel for system packages but subscribe to the unstable channel for packages installed per-user. Of course, NixOS also has atomic upgrades and rollback, so there's not much risk just running unstable everywhere
md8z 5y ago
I'm not sure what you mean, this is exactly what Flatpak and Snap were meant to solve. IIRC Steam should also bundle older copies of the libraries needed.
- ludocode 5y ago
  No, you misunderstand. You need new libraries to make your new hardware work. You can't use versions of driver libraries like Mesa that are older than your hardware, and Mesa has a ton of dependencies like libstdc++ and LLVM so you can't use old versions of those either. This is a major problem for Flatpak.
  - md8z 5y ago
    I don't see why that's any bigger problem than anything else, flatpak includes mesa as part of the SDK: https://docs.flatpak.org/en/latest/available-runtimes.html#freedesktop https://docs.flatpak.org/en/latest/available-runtimes.html#f... 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.
    - ludocode 5y ago
      It is nowhere near as simple as you make it out to be. 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.
jcelerier 5y ago
Even on windows you generally have to install the very latest GPU drivers when an AAA game comes out though
- rodgerd 5y ago
  Sure. But I don't have to upgrade my whole userland from Win 10 to Win 11 for hardware compatibility. I don't have to upgrade my core OS to run a new version of Lightroom.
  - jcelerier 5y ago
    > Sure. But I don't have to upgrade my whole userland from Win 10 to Win 11 for hardware compatibility. I don't have to upgrade my core OS to run a new version of Lightroom. 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.
  - the_af 5y ago
    Throughout the history of Windows I've had to upgrade the whole OS in order to run some software or play some videogame, so I'm not sure what you mean.
- the_af 5y ago
  Exactly. People focused too much on my Linux example (in hindsight, I should have foreseen this), when it's a problem of all software. 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.
the_af 5y ago
People focusing on nitpicking my Linux example: it's irrelevant. In general the principle stands true: sometimes, to get a feature you need, you must install unstable software. Nobody wants instability for its own sake; what they want is the feature. 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.

by the_af 5y ago

AnIdiotOnTheNet 5y ago

This is a flaw in Linux Desktops' choice of application management paradigms, which insists that everything be tightly coupled and managed. It is entirely possible and reasonable to have a stable set of base system libraries everyone can depend on and otherwise applications must bring their own.

torstenvl 5y ago
Agreed whole-heartedly, and one of the reasons I love the FreeBSD model. My ideal Linux distro would be the inverse of Debian k/FreeBSD – a Linux kernel with FreeBSD kernel interfaces provided by loadable module and a FreeBSD-style userland. Might be possible soon, now that building Linux with clang is supported.
- yjftsjthsd-h 5y ago
  Huh. There are already others implementing the Linux ABI, but I can only think of NetBSD rump kernels and some Plan 9 thing...vx9? going the other way. No reason it shouldn't work. Edit: Oh, and Darling runs Darwin binaries on Linux, which isn't quite a BSD but is non-Linux
ludocode 5y ago
It's not just possible and reasonable. It's how literally every other platform works. 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.
- delusional 5y ago
  Eh, it doesn't really work for a volunteer based projects. It's already hard to find people that want to fix bugs in open software, it would be even harder to find someone willing to fix it in a version 10 years old and then have them verify it working in all possible cases without regression.
assbuttbuttass 5y ago
NixOS manages this, it's entirely possible to use the stable channel for system packages but subscribe to the unstable channel for packages installed per-user. Of course, NixOS also has atomic upgrades and rollback, so there's not much risk just running unstable everywhere

md8z 5y ago

I'm not sure what you mean, this is exactly what Flatpak and Snap were meant to solve. IIRC Steam should also bundle older copies of the libraries needed.

ludocode 5y ago
No, you misunderstand. You need new libraries to make your new hardware work. You can't use versions of driver libraries like Mesa that are older than your hardware, and Mesa has a ton of dependencies like libstdc++ and LLVM so you can't use old versions of those either. This is a major problem for Flatpak.
- md8z 5y ago
  I don't see why that's any bigger problem than anything else, flatpak includes mesa as part of the SDK: https://docs.flatpak.org/en/latest/available-runtimes.html#freedesktop https://docs.flatpak.org/en/latest/available-runtimes.html#f... 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.
  - ludocode 5y ago
    It is nowhere near as simple as you make it out to be. 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.

jcelerier 5y ago

Even on windows you generally have to install the very latest GPU drivers when an AAA game comes out though

rodgerd 5y ago
Sure. But I don't have to upgrade my whole userland from Win 10 to Win 11 for hardware compatibility. I don't have to upgrade my core OS to run a new version of Lightroom.
- jcelerier 5y ago
  > Sure. But I don't have to upgrade my whole userland from Win 10 to Win 11 for hardware compatibility. I don't have to upgrade my core OS to run a new version of Lightroom. 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.
- the_af 5y ago
  Throughout the history of Windows I've had to upgrade the whole OS in order to run some software or play some videogame, so I'm not sure what you mean.
the_af 5y ago
Exactly. People focused too much on my Linux example (in hindsight, I should have foreseen this), when it's a problem of all software. 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.

the_af 5y ago

People focusing on nitpicking my Linux example: it's irrelevant. In general the principle stands true: sometimes, to get a feature you need, you must install unstable software. Nobody wants instability for its own sake; what they want is the feature. 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.