Yeah typing “apt install firefox” and getting the Snap version does loudly and obnoxiously disqualify Ubuntu from any devices owned by me or my family.
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.
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.
If you don’t want to explain, you’re perfectly welcome to not explain. But saying what amounts to “if you don’t know I’m not telling you”, especially when you weren’t specifically asked, is a pretty unkind addition to the conversation.
In both cases, the packages are owned by the same people? (Fun fact: mozilla actually owns both the Firefox snap and the firefox package in the Ubuntu repos.) I’m non sure how that “potentially introduces vulnerabilities” any more than “having a package which has dependencies” does.
I’m not sure what you’re referring to with Docker. Canonical provides both the docker.io package in apt and the docker snap. Personally I use the snap on my machine because I need to be able to easily switch versions for my development work.
Because the separate installation means you can actually end up with both an apt installed and a snap installed.
My comment about docker was a specific example of such a case, where vulnerabilities were introduced. It was actually a commonly used attack a few years ago to burn up other CPU and GPU to generate crypto.
Yes, canonical provides both. Guess what? They screwed up, and introduced several vulnerabilities, and you ended up with both a snap and apt installed docker.
The fact that they are both packaged by Canonical is both irrelevant and a perfect example of the problem.
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.
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.
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.
Yeah typing “apt install firefox” and getting the Snap version does loudly and obnoxiously disqualify Ubuntu from any devices owned by me or my family.
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,
ffmpegwithlibav.$ 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.Well, that’s your problem for not understanding the massive difference, not mine.
If you don’t want to explain, you’re perfectly welcome to not explain. But saying what amounts to “if you don’t know I’m not telling you”, especially when you weren’t specifically asked, is a pretty unkind addition to the conversation.
One selects a different package, same source repo.
The other completely changes the installation, invisibly to the user, potentially introducing vulnerabilities.
Such as what they did with Docker, which I found less than hilarious when I had to clean up after someone entirely because of this idiocy.
The differences seem quite clear.
In both cases, the packages are owned by the same people? (Fun fact: mozilla actually owns both the Firefox snap and the firefox package in the Ubuntu repos.) I’m non sure how that “potentially introduces vulnerabilities” any more than “having a package which has dependencies” does.
I’m not sure what you’re referring to with Docker. Canonical provides both the
docker.iopackage in apt and thedockersnap. Personally I use the snap on my machine because I need to be able to easily switch versions for my development work.Because the separate installation means you can actually end up with both an apt installed and a snap installed.
My comment about docker was a specific example of such a case, where vulnerabilities were introduced. It was actually a commonly used attack a few years ago to burn up other CPU and GPU to generate crypto.
Yes, canonical provides both. Guess what? They screwed up, and introduced several vulnerabilities, and you ended up with both a snap and apt installed docker.
The fact that they are both packaged by Canonical is both irrelevant and a perfect example of the problem.
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.
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
snapdmuch the wayapttreatsdpkg. (In fact givenapt-rpmI think it would probably be feasible to quite literally use apt for that.)KDE also maintains most of the flathub.org packages for KDE apps. Not sure what the point is here.
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.