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.
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.