3 ms·

Unlikely. Games need a stable ABI and Win32 is the only stable ABI on Linux.

akdev1l 7mo ago
Proprietary software needs a stable ABI. Not games. DOOM runs on any Linux system since forever because we had access to the source. You can build it for Linux 2.6 and it’ll probably still work today. Sadly most games are proprietary
- fluffybucktsnek 7mo ago
  Even if all games were FOSS, without - at least - a stable API, most games will remain a hassle to run. DOOM doesn't deal as much with this due to the high amount of volunteers, but relying on community support for all games is just outsourcing labor to some unlucky fellows. At best, it's yet another pain for Linux users. At worse, it's the death of unpopular games. Either case, a hurdle for Linux adoption.
- badsectoracula 7mo ago
  > Proprietary software needs a stable ABI. Open source software also needs a stable ABI because: a) i don't want to bother building it over and over (not everything is in my distro's repository, a ton of software has a stupid building process and not every new version is always better than the old versions) b) a stable ABI implies a stable API and even if you have the source, it is a massive PITA to have to fix whatever stuff the program's dependencies broke to get it running, especially if you're not the developer who made it in the first place c) as an extension to "b", a stable API also means more widely spread information/knowledge about it (people wont have to waste time learning how to do the same tasks in a slightly different way using a different API), thus much easier for people to contribute to software that use that API
- Pannoniae 7mo ago
  Not really. I actually tried building an "old" game (read: not updated since 2014 or so) on Linux when I used it. It didn't work because autotools changed, some weird errors with make, and the library APIs have changed too. In the end I gave up and just used proton on the windows .exe. Unbelievable. :(
  - akdev1l 7mo ago
    I should clarify my original comment about stability only applies to glibc itself. Once we go out of glibc there will be varying degrees of API/ABI stability simply because at that point it’s just different groups of people doing the work In some cases such libraries are also cross-platform so the same issues would be found on Windows (eg: try to build application which depends on openssl3 with openssl4 and it will not work on either Linux or windows) For future reference if you ever need to do that again, it would be way easier to spin up a container with the build environment the software expects. Track down the last release date of the software and do podman run —-rm -it ubuntu:$from_that_time and just build the software as usual. You can typically link the dependencies statically during build time to create system independent binaries. So the binary produced inside the container would work on your host as well.
    - NetMageSCW 7mo ago
      That sounds almost as easy as just copying an .exe file from Windows and running it. /s
LtWorf 7mo ago
People who keep parroting this clearly have no experience of gaming on linux.
- fluffybucktsnek 7mo ago
  Please elaborate.
  - LtWorf 7mo ago
    Wine has constant regressions. What works fine today will completely fail next year. Which is why steam lets you pick which proton version you want to use. Which means that a .exe without the exact version of wine won't run. Plus of course there's the whole vulkan stuff. Older cards aren't well supported but it will rather crash than just run openGL normally where it would work fine.
    - orbital-decay 7mo ago
      In practice, Wine is constantly improving. It's in active development and not that stable, but regressions are mostly local. Treat its releases like bleeding edge. >What works fine today will completely fail next year. Usually not on the timescale of a year. I have many new games that worked a year ago and none of these stopped working now. The worst breakage I had recently was some physics glitches in an old RPG (released in 2001) on Wine 11.0, and it was fixed in the next release.
    - fluffybucktsnek 7mo ago
      Those issues seem othorgonal to stable ABI issue from OP, specially the OpenGL one (that is more like a hardware incompatibility issue). When apps fail to run due to Wine updates, they are considered bugs to be fixed. On the native side, apps may break becuase: 1) required library is unavailable, normally because it is too old and unsupported; 2) required library's path is different in distro A from B. None of these are considered bugs and, as such, are rarely addressed. I believe Steam Linux Runtime is an attempt at fixing this,but I'm not sure about its effectiveness. Also, you are exaggerating on the "exact Wine version". It helps to know which versions don't have a regression by knowing which specific version an app used to run on.

Proprietary software needs a stable ABI. Not games. DOOM runs on any Linux system since forever because we had access to the source. You can build it for Linux 2.6 and it’ll probably still work today. Sadly most games are proprietary

fluffybucktsnek 7mo ago
Even if all games were FOSS, without - at least - a stable API, most games will remain a hassle to run. DOOM doesn't deal as much with this due to the high amount of volunteers, but relying on community support for all games is just outsourcing labor to some unlucky fellows. At best, it's yet another pain for Linux users. At worse, it's the death of unpopular games. Either case, a hurdle for Linux adoption.
badsectoracula 7mo ago
> Proprietary software needs a stable ABI. Open source software also needs a stable ABI because: a) i don't want to bother building it over and over (not everything is in my distro's repository, a ton of software has a stupid building process and not every new version is always better than the old versions) b) a stable ABI implies a stable API and even if you have the source, it is a massive PITA to have to fix whatever stuff the program's dependencies broke to get it running, especially if you're not the developer who made it in the first place c) as an extension to "b", a stable API also means more widely spread information/knowledge about it (people wont have to waste time learning how to do the same tasks in a slightly different way using a different API), thus much easier for people to contribute to software that use that API
Pannoniae 7mo ago
Not really. I actually tried building an "old" game (read: not updated since 2014 or so) on Linux when I used it. It didn't work because autotools changed, some weird errors with make, and the library APIs have changed too. In the end I gave up and just used proton on the windows .exe. Unbelievable. :(
- akdev1l 7mo ago
  I should clarify my original comment about stability only applies to glibc itself. Once we go out of glibc there will be varying degrees of API/ABI stability simply because at that point it’s just different groups of people doing the work In some cases such libraries are also cross-platform so the same issues would be found on Windows (eg: try to build application which depends on openssl3 with openssl4 and it will not work on either Linux or windows) For future reference if you ever need to do that again, it would be way easier to spin up a container with the build environment the software expects. Track down the last release date of the software and do podman run —-rm -it ubuntu:$from_that_time and just build the software as usual. You can typically link the dependencies statically during build time to create system independent binaries. So the binary produced inside the container would work on your host as well.
  - NetMageSCW 7mo ago
    That sounds almost as easy as just copying an .exe file from Windows and running it. /s

LtWorf 7mo ago

People who keep parroting this clearly have no experience of gaming on linux.

fluffybucktsnek 7mo ago
Please elaborate.
- LtWorf 7mo ago
  Wine has constant regressions. What works fine today will completely fail next year. Which is why steam lets you pick which proton version you want to use. Which means that a .exe without the exact version of wine won't run. Plus of course there's the whole vulkan stuff. Older cards aren't well supported but it will rather crash than just run openGL normally where it would work fine.
  - orbital-decay 7mo ago
    In practice, Wine is constantly improving. It's in active development and not that stable, but regressions are mostly local. Treat its releases like bleeding edge. >What works fine today will completely fail next year. Usually not on the timescale of a year. I have many new games that worked a year ago and none of these stopped working now. The worst breakage I had recently was some physics glitches in an old RPG (released in 2001) on Wine 11.0, and it was fixed in the next release.
  - fluffybucktsnek 7mo ago
    Those issues seem othorgonal to stable ABI issue from OP, specially the OpenGL one (that is more like a hardware incompatibility issue). When apps fail to run due to Wine updates, they are considered bugs to be fixed. On the native side, apps may break becuase: 1) required library is unavailable, normally because it is too old and unsupported; 2) required library's path is different in distro A from B. None of these are considered bugs and, as such, are rarely addressed. I believe Steam Linux Runtime is an attempt at fixing this,but I'm not sure about its effectiveness. Also, you are exaggerating on the "exact Wine version". It helps to know which versions don't have a regression by knowing which specific version an app used to run on.