Hacker News Reader

Comment by adev_ | Hacker News Reader

> Even compilers are not that good at building old software.

Even old compilers can be boostrapped the same way.

Sandboxed prefx-install package manager like spack and Nix also allow you to do that without too much pain currently. They also give you the possibility to generate full featured Linux images if necessary for QEMU for instance.

That said: It is true they do not do it by default, it requires configuration (probably due to a too small userbase I guess).

I wonder if the userbase on that dedicated to old games/old app/old tools would be enough to dedicate a project on that entirely

View on HN

You point to Nix as if it was doing anything whatsoever the remove difficulty. You are replacing the entire libc. There's practically no benefit whatsoever to a prefix-install, Nix, a container, or whatever you want. You are going to hit the same issues whether you do this with Nix or you do this with plain old chroots. At the end of the day you'll have to use a chroot or ld/elf trickery anyway since the game binary will expect the libraries in hardcoded paths.

You'll hit build issues, bootstrap issues (at which point you'll likely need an old Linux on a VM), kernel issues (which will force you to either patch the kernel, the libc, or both), and then a myriad of desktop integration issues, which is as usual the pain point and the main reason I always say static linking is absolutely useless for forward compatibility. For example, the game will try to set a rare resolution & refresh rate using Xrandr (good luck!), or will try to use OSS (for which user-space emulation with LD_PRELOAD is almost always useless, the in-kernel one prevents you from using pulseaudio, and CUSE doesn't support mmap which a shitton of games use), or even expect some specific behavior from the window manager, etc.

With more recent software, you'll hit issues with the software expecting some D-Bus services e.g. such as project utopia (yet another Linux desktop compatibility disaster that has been quickly forgotten by everyone involved, except for the software that decided to embrace it and now will never run again). In these cases building the libraries is only half the way...

That said, it's still true that a lot of times having the source available for all the underlying libraries is what makes these things possible _at all_.

This is exactly what happened when I tried to run some of my old Loki [1] games a few years ago on a modern Linux distro. Tried a few tricks to get them working, but every problem solved opened up 2 more.

1. https://lokigames.com/

Nix actually is more capable than you give credit for. Sure, it does not solve every conceivable problem you can come up with. However, talking out of experience, it does make running older software easier and much more viable.

Nix offers more than just prefix installs. It offers:

1. Reproducible builds of past packages and all of its dependencies down to the compiler that was used to build it.

2. Reproducible configuration of an entire distro provided by NixOS. It can also build VMs from NixOS configuration. So running an older kernel or DE is hardly an issue in the rare case this is required.

3. The ability to treat package definitions as code. You can take an existing package or its dependency and modify it however you like with a few lines of code. Tedious tasks like modifying rpath are abstracted away. It makes iterating on packaging work easier and less error prone.

4. Large binary cache provided by the NixOS Foundation. Binary builds of packages dating back years are currently available. This is helpful because it greatly speeds things up.

All of these things reduce the amount of work required to run old software. And new ones too.

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).

> 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.

> You are going to hit the same issues whether you do this with Nix or you do this with plain old chroots.

The main advantage of Nix here is not its binary cache and reproducibility. It is Nix's ability to bootstrap any compiler tool chain + coreutils + kernel from scratch with just a bit of line of config.

Nix allow you to do what you would normally with a chroot but under steroid. It is not a magic bullet, far to be, but one order of magnitude easier to setup the exact tool chain you want than with anything else.

Most path related problems can be solved with a bunch of link and/or patchelf.

> will try to set a rare resolution & refresh rate using Xrandr (good luck!), or will try to use OSS

On this your are perfectly right. That will not protect you against this kind of crap related to exotic dependencies.

On that aspect Windows again is not much better (probably worst). Good luck to try to run in 2023 an old game that has a dependency on Novell IPX, an old version of Nvidia PhysiX or harcoded assumption on the GPU type

Reply on news.ycombinator.com