Support us on Patreon
PayPalIn 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:
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Direct Link
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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
rustybroomhandle Feb 5, 2020
I'm going to throw out a guess here that a lot of developers that do release on Steam for Linux do not have the slightest clue what the Steam runtime even is.
11 Likes, Who?
Meanwhile every game I try running with the "Steam Linux Runtime" fails with
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.
`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.
4 Likes, Who?
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.
4 Likes, Who?
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
2 Likes, Who?
BrazilianGamer Feb 5, 2020
Amazing job. All kudos possible to Valve and Collabora
3 Likes, Who?
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.
1 Likes, Who?
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?
1 Likes, Who?
Dont freeBSD apps come with every dependency required all in one package? Sounds like what they are trying to make happen here, which is a good idea!
0 Likes
I wonder if in the future, this project could help to solve the anticheaters/launchers problem
0 Likes
Pressure-Vessel has been in the SteamOS repository since August last year:
http://repo.steampowered.com/steamrt-images-scout/snapshots/0.20190821.1/
http://repo.steampowered.com/steamrt-images-scout/snapshots/0.20190821.1/
0 Likes
Yup, was quite a nice talk (been there), so I can recommend watching the video.
0 Likes
Ah the FOSDEM videos are finally up. Enough stuff to go through the next evenings :D
0 Likes
Quoting: minkiuOut of curiosity what linux are you running?I'm running Exherbo Linux and while we also offer the possibility to switch to musl if desired, the default is glibc, which is also what I'm using.
Could it be you are using musl instead of glibc?
1 Likes, Who?
Quoting: elmapulthings like this make me want to give up developing for linux...Ah yes: Developers try to make things easier to deploy across all distributions.
You: I give up.
Makes sense.
6 Likes, Who?
Quoting: tgurrwhile 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.
I completely agree. Meanwhile all the "compatibility issues" mentioned are completely distro-irelevant and are relevant with the evolution of linux and in some cases if you are just missing a library (which is also a really distro-irelevant thing). The whole distro-fragmentation thing has never been a real issue and the only problem with that is that it is misleading people.
The fact is that a proper executable will just work on linux using the host libraries no matter the version. If you do not use the host libraries and you are trying "to be safe" then it will stop working in the future because these libraries will be incompatible with new libraries.
So the real solution should be to give a proper way to developers to develop and test the games using API that we just know it will never break no matter what changes underneath in the future.
0 Likes
Quoting: GuestI'm not the most clued up person with container tech, and flatpaks, etc, but:
Really glad Valve is continuing to research ways of keeping games running, and giving some kind of interface stability. Just would prefer if there was something a little more generic for GNU/Linux desktop, so that games outside of Steam's environment could benefit.
Games -> Add non-Steam game to my library
0 Likes
Quoting: GuestWell, the steam-runtime is already open source and they're using bubblewrap which is also open source.Quoting: BrisseQuoting: GuestI'm not the most clued up person with container tech, and flatpaks, etc, but:
Really glad Valve is continuing to research ways of keeping games running, and giving some kind of interface stability. Just would prefer if there was something a little more generic for GNU/Linux desktop, so that games outside of Steam's environment could benefit.
Games -> Add non-Steam game to my library
== reliance on 3rd party proprietary software. That's not an answer to the problem at all.
0 Likes
Might give it a go, have some of humble bundles original linux ports from years ago that barely even ran on anything when they first dropped.
0 Likes
Quoting: Liam DaweQuoting: elmapulthings like this make me want to give up developing for linux...Ah yes: Developers try to make things easier to deploy across all distributions.
You: I give up.
Makes sense.
first off, if that is the easier way that they are proposing, i cant imagine how hard it was before, plus i cant afford to run that solution, containers will dry out my limited performance.
second, valve supposedly solved this issue already, why do we still need this solution?
either its impossible to solve it once and forever, or it dont worth the performance cost.
in any case, i dont like how it sounds, the way things are, looks like someone is causing problems to sell the solution.
as they say, when the service is free, you are the product, with so many distros breaking backward compatibility with then selves or evolving into different directions that cause problems to support all of then without standards and clear benefits to that fragmentaiton, the only thing i can think off is that its sabotage, really.
its just ridiculous that we had 4 different browser engines (gecko, trident, presto, webkit) and things just worked in all of then. (nowadays, most browsers just use webkit/bink, because its cheaper than continuing developing their own code base, not because things broke all the time) if even microsoft could agree to follow some standards (web standards) there is no reason why the opensource world has to be that mess.
and before any one say that browsers arent as complex as an operating system, we can run entire operating systems inside one browser, there is no excuse.
0 Likes
See more from me