7 ms·

Yeah I was going to say Linux is a strange choice of platform for this project. While the kernel per se is solid, the userland has zero backwards compatibility.

by Asooka 3y ago

Yeah I was going to say Linux is a strange choice of platform for this project. While the kernel per se is solid, the userland has zero backwards compatibility. I expect his ports will bitrot and none will run two to five years from now, while the win32 versions will be kept supported in perpetuity. Though who knows, maybe this is what finally makes the Linux community start paying attention to backwar.. pffhahaha no I can't finish this sentence with a straight face. I have been using Linux for over 20 years now and am absolutely certain it will never be a stable target. Just compile for win32. Or wasm. Maybe one day wasm will be the stable desktop ABI.

adev_ 3y ago
> While the kernel per se is solid, the userland has zero backwards compatibility That is entirely wrong. It is not because your latest distribution does not provide old/antique glibc by default that it means you can not run it. It is currently pretty trivial to get a 20 years old glibc (or whatever library) recompiled under Linux to run your old game and call it a day. Software like Nix nowadays even make that surprisingly easy with sandboxing. That is currently the strength OSS and something you will never be able to do on Windows. As long as the version used is known and the source not lost: Software lives forever.
- AshamedCaptain 3y ago
  It is not that trivial, and there have been breaking kernel changes that prevent running ancient glibc versions. Fortunately, glibc is open source, so you can actually patch it to run in older versions. Just grep a kernel's Kconfig and see how many entries claim "this will break binary compatibility". Even compilers are not that good at building old software.
  - adev_ 3y ago
    > 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
    - AshamedCaptain 3y ago
      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_.
      - ecliptik 3y ago
        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/ https://lokigames.com/
      - soraminazuki 3y ago
        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.
deleted 3y ago
[deleted]
AshamedCaptain 3y ago
> while the win32 versions will be kept supported in perpetuity Yeah.. no. I am surprised people would still believe the claim that Win32 has "good backwards compatibility", specially for games, when even the TFA is claiming that a Windows 7 game is _not_ going to work on Windows 11 without "maintenance". I'd not go as far as say that all Windows 7 games won't work, but it is definitely a good chunk. And I believe it's getting worse, with Windows 10 era games likely unable to run in "Windows 12". I already have at least one piece of software with runs in early Windows 10 but not in late Windows 10. People are resorting to literally use the Wine libraries in Windows to run old games. At this point, to target a Linux API doesn't seem that bad and likely would even be easier than having to maintain your win32 game AND wine.
livrem 3y ago
Barely any of the older Linux binary-only games I have (e.g. the early Humble Indie Bundles ca 2010) run without a lot of effort compared to old Windows games (in WINE). And even then there are several that I gave up on and some that only run without audio. Running the old Windows binaries is way easier. For several years whenever I buy a DRM-free game I make sure to download both the Linux version (if any; to install and play now) as well as the Windows version (to keep for the future, whenever the Linux version becomes annoyingly difficult to run).

by Asooka 3y ago

adev_ 3y ago

> While the kernel per se is solid, the userland has zero backwards compatibility That is entirely wrong. It is not because your latest distribution does not provide old/antique glibc by default that it means you can not run it. It is currently pretty trivial to get a 20 years old glibc (or whatever library) recompiled under Linux to run your old game and call it a day. Software like Nix nowadays even make that surprisingly easy with sandboxing. That is currently the strength OSS and something you will never be able to do on Windows. As long as the version used is known and the source not lost: Software lives forever.

AshamedCaptain 3y ago
It is not that trivial, and there have been breaking kernel changes that prevent running ancient glibc versions. Fortunately, glibc is open source, so you can actually patch it to run in older versions. Just grep a kernel's Kconfig and see how many entries claim "this will break binary compatibility". Even compilers are not that good at building old software.
- adev_ 3y ago
  > 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
  - AshamedCaptain 3y ago
    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_.
    - ecliptik 3y ago
      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/ https://lokigames.com/
    - soraminazuki 3y ago
      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.

deleted 3y ago

[deleted]

AshamedCaptain 3y ago

> while the win32 versions will be kept supported in perpetuity Yeah.. no. I am surprised people would still believe the claim that Win32 has "good backwards compatibility", specially for games, when even the TFA is claiming that a Windows 7 game is _not_ going to work on Windows 11 without "maintenance". I'd not go as far as say that all Windows 7 games won't work, but it is definitely a good chunk. And I believe it's getting worse, with Windows 10 era games likely unable to run in "Windows 12". I already have at least one piece of software with runs in early Windows 10 but not in late Windows 10. People are resorting to literally use the Wine libraries in Windows to run old games. At this point, to target a Linux API doesn't seem that bad and likely would even be easier than having to maintain your win32 game AND wine.

livrem 3y ago

Barely any of the older Linux binary-only games I have (e.g. the early Humble Indie Bundles ca 2010) run without a lot of effort compared to old Windows games (in WINE). And even then there are several that I gave up on and some that only run without audio. Running the old Windows binaries is way easier. For several years whenever I buy a DRM-free game I make sure to download both the Linux version (if any; to install and play now) as well as the Windows version (to keep for the future, whenever the Linux version becomes annoyingly difficult to run).