4 ms·

Will this game still be playable in 20 years? In this case, wouldn’t bundling everything be more stable? It’s notoriously difficult to install some very old s

Will this game still be playable in 20 years? In this case, wouldn’t bundling everything be more stable? It’s notoriously difficult to install some very old software on modern Linux distributions, because installing old dependencies might just be extremely hard or no longer possible. Also, what happens when the glibc has a new version with breaking changes? Then the game won’t run, even though it depends on an old version of that lib.

fock 5y ago
probably, because even today you can drop the program into a container and it will work - I guess a working X11 server is going to stay around for some time too! The only problem is 3D acceleration, but good luck running DX8 and older apps on Windows 10.
AnIdiotOnTheNet 5y ago
Yeah, unfortunately Linux Desktop doesn't really consider this a valid use case. It is still very much designed with the idea that everything will be open source and compiled and packaged by a third party middleman, or by the user themselves assuming they can get the appropriate development environment set up. It's one of the many reasons I think it is terrible as a Desktop. In my opinion, the best way to ensure your game will run on the majority of Linux distributions, now and in the future, is to distribute a Windows binary and rely on WINE (or use winelib). Just make sure to actually test it.
Conan_Kudo 5y ago
glibc has so far managed to guarantee backwards compatibility going back to every version that has offered libc.so.6 (which goes back two decades!). They explicitly guarantee that backward compatibility: https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...
- AnIdiotOnTheNet 5y ago
  Ok, is there a way to say "please compile my binary such that it will work with the oldest version of glibc"? I mean, other than to locate a copy of a distribution with a glibc that old to build on.
  - marcan_42 5y ago
    Not using new features will usually do that, but I wonder what's up with the math stuff pulling in symbol versions from 2018. There should be an explanation for that one...
    - AnIdiotOnTheNet 5y ago
      Sure, but is there any convenient mechanism to ensure that you don't use new features? I guess what I'm asking is, why does glibc not make this easier to do?
      - spystath 5y ago
        I think the generally accepted way to do that would be a container image running a relatively old distribution. This is exactly what python packages do when they need to distribute binary packages on linux [0]. You are supposed to compile the package in a container (or VM) that runs CentOS 7 (or older if you want broader support), although now the baseline is moving gradually to Debian 9. [0]: https://github.com/pypa/manylinux https://github.com/pypa/manylinux
        AnIdiotOnTheNet 5y ago
        So round about, the answer is a firm "no".
      - Conan_Kudo 5y ago
        I think you can pass a linker flag to make it use the oldest version of each symbol, but I'm not sure what that flag is.
  - 5y ago
marcan_42 5y ago
glibc does not (usually) do breaking changes. That's why the symbols are versioned as they describe.
MayeulC 5y ago
> Will this game still be playable in 20 years? > In this case, wouldn’t bundling everything be more stable? It might; or it might not. Relying on shared libraries is generally a good idea, as those get updated: for instance, you can get pulseaudio, wayland and more modern joysticks API compatibility by updating SDL. However, some libraries cease development. This will not happen for SDL or glibc, as those have too many users, there will always be a compat layer. Plus, their source is available to actually create such a layer. It's a good idea to ship those libraries, but I sure hope they rely on shared libraries for system calls or hardware access. As a bonus, relying on shared objects makes it easier to run something on other CPU architectures using a native build of the libraries, at least in theory.

fock 5y ago

probably, because even today you can drop the program into a container and it will work - I guess a working X11 server is going to stay around for some time too! The only problem is 3D acceleration, but good luck running DX8 and older apps on Windows 10.

AnIdiotOnTheNet 5y ago

Yeah, unfortunately Linux Desktop doesn't really consider this a valid use case. It is still very much designed with the idea that everything will be open source and compiled and packaged by a third party middleman, or by the user themselves assuming they can get the appropriate development environment set up. It's one of the many reasons I think it is terrible as a Desktop. In my opinion, the best way to ensure your game will run on the majority of Linux distributions, now and in the future, is to distribute a Windows binary and rely on WINE (or use winelib). Just make sure to actually test it.

Conan_Kudo 5y ago

glibc has so far managed to guarantee backwards compatibility going back to every version that has offered libc.so.6 (which goes back two decades!). They explicitly guarantee that backward compatibility: https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...

AnIdiotOnTheNet 5y ago
Ok, is there a way to say "please compile my binary such that it will work with the oldest version of glibc"? I mean, other than to locate a copy of a distribution with a glibc that old to build on.
- marcan_42 5y ago
  Not using new features will usually do that, but I wonder what's up with the math stuff pulling in symbol versions from 2018. There should be an explanation for that one...
  - AnIdiotOnTheNet 5y ago
    Sure, but is there any convenient mechanism to ensure that you don't use new features? I guess what I'm asking is, why does glibc not make this easier to do?
    - spystath 5y ago
      I think the generally accepted way to do that would be a container image running a relatively old distribution. This is exactly what python packages do when they need to distribute binary packages on linux [0]. You are supposed to compile the package in a container (or VM) that runs CentOS 7 (or older if you want broader support), although now the baseline is moving gradually to Debian 9. [0]: https://github.com/pypa/manylinux https://github.com/pypa/manylinux
      - AnIdiotOnTheNet 5y ago
        So round about, the answer is a firm "no".
    - Conan_Kudo 5y ago
      I think you can pass a linker flag to make it use the oldest version of each symbol, but I'm not sure what that flag is.
- 5y ago

marcan_42 5y ago

glibc does not (usually) do breaking changes. That's why the symbols are versioned as they describe.

MayeulC 5y ago

> Will this game still be playable in 20 years? > In this case, wouldn’t bundling everything be more stable? It might; or it might not. Relying on shared libraries is generally a good idea, as those get updated: for instance, you can get pulseaudio, wayland and more modern joysticks API compatibility by updating SDL. However, some libraries cease development. This will not happen for SDL or glibc, as those have too many users, there will always be a compat layer. Plus, their source is available to actually create such a layer. It's a good idea to ship those libraries, but I sure hope they rely on shared libraries for system calls or hardware access. As a bonus, relying on shared objects makes it easier to run something on other CPU architectures using a native build of the libraries, at least in theory.