Comment by akdev1l
20 days 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
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.
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. :(
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.
That sounds almost as easy as just copying an .exe file from Windows and running it.
/s
> 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