Support us on Patreon
PayPalCanonical announced some time ago their Steam Snap which was promoted as stable with Ubuntu 23.04, as they continue to push their own packaging format with Snap but it seems this has been causing problems for Valve.
Writing on Mastodon, developer Timothee "TTimo" Besset, who works on various things for Valve posted asking people to consider using the official Valve .deb package or at least consider using the Flatpak:
Valve is seeing an increasing number of bug reports for issues caused by Canonical's repackaging of the Steam client through snap.
The best way to install Steam on Debian and derivative operating systems is to follow the instructions at http://repo.steampowered.com/steam/ and use the official .deb
We are not involved with the snap repackaging. It has a lot of issues.
If you don't want the .deb, please at least consider the flatpak version.
Timothee "TTimo" Besset
So if you've been having various problems with Steam on Ubuntu (or a derivative like Kubuntu), it may be because you've installed it as a Snap. Worth trying out the official .deb or Flatpak to see if it runs better for you. You can also give Canonical feedback in your issues on their Discourse Forum and report issues to Valve on GitHub (if you're using their official packages).
Hopefully Canonical can look into any issues.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
MacabreHeart Jan 17
Quoting: KimyrielleI 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
2 Likes, Who?
rustybroomhandle Jan 17
Oh snap
14 Likes, Who?
slaapliedje Jan 17
Quoting: kerossinI've been running Steam Flatpak on openSUSE Tumbleweed for over a year (maybe 2 years, can't remember) and had no problems.Don't they already support flatpak version of Steam? Isn't that what the Steamdeck uses? (Maybe not, I'd have to look).
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.
1 Likes, Who?
Kimyrielle Jan 17
Quoting: TiZNot 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.
4 Likes, Who?
Quoting: slaapliedjeDon'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.
3 Likes, Who?
Quoting: KimyrielleI 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?
4 Likes, Who?
pleasereadthemanual Jan 17
Quoting: KimyrielleI 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/3671Quoting: TiZNot 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.
2 Likes, Who?
Linux_Rocks Jan 17
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)
(With how cold it's been here lately this GIF is even more fitting than it'd normally be. lol)
0 Likes
ElectricPrism Jan 18
Quoting: TiZQuoting: KimyrielleI 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.
2 Likes, Who?
QuoteValve 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
7 Likes, Who?
See more from me