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.
That’s gotta be the funniest backfire for an April Fools’ joke I’ve seen in a while lmao
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).
-
Proprietary on the server/distribution end
-
Controlled 100% by Canonical
-
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 is open source, Snap isn’t
- 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?
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.
Canonical’s SteamSnap is Causing Headachesfor Valve
-
Ubuntu wants to own snap, with their own proprietary store etc which runs against alternatives like Flatpak and goes against the FOS ethos
-
Snap is slower and worse than Flatpak (the most popular alternative) in most ways, with very few pros that will likely be caught-up-to soon too
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.
Every line of snap code that touches your computer is open source, so “closed off” is absolute hyperbole when you are discussing the format
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.
Not sure if I understand you correctly. Flatpak itself is not proprietary afaik and while people might make flatpaks of proprietary software, the problem with snap is that the snap system itself is proprietary afaik.
So every open source software packaged in snap gets this proprietary stain added to it. Thats what actually bothers me.
There’s a misunderstanding here. What we mean is that the Snap system itself is proprietary. The server side is proprietary and there’s no way to add repos other than Canonical’s.
Flatpak is open, and anybody can create/add a remote.
Both can be used to package and distribute proprietary software. But the same could be said of .deb or .rpm
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…?
Yes and no. Last time I checked, Ubuntu was the most used desktop Linux OS, and it obviously uses Snap (and has Flatpak disabled by default).
Ah, I hadn’t realized Canonical was so awful as to disable the format everyone else agreed on, but seems you’re right: https://www.omgubuntu.co.uk/2023/02/ubuntu-flavors-no-flatpak
How do you figure? For example, Arch Linux community on r*ddit is bigger than the Ubuntu one
Where did you get the numbers?
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.
I still don’t understand why everyone was so against static linking before the advent of Snaps/Flatpaks, but are now sooo into them. Windows software devs have been doing this for decades. Link statically and compress with UPX or whatever. This is nothing new, I have no idea why this didn’t become the de-facto standard, but instead things like Snap/Flatpak did. Maybe it was the fact that most people wouldn’t know where to put the binary or not having the icons and desktop files packaged with the app, or maybe that you have to chmod +x the binary in order to run it… also, the lack of a central repo could also be the case (this is the standard nowadays, so people like to have on their desktop what other OSes have as well: PlayStore, iOS Store, Marketplace, etc). I do agree that this does make things easier.
I still don’t understand why everyone was so against static linking before the advent of Snaps/Flatpaks, but are now sooo into them. Windows software devs have been doing this for decades. Link statically and compress with UPX or whatever.
Security is one aspect. You are distributing all the dependencies with your binary now, if a vulnerability is found in any of those dependencies you’re going to have to push out a new build instead of your OS providing you with an updated library.
Memory and storage are the other reasons. Libraries can be shared between running applications, loaded into memory once and stored on disk once. Modern hardware is so powerful now that memory and storage are nothing like the limitations that they once were.
Security is one aspect. You are distributing all the dependencies with your binary now, if a vulnerability is found in any of those dependencies you’re going to have to push out a new build instead of your OS providing you with an updated library.
The same thing is going on now with Snap/Flatpak. They don’t use system libs, they use their own integrated ones. If a lib has a security issue embedded in the app, the app developer has to make a new build. But, even if the developer doesn’t make a new build, that is the only app that is vulnerable, your distro will push a new build in the repos probably a lot sooner than the dev of that app.
As I said, Windows devs have been doing this for ages. Why? DLL hell is one reason, the other is “everything just works out of the box” (no end user late night calls after deployment). This was a security nightmare, I agree, but the alternative was a lot more work (make sure every user out there have those exact dependencies installed which work with your app)… not to mention this scenario: MS pushes a new version of that dll in an update or a redistributable, and guess what, your app doesn’t work with that version 😒. Great, now I gotta debug to see what the reason is. What if the buyer doesn’t want to pay you for this update? It has happened. It’s not my fault that MS pushed this.
We’ve had a situation where specific versions of C++ runtimes had to be installed because the software just doesn’t work with the latest ones. Not to mention hunting down those specific versions is a PITA. And even then there were problems. In the end, a redist repack of every version there is under the sun was the only solution that worked 100%. Mind you, this software works with AD, so it’s not something run locally, this thing uses TCP/IP.
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.
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).
That’s because years ago you had a choice between using the repo or compiling the package yourself.
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.
Imagine if Fedora came with software specifically made to install and update software from all of those different sources through a simple and unified gui. That would really streamline that whole ordeal. It could even include a snap backend for masochists.
PS
Wait till you learn about nix and guix
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.
It happens constantly both on my laptop (suse) and my Steam Deck (arch). Same exact behavior. I gave up trying to debug it, and I just keep retrying the update command until the list is empty.
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!)
Their refund policy is due to getting slapped around in EU courts, not because valve is benevolent or anything. I do like steam a lot, but it is a near monopoly which acts as DRM to a degree. They did and would abuse that power unless regulated.
As someone who was during those times, your Zgen knowledge is very incorrect. The games did work, including Crisis (original). As to why the myth you hear from fellow Zgen gamers; it’s because graphics cards were invented. Brand new, no one knew what they were doing with them. The companys Renzen and Nvidia started sponsoring games, it’s how they became popular, their logos were part of the game, Metal Gear Solid revengeance is proof of this.
Steam had no part in gaming history, they were not the first online platform. Dell made wild target before Valve Corporation was founded. Lootbox was invented before Steam launched it, Yahoo games (anyone remember them) in japan had the concept down to almost todays standards. Valve had nothing to do with gaming history, they are just known for their lawsuits and anti competitive behavior.
That’s the problem with doing everything yourself.
You also have to maintain everything, yourself.
Fuck snaps 🖕
