Linux Format has a Collabora dev talk about Steam's Linux container 'Pressure Vessel'

Getting the contents of the container updated is still a bit of a problem though. For example: https://github.com/ValveSoftware/steam-runtime/issues/55

So this sounds like it's only possible for native games, too bad.

So 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.

So this sounds like it's only possible for native games, too bad.

Seems to me it's not so much only possible for native games as only relevant for native games. I mean, how/why would someone developing for Windows and not Linux, care what Linux environment they weren't developing for?

"Yeah, before it was tough because we weren't targeting the whole range of different Linux distributions and environments. But now, we can simply not target Valve's 'Pressure Vessel', it saves a huge amount of not-work and non-effort!"

So 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.

Proton is a temporary workaround until we actually start getting native games. That's not happening yet. So Proton is still VERY much needed.

So this sounds like it's only possible for native games, too bad.

Seems to me it's not so much only possible for native games as only relevant for native games. I mean, how/why would someone developing for Windows and not Linux, care what Linux environment they weren't developing for?

"Yeah, before it was tough because we weren't targeting the whole range of different Linux distributions and environments. But now, we can simply not target Valve's 'Pressure Vessel', it saves a huge amount of not-work and non-effort!"

Um.... they wouldn't. Did you miss this part of the article?

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.

It's just as important for users, too. And I never mentioned devs.

So this sounds like it's only possible for native games, too bad.

Makes little sense otherwise, since wine/proton is a runtime by itself.
if you have trouble with an updated proton, switch to the previous.

So this sounds like it's only possible for native games, too bad.

Proton games already run in a similar container, that's why this works the same way as selecting a different Proton runtime.

Getting 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.

So 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

So 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.

Getting 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.

Proton 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.

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.

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.

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.

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.

Getting 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.

You 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.

Stadia 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.

there 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.

Getting 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.

I've been gaming on Linux since 2014

How 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.

Proton is the future of gaming on the platform

Proton 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.

Off 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.

Getting 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...