Please, do not use snap into UBUNTU, it's too early

There is no debate, I repeat:
Deb packages should be privileged, not snaps.

Snap packages have more disadvantages than advantages, they should not be recommended.

If you want to offer software in a more recent version, offer a PPA rather than a Snap.

  • Snap is not really secure
  • Snap is not efficient
  • Snap is slow
  • Snap takes up too much disk space
  • Snap is not adopted outside Ubuntu and derived (even Mint based on Ubuntu doesn’t want it)

To have a debate, I want to address some of your points:
Snap is not really secure
What is really secure? Debs certainly not. In comparison a containerized package system is more secure than without being containerized.
Snap is not efficient
Why? I didn’t find any deficiencies other than being slower.
Snap is slow
That might be an issue with small apps but bigger apps will not be instant, regardless of Deb vs Snap
Snap takes up too much disk space
Well, let’s admit that it takes more space than debs or even flatpak. If only few apps are chosen that will not matter in the grander theme of things.
Snap is not adopted outside Ubuntu and derived (even Mint based on Ubuntu doesn’t want it)
That is a non-issue because it is up to your distro to provide most of the software to you. And they have to choose in what format they want to deliver. It is not that deb-PPAs and Flatpaks will suddenly go away just because Ubuntu ships some Snaps (they even do now). That Red Hat (biggest Linux upstream around!!) and SuSE didn’t support debs, didn’t kill neither Debian nor Ubuntu.

  1. Wine should not be used at all, for it is to run Windows apps, not Linux apps.
  2. You have to trust the web browser you use, and if you are quite worried, if some organisation spies on you, use the incognito method. I trust the web browser, but not the "snapped’ one, if there is one. I’ll never use it.

This is not always true, see, for example:

$ snap info 0ad
  stable:    0.0.23b-alpha 2019-06-11 (91) 949MB -
$ apt show 0ad-data
Installed-Size: 2,093 MB
$ snap info chromium
  stable:    75.0.3770.100 2019-07-04 (784) 159MB -

Deb size (I don’t have it installed):
amd64 75.0.3770.90-0ubuntu0.18.10.1 [Package size:] 60,145.7 kB [Installed size:] 216,708.0 kB

These snaps will likely take up more space in practice because the three most recent versions on your system are kept by default so that you can revert easily to the previous version if the new version doesn’t work on your computer (it’s not as simple as this with Apt/Debs), this is customizable, so I think you can just have one verson stored (the version you have installed) if you prioritize disk space over being able to rollback app updates.

The reason why these snaps are smaller than the Debs, however, is because the apps are stored as squashfs filesystems, rather than uncompressed. This is actually an improvement on how Debs work, if you prioritize disk space usage! On the other hand, more space is taken up if an app’s dependencies aren’t included in the core snap or a base snap (e.g. core18 or kde-frameworks-5-core18), since the app has to bundle these dependencies, but this is good, the snap knows that dependency version it is running on on any computer, and this can thus be tested and dependency version differences (as is the case with Debs, which need to run on the possibly different dependency versions between Debian, its versions, and its derivatives, and their versions) are no longer a problem because they’re the same on every computer which supports snaps.

1 Like

We talk about .debs here (sort of negatively), and so on. Do you find a package named .deb anywhere in your installed system? You don’t.

Download a .deb package and unpack it, well, twice, and you see files that are to be placed in different places, /usr/share, /usr/lib and so on. And, if you unpack a “packed” deb package and place most of the unpacked files in relevant places, but won’t place those that allow apt to change/upgrade, you have no worry. Apt won’t update/change, or place an additional file in.

Now, the apt “installer” would “unpack” deb package and the “install” those “unpacked files” in relevant places, if you use apt to install them. And, it doesn’t leave a residue, after “installing.”

A deb is a packed amount of files, packed a different way, the way how Debian became such a well known, well respected OS, the Universal Operating System. And, everything is here.

All I want to say is: Use the Snaps but do not mess up with Apt / Deb.

As I posted in the links below, transforming the Apt into a Snap wrapper is a HUGE mistake that will charge a big price very soon.

Snap is really a nice tech and it’s impossible to stop it’s usage. It’s really nice to think about a very compact and secure system with a small set of libs and Snaps to be a source of new apps. But if an app is not supported by apt/deb anymore just deprecate it and moves on, as it was done with Ubuntu 12.04.

Ps.: Sorry if someone already said that but i got here late and i don’t have time to go through all the messages.

1 Like

The toggles work fine but after enabling/desabling you can’t visually see the change on the software store. You have to go to CLI to see the change

I have opened a new thread to discuss more specific problems of snap desktop integration here: Some snap desktop integration shortcomings


Actually, don’t think snappy is an bad idea.
But it’s still a bit early for an LTS system.
Snap apps have some problems I can’t stand.
1, Ugly font rendering
2, Lack of 3rd party theme support
3, bad support of CJK input method.
Hope newer version snap apps can solve these issues.

1 Like

Currently, the biggest problem of snaps is their slowness at first launch. It’s really painful. This defect alone justifies not using snaps!

On the French forum of Ubuntu (I’m French), many beginners have software problems only because of snaps. Many do not understand for example why it’s slow.

For example:

If you do not understand French, basically a user asks why the software installed with snap takes 3 minutes to start …

that’s why I recommend that Ubuntu developers do not activate a default snap.

I’m not saying that we have to give up this technology but it will be necessary that the snaps is just an alternative to install a software but not the main method by default.

So it is a big mistake to impose snap for Chromium for example, we must continue to propose the package deb.

Ubuntu is the only linux distribution that makes this mistake

1 Like

@sibe39 You don’t need to keep repeating the same message here. It’s not useful to the conversation.

Looking at the thread you posted, according to Google translate the thread suggests that all software that’s snapped takes 3 minutes to load. This is just factually not right. It’s certainly right that on first launch some snaps can be slow to launch, and faster on subsequent launches. We are actively working on improving that. But to say all snaps take 3 minutes is frankly, a lie.

You’ve repeatedly said “It’s not ready” and we shouldn’t ship snaps. You know what helps make things ready? Testing, and reporting actual bugs with actual data.

Rather than blindly telling people to remove the snap and install the deb, it would be considerably more useful to gather specific information. What snap are they having problems with? Does it only happen on first launch? What version of Ubuntu (or other distro), and snapd? etc.

Just saying “it’s slow, use the deb” won’t fix anything at all. If you want it to be better, help us.



What’s wrong with the .deb package, anyway? It is only needed to “install” the relevant files to the relevant places. There’s no .deb package anywhere in your installed Ubuntu, is there?

It is a different matter, if a snap is a self-contained file, and clicking on it it would run it by itself. It doesn’t do that, does it? It needs another app to run it. Snapd and lot of other files/folders are living in the root, aren’t they? I am all for self-contained packages that can be kept where a user considers safe to keep them, for example in my home folder, which I can keep even in a separate partition.

@chanath I think you’re missing one of the key reasons why we’re keen on snaps.

Chromium is an open source application, which has been packaged as a deb and is in the “universe” section of the Ubuntu repository. That means it’s “community supported”. Compare that to the Mozilla Firefox deb which is a default application on the Ubuntu desktop and is thus in the “main” section of the Ubuntu repository.

That means Canonical have a commitment to maintain the Firefox deb in the archive with security updates - because it’s in “main”. There is no such obligation for any package in the “universe” section. So you’ll notice that Mozilla Firefox gets regular and timely security updates. Universe packages are maintained by the wider community, which includes people who work on the various Ubuntu Flavours. Chromium is one of those debs. It’s not in main, so there’s no obligation to maintain the package, but we have done for some years now.

Every time there’s an update to Chromium, whether security or just a new upstream release, someone needs to ensure the new version builds. This is not a trivial operation. It’s not as simple as just changing one line from “66” to “67” and you’re done. There’s build failures to contend with, new dependencies, new compiler requirements and so on. It’s work and someone needs to do it. Right now, a Canonical employee is the main person doing that. They need to update the package not just for the 19.10 release currently in development, but all supported releases. That includes 19.04, 18.10, 18.04 (LTS) & 16.04 (LTS). That is a LOT of work.

Making a snap means one package which works on 19.10, 19.04, 18.10, 18.04 and 16.04. That’s a tremendous amount of effort saved.

The fact that a snap is a single file on the filesystem is a technical detail, and is a good thing. When you install a snap it’s a single file that gets mounted on boot. When you remove that snap, the file is unmounted and gets deleted. No files left lying around on the filesystem, it removes cleanly.


I am not talking about Chromium as a snap or as a deb.

Snap maybe a good idea, if I can take it and put it anywhere as a self-contained app. It is not that. It needs other apps to work and those live in the root.

Take for example web browsers; Firefox, Chrome, Opera or Vivaldi. I don’t have to install them in Ubuntu or any other Linux distro. Even in Windows. All I have to do is to download the web browser and unpack it and put it in a folder. (It actually unpacks to a folder.) Put it in my home folder and have a link to the exe file on the desktop, on the panel etc. They start up immediately. All those web browsers are self-contained. Once started, they create a user cache, which doesn’t get deleted, if you don’t delete them. The next time a new release is out, and if you want, change the contents of that web browser folder. Today, all web browsers are self contained, with maybe few additional files needed.

I have many web browsers, and none of them are installed. And, they can be run in any Linux distro. All I need is a link to the exe file. Many apps would run that way. Any Linux app that would be installed to /opt would run that way. That app can be placed in your home directory. Any app that “installs” itself to /usr/lib can be put into a folder in your home (LibreOffice). They are self-contained. Any app can be made to be self-contained, and without the “squashing” and still be safe to use. You, as the user decides when to upgrade or whether to upgrade. You are in charge, not another app.

(Btw, I use Opera most of the time, in Linux and in Windows 10).


Nothing snap is doing is stopping you continuing to do that. If you prefer to manually install applications in your home directory, carry on doing that.

1 Like

How about making snap work like that? For example, a downloaded snap stays in a different partition and and a link to it could clicked on from any Linux distro for it to start up? And without an additional app snapd?

You’re essentially describing appimage. We’re not about to re-architect our entire software delivery and solution to re-implement something else that already exists. If you want to carry on using appimage, or some other system, use it.

1 Like

Not exactly that, but also the way Ubuntu live iso is run (and installed). There too the whole root is squashed, and opened live with an app that won’t stay back. The app that installs came later, of course. In AppImage the idea is the same open the squashed set of files with a runtime. Those set of files are usually /usr/share, usr/bin, usr/lib, /etc and so on with the necessary dependent files.

What a web browser, Firefox for example, does is to have the whole set of files placed in folder somewhere (usr/lib) and put a link to the executive file. It is not squashed and opened every time, sort of wasting time at starting. When you squash a set of files, and need another app to unsquash it and then run, it takes bit of time. With the fastest processor, this might not be noticed, but not everyone has the fastest processors, so the time lap is noticed.

So, click on a link > run an additional app > unsquash the needed app > then run the needed app >> takes some time. And, this appears to be the problem of this kind of starting apps.

There are no debs installed in your Ubuntu, and when you click on the icon the needed app starts up bang (snappier). Click on the link > runs the exe app > app is on your screen.

Your analysis of the reasons why snaps may or may not be slow to start is incorrect.

I don’t see any future in this conversation other than speculation, so I think we should end it here.

There are plenty of alternatives for that.
For me snaps are not a bad thing, they just need a bit of polishing. I always remove my .deb apps in favor of snaps apps (Libreoffice, Firefox, chromium, gitkraken, text editor, VLC… just to mention a few).
For those who are always complaining about snaps how many ups have you tested or are just following the news and complaining?
My only concern is on metered connection, it shouldn’t allow updates when using it

1 Like