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.
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?'
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.
11 comments
[ 4.4 ms ] story [ 30.4 ms ] threadiOS 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?'
Previous discussion:
https://news.ycombinator.com/item?id=32471624