In a recent update to the Linux Steam Client, the ability to run Linux games inside a special container was added in. At the FOSDEM event, Collabora consultant Simon McVittie who works on helping Valve with the Linux steam-runtime gave a talk on it.
The talk goes over a brief bit of history on the different versions of the steam-runtime, which is definitely interesting for any developers looking at Linux support and for gamers who perhaps don't entirely understand much about it. This includes the problems with it and from there they go into info about "pressure-vessel", the new and experimental Container system.
Hilariously, Steam pops-up during the presentation asking McVittie to update. See the full video below:
Direct Link
We've heard so many times on how the fragmentation of Linux distributions causes issues for game developers, and while I'm no game developer and not knowledgeable enough on the internals of Linux and game dependencies to properly comment on that I do think it's fantastic that Valve funds attempts to make Linux gaming better in so many ways like this. Obviously a big hat tip to all the people at Collabora too, some really smart people working there.
A more up to date runtime code-named "Soldier" seems to be in testing, with the pressure-vessel container opening up options on this with it being a lot more flexible, so older games can keep an older runtime in the container with newer games using the newer runtime again in a container. Certainly sounds like the future of Linux gaming will be interesting.
There's more Linux videos up from Collabora which you can see listed on their website here.
Article taken from GamingOnLinux.com.
rustybroomhandle Feb 5, 2020
`g_io_module_load': /usr/lib/gio/modules/libgiognutls.so: undefined symbol: g_io_module_load
Failed to load module: /usr/lib/gio/modules/libgiognutls.so
bwrap: execvp readlink: No such file or directory
bwrap: execvp readlink: No such file or directory
pressure-vessel-wrap: None of the supported CPU architectures are common to the host system and the container (tried: x86_64-linux-gnu, i386-linux-gnu)while they run fine without the container solution.
It's funny how containers are said to be the cure to everything by adding yet another layer of complexity.
Quoting: tgurrMeanwhile every game I try running with the "Steam Linux Runtime" fails withIt's brand new and experimental, issues are to be expected. Did you log a bug report on the GitHub?
`g_io_module_load': /usr/lib/gio/modules/libgiognutls.so: undefined symbol: g_io_module_load
Failed to load module: /usr/lib/gio/modules/libgiognutls.so
bwrap: execvp readlink: No such file or directory
bwrap: execvp readlink: No such file or directory
pressure-vessel-wrap: None of the supported CPU architectures are common to the host system and the container (tried: x86_64-linux-gnu, i386-linux-gnu)
while they run fine without the container solution.
It's funny how containers are said to be the cure to everything by adding yet another layer of complexity.
EagleDelta Feb 5, 2020
Quoting: tgurrMeanwhile every game I try running with the "Steam Linux Runtime" fails with
`g_io_module_load': /usr/lib/gio/modules/libgiognutls.so: undefined symbol: g_io_module_load
Failed to load module: /usr/lib/gio/modules/libgiognutls.so
bwrap: execvp readlink: No such file or directory
bwrap: execvp readlink: No such file or directory
pressure-vessel-wrap: None of the supported CPU architectures are common to the host system and the container (tried: x86_64-linux-gnu, i386-linux-gnu)
while they run fine without the container solution.
It's funny how containers are said to be the cure to everything by adding yet another layer of complexity.
- Not sure where you got that Containers have been pushed as the "Cure to everything". In my experience, it's all about picking the best tool for the job. Many of the Container/Kubernetes heavyweight supporters have recently stressed that containers can't solve all problems.
- The talk addresses that the containerized runtime doesn't solve all problems. Specifically it only supports the Ubuntu 12.04-based runtime and are working on a newer 2018-based runtime version with the intent of having multiple runtime versions for developers/users to choose from.
- I don't think this is using what many of us would consider "true" containers in that they aren't (AFAIK) based on LXC or ContainerD, but are Flatpak-based containers. I could be wrong though
BrazilianGamer Feb 5, 2020
Quoting: EagleDeltaA container to me is something that encapsulates itself into it's own namespace.I don't think this is using what many of us would consider "true" containers in that they aren't (AFAIK) based on LXC or ContainerD, but are Flatpak-based containers. I could be wrong though
Sometimes I even only need a secondary ip stack... ip netns to the rescue...
Lxc is just a wrapper on the set of different nameserver creations and migrate systemcalls. You can do it using bash :-). Lxc is very nice though.
I don't know flatpak, but from what I've seen, they are just squasfs like files mounted. No security or whatever unless the flatpak itself does that. I doubt that's what they are doing.
Quoting: tgurrMeanwhile every game I try running with the "Steam Linux Runtime" fails with
`g_io_module_load': /usr/lib/gio/modules/libgiognutls.so: undefined symbol: g_io_module_load
Failed to load module: /usr/lib/gio/modules/libgiognutls.so
bwrap: execvp readlink: No such file or directory
bwrap: execvp readlink: No such file or directory
pressure-vessel-wrap: None of the supported CPU architectures are common to the host system and the container (tried: x86_64-linux-gnu, i386-linux-gnu)
while they run fine without the container solution.
It's funny how containers are said to be the cure to everything by adding yet another layer of complexity.
Out of curiosity what linux are you running?
Could it be you are using musl instead of glibc?
http://repo.steampowered.com/steamrt-images-scout/snapshots/0.20190821.1/
Patreon
PayPal
See more from me