Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone with no article paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

Want to see the dirty innards of more Valve code? Well you're in luck as they now have a lot of work involved in the Steam Runtime on GitLab including the Pressure Vessel container.

Valve has for some time now had their own GitHub account, which is where they listed many different open source projects like GameNetworkingSocketsProton and more. However, they've now added a bunch of other projects to their own hosted GitLab.

You can now find the steamrt group on their GitLab, which contains projects for various parts of the Steam Linux Runtime, including the source for the much newer Pressure Vessel container system which according to Valve contractor Timothee Besset on Twitter was previously "only available as a tarball release" from their download servers.

What is Pressure Vessel? It's kinda of like a simple version of Flatpak made for Steam games. Within the Linux Steam client, you can select "Steam Linux Runtime" under the right click -> properties menu of games at the bottom like so:

This then puts those Linux game builds into a game-specific container. There's many reasons for it, like allowing developers to test against a contained environment, and have it run across any Linux distribution and allow old games to continue working long into the future. Learn more about it here, where Collabora engineer Simon McVittie gave a run-down of their work. Valve are also now using the latest generation of the Linux Steam Runtime for the Proton 5.13-1 compatibility layer too.

When we queried on why Valve are now putting more up in the open on GitLab, instead of the GitHub that was being used originally, Besset mentioned to us "The projects you see on GitHub are often mirrored from an internal repo. It's awkward and creates friction for community contributions. The projects on gitlab is where we will do our work in the open.", which is awesome.

Article taken from GamingOnLinux.com.
44 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
15 comments
Page: «2/2
  Go to:

omer666 30 Oct, 2020
Quoting: LinasAlthough it is already useful for getting games like Dying Light to work properly.
What is wrong with Dying Light? It seems to run just fine for me...


Last edited by omer666 on 30 October 2020 at 5:40 pm UTC
minidou 30 Oct, 2020
Quoting: Linas
Quoting: minidouI still don't understand what a user is supposed to make of "Steam Linux Runtime".
Not so much right now. Although it is already useful for getting games like Dying Light to work properly.

The whole idea is to give a stable runtime environment to the game developers where you don't need to care about what distribution is the game run on, or that upgrades to the system would break something. It is essentially a Linux compatibility layer for Linux to address the main argument a lot of people have against Linux - fragmentation.

So it is for linux games then. Another step to the existing libs bundled with steams. I thought this was to package proton/wine configs, I think it is misplaced, or mislabeled. Why does it appear on windows games ?
lucinos 31 Oct, 2020
Quoting: minidouI still don't understand what a user is supposed to make of "Steam Linux Runtime".

Although I do agree that it is not as useful as it sounds to many people that unfortunately believe the distro fragmentation myth , (the obvious best would be the everything to just work with native runtime) but at least it is way-way better way than the runtime to be bundled with steam by default. It was an obvious blunder that steam is bundled with an 32bit ubuntu 12.04 runtime by default in the first place.

So it is clearly positive.

The best would have been helping the game developers do linux right.

The fragmentation problem is not that a linux executable is not compatible with every distro. This is a myth. The fact is a linux executable work in every gnu/linux.

The real fragmentation problem is that developers do not know what is really supported and what will be depraceted or very depended is specific environment. And I would not blame the developers, the information about linux is scattered.


Last edited by lucinos on 31 October 2020 at 9:13 am UTC
Arten 31 Oct, 2020
Quoting: gradyvuckovic
Quoting: LinasThe whole idea is to give a stable runtime environment to the game developers where you don't need to care about what distribution is the game run on, or that upgrades to the system would break something. It is essentially a Linux compatibility layer for Linux to address the main argument a lot of people have against Linux - fragmentation.

That's how I read it too. Which is awesome, as usual for anything Valve is working on related to Linux. Fragmentation is one of those hard problems with Linux, and this goes right to the heart of addressing it.

I don't think Valve is planning another console. Even Steam Machines weren't really consoles as such, more like prepackaged PCs with a living room tailored experience, like a media center PC.

To me the way I read everything they're doing, it feels like they've taken a step back, looked at the Linux gaming ecosystem, identified every pain point they can find that's preventing adoption and they're just systematically going through each one and trying to either fix it or at least reduce the pain as much as possible. I think they're hoping if they fix enough pain points and wait long enough, eventually organic growth will take off.

The question is why of course. Why do they care. It is possible that perhaps they're just passionately and ideologically supportive of Linux. Or the popular theories of it being a preemptive defensive strategy against any future moves Microsoft might make. Either way, at this point they're putting so much effort into this, it's clearly one of their main goals now, not just a side interest, they're 100% committed to this.

Will it work? Honestly I think it will. But it's definitely going to take a long time.

The analogy I'd use is ... imagine that Linux gaming is like a 100m diameter ball of lead, on a flat plateau of land on top of a hill.

We're been trying to get the ball rolling. Once it does build up speed and start going down the hill, it will become an unstoppable force. We've been trying to get it rolling for years, but it's a 100m diameter ball of lead and we're just a dozen people pushing at the side, having no impact. The stubborn bastard wouldn't shift.

Valve's efforts with Steam, Proton, DXVK, ACO, Pressure Vessel, etc, is like bringing 4 giant trucks up to the top of the hill to help us out, they've strapped them up to the ball and are gunning the engines with the tires screeching. The ball is shifting a little, starting to move, a few inches at least, it's working but it's slow. If they keep at it for the long haul and the tires don't pop, eventually it will build up momentum and it'll work.

If it works, Valve is best positioned to benefit from the success. A new mainstream gaming platform will emerge and Valve will be the centre of it's universe.
preemptive defensive strategy against any future moves Microsoft might make... like Windows 10X? Microsoft want kill win32 apps because they have problem maintain backward compatibility. So Steam can lost main advantige against other stores...
Cybolic 1 Nov, 2020
From what I've understood, the latest Proton version uses this to sandbox the Proton prefix, right? The reason I'm asking is that I've noticed the the sandboxing seems a bit extreme and I can't find a way to edit it. On my system, anything run with Proton 5.13-1 is kept away from accessing mount points that aren't registered as Steam Library locations, making it somewhat difficult to run productivity software when one's files aren't located in $HOME - even symlinks seem to be cut off.
Long story short: Does anyone know how to edit what's made available in these sandboxes?
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: Liberapay or PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.