They’re a packaging solution for apps and dependencies. They’re apparently quite comfortable for app developers to use too. There was a hiccup where some apps really struggled to run well as snaps, but AFAIK that was fixed.
The common issues are snapcraft being the only repository and the methods of pushing them:
Snapcraft is where the packages are stored and loaded from, and it’s a closed-source repo hosted and controlled by Canonical, with no option to configure snap to use a different source. That has advantages for security, if you trust Canonical to vet and take responsibility for the packages on their system, but some people chafe at that lack of control. Compare to flatpak, where you can add arbitrary repos, so any distro vendor can have their own set of packages and versions they’ve vetted for stability and compatibility, but if I want a different version than my vendor maintains in their remote, I can use a different remote for certain apps instead.
The second issue is that the classical apt system, which used to install .deb packages, was utilised to install snaps instead, so you’d run apt install package and expect a .deb to be installed, but instead it just downloads a script that runs snap install package and you get a snap instead, which is particularly annoying when you previously had it as a deb and it suddenly gets replaced. The argument here is a smooth transition to the “better” system, on the premise that snaps are better and the assumption that users won’t care or notice. In some cases (the hiccups mentioned earlier) that just wasn’t the case and people got frustrated, but even if it worked, some people (including me) take issue with expecting a deb and getting a snap - if I want a snap, I’ll use snap, and if your deb is deprecated, offer me to switch instead of silently installing the alternate source instead.
Deb packages have dependencies on other packages. To install and run a given application, you will have to install other packages (typically libraries the app depends on) too. In the case of using apt, you may see it show a list of packages to install, even when you asked for just one - those other packages are things the one you asked for requires.
These packages are shared across apps. If I install one app that requires a specific graphics library, then later install another that requires the same library, it won’t have to install it again. On the other hand, if some library introduces changes that break something, updating that shared library because one app requires a newer version may break a different app which required the old version and isn’t compatible with the new one.
Snaps on the other hand are self-contained: All the dependencies are included with the snap, frozen into whatever version the snap author chose. You can have multiple different versions of the same snap installed in parallel, and each will have their dependencies isolated from each other and the rest of the system. Additionally, they come with certain security measures like restricting the app’s access to the filesystem, network, display etc.
As a downside, snaps can be larger (but don’t have to be, as they can be stored compressed because the dependencies don’t need to be available elsewhere) and take a little longer to start (though this has apparently been much improved).
So they’re not generally a bad thing, all in all. I understand their advantages, I respect that they can be a comfortable solution for devs, I like the idea behind the security measures.
For my personal experience:
I recall that the Firefox snap had issues as opposed to the deb (among other things, the startup time was atrocious for me), which was how my issues with it started, because it took some effort to figure out how to get a deb version again and make sure I kept getting deb versions. Some other app - I don’t recall which one - also had persistent lag issues which were apparently due to some permissions problem, where security evidently hamstrung usability.
Accordingly, I was somewhat disgruntled with having my working app ripped out from under me and replaced with a worse one and no comfortable way to get back. I had issues with my Firefox profile too, which turned out to be user error on my part, but obviously still annoyed me in absence of an easy migration mechanism between the two.
Again, these issues may be fixed now, and they might not be issues for everyone in the first place: if you start out with the snap, migration won’t be an issue, and if it runs well, it may well be a better solution for you. I personally resent the philosophy of “Here, let me assume you want a different thing and just swap it out for you”, but you don’t need to share that resentment.
To expand on the hate of snaps:
They’re a packaging solution for apps and dependencies. They’re apparently quite comfortable for app developers to use too. There was a hiccup where some apps really struggled to run well as snaps, but AFAIK that was fixed.
The common issues are snapcraft being the only repository and the methods of pushing them:
Snapcraft is where the packages are stored and loaded from, and it’s a closed-source repo hosted and controlled by Canonical, with no option to configure snap to use a different source. That has advantages for security, if you trust Canonical to vet and take responsibility for the packages on their system, but some people chafe at that lack of control. Compare to flatpak, where you can add arbitrary repos, so any distro vendor can have their own set of packages and versions they’ve vetted for stability and compatibility, but if I want a different version than my vendor maintains in their remote, I can use a different remote for certain apps instead.
The second issue is that the classical apt system, which used to install
.debpackages, was utilised to install snaps instead, so you’d runapt install packageand expect a .deb to be installed, but instead it just downloads a script that runssnap install packageand you get a snap instead, which is particularly annoying when you previously had it as a deb and it suddenly gets replaced. The argument here is a smooth transition to the “better” system, on the premise that snaps are better and the assumption that users won’t care or notice. In some cases (the hiccups mentioned earlier) that just wasn’t the case and people got frustrated, but even if it worked, some people (including me) take issue with expecting a deb and getting a snap - if I want a snap, I’ll use snap, and if your deb is deprecated, offer me to switch instead of silently installing the alternate source instead.Thank you for explaining that. I’m new to Linux and really didn’t understand that snap thing I heard about
In that case, let me add a few more details:
Deb packages have dependencies on other packages. To install and run a given application, you will have to install other packages (typically libraries the app depends on) too. In the case of using apt, you may see it show a list of packages to install, even when you asked for just one - those other packages are things the one you asked for requires.
These packages are shared across apps. If I install one app that requires a specific graphics library, then later install another that requires the same library, it won’t have to install it again. On the other hand, if some library introduces changes that break something, updating that shared library because one app requires a newer version may break a different app which required the old version and isn’t compatible with the new one.
Snaps on the other hand are self-contained: All the dependencies are included with the snap, frozen into whatever version the snap author chose. You can have multiple different versions of the same snap installed in parallel, and each will have their dependencies isolated from each other and the rest of the system. Additionally, they come with certain security measures like restricting the app’s access to the filesystem, network, display etc.
As a downside, snaps can be larger (but don’t have to be, as they can be stored compressed because the dependencies don’t need to be available elsewhere) and take a little longer to start (though this has apparently been much improved).
So they’re not generally a bad thing, all in all. I understand their advantages, I respect that they can be a comfortable solution for devs, I like the idea behind the security measures.
For my personal experience:
I recall that the Firefox snap had issues as opposed to the deb (among other things, the startup time was atrocious for me), which was how my issues with it started, because it took some effort to figure out how to get a deb version again and make sure I kept getting deb versions. Some other app - I don’t recall which one - also had persistent lag issues which were apparently due to some permissions problem, where security evidently hamstrung usability.
Accordingly, I was somewhat disgruntled with having my working app ripped out from under me and replaced with a worse one and no comfortable way to get back. I had issues with my Firefox profile too, which turned out to be user error on my part, but obviously still annoyed me in absence of an easy migration mechanism between the two.
Again, these issues may be fixed now, and they might not be issues for everyone in the first place: if you start out with the snap, migration won’t be an issue, and if it runs well, it may well be a better solution for you. I personally resent the philosophy of “Here, let me assume you want a different thing and just swap it out for you”, but you don’t need to share that resentment.