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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: GuestQuoting: t3gQuoting: mphuZQuoting: 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.
1 Likes, Who?
pentarctagon Aug 27, 2020
Quoting: F.UltraQuoting: 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.
0 Likes
gardotd426 Aug 27, 2020
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.
0 Likes
gardotd426 Aug 27, 2020
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: GuestI 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.
1 Likes, Who?
Quoting: pentarctagonQuoting: F.UltraQuoting: 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.
0 Likes
gardotd426 Aug 28, 2020
Quoting: GuestYou 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: GuestStadia 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: Guestthere 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.
1 Likes, Who?
pentarctagon Aug 28, 2020
Quoting: F.UltraQuoting: pentarctagonQuoting: F.UltraQuoting: 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.
Not really; there's a large gap between "one more" and "1 million". Beyond that though, if for whatever reason Valve is not able to provide any more containers with updated software, then the use of the containers shouldn't be something that's encouraged for future use since they will only become more outdated and less useful.
0 Likes
Quoting: t3gI've been gaming on Linux since 2014How long you've been doing doesn't really mean anything. Things change all the time, nothing is set on stone. I've been running GOL for 10 years, but running and gaming on Linux for longer. Does that mean what I say holds more value or what I say/think is what will happen? God no.
Quoting: t3gProton is the future of gaming on the platformProton is a stepping stone, not the future and not the future people should want either. For a lot of the reasons mirv outlined in his comment. To add into that though, it really does just push Windows development practises further and developers don't need to care about Vulkan either for it. It does nothing but keep us in a catch up loop.
Quoting: t3gOff the top of my head, Dying Light, Life is Strange, and Metro 2033 now run better in Proton vs their native versions.We're talking about games released before Proton, some like a good 4 years. This is why I often find these comparisons completely ridiculous, as you're comparing things made multiple years ago with what they had at the time versus Vulkan. It's a valid comparison on how things are now and can be, but not on "why" Proton, because as we've seen plenty of times Linux versions can perform perfectly well and as a result developers get more experience, more cross-platform support in their games and engines and so on...you get the idea.
0 Likes
Quoting: pentarctagonQuoting: F.UltraQuoting: pentarctagonQuoting: F.UltraQuoting: 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.
Not really; there's a large gap between "one more" and "1 million". Beyond that though, if for whatever reason Valve is not able to provide any more containers with updated software, then the use of the containers shouldn't be something that's encouraged for future use since they will only become more outdated and less useful.
Of course there is a large gap between 1 and 1 million, I only used that number to describe the extreme outcome. I'm quite sure that they will release a new updated container later once they are out of beta so to speak, but then of course we are talking about Valve so it might not happen also...
0 Likes
Patreon
PayPal
See more from me