Snaps versus Debian packages

[Jeff]

@tsugu-sk

wouldn’t it make sense to get rid some of the traditional .deb packages in favour of already existing snaps?

Ubuntu will loose a LOT of users including me if that happens. I personally will switch to Mint.

[tsugu-sk]

I don’t think many would care, or know how the apps are packaged. I think it makes sense to only maintain one version of a package across all Ubuntus. But ultimately it’s not up to me.

[Jeff]

Of course many would care. The load speed of regular .deb and snap are incomparable. If one wants to keep only 1 package type, then .deb is the way to go.

[VMC]

I will switch too, if I loose apt packages.

[wxl]

That argument would probably carry a bit more weight if you had some real world tests. Care to provide some? Pick a few apps so it’s not just relevant to one, test many times so it’s statistically significant, test using the same hardware (although perhaps might be useful to provide 3 different tests for 3 different levels of resources) and most importantly, test in the same way.

[Athayde]

With all due respect, life is about choices based upon certain needs. As far as I concerned, there are no reasons at all to underscore or support hypothetical event such as “From now on, Ubuntu will not accept .deb packages”.

[ian-weisser]

Snap vs Deb discussions tend to become heated, so I’m putting this topic into Slow Mode for a few days.

• Your posts must be separated by several hours.
• You won’t be able to edit your posts.

So be sure, before you post, that you are saying exactly what you want to be saying.
And be sure that your post is in line with the Ubuntu Code of Conduct.

Ubuntu Discourse is package-agnostic. We welcome and provide support for debs AND snaps.

[Jeff]

@wxl

That argument would probably carry a bit more weight if you had some real world tests.

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?
Notice that tsugu-sk argues for COMPLETE transition to snap, i.e. to have every single package in snap.
Can you give us a single reason to have all even fundamental open source apps/packages in snap?
I can’t imagine how many mounts will there be returned by “mount”… Hundreds?

[wxl]

There certainly are arguments to be made for how easy software distribution is for universal packages of all kinds. It’s entirely possible to provide a wide variety of distros across a wide variety of release versions the most recent version of the software in a single package. That’s exponentially more difficult with traditional package forms— and I don’t just mean Debian packages but all of them.

I see pros and cons for both, though. By contrast, you seem to have incredibly strong opinions for only one side of the argument. So why not share the logic behind those opinions? If you’re right, wouldn’t you rather everyone see that? If you’re so certain of yourself, it should be pretty trivial to prove your point. And then we’d be all better off for knowing it.

[tsugu-sk]

I should elaborate to not seem like I’m trolling or something.

On Snapcraft we can find packages such as curl, cups, and likely many others. I tried the curl snap just for fun, ran a script and it turned out curl couldn’t access /usr/ or a similar directory. So, I went back to the regular .deb version. This can be fixed. And issues like this would get fixed if this was the default package that users relied on.

@jnsgruk said:

Delivering a Linux distribution is a monumental task. With tens of thousands of packages across multiple architectures, the workload can be overwhelming
…
I’d like to focus on enriching our build process with modern ideals and processes for automating the version bumps, testing, performance benchmarking and releasing of packages in the archive

The simplest packages to maintain are those that don’t exist. So I propose to use the already existing snap packages where it makes sense while improving them to be on par with their .deb counterparts.

I’m not saying “scrap regular Ubuntu and replace it with Core Desktop”. In fact Snaps rely on the existence of regular Ubuntu. When you install ‘core’ that’s a heavily stripped down version of that LTS.

[tenplus1]

I would much rather have official .deb packages to reduce disk space and increase performance and improve compatibility, and if a later version is required then use an author packaged flatpak or snap.

[vidtek99]

I would happily switch to snaps if two conditions can finally be met:

1. The same ability as .debs have to be installed for all users without going through convoluted hoops.

2. The incredibly slow performance of snap installs compared with the .deb package, Mozilla in particular.

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

[TonyS]

The main downsides to the current approach to Ubuntu’s choice on packaging:

• Flatpak seems to be dismissed even from consideration for inclusion in the new App Store. Flatpak is growing, and I think having Flathub apps available from the App Store should be a no-brainer for a distro that presents itself as an easily accessible, main usage Linux desktop distro.
• Snaps don’t always integrate well with GNOME. Unless things have changed recently, I can’t look for snaps from the overview search, nor do GNOME apps like Calculator or Weather integrate with the search function or the notification area. This cripples the GNOME experience, which is kind of a big deal for me.

[paulw2u]

@vidtek99

The incredibly slow performance of snap installs compared with the .deb package, Mozilla in particular.

That may well be true of ‘Mozilla’ and I think you might well be right in the case of Firefox and Thunderbird. How can you say that is typical of all snap installations?

Until recently I was a regular user of VSCode. I used both the stable and ‘Insider’ releases, which I always installed as a snap. For reasons which are not relevant here I needed to install the .deb package from Microsoft’s own repository on a temporary basis. The installation time increased significantly while using Ubuntu 22.04 on a relatively fast laptop.

I reverted to the snap version of VSCode as soon as I was able to and so benefited from much quicker install or update times.

[vidtek99]

@popey Who works on the snap ecosystem put some real data in his post for us. It seems there are some apps which work faster on snaps than as a .deb. This is great news as without exception, every single snap I tried when snaps first became a thing the snaps were noticeably slower than the equivalent .deb package. Maybe it just happened that I use those snaps that happened to be slower.

For me the slowness is one thing that I could live with if only the snaps behaved the same as .deb when it comes to multiple users, or even the same user when using particular directories. The frustration that occurs when access is denied to a particular function because it was installed as a snap instead of a .deb is something I will not tolerate. I understand it’s a function of the security decisions taken with the snap ecosystem, but for me, I prefer to have slightly less security with function taking priority. After all, if I am unable to access a particular function on my machine, what’s the point of having it?

If that issue can be sorted, then snaps is a great idea, although why do we need snaps, flatpac and all the other packaging systems? Wouldn’t it be great for one size fits all without these sort of issues?
Cheers Tony

[wxl]

@vidtek99

why do we need snaps, flatpac and all the other packaging systems? Wouldn’t it be great for one size fits all without these sort of issues?

That’s exactly what Snaps, Flatpaks and other universal packaging systems try to solve. You can use Snaps on Ubuntu, Fedora, Arch, etc. etc. etc. You can use Debian packages (“.debs”) only on Debian derivatives (e.g. Ubuntu, Mint, etc.). Nearly every distro has their own non-universal system. The universal packaging systems attempt to solve this problem, which in turn makes it a lot easier for software developers to distribute their software. Re-read what Alan said as he address a lot of that (and more).

[vidtek99]

@wxl I understand that is what they are supposed to do. It just seems the technical issues are so complex to achieve the desired outcome that as I’m turning 75 in July I may never actually live to see it…

[VMC]

I’m with Jeff here. No Snap period! All the propaganda that the Ubuntu members are trying to sell may work for new users, just not me. It will be a sad day if/when deb packaging ends.

I started with Horary years ago, and I’m hoping that my 24.04 will be safe with deb.

[wxl]

@VMC

All the propaganda that the Ubuntu members are trying to sell may work for new users, just not me

What I see from the propaganda camp is a lot of reasoned arguments. I’m not saying they’re right or wrong, good or bad, but at least there is something of substance to what they’re saying. By contrast, what I see from the other side of the argument is a lot of statements like yours, though. Saying “Snaps suck!” doesn’t do anything to add to the discussion on the subject. What does add to the discussion is providing information, logic, and data. At least @vidtek99 points out a legitimate problem in Snaps.

So, I ask you: why doesn’t it work for you? Please be elaborate and verbose. The other side might be missing something that’s obvious to you.

As a somewhat related aside, I was reading Debian history today and this caught my attention:

some debate arose between members of the project – some felt that the Debian-specific format created by dpkg-deb should be dropped in favor of the format produced by the ar program

So even the almighty Debian package had its own growing pains that created friction in the community. But they survived and thrived. I’m sure that occurred through trying to work together. Let’s do more of that. I mean, isn’t that baked right into the very name of Ubuntu?