this post was submitted on 23 Nov 2025
126 points (99.2% liked)

Linux Gaming

22296 readers
226 users here now

Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.

This page can be subscribed to via RSS.

Original /r/linux_gaming pengwing by uoou.

No memes/shitposts/low-effort posts, please.

Resources

WWW:

Discord:

IRC:

Matrix:

Telegram:

founded 2 years ago
MODERATORS
 

An updated version of the Steam Linux Runtime 4 branch was rolled out that has now shifted from Debian 11 to Debian 13 libraries for some significant upgrades. In the process more libraries have gone x86_64 only in foregoing the i386 builds. In addition, the SDL 2 library support for the Steam Runtime is now provided by sdl2-compat as the compatibility layer for SDL2 atop SDL3.

Valve and their partners at Collabora have rolled out a significant Steam Linux Runtime update to shift libraries from Debian 11 to Debian 13.2 after having skipped out on Debian 12. The approximate four year version jump has resulted in some libraries having a new SONAME for breaking ABI compatibility.

top 9 comments
sorted by: hot top controversial new old
[–] sparky@lemmy.federate.cc 6 points 6 days ago (3 children)

Cool but I wonder if the Linux initiative is almost a victim of Proton’s success, as even previously Linux friendly studios like Paradox have stopped supporting it natively in recent titles.

[–] Willdrick@lemmy.world 15 points 6 days ago (1 children)

I'd rather have studios continually testing against proton over releasing a decent port that gets abandoned, foregoing all the improvements. I went full Linux back in the previous "steam for Linux" push. A few studios released competent ports for what we had back then. As an example: Metro games were OK ports but now they look and work far worse than just switching to the windows version on Proton.

And other devs made poor ports, got a ton of flak from the very vocal userbase and said "never again" (CDPR with witcher 2)

[–] sparky@lemmy.federate.cc 4 points 6 days ago (1 children)

Maybe that’s actually the right approach, counter-intuitively. Though it does make me wonder how many devs actually test against Proton, versus just taking the lazy option and saying it’s Windows only. Officially stating they support Proton would go a long way to help justify the lack of a native port.

[–] Willdrick@lemmy.world 1 points 5 days ago (1 children)

Remember that at the end of the day Proton is just a stopgap measure (and future compatibility for legacy titles) up until Linux gathers enough critical mass for engines, studios and publishers to start targeting linux

[–] sparky@lemmy.federate.cc 2 points 5 days ago (1 children)

Yes - but will it become a permanent crutch? That’s the double edged sword. A necessary risk, of course.

[–] Willdrick@lemmy.world 1 points 4 days ago

True, tho I rather rely on Proton than stuff like the borked BG3 port or the incompatible Total Warhammer port. Until there's enough people already settled in, there's no point in pressuring people to maintain ports for such a moving target. Maybe we'll get stuck like this, but still all the older games that were already released will need to work via compatibility layers anyway

[–] chronicledmonocle@lemmy.world 6 points 6 days ago (1 children)

As long as they are testing proton versions, this is fine. Proton is eventually going to "do Windows" better than Windows, at the rate it's going.

[–] sparky@lemmy.federate.cc 4 points 6 days ago

My experience so far is that it already is! Most of the titles I play (admittedly not cutting edge), I get 5-10% higher framerates running under Proton-GE on Fedora than I do natively on windows. Pretty wild to think about.

[–] x00z@lemmy.world 3 points 6 days ago

I think that's a temporary thing. Linux compilation and packaging has become easier and easier. Most libraries have also been working hard on complying with semver to lower the good ol' dependency problems.