What are the advantages and disadvantages of installing via apt and snap?

Question

linux

What are the advantages and disadvantages of installing via apt and snap?

Answer 1

You need to understand the fundamental difference in the approach:
apt is an installation from small packages that together form a large and complex system, while the software can massively share the same files and libraries, which saves disk space, RAM, etc. etc. It must be understood that apt is a package manager for a certain type of package (deb), although at one time there was an option for rpm (maybe it still exists, it just makes little sense after the advent of yum).
snap - installation of a large application with all the dependencies that the rest of the software on the same computer does not use. This wastes extra space on the disk and in RAM. But there are no problems with dependencies, plus snap works on any system and is not tied to a specific package manager and the actual package format.
snap is by and large often used to install heavy applications that can be difficult to package, especially given the variety of distributions (debian / ubuntu and their clones) of different versions present in the world. While the majority of standard commonly used software is more often distributed in the form of packages that come as part of the distribution kit or separately (including in the form of various packages compiled for different versions of systems).

Answer 2

At one time, I also faced the choice of deb or snap. I studied this issue as much as possible. To make the right choice, you need to understand how it works.
I'll start by seniority - with deb. In the traditional deb world, our Linux operating system has a list of software sources called repositories. There are official ones that are stored here: /etc/apt/sources.list and non-official ones that are stored here: /etc/apt/sources.list.d/.
When installing software via the GUI or CLI, the installer first downloads the lists of software available in it from the repositories. Software, as a complex software product, is traditionally divided into logical parts that come in various packages, for this you need to process dependencies using the resources of your PC, this process is called full dependency resolution. The installer of deb packages downloads them from the repository to a directory like /var/cache/apt/archives/, unpacks their contents according to the absolute paths that go in the deb package. Commands like apt clean will remove the packages in /var/cache/apt/archives/ because they have served their purpose and are no longer needed.
In deb, the program is split into different packages, separating libraries / plugins / frameworks into separate packages in order to share them with other programs. A classic example, program A comes in the a.deb package and depends on the openssl.deb package, and program B from the b.deb package also depends on openssl.deb. It turns out that program A and B share (share) a common library from openssl.deb, i.e. depend on the same openssl.deb package.
In the world of snap, the concept of dependency does not exist. And one snap package with the program does not depend on another snap package. The program inside the snap is compressed with everything it needs using squashfs. The package is downloaded from the repository as a snap package to the /var/lib/snapd/snaps/ directory and never unpacked anywhere. The package with the program is mounted to the /snap/[name]/[version]/ directory. Snap is packaged with what it needs to run. For example, inside package a.snap there are program files A and openssl, and inside package B there are program files B and openssl.
When they came up with the snap format, they wanted to abandon full dependency resolution first of all. Most likely, everyone has met a situation where the resolution of dependencies ended with an error. It was necessary to try to solve the situation with commands like sudo apt-get install -f. It was possible to try to reinstall the package with the installation of default settings. All this is not reliability in the world of servers and desktops, but in the world of mobile devices, for which the snap format was prepared - deadly. For example, how to solve a situation with a probable problem on a low-powered device? Moreover, full dependency resolution is quite an expensive operation for the CPU. I needed reliability in the face of atomicity:
1. Downloaded the snap package.
2. It is not expensive for the CPU to mount the package, without full dependency resolution, without unpacking.
3. Got a new version of the program.
4. If the new version of the program causes problems, then you can easily roll back to the old version by remounting to the old version of the package.
Most likely the question arose, do you need more space using snap packages? Yes, more. This is a payment for versioning and reliability. Without share technology, snap packages use more space. To support the rollback mechanism and the ability to return to an old working version, several versions of the snap package of the program are stored on the system.
All programs inside a snap package are isolated from the operating system and from each other by the AppArmor mandatory access profile. In snap terms, technologies are interfaces. An interface is when a plug is connected to a slot. Do you want sound from the program? When packaging the program via snapcraft.yaml, ask that the pulseaudio plug be connected to the pulseaudio slot of the same name in the system (ubuntu-core package). Until now, all slots have been provided by the operating system via the ubuntu-core snap package. That is, all programs docked (connect) only with the slots of the system and received what was required. The developers implemented the connect interface and it became possible to connect snap A to snap B. Using the KDE framework as an example, you can see how the developers used this solution. The first attempts at packaging KCalc produced snap packages of 70 mb due to kde-frameworks-5 inside, but it was worth using the connect interface and moving kde-frameworks-5 into a separate snap package, then KCalc lost weight to 300 kb. The relationship between snap packages is described in snapcraft.yaml, which is added to the package when it is packaged. Snap allows the operating system to have several versions of libraries and ask for a connection to the right one if necessary.
Now let's look at the differences in the operation of programs installed from deb and snap packages. Most Linux systems are discretionary access control (DAC). You installed program A and when you run its binary, in memory it becomes a concept - a process. When running the program on its own behalf, the process will have the rights that our account has. If we can go to the /share/folder_x/ folder and read the secret.txt file, then program A can do it too. In the traditional Linux world, we rely on the decency of the programmers who write the software and the care of the package maintainers who try to prevent abuse by, for example, sending our files to them.
The snap world is a mandatory access control (MAC). When packaging a program, they declaratively describe many things in the snapcraft.yaml file, including which interfaces the program should connect to. These desires will be expanded into the rules of the AppArmor mandatory access system and can be analyzed at /var/lib/snapd/apparmor/profiles/.
MAC is stricter than DAC. The program is in isolation and can only do what is allowed by the profile. Program A running snap will not be able to go to /share/folder_x/ and read the secret.txt file if it wants to. After installing the program as a snap package, any of its binary will not be able to read anything except from the /snap/[name]/[version]/ path.
The advantages of snap include the fact that with any changes in the operating system, you can be sure that the program will not "break" due to changes in libraries / frameworks. Installed once - always works. There are no problems installing and updating software. Always fresh software from the developer, without intermediate links in the person of the maintainer. There are no bindings of the software version to the version of the system, libraries, frameworks, etc.
DEB:
- A program with its libraries is presented as a set of packages that depend on each other.
- Deb packages download, unpack contents by executing straightening control scripts.
- The program from the deb package is not limited by anything and gets access to everything to which you have rights.
- Versioning is more difficult in the deb world. Rolling back to an older version may be technically impossible, because the repository may not have the old package by that time. The downgrade procedure is not easy and is rarely used in practice. Atomicity is not guaranteed. Everyone tries to ensure that everything goes smoothly during the upgrade, but not always the system can be transferred from one working state to another.
SNAP:
- A snap package usually comes with a program with everything it needs. Sometimes heavy frameworks are taken out to a separate snap and connect to it.
- Snap package is downloaded and mounted in a directory, nothing is unpacked anywhere. There are no scripts inside the compressed snap package that are called by anyone.
- A program in a snap package runs in isolation. Gets it through interfaces and doesn't get any access even if you have permission to do so.
- Snap packages support atomicity and versioning. You can roll back the software to a version earlier and the package is either installed completely or not installed at all if there are any technical problems.

Answer 3

shurshur described well. I'll add from myself:
snap-package - when you need the novelty of versions and more frequent releases of new versions. Sort of like Docker, just for app packages.
apt package - when you need stability and official source. Such packages are updated only with the update of the OS version.
Let's say that when you change from Debian stable to Debian testing, it affects the entire OS, but you don't want to lose system stability. And then, if you want a new version of GIMP that is not in the apt repository, install the snap package. All OS stability remains.
You can even install several recent versions of the software without detracting from overall stability.

Answer 4

I don’t see any shortcomings
snap = I don’t use it, I used to have some Wishlist (I set something b = I don’t remember,
but FSE can be solved with standard / on-board tools + wine for especially stubborn))).
linux = you need to understand / get used to it = everything is there, just learn (not just poke the mouse)))
or sit down / return to Windows

Answer 5

snap - as written above, a container with all the giblets inside. It weighs a lot, it starts for a long time. Perhaps now the situation is better, but in due time 10-12 seconds to start the calculator!!! (regular, gnome calculator) on the SSD somehow strained me. It was surprising that in Ubuntu some snap packages were installed by default, and they had to be disposed of by removing the snap and installing the same calculator through the "native" apt. The calculator, by the way, starts instantly. But if you need to install software newer than in the repositories (with which the package manager works, the same apt), there are a couple more ways. This is AppImage (yes, another container that has been renamed several times and has a long history) - such portable versions of applications, in fact, cannot be considered an installation, and Flatpak (which was inspired by AppImage) is a very isolated container, to the point that it cannot use the system theme (this is solved by installing the same theme from Flathub), but it can share environment libraries between several packages. I use both, simply because for some applications there is only AppImage, well, or it is on Flathub. Unlike Snappy, I have no complaints about them, they work in all distributions that I used (I don’t think it exists in ArchLinux at all, but I could be wrong)