Snaps versus Debian packages

[popey]

Hi Jeff. I am replying to you, because you asked some questions, and made some points. But what I say below isn’t a slight on you, nor meant as an attack or to dismiss anything you have said. Your opinions are valid, but may be based on some assumptions or misconceptions. No hate or disrespect intended.

I’m going to just trying to explain things as I see them, with data. I’ve worked on snaps for years, since the very start, so while I may come across as a “shill” or “biassed”, I’d like to think I also come across as empathetic, understanding, and a little bit knowledgeable.

I am sorry this is very long. Unfortunately the “why snap?” question is not simple, and isn’t answerable in one line.

@Jeff

Are you seriously asking for benchmarks of simply running “native” executables w/o unpacking overhead vs some kind of packing system with a kind of virtual FS?

Yes, it is a reasonable ask when someone states something as fact, to ask for data to back it up. I have, many times, run snaps and debs of the same application to check startup time, and user experience. I did this for years, in fact. The reason for this was to be able to help the developers of snapd identify where bottlenecks were.

Also, sometimes, the snap is faster than the debian package. That can be due to a lower number of blocks needing to be read from disk - thanks to the snap being compressed on disk. The speed of dynamic decompression with CPU enhanced instructions, these days, vs the speed of loading more blocks from disk, can mean the snap loads faster.

I took a “random” snap that I publish and compared running it to running the standalone binary, sat in my home directory. I put the python script in a gist snap-vs-nonsnap.py. It just runs any two commands 10 (or however many you like) times, and shows the fastest, sloest and average speeds.

The results, well.

Command	Min (s)	Max (s)	Average (s)
snap run	2.06	2.48	2.17
~/bin/syft run	2.04	2.47	2.19

Feel free to try this yourself with this or any other command. It’s actually quite fun, if you’re that way inclined

Thanks to the work of those of us providing data, and the drum beat of feedback from the community, improvements to snap startup time were made. This includes:

• Moving some parts of application launch to install, such as font cache generation. The upshot is the application starts faster, but is slower to install and update. A tradeoff most people felt was fine
• Providing an alternative compression algorithm for snap packagers. Some snaps (such as javascript heavy ones) contain many small files which cause an overhead on decompression.

There were almost certainly other changes I’m not aware of, as I stopped looking at snapd development a few years ago.

That said, there’s always room for improvement, so if you can show a specific application, or group of applications adversely affect the experience, provide the data, and help fix the issue.

@Jeff

Notice that tsugu-sk argues for COMPLETE transition to snap, i.e. to have every single package in snap.

There are a few possible responses to this:

1. Are they, really asking for that? If they are, then they too may be under the misapprehension that this would be easy, and worthwhile
2. There is already an “all snap” system - it’s called Ubuntu Core - so this ship has long sailed. I even tested out the desktop version on my steamdeck, for “fun” a couple of years ago.
3. People seem to interpret “I think there should be more snaps of popular things” as “GET RID OF DEBS”. Anyone who thinks about this for a little bit will:
   a) Note that’s not what’s being suggested
   b) Realise that (Ubuntu Core aside) it makes no sense to replace every deb package with a snap for a few reasons

Let’s dive into why all the debs aren’t going away, even if it might look like that, and some people (who haven’t thought this through) have been saying this is happening, or has happened already, for years already:

1. The engineering effort required to re-tool every deb as a snap is not insignificant. “Ain’t nobody got time for that”.
2. It makes no technical sense to replace some debs with snaps. Some examples:
   a) Low-level libraries used by other applications at build or runtime
   b) Developer tools specifically created to maintan debs
   c) Individual packages served well by other ecosystems - npm, pypi, rust crates etc
3. Many snaps (and flatpaks, and appimages) are actually made from debs. “Let that sink in” as they say. A snap, (or flatpak, or appimage) will have, inside it, none, some or many files that came from debs. If you take away debs, then all those snaps (and flatpaks, and appimages) will need to be re-worked, for no perceived benefit.

I can illustrate this with a terrible python script that I just wrote called debs-in-snaps-py. It looks at the 140+ snaps I have installed on my primary laptop, and (if they have a manifest file (some don’t)) figures out what debs were involved in the building and shipping of the snap.

The results may surprise you, and are in debs-in-snaps.md. There are tons of debs used in the production of snaps. Here’s the most common ones, that I put in most-used-debs.txt. Here’'s the top ten.

$ grep '^  -' debs-in-snaps.md  | sort | uniq -c | sort -rn | head -n 40
     29   - libxdmcp6=1:1.1.3-0ubuntu5
     29   - libxcb1=1.14-3ubuntu3
     29   - libxau6=1:1.0.9-1build5
     27   - libx11-data=2:1.7.5-1ubuntu0.3
     27   - libx11-6=2:1.7.5-1ubuntu0.3
     26   - libxext6=2:1.3.4-1build1
     24   - pkg-config
     23   - x11-common=1:7.7+23ubuntu2
     23   - libxcb-randr0=1.14-3ubuntu3
     23   - libasound2-data=1.2.6.1-1ubuntu1

In case it’s not clear, what this shows is that there’s a significant amount of investment in debs, which isn’t going to be just jettisoned into the sun. These packages are important for snaps, flatpaks, appimages, and a thousand other things like GitHub runners, developer workstations and more.

Debs aren’t going away

@Jeff

Can you give us a single reason to have all even fundamental open source apps/packages in snap?

I can give a few general advantages to having prominent and popular packages as snap, sure:

Developer & user advantages:

• Snaps can be confined, so they can’t grub around in your ssh keys, photos, or other data

• The snap store provides interesting metrics for developers

• One snap package can can be run on many different distros (e.g. the snap pictured below is installed on over 300 combinations of distro and version)
  

  

• Snaps don’t have root access to your machine, like debs do

• Snaps (generally) don’t catastrophically break upgrades, like debs from PPAs often do

• Developers are in control of the packaging. They don’t have to wait for a review from a Debian packaging expert, or archive maintainer. They can hit the ‘release’ button when they like - as is common with most other software stoeefronts.

• Developers can push new versions of their applications to users very quickly, and know that most of their app users will be on the most up to date, supported and secure version, typically within a week.A good example is the grype vulnerability scanner (that I maintain). When the upstream developer publishes a new release, I can get that snap published within minutes.

• They can publish multiple package versions under one name. A good example is the node snap, which has multiple published supported versions of the popular javascript tools.

• LTS users can get newer versions of software, faster.

• Snaps can be rolled back easily with snap revert, if something goes wrong.

• Snap data can be isolated in a known folder structure, making for easier backups, and organisation.

• Developers can publish beta versions, or ‘bug fix’ versions in channels, so users can confirm their isssues are resolved, before publishing to everyone

• Users can control when updates happen, down to the time of day, very easily

In the interests of balance, here are some disadvantages.

• Snaps are sometimes unmaintained, and not updated for long periods
• It can be difficult for users to figure out where to file bugs
• Snaps don’t integrate with the bug reporting system that exists on Ubuntu
• Snaps aren’t exactly the same experience on every flavour, or on non-Ubuntu distros
• Snaps sometimes break in interesting ways (to be fair, so do debs, but somewhat less so, as they’ve been around a while longer)
• Snapped desktop applications sometimes exhibit visual issues:
  • Sometimes they don’t fit the desktop theme
  • HiDPI support is sketchy
  • Mouse cursors change weirdly
• Confinement can get in the way - for example saving a PDF from one snapped application can end up in a folder that is inaccessible to another snapped app
• Snap folder structures break with convention

There are more, of course, but I wanted to ensure you didn’t think I’m just shilling, but accept that like anything, nothing is perfect.

@Jeff

I can’t imagine how many mounts will there be returned by “mount”… Hundreds?

Not many, or none, if your system is configured well, even with over 140 snaps installed, this is a solved problem.

echo alias mount='mount -t nosquashfs,nocgroup,nsfs,tmpfs,fuse' >> ~/.bashrc
echo alias df='df -x squashfs' >> ~/.bashrc

I hope the information and data I have provided is seen in the respectful and educational way it is intended.