What the heck is Steam Linux Runtime 2.0 and 3.0?

[DannDaMANN]

I know that SLR is a container that allows games to run equally on all distros, but what is up with 2.0 and 3.0? What is the difference between the versions? Also on both Steam Deck and Linux PC I can only force 1.0, and the only way to get 2.0 or 3.0 is if Valve selects it (For the games I play, this applies for 3.0 to Counter-Strike 2 and Retroarch, but no games have 2.0). Does anyone know what the difference between these are?

[thetargos]

Most likely the base versions of the several libraries and supporting environment as found on Ubuntu 12 (1.0) and 18 (2.0) and possibly some more recent and 'distro agnostic' (3.0).

I have not dug into the actual versions as shipped by the three versions, though.

[DannDaMANN]

Originally posted by thetargos:

Most likely the base versions of the several libraries and supporting environment as found on Ubuntu 12 (1.0) and 18 (2.0) and possibly some more recent and 'distro agnostic' (3.0).

I have not dug into the actual versions as shipped by the three versions, though.

That kind of makes sense, but why wouldn't they just throw all the libraries into one tool?

[thetargos]

Originally posted by DanDaMan:

That kind of makes sense, but why wouldn't they just throw all the libraries into one tool?

Because some ported games make use of very old libraries that have no support in newer versions, and games that were built with newer versions, hence the separation in different runtimes.

[DannDaMANN]

That makes sense. Still don't get why you can only force 1.0, but whatever.

[thetargos]

Originally posted by DanDaMan:

That makes sense. Still don't get why you can only force 1.0, but whatever.

I think that's a limitation imposed by Valve for the time being.... hopefully they'll lift it.

[DannDaMANN]

Originally posted by thetargos:

Originally posted by DanDaMan:

That makes sense. Still don't get why you can only force 1.0, but whatever.

I think that's a limitation imposed by Valve for the time being.... hopefully they'll lift it.

From one perspective there is that Valve is trying to be user friendly, but at the same time they should still let use force 2.0 and 3.0 since valve hasn't yet chosen it for every game that may need it.

[WarnerCK]

Originally posted by DanDaMan:

What the heck is Steam Linux Runtime 2.0 and 3.0?

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md

Originally posted by DanDaMan:

That kind of makes sense, but why wouldn't they just throw all the libraries into one tool?

They did: the Steam Linux Runtime.

But you also seem to want "the versions of libraries that were included in Ubuntu 12.04", "the versions of libraries that were included in Debian 10“ and "the versions of libraries that were included in Debian 11" to be identical, which is obviously nonsensical.

[DannDaMANN]

Originally posted by WarnerCK:

Originally posted by DanDaMan:

What the heck is Steam Linux Runtime 2.0 and 3.0?

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md

Originally posted by DanDaMan:

That kind of makes sense, but why wouldn't they just throw all the libraries into one tool?

They did: the Steam Linux Runtime.

But you also seem to want "the versions of libraries that were included in Ubuntu 12.04", "the versions of libraries that were included in Debian 10“ and "the versions of libraries that were included in Debian 11" to be identical, which is obviously nonsensical.

Sorry, I have just started using linux so I don't know everything about it yet.

[kitty]

Valve is the example of bad practices when it comes to compatibility. instead of making their client compatible with native libraries of mainstream distro they don't bother and just preload whole stack of their own libraries. steam app on Linux is Frankestein.

[Marlock]

Originally posted by kitty:

Valve is the example of bad practices when it comes to compatibility. instead of making their client compatible with native libraries of mainstream distro they don't bother and just preload whole stack of their own libraries. steam app on Linux is Frankestein.

steam used to run with distro libs by default, and that just didn't work so well... you can still do it with a flag, but the results are spotty at best

what steam did helped steam itself, but more so a lot of games, run similarly on all linux distros

it's not too different from how flatpaks work

what's horrible is how inconsistent the steam client is at downloading, installing and listing stuff that's installed... and how heavy and unstable its web UI is (because CEF is ♥♥♥♥♥), regardless of using their own or thesystem's libs

[kitty]

Originally posted by Marlock:

it's not too different from how flatpaks work

and that's a bad thing.

all game developers target steam Frankenstein libs and don't worry about anything else. then you purchase DRM free game and want to run it from your desktop. you know what will happen - nothing. games become defunct without steam.

game devs should drag their own libs and preload them manually. it should be shipped with game.

[Marlock]

Originally posted by kitty:

Originally posted by Marlock:

it's not too different from how flatpaks work

and that's a bad thing.

all game developers target steam Frankenstein libs and don't worry about anything else. then you purchase DRM free game and want to run it from your desktop. you know what will happen - nothing. games become defunct without steam.

you're mixing the idea of using runtimes with their use of the steam APIs in them, which hook into steam client functionality

using namespaces to provide a standardized and stable environment for games is a good idea because:
1) it makes linux just "linux" instead of a bunch of smaller OSs like "ubuntu", "arch", "fedora", etc... this helps linux be a viable target for game devs
2) games aren't FOSS software, they're mostlyreleased once and forgotten... if a lib API changes a game breaks and the game dev/studio might not be interested in updating the game to fix it, or they might not even exist anymore... FOSS apps can be forked and fixed if the original devs are lost to time
3) games are irreplaceable, unlike utility apps... as much as i like Two Point Hospital, it doesn't really replace Theme Hospital, it's another game and i want to be able to run both forever

had Valve just used the FOSS flatpak runtimes as a target, this part would be a non-issue, because the runtimes would be 100% FOSS and forever replaceable for API-compatible hooks into whatever exists on a newer system

for replacing the proprietary steam APIs, which i agree are an issue in the long term (and i'd love FOSS crossplatform crossvendor alternatives to emerge as defacto standards like SDL is and mod.io is rising up to be), see Goldberg Emulator:
https://mr_goldberg.gitlab.io/goldberg_emulator/

game devs should drag their own libs and preload them manually. it should be shipped with game

no, that's just making things worse... imagine a game dev drags in their own copy of OpenSSL, and unfortunately it's based on OpenSSL 1.01f:
https://heartbleed.com/

updating the OS's version of OpenSSL fixes the heartbleed vulnerability in FOSS native software using that system-wide lib... the flatpak runtimes are auto-updated in one or two days and all flatpak apps are fixed too... steam pushes an update with the fix to steam linux runtimes 1, 2 and 3 in a couple weeks because people bash them for taking so long... and the game devs are nowhere to be found, they got bought and dispersed by Eletronic Arts or Epic, which just don't care to spend a penny fixing security vulnerabilities on a linux version of the game they wouldn't even have made... this game is a menace forever unless tightly sandboxed, whixh is ironic because now it's sort of a bad flatpak...

[kitty]

Originally posted by Marlock:

you're mixing the idea of using runtimes with their use of the steam APIs in them, which hook into steam client functionality

I spoke about libraries steam loads with LD_PRELOAD for every game you run. I'd prefer to have no steam API hooks to be present in my games, I don't care about achievements or other social features related to games. Perfect game is what runs from desktop without additional unlinking it from steam API (with goldberg or steamless). however I started to notice a trend in Linux ports where they gradually stop working from desktop because of failed dependencies or steam API requirement. the only way to "fix it" is to invoke "replacement" for steam functionality or manually preload missing libs.
gog ships Linux games without this hassle. their selection isn't as big as Steam store but games do work (within supported mainstream distro). somehow gog managed to deliver Linux ports without preloading Frankenstein library so maybe there is a way to achieve the same for steam games?

[i_nive]

Think (native and Protonized) Linux games have been running containerized for quite some time now (SR 2+),

Originally posted by https://github.com/ValveSoftware/steam-runtime#introduction:

The Steam client itself is run in an environment that adds the shared libraries from Steam Runtime 1 'scout' to the library loading path, using the LD_LIBRARY_PATH environment variable. This is referred to as the LD_LIBRARY_PATH runtime. Most native Linux games available through Steam are also run in this environment.

A newer approach to cross-distribution compatibility is to use Linux namespace (container) technology, to run games in a more predictable environment, even when running on an arbitrary Linux distribution which might be old, new or unusually set up. This is implemented as a series of Steam Play compatibility tools, and is referred to as the Steam container runtime, or as the Steam Linux Runtime.

Details: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/container-runtime.md

Originally posted by https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/container-runtime.md#why-the-container-runtimes-are-necessary:

Why the container runtimes are necessary

The traditional LD_LIBRARY_PATH runtime
only works because modern host OSs are strictly newer than it.
Making a LD_LIBRARY_PATH-based runtime reliable is difficult, especially
since we want it to be runnable on host OSs that have some packages that
are older than the runtime, allowing users of older LTS distributions to
run the latest games.
Some libraries cannot be bundled in a LD_LIBRARY_PATH for technical
reasons (mainly glibc and graphics drivers). A LD_LIBRARY_PATH runtime
needs to get these from the host system, and they need to be at least the
version it was compiled against. This is fine for scout, which is very
old, but would not be OK for a Debian 10-based runtime, which wouldn't work
on (for example) Ubuntu 18.04.
Some libraries can be bundled, but need to be patched to search for
plugins in different places (either inside the runtime itself, or in
multiple distro-dependent places), which is not really sustainable.
Avoiding the need to patch these libraries greatly reduces the time
required to update them, ensuring that we can apply security and
bug-fix updates as needed.
Using namespace (container) technology to replace /usr with the
runtime's libraries sidesteps both these problems.

Edit; BTW, the previous link introduces SR5 (2025+), same as SR2 but newer (Debian 13) bundle.

[Marlock]

Originally posted by kitty:

gog ships Linux games without this hassle. their selection isn't as big as Steam store but games do work (within supported mainstream distro). somehow gog managed to deliver Linux ports without preloading Frankenstein library so maybe there is a way to achieve the same for steam games?

true, GOG games are DRM-free, no steam APis

sometimes they assume system libs (eg: for me the native linux version of crayon physics deluxe broke on newer distros for lack of an old lib) and sometimes they ship their own everything, which breaks them on distros with conflicting libs (mostly mismatched libgcc or something like that)... putting these rebels on an isolated namespace along the stuff they need might fix them...

there are pros and cons to every approach


true, Goldberg Emulator and Steamless are workarounds, not an ideal situation... i've already mentioned how we should ideally have a vendor neutral FOSS solution for whatever is currently provided by Steam APIs

trivia: multiple steam games can be run directly (the game binary) without steam even being present... steam APIs aren't always a hard requirement, some game devs don't use them and some make a single game work with and without them (eg: so the same version can be distributed on steam and gog)