5 ms·

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 doe

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.

md8z 5y ago
I'm still not sure I understand, it sounds like a solution exists and both Steam and Flatpak are working towards it. I don't see why nvidia can't also do the same things. 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.
- ludocode 5y ago
  The "solutions" are hacks at best. This is not the way to build stable software. > 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.
  - md8z 5y ago
    AFAIK the win32 API is kept backwards compatible by doing exactly as we describe, shipping older versions of the system libraries and automatically using them when it's detected that an application needs them. So it's the same thing you call a "hack". Please don't misunderstand, I'm not saying backwards compatibility is bad. But it does cost a non-trivial amount of money and time, it's not just a magic solution to reduce the maintenance cost of something down to zero. If you're doing a cost comparison, that always has to be taken into account. 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.
  - gpderetta 5y ago
    To be fair the equivalent of libstdc++ on Windows has broken the ABI on every MSVC release until very recently. 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.
  - bluGill 5y ago
    The C++ standard committee regularly has debates about breaking the ABI. They forced it for 11, who knows if they will again.
marmaduke 5y ago
> NVidia client-side library must exactly match the version of the loaded kernel module 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.
- ludocode 5y ago
  NVidia has special support for making their drivers work in Docker containers: https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/overview.html https://docs.nvidia.com/datacenter/cloud-native/container-to...

md8z 5y ago

I'm still not sure I understand, it sounds like a solution exists and both Steam and Flatpak are working towards it. I don't see why nvidia can't also do the same things. 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.

ludocode 5y ago
The "solutions" are hacks at best. This is not the way to build stable software. > 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.
- md8z 5y ago
  AFAIK the win32 API is kept backwards compatible by doing exactly as we describe, shipping older versions of the system libraries and automatically using them when it's detected that an application needs them. So it's the same thing you call a "hack". Please don't misunderstand, I'm not saying backwards compatibility is bad. But it does cost a non-trivial amount of money and time, it's not just a magic solution to reduce the maintenance cost of something down to zero. If you're doing a cost comparison, that always has to be taken into account. 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.
- gpderetta 5y ago
  To be fair the equivalent of libstdc++ on Windows has broken the ABI on every MSVC release until very recently. 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.
- bluGill 5y ago
  The C++ standard committee regularly has debates about breaking the ABI. They forced it for 11, who knows if they will again.

marmaduke 5y ago

> NVidia client-side library must exactly match the version of the loaded kernel module 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.

ludocode 5y ago
NVidia has special support for making their drivers work in Docker containers: https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/overview.html https://docs.nvidia.com/datacenter/cloud-native/container-to...