I don’t have a problem with snaps as a technology. If you want to use them, then who am I to judge?
But what I do have a problem with is when I don’t have a choice and I am being forced to use what the distro maintainers think is good for me. That is what finally made me quit Ubuntu and switch to Fedora.
If Canonical folded Snap could be taken over by others who could build new server software for it, either from scratch or based off the other projects to develop alternative servers for it, and modify snap to accept multiple repos like that. That’s the difference, also just being able to fork snap like that. Though the fact it hasn’t been done says something about how many real snap enthusiasts there actually are.
What makes it open source is the fact that the parts which matter most are open source. The part that installs on the system is open source, and because of that it can be more easily tweaked and modified to accept other servers. In actuality it can be modified to do so right now, it’s just that there is little reason to do so because the amount of people enthusiastic about snap isn’t very large, as it has many other problems besides just the centralized server infra.
I do have a problem with them, the same problem was solved, better, with other technologies like appImage (which doesn’t litter your mount list with 100 meaningless entries).
Even flatpak is better, snap is an also ran they’re trying to force on us without being as good as any of the competitors.
Couldn’t the same argument be made for any distro? They give you what they put in their repos. If you want a deb package, use the mozillateam PPA (which is built on Canonical’s hardware, same as Mozilla’s snap of it).
IIRC, the issue was that - unless you take steps to explicitly prevent it - Ubuntu would occasionally reinstall the snap version. I don’t remember the details, been a while since I had to dance that dance, but I recall it being one of the things that put me off snap in particular, Ubuntu in general and sparked my search for a different distro.
I’m now on Nobara, a Fedora-based gaming-oriented distro maintained by GloriousEgroll (who also maintains the popular Proton-GE)
Like with any time you’re trying to select a specific source for a package, you need to set apt configuration to prefer that source. It’s standard apt behaviour with a standard way to configure it.
Correct me there, but wasn’t the “select source” thing intended to be about different deb sources?
The issue is that what you expect to be a deb package manager ends up redirecting to snap anyway. It’s not a different source, it’s a different system. If I have to manually take steps to avoid using the distro vendor’s default sources because they just redirect to a system I don’t want to use, I might as well look for a different vendor.
It’s literally a choice between what deb you want to get. One is a transitional package that installs a different package on the system (in this case the snap) as Debian transitional packages have done for decades, and the other is a third party package that provides the app rather than the transitional package. Just as when there was the ffmpeg vs. libav split, if you don’t want the transitional package to be installed and you want your third-party package from a different repository, you have to tell apt that.
Thanks for that correction then. I wasn’t conscious of that detail.
In any case, the issue remains that, if the vendor’s default repositories push for a type of package I don’t want, I either have to manually find and vet third party repositories I trust or find someone else to rely on for defaults I’m fine with.
The difference between “I want a different source for a single package, so I’ll manually select a different source for that one” and “I don’t trust Canonical to select sources I agree with anymore” is one of scale. I’m fine with manually pinning the transitional package, uninstalling it and the snap (hopefully remembering to back up my profile before realising that it also deletes user data) adding a ppa, reinstalling it and reimporting my profiles just for firefox.
But if I feel like I have to fight my distro vendor over not using their preferred package distribution system, it’s probably better to jump ship - other vendors have beautiful distros too.
(Also, “you can just use a different source” is part of the reason people prefer not to use snap, where you can’t do that)
If you’re fighting your distro vendor over the choice of packages they’re providing in their repos, then yeah, you should probably use another distro. But that’s exactly what I was saying in my original comment above. If you don’t like rpms or flatpaks, you shouldn’t be using Fedora either, since those two packaging technologies are what Fedora uses for their distribution. For me the Linux Mint developers’ hostility to snaps (which in my experience tend to be the best trade-offs for my needs) is one of the many reasons I won’t use or suggest Mint.
KDE Neon provides their own packages in their repo that add Mozilla’s apt repository for Firefox as well as setting up the preferences. In fact, here’s the file, which gets placed in /etc/apt/preferences.d/org-kde-neon-packages-mozilla-org-pin:
# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL# SPDX-FileCopyrightText: 2022 Harald Sitter <sitter@kde.org>Package:firefoxPin:releaseo=packages.mozilla.orgPin-Priority:1000Package:firefox-*Pin:releaseo=packages.mozilla.orgPin-Priority:1000Package:firefox-locale-*Pin:releaseo=packages.mozilla.orgPin-Priority:1000
The great part of KDE Neon’s approach to it is that since I do want the Firefox snap on my KDE Neon laptop, I can simply run sudo apt remove neon-repositories-mozilla-firefox firefox && sudo apt update && sudo apt install firefox to get the snapped version of Firefox.
Also, snapd keeps a snapshot of your per-revision configuration from an app for a while after you remove it. You can run snap saved to see all the current snapshots. It doesn’t remove your $SNAP_USER_COMMON directory for that snap (which is where the Firefox snap stores its profiles), so moving from the snapped Firefox to the version from apt is just a matter of moving the .mozilla directory out of ~/snap/firefox/common to ~/
For me the Linux Mint developers’ hostility to snaps (which in my experience tend to be the best trade-offs for my needs) is one of the many reasons I won’t use or suggest Mint.
I mean, analogous to firefox example you supplied, you could just delete nosnap.pref and be on your way.
Also, snapd keeps a snapshot of your per-revision configuration from an app for a while after you remove it. You can run snap saved to see all the current snapshots. It doesn’t remove your $SNAP_USER_COMMON directory for that snap (which is where the Firefox snap stores its profiles), so moving from the snapped Firefox to the version from apt is just a matter of moving the .mozilla directory out of ~/snap/firefox/common to ~/
I could have sworn I checked that, but I was a lot less familiar with these things at the time, so maybe I missed it.
I don’t think snaps are a bad thing on principle, my own bad experiences with them notwithstanding. I could also live with a for-profit operating its own curated package repository as part of its service.
I’d personally prefer not to use a client locked into one particular package provider, but if that’s the tradeoff for that provider’s security guarantee that your packages are all Canonical-certified safe, I’d accept that. If it were preinstalled with an OS, that’s fine. If they make it the default Software Store, we’re on par with the Microsoft Store and other App Stores and those too provide a utility and convenience, particularly for those less technically minded. The ship on “don’t bundle your browser with your OS because that’s monopoly grabbing” has sailed long ago anyway.
All of these are things I’m fine with, even if I personally would choose not to use them. If that was all, I’d still recommend Ubuntu as a beginner distro, because it was my intro to Linux too and I found it good at the time.
The thing that irks me is when they’re being dishonest about it. You no longer wanna support a deb package in your repos? Fine, let me know, offer me a one-click migration option for installing the snap instead and moving my data over, give me the whole marketing routine of telling me how much better your new solution is, but make it my choice.
Having a transition package for a name change or breaking up a larger project into modular packages is one thing. Using it to instead run an entirely different package manager pulling from a proprietary repo?
Worse still, if you had trouble with one app so you went and found a non-snap repo, you pinned it with higher priority, reinstalled it from the new source and thought you were in the clear because that worked as expected.
But you forgot or didn’t know to also put a negative priority on the snap source because pin priorities seem intuitive enough, only for unattended upgrades to look at the pins and say “That sign can’t stop me, because I can’t read” (pins from repos I don’t know) and reinstall the snap…
I get that automatic upgrades don’t pull from all repos by default for security reasons, but at least look at the priorities and realise “Ope, not gonna touch that, I’ll notify the user to do it manually if they trust the update”.
And that, for me, is the part that takes it from apathy to disdain; the part that goes beyond “each distro has its own preferences, no big deal”; the part that reeks of a profit-oriented company aiming for vendor lock-in.
To close the topic out: All of this is just explaining my stance; I’m not telling anyone what to do or not to do. You gave your point, I gave mine. By all means, if it works best for you, I’m not getting in your way. I just wish there was a better option.
the difference is that the folder/package structure for other package manager is open and well known
everyone can host their own i.e. apt, pacman or Flatpak repository with little effort
the required folder/package structure for snaps is no longer open and you cannot change the default snap repository either easily
The package structure for snaps is very much open, as is the API for a snap store. There was for a long time an open source snap store implementation, but it died out due to lack of interest by others in actually hosting their own stores, which to me says a lot about whether people actually want to host their own repo or just want to use it as a way to complain.
when I don’t have a choice and I am being forced to use what the distro maintainers think is good for me.
That’s the case on literally any distro.
And just like on literally any distro, you can also install Firefox from FlatPak, the Mozilla repo or from source.
Except on Ubuntu it just installs the snap regardless. If you don’t pay attention you may not even realize that it is a snap. Also the snap store is controlled exclusively by one company with a questionable history.
install Firefox from FlatPak
the Mozilla repo
or from source
In none of these cases will Ubuntu be able to install it from snap instead.
Only the Firefox “package” in the Ubuntu repos actually just links to a script that installs the snap.
I don’t have a problem with snaps as a technology. If you want to use them, then who am I to judge?
But what I do have a problem with is when I don’t have a choice and I am being forced to use what the distro maintainers think is good for me. That is what finally made me quit Ubuntu and switch to Fedora.
Also, Snap is proprietary. That alone is reason enough for me to steer clear.
Well snap itself isn’t proprietary, the backend server distributing the snaps is.
Explain how this distinction matters in the real world?
Snap distribution is as much a part of snaps as Snapd.
Who cares that part of it is open source if other parts aren’t?
If Canonical folded Snap could be taken over by others who could build new server software for it, either from scratch or based off the other projects to develop alternative servers for it, and modify snap to accept multiple repos like that. That’s the difference, also just being able to fork snap like that. Though the fact it hasn’t been done says something about how many real snap enthusiasts there actually are.
If Canonical folded, someone else could come along and reinvent everything on the server side. And that makes it Open Source?
What makes it open source is the fact that the parts which matter most are open source. The part that installs on the system is open source, and because of that it can be more easily tweaked and modified to accept other servers. In actuality it can be modified to do so right now, it’s just that there is little reason to do so because the amount of people enthusiastic about snap isn’t very large, as it has many other problems besides just the centralized server infra.
deleted by creator
https://github.com/canonical/snapd/blob/master/COPYING
I do have a problem with them, the same problem was solved, better, with other technologies like appImage (which doesn’t litter your mount list with 100 meaningless entries).
Even flatpak is better, snap is an also ran they’re trying to force on us without being as good as any of the competitors.
Couldn’t the same argument be made for any distro? They give you what they put in their repos. If you want a deb package, use the mozillateam PPA (which is built on Canonical’s hardware, same as Mozilla’s snap of it).
IIRC, the issue was that - unless you take steps to explicitly prevent it - Ubuntu would occasionally reinstall the snap version. I don’t remember the details, been a while since I had to dance that dance, but I recall it being one of the things that put me off snap in particular, Ubuntu in general and sparked my search for a different distro.
I’m now on Nobara, a Fedora-based gaming-oriented distro maintained by GloriousEgroll (who also maintains the popular Proton-GE)
Like with any time you’re trying to select a specific source for a package, you need to set apt configuration to prefer that source. It’s standard apt behaviour with a standard way to configure it.
Correct me there, but wasn’t the “select source” thing intended to be about different deb sources?
The issue is that what you expect to be a deb package manager ends up redirecting to snap anyway. It’s not a different source, it’s a different system. If I have to manually take steps to avoid using the distro vendor’s default sources because they just redirect to a system I don’t want to use, I might as well look for a different vendor.
And so I did
It’s literally a choice between what deb you want to get. One is a transitional package that installs a different package on the system (in this case the snap) as Debian transitional packages have done for decades, and the other is a third party package that provides the app rather than the transitional package. Just as when there was the ffmpeg vs. libav split, if you don’t want the transitional package to be installed and you want your third-party package from a different repository, you have to tell apt that.
Thanks for that correction then. I wasn’t conscious of that detail.
In any case, the issue remains that, if the vendor’s default repositories push for a type of package I don’t want, I either have to manually find and vet third party repositories I trust or find someone else to rely on for defaults I’m fine with.
The difference between “I want a different source for a single package, so I’ll manually select a different source for that one” and “I don’t trust Canonical to select sources I agree with anymore” is one of scale. I’m fine with manually pinning the transitional package, uninstalling it and the snap (hopefully remembering to back up my profile before realising that it also deletes user data) adding a ppa, reinstalling it and reimporting my profiles just for firefox.
But if I feel like I have to fight my distro vendor over not using their preferred package distribution system, it’s probably better to jump ship - other vendors have beautiful distros too.
(Also, “you can just use a different source” is part of the reason people prefer not to use snap, where you can’t do that)
If you’re fighting your distro vendor over the choice of packages they’re providing in their repos, then yeah, you should probably use another distro. But that’s exactly what I was saying in my original comment above. If you don’t like rpms or flatpaks, you shouldn’t be using Fedora either, since those two packaging technologies are what Fedora uses for their distribution. For me the Linux Mint developers’ hostility to snaps (which in my experience tend to be the best trade-offs for my needs) is one of the many reasons I won’t use or suggest Mint.
KDE Neon provides their own packages in their repo that add Mozilla’s apt repository for Firefox as well as setting up the preferences. In fact, here’s the file, which gets placed in
/etc/apt/preferences.d/org-kde-neon-packages-mozilla-org-pin:# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL # SPDX-FileCopyrightText: 2022 Harald Sitter <sitter@kde.org> Package: firefox Pin: release o=packages.mozilla.org Pin-Priority: 1000 Package: firefox-* Pin: release o=packages.mozilla.org Pin-Priority: 1000 Package: firefox-locale-* Pin: release o=packages.mozilla.org Pin-Priority: 1000The great part of KDE Neon’s approach to it is that since I do want the Firefox snap on my KDE Neon laptop, I can simply run
sudo apt remove neon-repositories-mozilla-firefox firefox && sudo apt update && sudo apt install firefoxto get the snapped version of Firefox.Also, snapd keeps a snapshot of your per-revision configuration from an app for a while after you
removeit. You can runsnap savedto see all the current snapshots. It doesn’t remove your$SNAP_USER_COMMONdirectory for that snap (which is where the Firefox snap stores its profiles), so moving from the snapped Firefox to the version from apt is just a matter of moving the.mozilladirectory out of~/snap/firefox/commonto~/I mean, analogous to firefox example you supplied, you could just delete nosnap.pref and be on your way.
I could have sworn I checked that, but I was a lot less familiar with these things at the time, so maybe I missed it.
I don’t think snaps are a bad thing on principle, my own bad experiences with them notwithstanding. I could also live with a for-profit operating its own curated package repository as part of its service. I’d personally prefer not to use a client locked into one particular package provider, but if that’s the tradeoff for that provider’s security guarantee that your packages are all Canonical-certified safe, I’d accept that. If it were preinstalled with an OS, that’s fine. If they make it the default Software Store, we’re on par with the Microsoft Store and other App Stores and those too provide a utility and convenience, particularly for those less technically minded. The ship on “don’t bundle your browser with your OS because that’s monopoly grabbing” has sailed long ago anyway.
All of these are things I’m fine with, even if I personally would choose not to use them. If that was all, I’d still recommend Ubuntu as a beginner distro, because it was my intro to Linux too and I found it good at the time.
The thing that irks me is when they’re being dishonest about it. You no longer wanna support a deb package in your repos? Fine, let me know, offer me a one-click migration option for installing the snap instead and moving my data over, give me the whole marketing routine of telling me how much better your new solution is, but make it my choice.
Having a transition package for a name change or breaking up a larger project into modular packages is one thing. Using it to instead run an entirely different package manager pulling from a proprietary repo?
Worse still, if you had trouble with one app so you went and found a non-snap repo, you pinned it with higher priority, reinstalled it from the new source and thought you were in the clear because that worked as expected.
But you forgot or didn’t know to also put a negative priority on the snap source because pin priorities seem intuitive enough, only for unattended upgrades to look at the pins and say “That sign can’t stop me, because I can’t read” (pins from repos I don’t know) and reinstall the snap…
I get that automatic upgrades don’t pull from all repos by default for security reasons, but at least look at the priorities and realise “Ope, not gonna touch that, I’ll notify the user to do it manually if they trust the update”.
And that, for me, is the part that takes it from apathy to disdain; the part that goes beyond “each distro has its own preferences, no big deal”; the part that reeks of a profit-oriented company aiming for vendor lock-in.
To close the topic out: All of this is just explaining my stance; I’m not telling anyone what to do or not to do. You gave your point, I gave mine. By all means, if it works best for you, I’m not getting in your way. I just wish there was a better option.
the difference is that the folder/package structure for other package manager is open and well known
everyone can host their own i.e. apt, pacman or Flatpak repository with little effort
the required folder/package structure for snaps is no longer open and you cannot change the default snap repository either easily
The package structure for snaps is very much open, as is the API for a snap store. There was for a long time an open source snap store implementation, but it died out due to lack of interest by others in actually hosting their own stores, which to me says a lot about whether people actually want to host their own repo or just want to use it as a way to complain.
That’s the case on literally any distro.
And just like on literally any distro, you can also install Firefox from FlatPak, the Mozilla repo or from source.
Except on Ubuntu it just installs the snap regardless. If you don’t pay attention you may not even realize that it is a snap. Also the snap store is controlled exclusively by one company with a questionable history.
Read my comment again:
In none of these cases will Ubuntu be able to install it from snap instead.
Only the Firefox “package” in the Ubuntu repos actually just links to a script that installs the snap.
Welcome to the gang. I think you’ll like it here.