Canonical 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.
Quoting: Fester_MuddValve could start collaborating with Canonical for the snap package. Also with who creates the flatpak mutually. These packaging formats are the present and future of Linux app packaging.Ultimately I think the best way to go about all of it is to have a mix. It is much more difficult for a distribution (and in this case most are community supported) to have 'official' repositories for the vast majority of software that can be the supported side, and then you have software that needs to be newer, installed via methods like Flatpak. Perfect example of this is Debian. They do not package normal Firefox for their Stable releases. Instead they have Firefox-ESR. If you want current Firefox, use their official flatpak.
AppImage is just not it: they don't integrate with the system, don't have an automatic update by default and they need to be made executable manually (this is already too much for normal users).
This is not that much of a Canonical or a Ubuntu issue though as this same could happen easily with flatpak.
Flatpak cannot handle CLI and server side stuff for the record but snaps can. That said we have managed to narrow the packaging methods kinda to only 2. Snap and flatpak it is. Kind of like MSI and EXE in Windows world, i suppose.
Steam doesn't make much sense to do that, as the steam installer script installs it in the correct places, then sets up all the things in your home directory, and self-updates the bits there.
Quoting: KimyrielleQuoting: 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.
I didn't read the whole comment thread, but let me give you a more specific example: try to play an online match of Unreal Tournament 1999 (on Steam). It will download a few DLLs from the server when connecting, then happily execute whatever code is inside. Remote code execution by design! Great for server-provided mods, isn't it?
As someone wrote above, games are usually not written with security in mind, especially decade-old games. They often connect to the network, and are quite often never updated past release, except maybe to fix game breaking compatibility issues. I believe even Steam is looking into containerizing games (possibly with thermal Linux runtime?), even on Windows.
Quoting: MayeulCOn the bright side of that, this would be ran via Wine, which itself is sort of sanboxed in ways where you'd still have a separate folder structure that particular install is only aware of. So the most that would be trashed is the install directory of that particular game.Quoting: KimyrielleQuoting: 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.
I didn't read the whole comment thread, but let me give you a more specific example: try to play an online match of Unreal Tournament 1999 (on Steam). It will download a few DLLs from the server when connecting, then happily execute whatever code is inside. Remote code execution by design! Great for server-provided mods, isn't it?
As someone wrote above, games are usually not written with security in mind, especially decade-old games. They often connect to the network, and are quite often never updated past release, except maybe to fix game breaking compatibility issues. I believe even Steam is looking into containerizing games (possibly with thermal Linux runtime?), even on Windows.
Could the sandboxing of that be better? Certainly. But can you make it so the rest of your filesystem is invisible to it? Pretty sure you can.
Quoting: slaapliedjeOn the bright side of that, this would be ran via Wine, which itself is sort of sanboxed in ways where you'd still have a separate folder structure that particular install is only aware of. So the most that would be trashed is the install directory of that particular game.I think Proton still maps Z: to / for game prefixes. I would assume Windows malware would happily make a target of that.
Quoting: whizseYeah, what I was saying is it doesn't 'have to'. It's definitely something you can turn off in wine. Might be worthwhile to see if it does and request that it stop.Quoting: slaapliedjeOn the bright side of that, this would be ran via Wine, which itself is sort of sanboxed in ways where you'd still have a separate folder structure that particular install is only aware of. So the most that would be trashed is the install directory of that particular game.I think Proton still maps Z: to / for game prefixes. I would assume Windows malware would happily make a target of that.
See more from me