Game devs should 100% focus on making sure their game runs flawlessly on Proton instead of releasing a half-assed Linux version. This is what Valve has infamously done with games such as Left 4 Dead 2, whose Linux version has multiple game-breaking bugs that have been known for over 15 years. Unfortunately that game does not run on Proton because of an obscure VAC bug that Valve hasn't bothered to fix since they can already claim Linux compatibility through their terrible Linux port.
Game devs should just design their games to be cross platform from the start, thus making this problem go away. Every major language compiles everywhere, so all that you need to do is not use libraries that tie you to a specific OS. When I test on the OSes that I'm not developing on I usually find a few bugs to work out, but never anything major. DirectX is the main thing to avoid, so I use Vulkan for my graphics work.
From when I first got into graphics, I immediately dismissed DirectX because of platform locks. I wish that more developers had this same stance of refusing all options with abusive practices like platform exclusivity.
It already does. When Elden Ring released, it suffered from terrible performance problems, which were worked around in VKD3D (DX12 for Wine) in the first week of release.
I've heard people complaining about Elden Ring performance on Windows for months afterwards.
This is not an ABI stability problem, this is a UX problem.
iOS and Android do backwards incompatibility all the time. If you find a mobile app that hasn't been updated in 10 or 15 years, you won't be able to install it on a modern device. But, iOS and Android ship apps to billions of users, nobody complains about ABI stability and nobody uses a Win32 compatibility layer.
glibc already has decent UX in that it doesn't allow you to load an app built for a newer version on a host with an older version. Unfortunately, the message is not user friendly at all "could not load @@GLIBC_X.YZ@@foo()", instead of something more readable, but the restriction is, in itself, good.
The problem is that there is no system to trigger backwards incompatibility at any point, nor is there a simple way to target an older Glibc version without spinning up a docker container.
And glibc is a HELL of a codebase, I would NOT want to be responsible for implementing those features, so I understand why they're not there. But 'our Linux build for our game we are still selling and advertising as working on Linux is no longer compatible with new Linux distributions, so let's rebuild it' is a much easier decision for a developer, publisher, etc. to make than '"some" Linux users are reporting issues with our game, should we dedicate resources to investigating this?'
> nor is there a simple way to target an older Glibc version without spinning up a docker container
? I feel like you might be falling into the trap of assuming that the compiler always targets the current running system, but you 100% should always always always be doing a Linux-to-Linux "cross" compile with a sysroot... you don't need a docker container: you just extract an old Linux distribution into a folder and tell your current/modern compiler to target it.
Because if function foo's third flag parameter supports FOO_ENABLE_FEATURE_X starting from 2.31, and a program only occasionally calls foo with this flag, there is no good way to detect this incompatibility on a 2.30 system at link time.
The restriction is only annoying because there is no way to trivially link against an older "minimum requirement" ABI.
I shipped godot games on Linux and it just worked. Maybe some people had some issues but it never surface to me. As usual I feel like people make it sound worse than it is. It's not like a barren wasteland of broken apps on Linux.
Not much software directly targets syscalls. Even just linking to libc (musl/glibc) exposes you to the churn of userspace linux.
Games depend on the entire stack (audio, HID, VR, Vulkan, desktop compositor choice, etc.) so are the most vulnerable to any minor change. And game developers, rightly so, have better things to do than to recompile if not re-port their game because Linux has decided that Pulseaudio is out, or X11 has been replaced with Wayland.
So yes, in practice, there are only two stable APIs/ABIs on Linux: the syscalls, and Proton.
It’s a tongue in cheek comment, but the author does say:
> Personally I share Linus’ opinion (link to YouTube) that changing ABI is okay as long as no one has noticed, but once it gets noticed - then it’s a regression. Once it’s a thing people depend on, it becomes a feature.
Game devs should 100% focus on making sure their game runs flawlessly on Proton instead of releasing a half-assed Linux version. This is what Valve has infamously done with games such as Left 4 Dead 2, whose Linux version has multiple game-breaking bugs that have been known for over 15 years. Unfortunately that game does not run on Proton because of an obscure VAC bug that Valve hasn't bothered to fix since they can already claim Linux compatibility through their terrible Linux port.
Game devs should just design their games to be cross platform from the start, thus making this problem go away. Every major language compiles everywhere, so all that you need to do is not use libraries that tie you to a specific OS. When I test on the OSes that I'm not developing on I usually find a few bugs to work out, but never anything major. DirectX is the main thing to avoid, so I use Vulkan for my graphics work.
From when I first got into graphics, I immediately dismissed DirectX because of platform locks. I wish that more developers had this same stance of refusing all options with abusive practices like platform exclusivity.
Consoles only do C, C++ and Assembly, C# does it via IL2CPP or in-house compilers, so not "every major language compiles everywhere".
Games industry is built on platform locks and exclusives since the Atari 2600.
Until Proton becomes another OS/2, "runs Windows better than Windows".
Just wait until all the PC handelds start shipping the better Windows version, like it happened with netbooks.
> runs Windows better than Windows
It already does. When Elden Ring released, it suffered from terrible performance problems, which were worked around in VKD3D (DX12 for Wine) in the first week of release.
I've heard people complaining about Elden Ring performance on Windows for months afterwards.
OS/2 also did, until it did not.
The point is the historical lesson of building castles on other companies kingdoms, not the technical achievement.
This is not an ABI stability problem, this is a UX problem.
iOS and Android do backwards incompatibility all the time. If you find a mobile app that hasn't been updated in 10 or 15 years, you won't be able to install it on a modern device. But, iOS and Android ship apps to billions of users, nobody complains about ABI stability and nobody uses a Win32 compatibility layer.
glibc already has decent UX in that it doesn't allow you to load an app built for a newer version on a host with an older version. Unfortunately, the message is not user friendly at all "could not load @@GLIBC_X.YZ@@foo()", instead of something more readable, but the restriction is, in itself, good.
The problem is that there is no system to trigger backwards incompatibility at any point, nor is there a simple way to target an older Glibc version without spinning up a docker container.
And glibc is a HELL of a codebase, I would NOT want to be responsible for implementing those features, so I understand why they're not there. But 'our Linux build for our game we are still selling and advertising as working on Linux is no longer compatible with new Linux distributions, so let's rebuild it' is a much easier decision for a developer, publisher, etc. to make than '"some" Linux users are reporting issues with our game, should we dedicate resources to investigating this?'
> nor is there a simple way to target an older Glibc version without spinning up a docker container
? I feel like you might be falling into the trap of assuming that the compiler always targets the current running system, but you 100% should always always always be doing a Linux-to-Linux "cross" compile with a sysroot... you don't need a docker container: you just extract an old Linux distribution into a folder and tell your current/modern compiler to target it.
> you just extract an old Linux distribution into a folder and tell your current/modern compiler to target it
That sounds like more work than spinning up a Docker container though. I'm imagining
How?
> glibc [...] doesn't allow you to load an app built for a newer version on a host with an older version
> the restriction is, in itself, good.
Why do you consider this a good restriction?
Because if function foo's third flag parameter supports FOO_ENABLE_FEATURE_X starting from 2.31, and a program only occasionally calls foo with this flag, there is no good way to detect this incompatibility on a 2.30 system at link time.
The restriction is only annoying because there is no way to trivially link against an older "minimum requirement" ABI.
This should be updated to include the GLIBC libcrypt fiasco.
Wait, I remember Silverlight... do you?
I shipped godot games on Linux and it just worked. Maybe some people had some issues but it never surface to me. As usual I feel like people make it sound worse than it is. It's not like a barren wasteland of broken apps on Linux.
Them's fightin' words
Huh?!? Syscalls are stable ABI on Linux, this is why docker works
Not much software directly targets syscalls. Even just linking to libc (musl/glibc) exposes you to the churn of userspace linux.
Games depend on the entire stack (audio, HID, VR, Vulkan, desktop compositor choice, etc.) so are the most vulnerable to any minor change. And game developers, rightly so, have better things to do than to recompile if not re-port their game because Linux has decided that Pulseaudio is out, or X11 has been replaced with Wayland.
So yes, in practice, there are only two stable APIs/ABIs on Linux: the syscalls, and Proton.
It’s a tongue in cheek comment, but the author does say:
> Personally I share Linus’ opinion (link to YouTube) that changing ABI is okay as long as no one has noticed, but once it gets noticed - then it’s a regression. Once it’s a thing people depend on, it becomes a feature.