Check out our Monthly Survey Page to see what our users are running.

Linux Format issue 267 went out today (not affiliated) and in it there's a rather wonderful interview with Simon McVittie, a software engineer at Collabora who also works on things for Valve to do with Steam on Linux.

In the latest interview, McVittie talks a little about all the work they do including being a Debian contributor and for GNOME too. If you're interested in learning more about the people working behind the scenes, it's quite an interesting interview. Especially so, if you're a Linux gamer. McVittie has also been working on Pressure Vessel, a container system for Steam on Linux to run games inside and hopefully ensure they work pretty much everywhere. For regular readers here at GOL, this hopefully won't be brand new news, as we've written about it a few times (#1, #2) before.

Here's just a small teaser slice of the interview:

Part of the idea is that a game developer can do their QA against Pressure Vessel, which is a really quite strict system. If it works on that then it’s much more likely to work everywhere. Whereas if they did their QA on the Steam runtime with, say, the latest Ubuntu LTS, will it work on Arch Linux? Who can say? Will it work on older Ubuntu? It might, but probably won’t though. Having a giant test matrix of all the distributions isn’t really feasible. So now, of course, we have a giant test matrix for Pressure Vessel on all the distributions, but at least we only have to do that once.

Simon McVittie, Linux Format issue 267

Want to read the whole interview? You can read just that interview here on Scribd, or buy a full copy of Linux Format issue 267 over here.

The whole idea behind Pressure Vessel is great! Giving developers a properly stable environment to QA their Linux builds and just as importantly it gives users a container to put games in to ensure they work on whatever distribution they happen to have hopped on over to.

Want to try out the container system? It works with Linux builds on Steam. Right click on a game in your Steam Library, go to Properties and at the bottom look for the Steam Play section. Remember, Steam Play is just a feature of Steam to run other things inside (like the Wine fork Proton, Roberta, Boxtron and so on). In the drop-down box, simply pick "Steam Linux Runtime" for the container like so:

Handy tip: if a game releases a Linux version, which you previously used Proton for, selecting this container can help things reset so you get the Linux version downloaded. I've seen a few people stuck with that at times.

If you do have issues, you can report them to Valve's GitHub tracker.

Article taken from GamingOnLinux.com.
39 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. 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
23 comments
Page: «2/3»
  Go to:

t3g 27 Aug
Quoting: mphuZ
Quoting: gardotd426So this sounds like it's only possible for native games, too bad.
It's not bad. The main goal is to switch to native games. Proton is only a temporary workaround.

I've been gaming on Linux since 2014 and unfortunately Proton is the future of gaming on the platform. We are seeing fewer native releases and the ones we do have run better in Proton. They run better because the native port is not updated, while Wine/Proton is constantly moving forward and fixing issues.

Off the top of my head, Dying Light, Life is Strange, and Metro 2033 now run better in Proton vs their native versions.


Last edited by t3g on 27 August 2020 at 3:14 pm UTC
mirv 27 Aug
View PC info
  • Supporter Plus
Quoting: t3g
Quoting: mphuZ
Quoting: gardotd426So this sounds like it's only possible for native games, too bad.
It's not bad. The main goal is to switch to native games. Proton is only a temporary workaround.

I've been gaming on Linux since 2014 and unfortunately Proton is the future of gaming on the platform. We are seeing fewer native releases and the ones we do have run better in Proton. They run better because the native port is not updated, while Wine/Proton is constantly moving forward and fixing issues.

Off the top of my head, Dying Light, Life is Strange, and Metro 2033 now run better in Proton vs their native versions.

I'll admit I'm a little bit sad if people think that "Proton" is the future of gaming on a GNU/Linux system. Maybe it will be, but that's (in my opinion) bad for several reasons:
  • The games are predominantly written for Windows. Tested on Windows. Supported on Windows. Any of this "Proton" based gaming is therefore, by definition, playing continual catchup on Windows.

  • Microsoft are in control, and quite happily modify anything that want that will end up making it nigh impossible to run these games on a GNU/Linux system.

  • Microsoft are in control. And I'm sure they're more than happy to remain that way, seeing as they're buying up ways of controlling Linux in general anyway, but that's not good for users (hopefully I don't need to go into details of why).

  • The main reason that "Proton" is gaining such traction is arguably actually DXVK. Other patches aside, that's the core element making the games run as well as they are - and that's ultimately going to mean DX11 on older titles. Ideally we'd rather developers directly using Vulkan, not using something else and trying to cludge it on top of Vulkan (again, hopefully I shouldn't need to go into details why).

  • I'll make a point about wine being a better target. Like it or not, even though it's open sourced, "Proton" is still very much tied to Steam. Valve are in control, via a proprietary client, of your ability to choose and play the games you want. I'm not saying Valve is being evil (they're not), but I am saying that developers relying on Valve and Steam isn't a good situation for GNU/Linux gaming. Native versions, or even easier packaging of vanilla wine, would allow an easier time with other stores such as itch.io, gog.com, and more ability for open source and innovative game management clients to be developed.


I'd rather have wine, and "Proton", be another tool in the chest. The future of old games maybe, but not the future of games. And I'm very, very concerned if it actually is.
Gryxx 27 Aug
Quoting: mirv
Quoting: t3g
Quoting: mphuZ
Quoting: gardotd426So this sounds like it's only possible for native games, too bad.
It's not bad. The main goal is to switch to native games. Proton is only a temporary workaround.

I've been gaming on Linux since 2014 and unfortunately Proton is the future of gaming on the platform. We are seeing fewer native releases and the ones we do have run better in Proton. They run better because the native port is not updated, while Wine/Proton is constantly moving forward and fixing issues.

Off the top of my head, Dying Light, Life is Strange, and Metro 2033 now run better in Proton vs their native versions.

I'll admit I'm a little bit sad if people think that "Proton" is the future of gaming on a GNU/Linux system. Maybe it will be, but that's (in my opinion) bad for several reasons:
  • The games are predominantly written for Windows. Tested on Windows. Supported on Windows. Any of this "Proton" based gaming is therefore, by definition, playing continual catchup on Windows.

  • Microsoft are in control, and quite happily modify anything that want that will end up making it nigh impossible to run these games on a GNU/Linux system.

  • Microsoft are in control. And I'm sure they're more than happy to remain that way, seeing as they're buying up ways of controlling Linux in general anyway, but that's not good for users (hopefully I don't need to go into details of why).

  • The main reason that "Proton" is gaining such traction is arguably actually DXVK. Other patches aside, that's the core element making the games run as well as they are - and that's ultimately going to mean DX11 on older titles. Ideally we'd rather developers directly using Vulkan, not using something else and trying to cludge it on top of Vulkan (again, hopefully I shouldn't need to go into details why).

  • I'll make a point about wine being a better target. Like it or not, even though it's open sourced, "Proton" is still very much tied to Steam. Valve are in control, via a proprietary client, of your ability to choose and play the games you want. I'm not saying Valve is being evil (they're not), but I am saying that developers relying on Valve and Steam isn't a good situation for GNU/Linux gaming. Native versions, or even easier packaging of vanilla wine, would allow an easier time with other stores such as itch.io, gog.com, and more ability for open source and innovative game management clients to be developed.


I'd rather have wine, and "Proton", be another tool in the chest. The future of old games maybe, but not the future of games. And I'm very, very concerned if it actually is.

I agree with your arguments. I disagree with "The future of old games maybe, but not the future of games.". What we, as a community, need is larger player base. Without that there is no way we will have "mainstream support". At least for near future Proton will be essential to Linux gaming. Sure, it would be nice to overthrow DX, Windows and all that proprietary crap. Thing is- i don't think we can. Or at least not now.
mirv 27 Aug
View PC info
  • Supporter Plus
Quoting: GryxxI agree with your arguments. I disagree with "The future of old games maybe, but not the future of games.". What we, as a community, need is larger player base. Without that there is no way we will have "mainstream support". At least for near future Proton will be essential to Linux gaming. Sure, it would be nice to overthrow DX, Windows and all that proprietary crap. Thing is- i don't think we can. Or at least not now.

Ironically, I've wondered if one of the better ways to introduce more people to GNU/Linux was showcasing those older games that work flawlessly through wine, but that don't work with Windows anymore. I mean why not - after all, GOG made an entire business around getting older games to work on a modern version of Windows.

I will say that my own concerns are very much not shared by many: I worry that in an effort to increase usage of GNU/Linux, then the GNU part of that is forgotten about. I want more gaming available to GNU/Linux, but not by sacrificing development freedoms. I'd rather not see gaming increase if that were the cost.
(Yes, of course, if it were the case that all gaming was native, I would be one of those then arguing for all games to be open sourced once they reach a certain point.)

This is actually why I think Stadia is just as important ultimately, because one of the few ways I see wine (or "Proton") helping is if more games use Vulkan. If they could then do that on Windows versions, then wine becomes are relatively minor (audio and networking aside) shim layer, and this Collabora work then makes it an even smaller step to a fully native version that will run hassle-free for a long time.

....and I'm ranting a bit I suppose. Guess I'm passionate on the subject, sorry about that! Whatever concerns I have though, "Proton" is here to stay and we'll see how it all works out going forward.
View PC info
  • Supporter
Quoting: F.Ultra
Quoting: pentarctagonGetting the contents of the container updated is still a bit of a problem though. For example: https://github.com/ValveSoftware/steam-runtime/issues/55

Well that is the nature of being a container, the whole idea is that everything in it remains unchanged. Upgrading gcc for C++ will just break things as the ABI changes when you do that.

Not being able to have a container that has more up to date dependencies available means it will become progressively less useful though. Over at Battle for Wesnoth for example, the steam runtime makes it a lot easier in that it means most dependencies can be consistently provided by the runtime, but being stuck at gcc 5 means means it only supports up to C++14.
gardotd426 27 Aug
Quoting: wintermuteProton games already run in a similar container, that's why this works the same way as selecting a different Proton runtime.

The type of containerization isn't really the same, though.

I never said it would be as or more useful if it was available for Proton vs Native, but it would still be useful.
gardotd426 27 Aug
QuoteIronically, I've wondered if one of the better ways to introduce more people to GNU/Linux was showcasing those older games that work flawlessly through wine, but that don't work with Windows anymore. I mean why not - after all, GOG made an entire business around getting older games to work on a modern version of Windows.

No... not really.

For one thing, it is true that some older games run better on Linux than on Windows, but it's also true that others run on Windows and don't run on Linux at all. It's not remotely "all old Windows games run on Linux and not Windows," nor is it true that "all old games run better on Linux than on Windows."

But more importantly, the size of people that would care about that enough to switch is effectively zero (not 0.0, as in not a single person, but 0 as in not any statistically significant number of people). You bring up GoG. Sure, GoG isn't unpopular, but it's also not at all huge, but even if it were, you're making a false analogy. Practically no one playing GoG ONLY uses GoG. They're also going to be using Steam, Origin, Battle.net, Uplay, EGS, etc. Almost all of them are going to be using Steam, specifically. So the fact that Linux might do well with old titles is going to mean absolutely nothing to any of those people, or at most, it will mean something, but **definitely** not enough to switch.

See, it's a false analogy because with GoG you don't have to choose to only use GoG. It's not an either/or. But with Linux and Windows, it is. Yes you can dual-boot, but that's not what we're talking about here. People willing to dual-boot can switch to Linux already with no issues. But you can't use two operating systems at the same time to play games (again, in THIS context. Obviously VFIO doesn't count here).

Seriously, even if we completely showcased how well Linux did with older titles (and hell, even add old console/arcade emulation to that), the number of people that might be persuaded to switch is literally not likely to surpass a couple thousand.

All of our growth the past couple years (in terms of gaming users) is because of Proton. Yes, that also means by extension that Wine is owed all the accolades, but that's not the context in which I mean "because of." Proton is the solution to the chicken and the egg problem, and until we can gain more market share, we literally have no other choice.

Quoting: mirvI will say that my own concerns are very much not shared by many: I worry that in an effort to increase usage of GNU/Linux, then the GNU part of that is forgotten about. I want more gaming available to GNU/Linux, but not by sacrificing development freedoms. I'd rather not see gaming increase if that were the cost.

There are no developer freedoms being sacrificed. Linux would have to become a closed platform (which is practically impossible) for that to ever happen. I'm a bit confused as to how you think this effects freedom at all. And yes, Steam is a company, and the Steam client is proprietary, but PROTON is open source.
F.Ultra 28 Aug
Quoting: pentarctagon
Quoting: F.Ultra
Quoting: pentarctagonGetting the contents of the container updated is still a bit of a problem though. For example: https://github.com/ValveSoftware/steam-runtime/issues/55

Well that is the nature of being a container, the whole idea is that everything in it remains unchanged. Upgrading gcc for C++ will just break things as the ABI changes when you do that.

Not being able to have a container that has more up to date dependencies available means it will become progressively less useful though. Over at Battle for Wesnoth for example, the steam runtime makes it a lot easier in that it means most dependencies can be consistently provided by the runtime, but being stuck at gcc 5 means means it only supports up to C++14.

Yes but that is about creating a new container and not updating an existing container which is how I interpreted the issue on github. Then there is the problem that you don't want to create 1 million containers either since then we are back to square one again.
mirv 28 Aug
View PC info
  • Supporter Plus
Quoting: gardotd426
(snipped to keep things smaller)
I didn't suggest it would make people switch, or that running some old games alone would be enough to make people swap over. I said introduce, as in "hey, look at one of the nice things that can be done". An inducement to give GNU/Linux a try.

Quoting: gardotd426There are no developer freedoms being sacrificed. Linux would have to become a closed platform (which is practically impossible) for that to ever happen. I'm a bit confused as to how you think this effects freedom at all. And yes, Steam is a company, and the Steam client is proprietary, but PROTON is open source.

You say that, and yet so many games are closed, on a closed gaming client, nvidia people effectively stuck with closed drivers, Stadia development targeting closed AMD drivers, and there being some grumblings about possible easy anti-cheat injecting into the kernel, full root permissions, to function.
I think that's enough to be concerned about where things are headed.

-- edit, gone completely off topic, I'll stop here.


Last edited by mirv on 28 August 2020 at 12:26 am UTC
gardotd426 28 Aug
Quoting: mirvYou say that, and yet so many games are closed, on a closed gaming client

That's how the PC gaming industry has always been, and native Linux games are proprietary too (outside of the obvious STK and Xonotic, etc).

And again, that's still not limiting developer freedom. They can create as many open source games as they want, and release them on an open platform. It's not remotely limiting.

Quoting: mirvStadia development targeting closed AMD drivers

Stadia uses AMDVLK. AMDVLK is open-source, not proprietary. vulkan-amdgpu-pro is the proprietary AMD-developed Vulkan driver. AMDVLK is the open-source AMD-developed Vulkan driver. And Stadia uses AMDVLK, which Phoronix just mentioned (though they goofed super hard when they did it), when they mentioned AMDVLK just recently getting a fix for Ghost Recon Wildlands.

Quoting: mirvthere being some grumblings about possible easy anti-cheat injecting into the kernel, full root permissions, to function

Nope. Well, not from anyone who knows what they're talking about. Wine-EAC has no kernel-level anything whatsoever, there are no root permissions involved whatsoever, and everything is in user-space, by necessity, as a kernel driver is pretty much impossible (in every practical manner) in Linux (and I'm pretty sure Wine would never allow it anyway).

I've spent a ton of time in the discord where Wine-EAC development and testing was discussed (and will be discussed again when it restarts) and there's no talk whatsoever of anything running with root permissions or at kernel-level. That's not a thing.

This is what happens when you have a community that is so obsessed with FUD and outrage culture.
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. 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!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.