Why snap?

snapd
1

I am unclear why snap is better than apt?

2

can you point to any official source for that statement ?

they are completely different package mechanisms with completely different purpose … i can not imagine anyone would call one “better” than the other …

4 Likes
3

I think that was meant as an open question, a request for clarification.

Can you elaborate on how far the mechanisms are different and explain the differing purposes?

4

From a developer perspective:

Pro Snap

  • Packages are more up-to-date
  • It’s a lot easier and faster to publish your updates.
  • When using deb packages, it’s better to use a PPA if you want to release in small iteration steps.
  • Different versions in channels (stable, candidate, beta, edge).
  • Finding a Debian maintainer is hard
  • Deb integration process is slow and frustrating
  • Sandboxing of applications

Pro deb packages

  • Smaller packages because of access to shared resources
  • Faster (from my experience)
  • Better IPC
  • Less overhead (e.g. snapd)
  • If there’s a bug in an essential lib, all snap maintainers need to update their snaps, with deb you only need to update the lib
5

i can not imagine anyone would call one “better” than the other

Out of curiosity, do you know why Firefox and Gimp are not in the Ubuntu repos anymore and Snap is preferred? Maybe this answers @ineuw 's question.

6 
$ LC_ALL=C apt policy gimp
gimp:
  Installed: (none)
  Candidate: 2.10.30-1build1
  Version table:
     2.10.30-1build1 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
$

gimp is obviously in universe …

firefox was switched to snap because mozilla asked for it.

maintaining a deb for multiple different (LTS/and current non-LTS) releases (with multiple different library versions and base systems) is a huge amount of work. maintaining a single snap that runs on all supported releases is a lot less work …

2 Likes
7

Oh, I missed this. Sorry, my bad.

maintaining a single snap that runs on all supported releases is a lot less work

I strongly can confirm that

1 Like
8

Okay, here is (a very incoplete) list of differences:

Debian packages:

  • apt/deb packages typically package binaries into the smallest chunks (libraries, common data, executables, help files, specific data, all go into separate packages) and build a big and complex network of package interdependencies (see SeedManagement - Ubuntu Wiki for a graph of all dependencies of one Ubuntu release for example)

  • Need to come from the same archive and need to be built from source to link properly against their depending packages, if you replace a package in the low level chain (i.e. a library package) with a modified package the whole layer higher up breaks. This is pretty fragile due to its complexity and requires a high level of knowledge about required dependencies and a high level of maintenance when an underlying package requires the transition of 100s of packages in the higher up layer).

  • Are installed with 100% root permissions and debian packages use maintainer scripts that can modify every aspect of your system (including i.e. changing the root password, adding accounts, opening ports to allow login etc).

  • security of debian packages is hard-bound to the source they come from and to the trust you apply to this source due to the above (i.e. a deb package from any PPA can fully take over your machine without you even noticing)

  • once installed debian packages get uncompressed on disk and the unpacked binaries are modifyable and tweakable by system administrators. security of debian packages in the ubuntu archive is maintained by signed “Package” files for the archive, but not on a per package level.

  • Are usually the core set of a distribution and are rarely mixed with other package systems (i.e. on a rpm based distro you likely do not use deb’s but will try to find an rpm, (indeed here are exceptions where people mix and mesh but this requires a high level of maintenance))

  • Can only “move forward”, downgrading a deb on an installed OS usually means you also need to reverse-downgrade all depending packages which is often impossible.

  • debian packages do directly run on your hardware, without any security measure, containerization, confinement or any other isolating mechanism.

Snap packages

  • Are readonly compressed filesystem images that are GPG signed, so that they are 100% immutable and can not be modified locally at all.

  • Never get unpacked on your system, but only loop mounted, so the compression stays intact and they consume significantly less disk space than the identical set of files packaged as deb packages

  • Must be self contained, i.e. all dependencies of all executable binaries in the packages need to be shipped inside the snap or via a content snap or extension.

  • Are confined and can only communicate with the outside world, your hardware or other system resources via pre-defined interfaces (see snap connections).

  • Are getting an automated security review for every single upload and get automatically blocked from being released when they do not pass this test (at which point they go into a manual review process)

  • Are using binary diff files on upgrades so that only the changed bits are actually downloaded through the network when updating a package.

  • Are transactional, you can always go back to the former version using the snap revert command (or if you are a packager you can use the built in self-test mechanism to do this automatically to check that an upgrade was successful) .

  • Come with a built-in self test mechanism (see above), that allows package maintainers to run tests on upgrades and roll back as needed when these tests fail, so you have a guarantee of an always running application, even when a faulty update might be released (this indeed depends on the quality of self-tests shipped :slight_smile: ).

  • Come with a builtin backup mechanism to protect application data (see snap help save)

  • Come with a built in configuration mechanism to manage all configuration of the contained binaries if desired (see snap set/get)

  • Have a central management system via a REST API that allows you to easily implement a centralized fleet management though the snapd-control interface so you can centrally manage your complete fleet of IoT devices, servers, cloud instances or enterprise class desktop installations.

  • Provide a very powerful built in update management system that allows you to schedule updates according to your enterprise IT maintenance plans.

  • Come with different channels for different levels of quality of the software shipped (edge → typically the git HEAD for developers, beta/candidate → typically used by QA teams to run their QA pipeline, stable → release channel to ship your software to end users)

  • Provide tracks that allow packagers to provide an unlimited set of different versions of the same package (see i.e. snap info lxd)

  • Allow parallel installs of the same package unlimited times from the same or different tracks/channels

  • unless you use Ubuntu Core, they are typically not the main package system of the OS but are designed to peacefully co-exist with existing other package mechanisms (rpm, deb, flatpak, appimage, emerge etc etc)

There are indeed many more differences that i did not cover …

4 Likes
9

Snap means (mostly) never having to worry about library compatibility issues! :slight_smile:

I run manjaro (so not quite the same as apt vs snap, but really the same issues crop up with ubuntu too) and a library was recently updated which broke libreoffice, rather than stuff around with trying to downgrade that package, I just installed the snap version of libreoffice and I was back in business.

3 Likes
10

ogra, would you be kind enough to elaborate a little bit more about controlling a fleet of machines using API? Case I have in mind, being more specific, is desktop installations. What could be possible use cases, for instance?

11

well, see:

and:

you can run a local agent that you hook up to your existing fleet management (via MQTT or whatnot), you could write a web based management tool hooking up to the snapd API and if you use a brand store to attach your desktops to you could as well package the whole thing as a snap using the snapd-control interface…

there is also an example fleet management implementation (IoT focused, but you can likely easily adapt it to be desktop focused) using digital twins at:

1 Like
12

Thanks for your explanation, ogra; will take a look at the references to dive deeper into the possibilities.