this post was submitted on 21 Jan 2025
480 points (98.8% liked)
Linux
49217 readers
332 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
No way. Containers are absolutely necessary to provide reliability across a wide range of distros and to keep games working in the future.
Then we need better tooling and documentation to interact with the container, not to get rid of them. I don't see any technical limitation that would prevent your use case. It's just not implemented or maybe simply undocumented.
How so? The end result is probably the opposite. Without the containers Steam would be less reliable on unsupported distros, which might mean your only choice would be to use Ubuntu LTS. That would be a much bigger loss of control.
That's more or less it. Linux Torvalds hates the different package managers and dependencies in different dists and versions of dists. He claims it's virtually impossible to ship products that just run on some random dist and cites his own sideproject which is a sea diving app where he builds binaries for Mac OSX and Windows but can't for Linux. He also praises Valve for using containers.
In theory it means slightly larger binaries, but the flipside it means Steam for Linux runs on a lot more dists, and so do the games and it's far easier to test they actually run.
We are going through more or less Wine anyway, the libraries on the system don't matter as long as Wine compiles
In ideal world it would be pure Wine, with Valve putting merge requests for things they want to change, instead of another EEE that's only waiting to happen. More like AMD interacts with kernel driver. Valve already runs SteamOS, they can use it to have a stable 100% supported platform for their decks etc
One of the core features of containers is process and process memory separation from host. So in case of headtracking (accessing game's shared memory), containerization is directly working against it working. It's not the tooling, it's the choice of what to use
Linux has had
chrootsince a long time if we are really afraid about supporting dwindling native client gamesWe have no control over what they put in those containers. Similar (to put perspective) as we have no control over what Google does in their Gapps (and app developers neither have!), So far we can go inside and inspect what are they running apart from the game's exe directly. Once they disable the
PRESSURE_VESSEL_SHELL=insteadwe will have no insight into what's inside. And the other option - if it doesn't work for some reason (with Wine I don't really see it happening as what we run doesn't rely on our OS libraries directly), you can create chroot, additional library packages with old versions, etc. Worst case scenario, Linux community will figure something outMost games on Steam are proprietary software you don't control to begin with. It seems reasonable to keep them encapsulated in containers (+1 if you run Steam on flatpak or so) rather than granting them the capacity to run amok in the entire system, which we would have even less control over.
It seems contradictory to want to remove barriers that are preventing the software from taking more control, and at the same time complaining about how they are having too much control.
But those are small fries, not "the provider of games"
WDYM?
They have less to loose, then. That's just as dangerous, if not more.
I'm a small fry too, would you run a binary I send you without any form of sandboxing?
No, we typically run them with the same user that stores all our useful private data and that we typically type our passwords with.
Also, why are you OK with that level of sandboxing? don't you want more "control"? You say containers are bad, but using user roles to protect parts of the system is ok? why are you not running all as root if you want "control"?
Not really, by default you have access to other drives (
Z:\being/, the fs root), wine is not a perfect sandbox, it's not designed for that.. and if you actually did want it to become one (which ultimately would also lead to a need for memory separation to fight memory-leak attacks) then it would not be that different from what's being pursued. You'd be essentially building the container in a custom version of wine shipped by Valve on Steam, it does not make any difference in terms of "control".Which wine though?
The one pre-packaged by your distro? That doesn't work because Valve needs to control the version you use and to provide additional stuff not part of vanilla wine.
The one part of proton that is built and delivered to your system by Valve? They would have to compile and support it for every set of dependency versions out there.
As far as container technology is concerned, the isolation is configurable. pressure-vessel is most likely using (possibly indirectly) namespaces and/or cgroups to achieve the isolation. I don't see a technical reason that you can't disable the isolation of shared memory or any other resource. The issue is whether you are given access to disable it.
According to the docs the runtime is based on flatpak and uses bubblewrap and libcapsule. I don't know about libcapsule, but I recall that bubblewrap has granular control over what resources it isolates.
Apparently, you can modify the container as shown here. But there's no reason why you shouldn't be able to install custom containers alongside the default ones in the same way that you can install custom proton versions. Steam just doesn't provide the interface for it.
There already exists an alternative that is "more likely to be extended in future" rather than being removed as shown here. But I believe you would always be able to gain access to the container because it remains a chroot + namespace + cgroup isolation, all of which you can control on your system.
App developers don't control what's on your system either. The container is a huge improvement for them because it at least gives them a known target to build for. They can still bundle dependencies in any way that they would on a non-containerized system. There's no loss of control from their perspective.
That's what pressure-vessel is and as shown above you can modify it. And if you couldn't it would be a tooling issue, not an inherent container disadvantage.
No, they won't. Compatibility significantly increased after Valve got involved. In fact, the linux community is porting pressure-vessel outside of Steam to use it across different launchers as umu. The community is headed towards using pressure-vessel for everything.
Now I replied to each claim individually, but it's not really about any specific point you're making. The general idea is that there's nothing inherent to container technology that prevents you from tinkering with it. Anything that you can't do currently is because Steam is not designed to allow you to do it. It's got nothing to do with whether Steam uses containers or not. Any control that you've lost over your system is because you're using a proprietary app. They could remove the containers and still prevent tinkering, eg by using a bundled wine with no way for you to modify it or its launch options. It's not about what Steam does, but about how it does it.
Most of Proton code is Wine. So basically if you have Wine in your system, library dependencies are not an issue anymore, apart from DLLs that some games require
And that is one of the reasons why I expect them to pull the rug at some point. Why are they doing a fork instead of contributing?
Then why not let us manage Wine runners, like for example Lutris does?
And that is my issue
And that's exactly my gripe. But I expect it will be easier to push back on using containerization in Proton, than making Valve allow us such control
I'm less optimistic. I expect they will in the future make it as hard as possible
That parenthesis was a tangent on Android Google apps, to show what I am afraid will happen in the future. Currently, in order for Android app to appear in the official Store, developer has to allow Google to repackage their app and sign it with Google key. So while we can inspect what is there in the code of the app in git, we don't really know what lands on our phones if installed via Google Play
And as for taking the topic back to game developers, when we are talking about games ran with Proton, their known target is Windows anyway
I couldn't find a way to disable memory separation. And if that's not available, that is an issue with pressure-vessel, not tools
I think that was only because of additional work spent on games. I haven't seen an example where a game would not work at all with Wine but would work with Proton. There are improvements on how it runs, of course. But my argument is that if some implementation in Proton makes a game work better, then it should land in mainline Wine
Yes. But "please, don't fuck us up" is not something we can enforce
We can always just go back to running Windows version of whole Steam via Wine, as we were doing before Proton
You can still open an APK and decompile it.. it being signed with a specific key is no different than the digital signatures some attach to their emails, it's a way to prove authenticity, not a way to encrypt the message.. you can open the email without having to even care about the signature.
If I have wine on my system and try to run steam-managed proton without any sort of runtime or container, then I'm running proton on different versions of libraries than the ones it was compiled for and tested on. Proton also has additional components which might mean additional dependencies, so your statement is false to begin with.
The fork is open source. As far as I know, some contributions do get merged into wine. Valve is also funding work from Collabora which is contributed directly into wine. They cannot contribute the entirety of proton to wine because wine does not want all their contributions. This is a very common situation to arise when someone wants to use an open source project but their goals don't align.
Valve is never going to rip out a solution that is working great for them and risk causing issues for customers for no good reason. Thinking that Valve are more likely to remove containerization than they are to allow you to modify the container is, frankly, delusional. It's also completely irrelevant, as I've already said. If Valve wants to "fuck us up" then they're going to do it. Steam is a proprietary piece of software that supports DRM for all your (also proprietary) games, which are stored on the cloud. You have no control over your games, but containers have nothing to do with it. And if they did, and Valve really wanted to pull a trick on us, asking them to remove the containers would make even less sense...
We are slowly getting to the end of my depth in Wine. But in all the years of watching various Wine bugs and enhancements, I have never seen something blocked by the version of library or because some OS does not have, for example, current standard library updated. Kernel version, sure, but that's much less a compatibility problem. Hence, as long as Wine compiled and is available on your system, from the game perspective, the only libs you have to worry about are Windows DLLs or Wine built-ins of those
For now. I'm sure they would love to get into the position that console companies and Microsoft with its DirectX had. "You want to ensure your game works on the new gen? Here's the paywalled support for our closed-source thing".
If they haven't started already, I expect them to come up with their own, closed sourced implementation in a few years/when they gain enough market
Boycotting their containerization might be doable. Forcing them to make their containerization configurable much less so