3 ms·

You must be one of these who believe that if you have a copy of a game binary and all its dependent libraries down to the last byte it will work as-is on a newe

You must be one of these who believe that if you have a copy of a game binary and all its dependent libraries down to the last byte it will work as-is on a newer desktop. The entire point of my previous post is that this is as far from the truth as it gets, and even if I keep such a backup set of libraries (which we do, as that is the easiest part) the game will still not work. Nothing that you mentioned is absolutely of use and is just going to get in the way. For example, the kernels you are going to need to use likely don't even have NPTL. No ELF exec in the NixOS "binary cache" will even work without NPTL; NixOS did not exist during the LinuxThreads eras. Reproducible builds are absolutely useless here; I have the exact binaries that I want to run already, and most of the solutions are going to require patching the underlying libraries while still running the same game binary, practically the complete opposite idea to "reproducible builds and reproducible dependencies". You are going to spend more time fighting the package manager than the actual problems. How much does NixOS help running games which require OSS? Old versions of OpenGL that your graphics card now supports only poorly? Static linking and NixOS may have its usefulness somewhere but definitely not here. They are not guarantees of long-term compatibility, and may actually hinder it (by preventing patching of the underlying libraries, and enforcing deviations from LSB that a lot of software can't cope with).

soraminazuki 3y ago
> You must be one of these who believe that if you have a copy of a game binary and all its dependent libraries down to the last byte it will work as-is on a newer desktop. That is not at all what I wrote. I think I made myself clear in the first three sentences from my previous comment. > Nothing that you mentioned is absolutely of use and is just going to get in the way. I disagree. Making it easy to recreate old software environments is a huge time saver when it comes to running old software. "Absolutely of no use and is just going to get in the way" is a baffling statement. What's the easier alternative then? Patch the latest versions of software to make it compatible with the old ones? And I repeat, I said time saver, not a magic wand that solves every exotic problem. And the LinuxThreads thing isn't an inherent problem with Nix either. Software made after Nix can benefit from its reproducibility. > Reproducible builds are absolutely useless here > You are going to spend more time fighting the package manager than the actual problems. > by preventing patching of the underlying libraries The exact opposite is true. Nix makes it easy to use previous package definitions as a starting point and modify it to fit your needs. Applying a patch to a dependency is only a few lines worth of Nix code. Compare that with other package managers, where you have to fork a whole world's amount of package definitions in order to apply changes to a dependency few levels deep. Also see point 3 from my previous comment. > enforcing deviations from LSB that a lot of software can't cope with There are countless ways to deal with this. If source code is available, then Nix supplies the adequate configure flags. This works most of the time. Grepping and patching is also an option. If source code isn't available, there's buildFHSEnv, steam-run, and nix-ld. Also, many applications support configurable paths.

soraminazuki 3y ago

> You must be one of these who believe that if you have a copy of a game binary and all its dependent libraries down to the last byte it will work as-is on a newer desktop. That is not at all what I wrote. I think I made myself clear in the first three sentences from my previous comment. > Nothing that you mentioned is absolutely of use and is just going to get in the way. I disagree. Making it easy to recreate old software environments is a huge time saver when it comes to running old software. "Absolutely of no use and is just going to get in the way" is a baffling statement. What's the easier alternative then? Patch the latest versions of software to make it compatible with the old ones? And I repeat, I said time saver, not a magic wand that solves every exotic problem. And the LinuxThreads thing isn't an inherent problem with Nix either. Software made after Nix can benefit from its reproducibility. > Reproducible builds are absolutely useless here > You are going to spend more time fighting the package manager than the actual problems. > by preventing patching of the underlying libraries The exact opposite is true. Nix makes it easy to use previous package definitions as a starting point and modify it to fit your needs. Applying a patch to a dependency is only a few lines worth of Nix code. Compare that with other package managers, where you have to fork a whole world's amount of package definitions in order to apply changes to a dependency few levels deep. Also see point 3 from my previous comment. > enforcing deviations from LSB that a lot of software can't cope with There are countless ways to deal with this. If source code is available, then Nix supplies the adequate configure flags. This works most of the time. Grepping and patching is also an option. If source code isn't available, there's buildFHSEnv, steam-run, and nix-ld. Also, many applications support configurable paths.