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 https://github.com/ValveSoftware/steam-for-linux/#getting-started 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.

#steam #ubuntu #snap #flatpak

GitHub - ValveSoftware/steam-for-linux: Issue tracking for the Steam for Linux beta client

Issue tracking for the Steam for Linux beta client - ValveSoftware/steam-for-linux

GitHub
@TTimo Is the Flatpak version considered to work fine or on par with the .deb version?
@SheepZone it's not officially supported either, but I hear it fares much better. Last time we looked at it there were concerns about performance overhead in some situations.
@SheepZone oh and if you want to do VR it's probably no good either
Hey @TTimo, volunteer for Flathub here. Do you happen to recall the concerns or have a link discussing them that I can share with the Flatpak and Flathub teams? It would be great to learn if/where the tech falls short to see if we could remedy it. :)
@cassidy we haven't revisited this in quite a while, but the performance overhead of the seccomp layer was a concern: https://github.com/flatpak/flatpak/issues/4187
Performance impact of seccomp filter in games · Issue #4187 · flatpak/flatpak

Linux distribution and version Fedora 33 Flatpak version 1.10.2 Description of the problem Most of the time performance impact of seccomp filter in games/apps not negligible and not relevant. But i...

GitHub

@TTimo @cassidy Much like one of the later comments in that bug report, I wonder how much of that is Linux 4.17 through 5.15 turning on an expensive Spectre mitigation by default when seccomp is used. Consensus seems to be that the mitigation isn't actually helping in practice, and Linux stopped doing it: https://github.com/torvalds/linux/commit/2f46993d83ff4abb310e

I notice that that bug report was with Fedora 33, which would be affected; Fedora ≥36 wouldn't be. For Ubuntu, 20.04 (and 18.04.5) would be affected but not 22.04.

It's possible to opt out, but the software that applies the filter (Flatpak and Snap in this case) would have to do it.

x86: change default to spec_store_bypass_disable=prctl spectre_v2_use… · torvalds/linux@2f46993

…r=prctl Switch the kernel default of SSBD and STIBP to the ones with CONFIG_SECCOMP=n (i.e. spec_store_bypass_disable=prctl spectre_v2_user=prctl) even if CONFIG_SECCOMP=y. Several motivations l...

GitHub
@cassidy @TTimo not to be a troll or to act entitled to open source volunteers in any way (I am myself an unpaid OSS volunteer), but there's been a bug with nvidia driver reinstallation for 3 1/2 years that seems never to get fixed + renders it unusable for me.

https://github.com/flatpak/flatpak/issues/3750
https://github.com/flatpak/flatpak/issues/5261
(there are many, many, many other reports)

(I have tried all suggestions btw nothing works)

I also had flatpak ironically break gtk for me when I tried to uninstall it, as a result of both of these things I won't be using flatpak for anything, let alone steam.

So can't say I'm hugely convinced that flatpak is a great alternative.

I btw obviously realise this might be:

a. an nvidia thing that flatpak can't do anything about
b. a(n arch linux) packaging problem flatpak (ironically for software designed to solve this problem) can't do anything about

BUT in practical terms it makes flatpak simply non-viable for me.
Flatpak downloads every nvidia driver from flathub at every update · Issue #3750 · flatpak/flatpak

Linux distribution and version Ubuntu 20.04 Flatpak version 1.6.3 Description of the problem Every time a new nvidia driver gets released I need to update the flatpaks and this already slow process...

GitHub

@ljs @TTimo my understanding is that folks are aware of that issue but it's tricky because it deals with NVIDIA's proprietary drivers and it requires NVIDIA hardware for testing. The upstream issue looks to be this: https://github.com/flathub/org.freedesktop.Platform.GL.nvidia/issues/42

That said, it sounds inconvenient—not unusable? But I could be missing something here.

Flatpak downloads every nvidia driver from flathub at every update · Issue #42 · flathub/org.freedesktop.Platform.GL.nvidia

Issue moved from here: flatpak/flatpak#3750 Linux distribution and version Ubuntu 20.04 Flatpak version 1.6.3 Description of the problem Every time a new nvidia driver gets released I need to updat...

GitHub
@cassidy @TTimo

Thanks for the link, I think the number of report speak to how common this issue is.

It's completely unusable, it's an O(n^2) * 100's of megabytes where n is the number of releases since flatpak was installed.

Everytime the nvidia drivers get updated flatpak steam dies and I have to do this again.

I'm confused as to why hardware would be required for testing other than flatpak guys don't have the nvidia hw I guess? I wonder whether logs could be got from people who do have.

For a bug from 2020 that is really (and google around) enormously frustrating it seems like flatpak people don't seem overly bothered which is... something.

From my point of view, I will never use flatpak for anything. Because if it's this bad for steam, and flatpak devs seem uninterested, how will it be for lesser known software?

I have no ill-will towards well intentioned flat pak people, it's the ones who loudly talk about how the world should move to flat pack that get my ire as much as those who claim snap is the way do.

I've been using native steam ever since and it's worked flawlessly across kernel/nvidia driver/system updates with zero effort.

Again, this isn't meant to be a troll or mean towards you or anybody else, but rather something flatpak needs to get better at.

@ljs @TTimo fwiw steam definitely does seem to be more of an edge case in flatpak. there's definitely way more energy going into improving the sandboxing, portals, and flathub itself for more "typical" apps (steam kinda has to bypass a lot of the security features anyways for many games?).

that being said, it seems like a pretty stupid bug :/

maybe @gnome @kde would be interested in doing a bug bounty for this (and maybe also to improve some of the other related nvidia/flatpak issues?).

@cassidy know anyone who might be up for organising something like that?

https://github.com/flathub/org.freedesktop.Platform.GL.nvidia/issues/42

Flatpak downloads every nvidia driver from flathub at every update · Issue #42 · flathub/org.freedesktop.Platform.GL.nvidia

Issue moved from here: flatpak/flatpak#3750 Linux distribution and version Ubuntu 20.04 Flatpak version 1.6.3 Description of the problem Every time a new nvidia driver gets released I need to updat...

GitHub
@cas @ljs @TTimo @gnome @kde @cassidy Maybe also @jorge because of ublue using Flatpak as the primary app delivery platform and ublue+nvidia being a standard image they ship?

@TTimo That's the way I installed steam on my debian 12, but now I'm considering flatpak. Lego Bricktales, for example, crashes randomly and I think it has to do with differences in debian libraries. Ii seems some games are only tested on ubuntu

Actually I followed instructions on debian's wiki. I'll try these later

@TTimo This has affected people internally too. I had to spend far too long trying to figure out why SteamVR was not working for someone, turns out they were using the Snap which is the default on the store + apt!

Ubuntu forwarding apt -> snap for certain package names is prime what-the-fuck-ery and actively hostile design.
@frog @TTimo make steam detect snap and error out 🐸
@riesi @TTimo I suggested that years ago.
@frog @riesi @TTimo but then you'd be infringing on Mark Shuttleworth's fates-given right to force Canonical tech on users who don't want it.
@root @riesi @TTimo There is a lot to be said about "powers that be" in the Linux space forcing new tech on those who it does nothing but harm.

@frog @riesi @TTimo

I swear I won't talk about that time glibc broke EAC for everyone.

...wait

@frog @riesi the runtime report detects snap/flatpak (or it will). But generally we wouldn't error out .. user freedom and all that. If it gets really bad I guess we could start popping a warning.

@TTimo @frog @riesi I think we reached that point. But then it might become a whole game (heh) of cat-and-mouse between maintaining a .deb that overrides the snap placeholder, and Canonical finding new ways to pin their packages to take priority over yours, etc.

This could become messy. At some point someone's going to have to get on the horn with Canonical and get them to stand tf down.

@TTimo @frog thats the diplomatic way :)
@TTimo @frog @riesi could you display a warning and suggest a link to the native installation at least?
@TTimo funny. Reminds me of a browser.
@TTimo Screw Snap and its vendor lock-in model.
@TTimo god I hate snap so much

@TTimo

I don't know why anyone would prefer a snap or flatpak when a deb package exists.

I'm not against either packaging system—they may be imperfect but they're at least trying to solve certain problems—but when a package exists for your _native_ package manager I don't understand why you wouldn't use it preferentially.

@jeffalyanak @TTimo cause it's much less likely to break or misbehave - especially if it's packaged, by the actual app author(s)
@razze @jeffalyanak @TTimo not true at all, specially if is foss.
@exahamza @jeffalyanak @TTimo so how do you ship a newer, older or custom version of python with a native package manager?

@razze @exahamza @jeffalyanak @TTimo

Ah that one is easy: Simply do. Python interpreters are neatly namespaced by version, and always have been, there are currently three Python versions in Debian that can coexist just fine.

@nik @exahamza @jeffalyanak @TTimo I don't think three are enough, and how do I patch them or use the current nightly build?
@razze @exahamza @jeffalyanak @TTimo Nothing stops you from packaging it as a dependency, or even package your tree of vendored dependencies and install to /opt/com.example.whatever/, from a .deb package.
@nik @exahamza @jeffalyanak @TTimo and my app will use it, if it calls python via lib or via the cmd? didn't know that

@razze @exahamza @jeffalyanak @TTimo Per FHS (filesystem hierarchy standard), /opt/dotted.package.path is intended for you to use as $PREFIX. From there, your wrapper script in /usr/bin would just prepend it to $PATH.

One prominent package doing this is google-chrome.

@nik @exahamza @jeffalyanak @TTimo would have been nice to know that when https://github.com/xbmc/xbmc/issues/20172 happend for e.g.
Kodi crashes continue in Arch and Debian Linux probably due to different python versions used, Flatpak Kodi doesn't crash · Issue #20172 · xbmc/xbmc

Bug report Describe the bug Here is a clear and concise description of what the problem is: Expected Behavior Here is a clear and concise description of what was expected to happen: After the numpy...

GitHub
@razze @exahamza @jeffalyanak @TTimo For the Python case, it's even simpler because you can just install it alongside the system Python.
@razze @exahamza @jeffalyanak @TTimo In short: What you could pack inside a Docker image, you can as well put into /opt/dotted.package.path.
@exahamza @jeffalyanak @TTimo e.g. Every time my distro, fedora updates major python versions (new fedora release) pgadmin starts crashing on start
@jeffalyanak @TTimo one reason might be that deb packages gain root privileges while installing which isn't optimal for third party apps, while it can be acceptable for system maintained repos

@fourlastor @jeffalyanak @TTimo

>>deb packages gain root privileges while installing

False. apt needs root privileges to install pkgs, those pkgs don't gain root privileges automatically, you'll still need to type your password if you want give them root privileges when executing those same pkgs, just like you do with flat pak, snap, etc.

@exahamza @fourlastor @jeffalyanak @TTimo Though apt will run the pre install and post install scripts if provided in the deb and I'm fairly sure those will be run with root privileges. So the packager of the app at least does gain some access to your system with root privileges.
@MWelchUK @exahamza @jeffalyanak @TTimo indeed, thanks for making it more clear, I couldn't remember the exact details
@MWelchUK @fourlastor @jeffalyanak @TTimo that's accurate, not that missinformation above.
@exahamza @fourlastor @jeffalyanak @TTimo you can install setuid binaries using apt which will allow them to gain root privs without authentication
@jeffalyanak @TTimo The flatpak is completely contained, I know it touches nothing outside its home in ~/.var and any configured shared paths; it can even be installed in a user account which does not have root access.

@jeffalyanak @TTimo flatpak allow you to install new packages on old distro versions and vice versa without any conflicts

also, some people just prefer sticking to one particular package manager

@TTimo We're using the Debian deb repackaging over here personally ("steam" debian package). Is that bad too?

@IceWolf there are minor things that are different with the Debian and Ubuntu deb compared with the official one.

Nothing that really breaks functionality. I think our main gripe is that it disables upload of minidump crashes back to us.

I understand that users might want that out of privacy concerns. For us it's just annoying when bug reports come in and we don't have good backtraces.

@TTimo oh! That's good to know.

It'd be nice to have a "do you want to upload this crash report" dialog, because given the /option/ I'd probably say yes, but if not given the option, absolutely not, do not upload it without permission. So yeah it's good they disable that, IMO.

@TTimo It's like updates! We update our Linux systems whenever we get around to it. We block Windows any way we can. And maybe should start doing that with Steam as well.

Consent is important.

@TTimo (though admittedly part of that is that Windows tends to get even shittier with every update. Steam doesn't do that, thankfully.)

@TTimo Is there any chance that Valve could start officially distributing Steam as a Flatpak instead?

This could solve a lot of issues, especially for distros that aren't based on Debian/Ubuntu.

@TTimo
Or you can use the nix version, that works well too.

#getting #steam #ubuntu #snap #flatpak

@TTimo I see that Mint’s latest iteration (Virginia) has deprecated snap.
@TTimo what about Flatpak vs rpm (rpmfusion's one) in Fedora?
@TTimo snap is crap. I am amazed that companies are still pushing it.
@TTimo I've had difficulties with both snapd and Flatpak on Debian Bookworm, so I don't use them at all.