Valve seeing increasing bug reports due to Steam Snap - other methods recommended

Same for Discord with high CPU usage and log cluttering, same for Firefox unable to open html files located in /usr/local or extensions that stop working (VideoDownloadHelper). And I'm not talking about slightly longer load times... Snap is more trouble than it's worth.

Snap is a gift that just keeps on giving.

I already uninstalled snap version of Steam as it was broken beyond repair. Many games and launchers are broken with it, including all of the Paradox games.

I've been running Steam Flatpak on openSUSE Tumbleweed for over a year (maybe 2 years, can't remember) and had no problems.

Would be great if Valve would officially support Steam Flatpak, it would cover a lot more distros than just the Debian family but I believe it wouldn't be that much more work since it uses specific versions of Flatpak runtimes.

Edit: Also, funny how they hired more devs to work on Snap support in other distros while their own doesn't work properly yet.


Last edited by kerossin on 17 January 2024 at 6:25 pm UTC

I am thinking of a really compelling reason to containerize Steam and can't come up with one...

On my Trisquel system I had success using the Flatpak for Steam. I would never use a Snap of anything myself.

I think it's worth sharing the opinions of Canonical and Valve here. The snap package format itself does look quite promising, given that it is already more suitable for IDE than flatpak, suitable for server deployments and used to deliver updates in Ubuntu Pro subscriptions.
A lot of work has also been done to make it even more suitable for GUI applications. For example, Firefox works with the integration of GNOME extensions, unlike the flatpak version.

Please also note that practically all STS releases have been partly experimental, so Steam is offered there in snap format.
And finally, it is Canonical itself that monitors this client and does not hide it. If many complain specifically to Valve that the snap client does not work well, then the problem is precisely the misunderstanding by users, and not that "snap is bad." This would be true for flatpak if it had a similar problem.

Disclaimer: An active Ubuntu fan since 2017 :)

I tried snap once, because a demo of a game I was interested in came as a snap package.
It crashed and rebooted my whole system.


Last edited by pb on 17 January 2024 at 9:03 pm UTC

I am thinking of a really compelling reason to containerize Steam and can't come up with one...

Not even one? I have an easy one. First, Steam is proprietary. Valve does do a lot of great FOSS work, and they are generally trustworthy, but Steam itself is still proprietary at the end of the day. And it has made catastrophic mistakes before. Containerizing it limits the scope of the damage it can possibly do.

That's not it, either. I have about... 800+ additional reasons, at least in my Steam library. A whole litany of proprietary, closed-source games. Only a fraction of them are native, and would have hypothetically unfettered access to the whole filesystem when unsandboxed, but that's enough to prefer to be safe rather than sorry. Steam does have its own container runtimes, Soldier and Sniper, but most native binaries don't use them. Proton is their main consumer, actually.

But containerization isn't just about sandboxing. It's about smoothing over the differences between distros that can randomly break applications. Providing libraries that are consistent and compatible across all base distros. You can even have glibc in a musl distro. The custom set of libraries provided by your base distro are a good thing for your system apps and desktop environment, but not so good for binary-only applications. By containerizing Steam, you can give it the consistent, stable libraries that it wants for its games, while letting your system apps and desktop environment continue to take advantage of your base distro's custom libraries. Because of this, more than anything else, Flathub's Steam package is more likely to work than whatever your base distro is doing to adapt the .deb provided by Valve.


Last edited by TiZ on 17 January 2024 at 7:43 pm UTC

I am thinking of a really compelling reason to containerize Steam and can't come up with one...

The flatpak at least simplifies the story around the 32-bit libs steam still uses and updsting the rest of the system in a timely and non-breaking fashion. Fedora blocked my system update several times because of the steam required libs not matching what the repos had. And while less useful for Arch in that sense it did help me debug a couple of issues i was having with my controller

Oh snap

I've been running Steam Flatpak on openSUSE Tumbleweed for over a year (maybe 2 years, can't remember) and had no problems.

Would be great if Valve would officially support Steam Flatpak, it would cover a lot more distros than just the Debian family but I believe it wouldn't be that much more work since it uses specific versions of Flatpak runtimes.

Edit: Also, funny how they hired more devs to work on Snap support in other distros while their own doesn't work properly yet.

Don't they already support flatpak version of Steam? Isn't that what the Steamdeck uses? (Maybe not, I'd have to look).

Not even one? I have an easy one. First, Steam is proprietary. Valve does do a lot of great FOSS work, and they are generally trustworthy, but Steam itself is still proprietary at the end of the day. And it has made catastrophic mistakes before. Containerizing it limits the scope of the damage it can possibly do.

That's not it, either. I have about... 800+ additional reasons, at least in my Steam library. A whole litany of proprietary, closed-source games. Only a fraction of them are native, and would have hypothetically unfettered access to the whole filesystem when unsandboxed, but that's enough to prefer to be safe rather than sorry. Steam does have its own container runtimes, Soldier and Sniper, but most native binaries don't use them. Proton is their main consumer, actually.

I love open source software as much as anyone, but let's be real here. There are plenty of super serious bugs in OSS applications, too. Saying that anything proprietary is untrustworthy by design is a bit over the top. With your logic, you'd need to containerize EVERYTHING, and the result of this would be a a fairly unproductive and ineffective system. I get containerization for high-risk applications (yes, like the internet browser), but locking software from trustworthy vendors inside a container is a bit much on the paranoid side.

Don't they already support flatpak version of Steam? Isn't that what the Steamdeck uses? (Maybe not, I'd have to look).

Flatpak Steam is also unsupported.

The Deck doesn't use flatpak Steam.

I am thinking of a really compelling reason to containerize Steam and can't come up with one...

Beyond what's already been pointed out, how about not getting most of your drive wiped out?

Not even one? I have an easy one. First, Steam is proprietary. Valve does do a lot of great FOSS work, and they are generally trustworthy, but Steam itself is still proprietary at the end of the day. And it has made catastrophic mistakes before. Containerizing it limits the scope of the damage it can possibly do.

That's not it, either. I have about... 800+ additional reasons, at least in my Steam library. A whole litany of proprietary, closed-source games. Only a fraction of them are native, and would have hypothetically unfettered access to the whole filesystem when unsandboxed, but that's enough to prefer to be safe rather than sorry. Steam does have its own container runtimes, Soldier and Sniper, but most native binaries don't use them. Proton is their main consumer, actually.

I love open source software as much as anyone, but let's be real here. There are plenty of super serious bugs in OSS applications, too. Saying that anything proprietary is untrustworthy by design is a bit over the top. With your logic, you'd need to containerize EVERYTHING, and the result of this would be a a fairly unproductive and ineffective system. I get containerization for high-risk applications (yes, like the internet browser), but locking software from trustworthy vendors inside a container is a bit much on the paranoid side.

I don't really have a horse in this race, but I think TiZ is referring to the time Steam wiped everything on the user's drive: https://github.com/ValveSoftware/steam-for-linux/issues/3671

It also doesn't help much that the Steam client itself is a shitshow even when you install it correctly.



(With how cold it's been here lately this GIF is even more fitting than it'd normally be. lol)

I am thinking of a really compelling reason to containerize Steam and can't come up with one...

Not even one? I have an easy one. First, Steam is proprietary. [..] That's not it, either. I have about... 800+ additional reasons, at least in my Steam library. A whole litany of proprietary, closed-source games. Only a fraction of them are native, and would have hypothetically unfettered access to the whole filesystem when unsandboxed, but that's enough to prefer to be safe rather than sorry.

100% this. "anti-cheats" *cough* *cough* kErNeL r00tk1Ts -- for now I have completely separate machines for Linux Gaming vs Desktop, and the Steam Deck does a great job Appliancizing and air gapping proprietary access by who knows which panaroid schitzo government to our machines.

Anyways, steam is a saint but there is a big difference between the store(s) and the publisher(s) in terms of ethos, ethics, and vision -- not all of them share the opinion that consumers are people or have human rights to privacy or dignity.

Valve posted asking people to consider using the official Valve .deb package

Please, please, please, please not!
I'm reading nearly every thread in the Steam for Linux forum, and we hear problems from people having used the downloadable deb for over a decade now! People should use what their distribution made of it, adding their dependencies and such. I cannot believe Valve proposes to actually use that!


Last edited by Eike on 18 January 2024 at 12:45 pm UTC