3 ms·
> Why is it Canonical's fault that authors of individual applications have yet to migrate Snaps? Canonical is the one pushing for snaps, and they own the centr
by thayne 7y ago
> Why is it Canonical's fault that authors of individual applications have yet to migrate Snaps?
Canonical is the one pushing for snaps, and they own the centralized Snap store. On most other distros snap support is either non-existent or much less than for package manager or even flatpak. Let me turn that question around. Why should individual application developers have to package their apps as snaps, which are mostly just used on ubuntu?
> Maybe I'm just naive and not doing advanced super user stuff these Snap haters are doing
Most of the complaints here have been about the automatic updates (and specifically that you can't disable it, not that they are on by default). But, personally, I am more concerned with the fact that snap apps run slower. Snap uses squashfs for the program and any associated files, and squashfs is not designed to be fast, it's designed to store a file system in a small amount of (usually read-only) space, such as on a Live CD. Besides slower startup times, snaps also take up more space on disk (which may not be a huge issue for most people), and more time to download (a bigger issue) since each snap has to include its own copy of all its dependencies.
The containerization of snaps provides some security benefits, but there are also a couple security concerns with snaps:
- Unlike the official apt repos, the snap store is not curated. It is much easier to put malicious software on the snap store than get in the official apt repos.
- Since all dependencies are bundled with the snap, if there is a vulnerability in a common dependency, such as libc or openssl, then instead of updating a single package on your system to get a fix, you need to update all of the snaps. And you are dependent on the maintainers of all of those snaps to watch for such vulnerabilities and make sure their dependencies are kept up-to-date.