Canonical may be ramping up its efforts to improve the Ubuntu gaming experience — yasss — but it seems their Steam snap package is causing a few headaches
Timothée Besset, a software engineer who works on the Steam client for Valve, took to Mastodon this week to reveal: “Valve is seeing an increasing number of bug reports for issues caused by Canonical’s repackaging of the Steam client through snap”.
“We are not involved with the snap repackaging. It has a lot of issues”, Besset adds, noting that “the best way to install Steam on Debian and derivative operating systems is to […] use the official .deb”.
Those who don’t want to use the official Deb package are instead asked to ‘consider the Flatpak version’ — though like Canonical’s Steam snap the Steam Flatpak is also unofficial, and no directly supported by Valve.
I'm sure Canonical's neverending death march towards Snap, along with the OS running outdated packages, is why Valve no longer uses Ubuntu for SteamOS development. The greatest April Fools was Ubuntu dropping Snaps because so many people were saying how they could go back to using Ubuntu again...then they noticed it was a joke and the sadness set in.
Why do people hate snap over flatpak? I feel like I’ve read a thread or two about it, but I haven’t seen an answer that was particularly satisfying (almost definitely for a lack of trying on my part, to be clear).
Worse performance, particularly in terms of app startup times
Snaps are mounted as separate filesystems, so it can make things look cluttered in your file explorer or when you're listing stuff with lsblk
Canonical often forces users to use Snaps even when users have explicitly tried to install with apt. e.g. you run sudo apt install firefox and it installs a Snap
It hasn't gained traction with other distros like Flatpak has, and Canonical's insistence on backing the "wrong" standard means Linux will continue to be more fragmented than it would be if they also went along with what has become the de facto standard
There are however benefits of snaps. It works for better for terminal programs, and Canonical can even package system stuff like the kernel as a snap - as you can imagine, this might be a very powerful tool when it comes to an immutable version of Ubuntu.
Flatpak allows other repositories besides the official one, therefore having the ability to be decentralised, Snap doesn't
Canonical (the company behind Snap and Ubuntu) is hated for some past decisions they made with Ubuntu
and more
(The only thing I really prefer Snap over Flatpak is that you need the whole package name in Flatpak (like com.valvesoftware.Steam for Steam) whilst you can simply use "steam" in snap but that's due to decentralisation vs centralisation I guess and overall a minor problem for me)
The article says that steam showing a notice on snap installs that it isn't an official package and to report errors to snap would be extreme. But that seems pretty reasonable to me, especially since the small package doesn't include that in its own description. Is there any reason why that would be considered extreme, in the face of higher than normal error rates with the package, and lack of appropriate package description?
Honestly, that seems like the nicest way to solve the problem. Afaik Valve would be fully within their rights to C&D them from unofficially rehosting their binaries. In any other situation, that would be a blatant security risk.
Was an unextreme solution mentioned? I don't see one. It seems very reasonable.
What would more extreme, but not inappropriate, is for Valve to send a cease and desist to stop Canonical from using the Steam logo on a package Valve does not maintain. I don't think that's warranted. But calling a little text clarification "extreme" is nonsense.
But Canonical using that logo is pretty misleading. I notice the thumbnail adds some Canonical-flare to the logo, but it's not there on snapcraft.
I don't even want to hate on Snap, I just think Flatpak is probably superior in almost every way and it's probably not great that there are three competing formats for "applications with dependencies included". It was supposed to be "package your app to this format, dear developer, so everyone can use it no matter the distro they use", now it's a bit more complicated. Frustrating, as this means developers without that many resources will only offer some formats and whichever you (or your distro) prefers might not be available.
I know that you can get every format to work on every distro (AppImages are just single binaries you can execute), but each has their own first class citizen.
By the way, the unofficial Steam Flatpak has been working well for me under Fedora 39 KDE Spin, but an official one would be great to have.
I didnt want to hate snap either, until I found out its proprietary technology… on a foss OS… since then I‘m pretty over it - and ubuntu for that matter. I‘ll probably switch to debian once ubuntu 23.10 runs out of support.
Well... Flatpak ships Propietary Software too. And at this point Propietary Software is almost avoidable (unless you have a LibreBoot. I want one too). But it's reasonable to be frustrated that an operating system as influential as Ubuntu has ended up falling so down in its technology, and that it has the support of a company like Chanonical.
Edit: Thank you for the comments. I didn't noticed Snap itself is propietary.
Personally, I don't get why devs would elect to package for Snap, in favor of Flatpak or AppImage. I guess, if your toolchain offers Snap packaging out of the box, then might as well. But aside from that, do you not just reach fewer users...?
The thing with AppImages is: it requires FUSE2 which doesn't really get packaged/included by default anymore in a lot of places and the recommendation is "build on the most old and crusty distro you want to support" which just sounds like a nightmare in multiple ways :)
And with snaps the sandboxing only really works on Ubuntu and nowhere else last time I looked into it (then there is also the entire problem if you want to host your own repository/"storefront").
So really the only universal sandboxing method that effectivly makes sense is Flatpak.
Flatpak with Fedora 39 must have come a long way. Almost every tutorial with workarounds or discussion of broken features you can find online is now obsolete. It just works out of the box, especially under KDE. Mostly.
That makes searching for actual issues extremely hard because I find myself chasing down paths of issues that have long been resolved.
Agreed. the only "workarounds" I've needed to do (on arch) is install gtk-desktop-portal-{gtk,kde} because it's not included with kde-plasma5 for some reason.
and it's probably not great that there are three competing formats for "applications with dependencies included".
Ok in snap/flatpak but i tink that's a bit unfair in appimage. First two are runtimes, second is a file format that does stuff with fuse. That's like saying there should only be one I/O scheduler.
now it's a bit more complicated
Do native for system/environment stuff and simple projects, flatpak for frontend molochs with lots of dependencies, no?
I don't think AppImage is a bad technology, but with the comparatively minuscule marketshare Linux desktop has barely any developer/software company can invest the resources to test and maintain packages in all these formats. It's often not worth it for commercial software to offer packages in every possible format (yeah, yeah, open source is great, I know; still, commercial software is real and many people (need to) rely on it).
I've been using Fedora for a couple of weeks (one of my New Year's Resolutions is to completely ditch Windows, so my main computer is now on Fedora :D) and most of the software I use is either available in the official repositories, as an rpm or a Flatpak. But there's the odd piece of software where I can only find AppImage or Snap versions, and often if a Flatpak is available, it's non-official (Steam for example).
So, you potentially have packages from the package manager (mostly deb- or rpm-based, and whatever format Arch uses), then you have AppImage, Snap and Flatpak and some applications are simply an archive with an executable binary. That's a far cry from installing everything from one or two places, which I feel like used for be one of the selling points for Linux (years ago).
Nothing most users can't handle, but it could certainly be more streamlined. Now before I install software, I check the website, then I check whether they offer an official flatpak or an rpm package if it's not in the official Fedora repositories, and if they don't, I check if there's an unofficial one on Flathub, which sometimes has implications. If there's no Flatpak whatsoever, I fall back to standalone binaries/archives when available. It's probably easier to install software on Windows now: download the installer from the official website, install it and done. Most software auto-updates itself.
Having options is great and one of the great things about OSS, but I feel like when it comes to "standards" like these, more collaboration instead of reinventing the wheel over and over again would be better.
My only complaint about flatpak is that updating them fails like 50% of the time for seemingly no reason, and I just have to run the update command over and over until they are all updated.
Just tell the billion dollar company to allow people to download the games on their browser. The Client only exists as a means to DRM and analytics, there’s no actual reason for games not to become standalone.
That's pretty unfair. Before Valve's efforts, the first thing we PC gamers asked eachother about a new game was always "could you get it running?"
Three bad old days were quite bad, and they started getting better in lock step with Valve's improvements to Steam.
Correlation/causation and all that. But for a lot of us Valve earned a lot of goodwill simply by allowing "request a refund" on games that run poorly. (Edit: which was apparently forced on Valve by a government. Valve got lucky there!)
Flatpak is not designed to solve all the same problems as snap they have very different scopes and goals. It’s really only Linux hobbyists that see these as comparable technologies.
Also the Steam flatpak is unofficial just like the snap, they would be unwilling to support flatpak issues as well.
Counterpoint: Snaps work fine for me, really convenient. But flatpak always shits the bed on my internet, it also needs huge Nvidia driver packages of it's own if you have an Nvidia GPU (my laptop has one)
Snap on the other hand is very much fire and forget
I know the "Arch BTW" meme exists for a reason, but one of the reasons I haven't been able to drag myself away from Arch-based distros in recent years is that it allows me to always have current versions of my software while also just not having to care about all this appimage/flatpak/snap brouhaha.
I guess it's somewhat of a "pick your poison" kind of situation, but I find dealing with the typical complaints about Arch based distros to be both less of a problem than detractors would have you believe, and less of a headache than having to pick one of three competing alternative packaging approaches, or worse, to use a mix of them all. Standing on the sidelines of the topic it seems like a small number of people really like that these options exist, and I'm happy for those people. But mostly I'm grateful that I don't have to care about this kind of thing.
Edited to add: Seeing how this thread has developed in the past 5 hours convinces me anew that "on the sidelines" is where I want to stay on this topic. 😁
Nah, it's repeating the installation process until you finally get enough stuff working to have internet, and then you can bootstrap installing every other bit of software that you need. Thank goodness for rolling release - I can't imagine having to go through that again.
100% all this. Canonical has been pushing snaps for awhile, and I wonder if the 12 year LTS for Ubuntu is part of that strategy - want something newer? It's in the snap store. snap is terrible, worse than flakpak and appimage - but just as you say, as an arch user I don't have to care. Whatever I want is probably in the AUR if not the main repos. Rolling distros, done right (arch), are an amazing experience.
I was like you using arch packages for everything until ferdium was hit by a terrible bug that broke its zoom function and wont be fixed in months since it is an issue with electron. Now I use the appimage version of it to downgrade to an older version.
And then there are the rust programs that you can only find as aur git packages which means installing a bunch of dependencies and all the crap that cargo puts into my home dir just to build one binary, for that I just instead take the appimage version or sometimes the binary if they release it and place it in ~/.local/bin.
Another good thing is that the appimages get compressed and take less disk space, for example the libreoffice package in arch is 600 MiB while the appimage is 300 MiB.
And the great thing is that I can just drop my homedir into any distro and as long as I make sure that fuse is installed everything will work out of the box.
I know you already got another answer, but - it's very rare that any software for Linux exists that is both 1) not present in the official Arch repos, and also 2) not packaged by a user for the AUR.
Probably 99% of what a typical user (I know we all define that differently) will want doesn't even require AUR access - it will be in the official Arch repositories and will be up to date to within a few weeks of release.
There are some potentially substantial downsides to the AUR (it's the Arch USER Repository - so these are not official arch packages) but IME the real world problems are minimal. I would suggest anyone who is new to the Arch way of distributing software should hit up the relevant page on the Arch wiki and make up their own mind before using the AUR - but it's about being aware of what you are doing more than it is a real warning, if that makes sense. I suspect few Arch or Arch-based users don't have at least a smidgen of AUR packages on their system. (Edit: That page is very thorough. I think it makes installing from the AUR sound much harder than it needs to be. For most people the command is just "yay -S packagename." There are gui options that handle all packages including AUR, and yay is not the only cli option, either.)
Interestingly, there are some AUR packages that work by pulling down the deb and deconstructing it for installation on your system - AFAIK it can be that, RPM, a true "compile from source" situation, or I'm guessing some AUR packages are deconstructing snaps\flatpaks\appimages during the install. Whatever the origin of the files, they include a pkgbuild file that tells your system how to either compile or deconstruct and install the software.
I think if we could drag users (at least gamers) away from these Debian/Ubuntu based distros we could have developers just shipping packages that wouldn't need to be compatible with some ancient LTS library release, and maybe we wouldn't need appimage/flatpak/snap at all anymore (or at least only in rare cases).
From my perspective as someone who is both getting into gaming on Linux and also not much of a power user, Arch would have to make the installation and maintenance process a lot simpler to attract more people, and I'm not sure that's something they actually want to do.
Looking at the official Arch installation guide, the average gamer may be overwhelmed by the process here, especially if they're not comfortable with the terminal. Something like Linux Mint, on the other hand, has a built-in GUI installer with reasonable partitioning defaults, and it comes packaged with stuff like an app manger and update manager, something that will feel much more familiar to someone coming from windows.
It's too bad. I feel like they're a versions of Ubuntu from 2006 to, say, 2012 or so, that were beautiful and perfect and were accessible to me as a college student. It set a new standard. It seems like half the battle is having people with good vision making important decisions so things don't go off the rails.
Canonical does a heck of a lot more for the Linux ecosystem than snap. For instance they have an entire (growing) team dedicated to fixing reported bugs in various upstream packages.
This is a big issue with Snap. It may be like Flatpak, allowing devs to set their own dependencies for ALL distros, but its poor uptake outside of Ubuntu's ecosystem means that it's no different to yet another distro repackaging system.
Flatpak, or even Nixpkgs, are the future because they allow devs to have control over the distribution of their software. Snap being such a closed ecosystem in comparison only means it will replicate many of the problems we've found with traditional (re)packaging systems.
I can't speak for Flatpak as I haven't tried it but nixpkgs are beautiful to work with and configuration of my system has become completely reproducible in a clean format.
As a dev, you can just distribute a nixpkg with whatever build tool inside. That beats the current system of "native" packages where your software is repacked and then maintained by half a dozen teams for different distros that use different dependencies and update cadences.
Bottles has gone as far as to demand its fedora package be removed and now shows a warning if you're not using the flatpak version because repackers just don't properly test all their software (how can they? there are thousands of apps in these repos!)
Snaps were designed to solve dependency hell, get modern software, security, among other issues. If it weren't for the fact Flatpak does a better job, many more people would be praising Snap.
It's good that Canonical is trying to make the desktop better. It would be better if they focused their efforts elsewhere.
Ubuntu used to get a lot of undeserved hate but lately the hate feels deserved. Ubuntu has been the face of the usable desktop Linux for a long time and they just keep tripping over themselves every time they try to move forward.
Their intentions are usually good. A lot of things they propose usually end up being adopted by the community at large (just not their implementation). They seem to just yank everyone's chain a little too hard in the direction we're eventually going to go and we all resent them for that.
Off the top of my head, there was Upstart (init system), there was unity (desktop), and now snaps (containerized packaging). All of these were good ideas but implemented poorly and with a general lack of support from the community. In almost each case in the past what's happened is that once they run out of developers who champion the tech, they eventually get onboard with whatever Debian and Rhel are doing once they were caught up and settled.
Valve's lack of interest in maintaining the snap makes sense. The development on the Ubuntu platform is very opinionated in a way where the developers of the software (valve) really want nothing to do with Canonicals snaps.
On another note: my favorite thing about the Ubuntu server was LXD + ZFS integration. Both have been snapified. It was incredibly useful and stable. Stephane Graber has forked the project now into INCUS. It looks very promising.
This might be an unpopular opinion but I really don't get this trend of wanting to containerized just about everything, it feels like a FOTM rather than doing something that makes sense.
I mean, containers are fantastic tools and can help solve compatibility problems and make things more secure, especially on servers, but putting everything into containers on the desktop doesn't make any sense to me.
One of the big advantages Linux always had over Windows is shared components, so packages are much smaller and updating the whole system is way faster, if every single application comes with its own stuff (like it does on Windows) you lose that advantage.
Ubuntu's obsession with snaps is one of the reasons I stopped using it years ago, I don't want containers forced upon me, I want to be free to decide if/when to use them (I prefer flatpack and appimage).
Debian derivatives that don't "reinvent the wheel" is the way to go for me, I've been using Linux MX on my gaming desktop and LMDE on laptop for years and I couldn't be happier, no problem whatsoever with Steam either.
Shared components work brilliantly in a fantasy world where nothing uses new features of a library or depends on bug fixes in new versions of a library, and no library ever has releases with regressions or updates that change the API. That's not the case, though, so often there'll exist no single version of a dependency that makes all the software on your machine actually compile and be minimally buggy. If you're lucky, downstream packagers will make different packages for different versions of things they know cause this kind of problem so they can be installed side by side, or maintain a collection of patches to create a version that makes everything work even though no actual release would, but sometimes they do things like remove version range checks from CMake so things build, but don't even end up running.
I agree with a lot of your points but I do think containers a great solution.
I've been a really big fan of Universal Blue lately. It presents a strong argument for containerizing everything. Your core is immutable and atomic which makes upgrades seamless. User land lives in a container and just gets layered back on top afterwards.
Would be cool if they just straight up supported flatpaks. That's been my main way of gaming for a couple years now, and it works great. The downside is that the folder structure is confusing so it makes things like modding pretty difficult.
The problem is that 3rd parties are doing the packaging both on Snap and Flatpak whereas if they had followed proper security practice ONLY THE REAL DEV should ever be allowed to package their app as a Flatpak or Snap.
This would ensure security, as well as a proper functioning flatpak/snap and also all feedback would be directed to the Dev.
I've never liked the fact that Canonical and whoever can make Snaps and Flatpaks of other people's software. There is zero security guarantee, zero guarantee they'll update it and zero guarantee it will work.
Just because Snap and Flatpak exist doesn't mean just anyone should be able to just make them.
If Valve only chooses to make a deb then so be it! It's their product!
The problem is that 3rd parties are doing the packaging both on Snap and Flatpak whereas if they had followed proper security practice ONLY THE REAL DEV should ever be allowed to package their app as a Flatpak or Snap.
Says who? If it were the case, Linux would either be a nightmare of fragmentation or become centralised on one distribution. Distros need to be able to package their own software, and these are kind of like distributions. Also since we're talking about proprietary software here, is it really any better security practice if the "real dev" packages it or somebody else, they both could contain malicious code.
Valve are not going to put malicious code on their app. Neither is VLC or any other FOSS developer.
The distros should stick to packaging their repo apps and leave the Snap/FlatPak tech as an alternative to the original dev if they decide they want to use that.
We can't have Bob from nowhere packaging Valve, then not updating it or patching it because he doesn't have time. Or 5 Bob's all doing the same thing with 5 copies of Valve on the Store.
It's crazy. This is what causes fragmentation. Flathub should vet every app and if you are not the dev of the app, you may not host it on Flathub. You're still welcome to make a Flatpak for home use on your own pc but not for wide distribution.
For security reasons the packaging of flatpaks in flathub is done by flathub, whether they are devs or third parties they just write the manifest. Although I seem to remember there are some exceptions, such as firefox.
However it exists to be used in cases where you want a sandbox/abstraction layer on purpose.
Unfortunately some applications are starting to be distributed as docker containers that never should have been, resulting in an snap-like situation developing there as well.
Right, Docker is an exception (usually). The same trend anyway is becoming common in all "snap like" solutions, namely AppImage. I have to admit, tho, that I have a couple of AppImages that did not install in .deb form
I'm really hoping this all forces Ubuntu out as the face of desktop Linux.
It's been pretty low tier for years now, and Canonical just proves corporate backing doesn't guarantee a good distro.
Snap is pretty garbage, default GNOME is horrendous, the repos break every other month, apt is still pretty lame despite being an user upgrade for apt-get, the packages are neither stable nor cutting edge, they change core OS backends like every update which breaks configs and makes documentation obsolete.
I'd like to suggest Fedora as the new goto, but I feel like it's a bit too privacy and FOSS oriented which may scare away new users.
Debian is great but it doesn't have latest packages which isn't optimal as performance upgrades would take time to release or need to be manually installed.
unfortunately, industry loves shit like Ubuntu and RHEL because of their corporate backing. comps love having the insurance of someone to blame or somebody to fix their shit when things hit the fan. I've worked for many comps who choose RHEL for that alone. Should we choose the OS built by a bunch of randos in their basement, or something backed by Red Hat where I can just pay them money to handle my support tickets faster if shit blows up? or who tf do I have my cyber liabilities insurance guys sue if the OS has a huge fuckin problem? I want a company behind that shit.
Well, I'd prefer Canonical to fix their shit, instead of forcing immature products onto users. I'm not against snap per se, as there are valid reasons for sandboxing, especially for games (remember when Steam accidentally wiped some user's home folders back in 2015? Sandboxing would have prevented that).
However, in its current state, snap causes just too much friction. For example Firefox can't remember the last used directory for up/downloads, Steam snap will just create a new data directory (forgetting about the games already downloaded), there's no way to allow additional folders (like /net from autofs) in snap apps etc. It's just a myriad of issues which make working with the system unnecessarily complex and frustrating, and there seems to be little progress fixing those.
I feel the same. My entry distro was ubuntu, and every time I updated major version the whole installation exploded and i had to reinstall it from scratch.
Luckly for me now i use Debian and updating major release is smooth af. Already went through 3 major updates and 0 problems.
Just swap to Debian, Valve. And snap is engineered to waste your time, imo.
As far as I know, SteamOS is already based on Debian. The dev is complaining about users trying to install steam on their own Ubuntu installs, not SteamOS.
EDIT: nvm, it used to be Debian, but the newer versions for steamdeck are based on Arch. Apparently they wanted rolling updates so that it would be easier to push out changes more frequently.
This is not an issue of what Distro Valve chose to use (SteamOS used Debian now it uses Arch) but is on Canonical for how they package it. I have just been dipping my toes into Linux lately and have been using Manjaro and Nobara and they have been working great for gaming and every day use... Until I play a game like Finals and have to swap to windows.
Snap is a sandboxed environment to install applications in.
Flatpak is a more portable implementation of the same broad idea, it downloads a chroot and runs applications from within using a separate program called bubblewrap (one could, in theory, use chroot to run apps from within the downloaded flatpak images, bubblewrap offers further isolation through things like namespaces and cgroups etc. )
Snap, unlike flatpak, is a Canonical specific implementation that has a reputation for breaking a lot of things.
It's perfectly possible to isolate a steam install, NixOS does that by default to even get it running (on NixOS nothing is where any binary blob expects it to be). There was a very brief issue with experimental steam when they tightened up their own sandboxing and doing sandbox-in-sandbox broke stuff but that was fixed before release as Valve is, indeed, responsive, even if the distribution isn't officially supported. But you gotta have some professionalism and have institutional continuity, they don't want to deal with J. Random Hacker doing a one-off packaging job. Or distros trying to be smart and replace the steam runtime with their own library versions. Basically, assume that the whole thing runs directly on the kernel, make sure to have graphics drivers, and you'll be fine running it as-is.
Snap is Canonical's (developers of Ubuntu) attempt at their own containerized software package format, conceptually similar to Flatpak in some ways but differing in details of implementation. One major note is the back end is kept closed source so you cannot host your own Snap repo, which ruffles some feathers.
Apparently distributing Steam (Valve's video game store/launcher) in Snap format is causing some problems.
I remember asking in one of their articles if they had planned to reign over (or partner up) the project over to Valve once it was ready and said they had no plans.
They could and they would if they wouldn't profit from this in the end,
for some reasons there is no official Flatpak and they don't want to support a Snap package, they just say anything but the *.deb is unsupported, kinda weird because they use the Flatpak package on Steamdeck because that is Arch-based, i guess they are somewhat involved there.
As much as they do for the Linux movement, they should get their shit together when it comes to a cross-distro client, preferably Flatpak obviously.