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.
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.
The “Discover” app from KDE and the “Software” app from GNOME actually support backend plugins, but it’s far from ideal. I had an issue where a Flatpak (Tor Launcher) showed up in Discover with an update available, but when trying to update it would fail silently and show up as an update again. Updating via CLI revealed that the package was deprecated in favor of another one and it asked whether I wanted to replace it.
Even if it’d work great, it wouldn’t really solve the issue that developers have to try and package their app in many different formats because not all distributions support all formats (out of the box). There isn’t a clear “release in this format” for developers. And as I said, unofficial packages aren’t ideal.
