I think most snap haters mostly hate, that Canonical forces snap upon them, an wouldn’t hate so much about it if they had the choice.
Isn’t that kinda the same with, for example, Fedora and Flatpaks? Or Debian and debs? Or Ubuntu and debs? Or Fedora and rpms?
The packaging system that your distro provides gets you the packages you get. For a small number of packages that were a maintenance nightmare, Ubuntu provides a transitional debs to move people over to the snaps (e.g. Firefox, Thunderbird), but if you want to get it from another repo, you can do exactly what KDE Neon does by setting your preferences.
No, Debian doesn’t take your apt install ... command and install a snap behind your back…
I don’t understand how a transitional package that installs the snap (which is documented in the package description) is any different from a transitional package that replaces, say, ffmpeg with libav.
$ apt show firefox
Package: firefox
Version: 1:1snap1-0ubuntu5
Priority: optional
Section: web
Origin: Ubuntu
Maintainer: Ubuntu Mozilla Team <ubuntu-mozillateam@lists.ubuntu.com>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 124 kB
Provides: gnome-www-browser, iceweasel, www-browser, x-www-browser
Pre-Depends: debconf, snapd (>= 2.54)
Depends: debconf (>= 0.5) | debconf-2.0
Breaks: firefox-dbg (<< 1:1snap1), firefox-dev (<< 1:1snap1), firefox-geckodriver (<< 1:1snap1), firefox-mozsymbols (<< 1:1snap1)
Replaces: firefox-dbg (<< 1:1snap1), firefox-dev (<< 1:1snap1), firefox-geckodriver (<< 1:1snap1), firefox-mozsymbols (<< 1:1snap1)
Task: ubuntu-desktop-minimal, ubuntu-desktop, kubuntu-desktop, kubuntu-full, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop, ubuntukylin-desktop, ubuntukylin-desktop, ubuntukylin-desktop-minimal, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop-minimal, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi, ubuntu-unity-live, edubuntu-desktop-gnome-minimal, edubuntu-desktop-gnome, edubuntu-desktop-gnome-raspi, ubuntucinnamon-desktop-minimal, ubuntucinnamon-desktop
Download-Size: 77.3 kB
APT-Manual-Installed: no
APT-Sources: http://us.archive.ubuntu.com/ubuntu noble/main amd64 Packages
Description: Transitional package - firefox -> firefox snap
This is a transitional dummy package. It can safely be removed.
.
firefox is now replaced by the firefox snap.
the thing people dislike about that is that you’re silently moved from an open system to a closed-source one.
Debian’s .deb hosting is completely open and you can host your own repository from which anyone can pull packages just by adding it to the apt config. fedora, suse, arch, same thing.
only Canonical can host snaps, and they’re not telling people how the hosting works. KDE seems to upload their packages to the snap store for Neon, judging from their page.
also, crucially, canonical are not the ones doing the maintenance for those apt packages. the debian team does that.
the thing people dislike about that is that you’re silently moved from an open system to a closed-source one.
Yeah. I didn’t realize I had fallen for it until I tried to automate a system rebuild, and discovered that a bunch of the snap back end seems to be closed and proprietary.
And a lot of it for no reason. Reasonable apt and flatpak alternates existed, but Canonical steered me to their closed repackaged versions.
While Canonical’s particular snap store implementation is closed source, all of the client software as well as the store API are open, and snap isn’t even tied to using snaps from their store. One could easily make a client app that treats snapd much the way apt treats dpkg. (In fact given apt-rpm I think it would probably be feasible to quite literally use apt for that.)
KDE seems to upload their packages to the snap store for Neon, judging from their page.
KDE also maintains most of the flathub.org packages for KDE apps. Not sure what the point is here.
canonical are not the ones doing the maintenance for those apt packages. the debian team does that.
This is wrong in two ways. First, Canonical are the primary employers of a lot of Debian developers, including to do Debian maintenance or development. This includes at least one of the primary developers of apt. Canonical also upstreams a lot of their work to Debian. Second, of the three (!) whole packages that Canonical decided to make transitional packages to the snap, none were coming from upstream Debian. Firefox was being packaged by Mozilla (and Mozilla were the ones who decided to move it to the snap), Thunderbird’s package had been something Canonical was packaging themselves due to the Debian/Mozilla trademark dispute that they never moved back to syncing from Debian due to technical issues with the port, and Chromium was, at least at the time, remaining frozen at old versions in a way that was unacceptable to Ubuntu users.
Fedora with Flatpaks is open and up front about whether you’re getting a Flatpak or a system installed package, and lets you choose if both are available. And installing through dnf/yum isn’t going to do anything at all with Flatpak.
And what about Debian with debs? That’s literally what apt was designed to work with. If it gave you Flatpaks, or the flatpak command installed debs, that would be more like what Ubuntu is doing.
The fact that Canonical shoehorned snaps into apt is the problem. I’ve heard bad things about snap, but I wouldn’t know because I’ve never used it, and I never will because of this.
When I tell my computer to do one thing and it does something completely different without my consent, that is a problem, and is why I left Windows. I don’t need that in Linux too, and Canonical has proven they can’t be trusted not to do that.
There are big differences between Snaps and Flatpaks.
- both the flatpak server and the client are open source
- flatpak does not publish 3rd party apps, promoting them as verified (https://news.itsfoss.com/valve-steam-snap-ubuntu/)
I never used snap, always use official repo > multilib > extra > chaotic aur > aur > flatpak > FUCK IT, I BUILD FROM SOURCE CODE FROM SHADY GITHUB REPO
Thread made by canonical employee
Now also throw GNU Guix, Homebrew and some AppImages in there
It’s a shame that snaps are forced to use Canonicals closed source backend because they are really good, and a fully snap system is a very compelling idea for immutable systems
They’re not forced to do so. You can install snaps locally (or provide a distribution system that treats snapd much the way apt treats dpkg), or you can point snapd at a different store. The snap store API is open and documented, and for a while there was even a separate snap store project. It seems to have died out because despite people’s contention about Canonical’s snap store, they didn’t actually actually want to run their own snap stores.
I don’t know why you’re getting downvoted. It makes perfect sense that Cannonical made it’s own proprietary package ecosystem and while technically anyone can build their own snap store, ain’t nobody got time for that.
I don’t agree that it made any sense to do that. If they wanted to containerize apps, there has been an open source solution to that for years; Flatpak.
ain’t nobody got time for that
As an app maintainer, that wants to support Ubuntu, why would I prefer to deploy a snap server, instead of publishing deb files, or creating a Flatpak?
