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

I would suspect that it’s 3rd party, non transparent snaps that present possible security issues, hence the need for confinement.

@coeur-noir +1 : for servers, IoT, developers, snaps are useful, but for Desktop (users) not (at least for now).

And even from Ubuntu, it has always been said that snap would not replace completely deb, the last one 4 months ago : : Shuttleworth said that Ubuntu users will still get access to an archive of .deb packages. : Alan Pope (Canonical) “All of this said, we do actually have an awesome “all snaps, no debs” version of Ubuntu called “Ubuntu Core” - and it’s been around for a while now. It targets IoT and devices, rather than desktops though. Not the same thing.”

But now Chromium is no more available as deb, so what to expect ?

1 Like

Mmm… then it’s a « problem » brought by snap ( easily packaging proprietary software ) and in the same time half solved by snap. Why not. « Half solved » because, hey, still it’s proprietary so who knows ? You have to trust the software editor then, it’s just moving the trust cursor.

But in my apt/deb world, where I use official repositories from my distro, where is the threat from 3rd party ? They are eventually « curated » in partner repository, or in universe ( I think, ie. nvidia drivers ).

Thinking about ppa maybe ? Some are very trustable. Some provide so many packages they can break dependencies. All are meant to be used cautiously and not aimed at primo beginners - I mean you first have to apprehend how apt and deb work to use them cautiously.

Snap gets rid of dependency mess. Good. Snap offers in one place FOSS and proprietary app’s. Here I am suspicious. It may be an advantage for a commercial app-store and for some users. But this advantage may lead to loss of comfort and flexibility for the many users that rely first on FOSS.

Here I totally speculate ! And myself could be interested in purchasing some industrial grade proprietary jpeg2000 encoder… at the end, wouldn’t that « lesser » the FOSS effort towards desktop app’s ?

( sorry for 2 answers, can’t we edit posts here ? )

Do you imply that FOSS snap do not need to be confined - then why it’s not the default behavior ?

None of what I’ve said is provided out of the box with apt/deb, and they can only be done in ways that are way to much complex for most non-technical users and in some points they require more work, and some things are simply not available with apt/deb, like the possibility to isolate dependencies, app confinement at the level snaps provide, the possibility to use the same package on other distros (including those that don’t have apt/deb) and different versions of the distro (same package will work on old and new versions independently on how it was built…

This example of the chromium really shows that unless snaps or other similar format was used, applications would have to be sometime very heavily patched to work on older versions of systems to the point that it generates so much work that it would not be worth do to it otherwise, or at least not worth when the snap option exists and doesn’t require that much more work.

Storage is not an issue, I’ve explained why it’s not. There could and should be improvements on that area, but this is not a relevant issue. Progress is made of compromises, this implies that we have to consider not only disadvantages, but also the advantages. Advantages do very clearly outweigh disadvantages. This doesn’t mean it perfect, or that work shouldn’t continue to minimize and reduce the disadvantages, but just considering disadvantages is not the correct way.

The benefits for developers do reflect on benefits for users, with more software delivered faster and more securely.

1 Like

I don’t think he implies that, he didn’t mentioned FOSS or non-FOSS. Third party doesn’t refer to licensing, only to who provides it. However there’s more benefit of confining proprietary closed source applications, because they are to audit to the same level, but that doesn’t mean that confining applications is not a benefit also to FOSS applications, security is an issue that needs to be addressed with many layers of measures no mater what licensing approach you use to license the software.

1 Like

The software installed with Snap is slow, so it is not acceptable.

we must continue to use deb packages for all software

The first launch is noticeable slower, after that you will be pressed to do a formal benchmark because, even if snaps were slower as you say, that is not immediately perceptible. Once snaps become pervasive this first launch issue will be irrelevant anyway, probably part of the session startup.


I disagree with this post! :smile:

Ofc snaps have their rough edges that need to be rounded but overall they are already the best package. Auto update and channel switching are my favourite features.

When I need to say something negative the ugly-cursor-bug in webappsnaps comes to my mind!

But imho snaps are ready enough to replace app debs


Would you be willing to do a test for me please.
In your company you buy a new computer. You do a demonstration in front of the staff of the installation of Ubuntu. Awesome. In front of all these people, you launch for the very first time the calculator or vlc or other snap. More than 20 seconds. What are people going to think about? They will choose this distribution. Will they be ready to follow you for their daily work? Would you be ready to make this presentation? I do not believe. It’s not very serious :slight_smile:

1 Like

Personally I have never done a demo in-front of people without practising first … so you always run the apps first!

Real world demonstrations.


Can we please take a step back and look at this like any other software in Ubuntu.

We frequently make decisions about what is default in the ISO, or available in the repositories. Often times those software packages aren’t perfect. When there are imperfections, we rely on users and our active community to tell us how the software is not working correctly, so we can fix it. The way we do that, and have done for 15 years now, is via bug reports. Discussion is great, but detailed bug reports are better for letting developers know what’s wrong.

Just saying “snaps are slow” is not helpful to anyone. Because frankly, they’re not. Some might be, but others aren’t. Using blanket statements which are wildly inaccurate will not help your argument. Bring data to the discussion, not hearsay or hyperbole.

Here’s a program running as a snap.

$ time snap run wethr
Farnborough, United Kingdom: 15.57C 🌧

real    0m1.278s
user    0m0.205s
sys     0m0.058s

Here’s the same program on the same PC running outside of being a snap.

$ time ./wethr.js 
Farnborough, United Kingdom: 15.57C 🌧

real    0m1.905s
user    0m0.153s
sys     0m0.036s

I ran the same command multiple times and it varies a little each time under both setups. But largely they’re the same, within a few ms. There are other factors at play, such as network latency speaking to a remote server to get the weather, what else is going on, on the PC and the hardware resources. But largely they’re the same.

Desktop applications are way more complicated though. With many libraries and other assets to load, some of the delays get compounded. This is offset by the fact that snaps are compressed on disk, so there’s fewer blocks to read, which is countered by the overhead of the realtime decompression taking some CPU overhead.

Further on top of this is the need to stand up the necessary directories, mounts and caches to ensure the application launches correctly. There is some overhead on doing this on first launch. It was way worse, and was improved recently. It turned out some font caches were being rebuilt on every launch of the application.

So for example on my machine running libreoffice from the deb takes 0.9 seconds to launch, from the snap it takes around 1.8 seconds. That’s certainly a difference, but it’s far from the 15s I have seen quoted here. If people are seeing significant time deltas between deb and snap installations of the same application, please file a bug. By all means link to those bugs here, so we can alert the people responsible and get these issues looked at.

Here’s some suggested places to file bugs:-

To be clear, I’m not trying to shut down discussion of these issues. But just think about what you’re asking for. Snaps have in general significant advantages for developers and users.

  • Developers can make one package that runs on many releases of the same distro
    • Currently when an update to LibreOffice or Chromium (as examples) is needed, that’s tremendous work for an Ubuntu developer to cover all supported Ubuntu releases - 16.04, 18.04, 18.10, 19.04 and 19.10 (in development)
    • With a snsp, they can update one package and benefit users across all those releases
  • Snaps automatically update so users have the latest software without manually updating
    • Users who prefer manual update can override this to a great degree
  • The Snap Store provides delta updates, so users don’t have to download the full snap file every time
  • Users get up to date releases
    • We have a tremendous number (hundreds of thousands to millions) of users on older releases of Ubuntu. They can get LibreOffice 6.2 where previously they might only have minor point release updates to 5.x
  • Developers can push out test releases to users who can test them before they go stable
  • Developers can publish one snap which works on multiple distros (less interesting for Ubuntu users)

Sure, they may have shortcomings, and we need to fix those. A rant on a web forum won’t fix those issues though.


There are 2 questions not answered at the moment :

  • Problem is not the use of snaps, even as default. It’s the fact that we thought a deb alternative would be always available. With Chromium in 19.10 it’s not the case anymore, contrary to what was promised before.

So does it mean that in the near future Ubuntu Desktop will only use snaps AND drop completely deb packages + ppa ? This is important to know because we participate in devel Ubuntu testing, but if such a decision is taken, it could make some users to change distro.

  • What about confinement and other partitions / hard drives not available as default by snap ? Here in Chromium I’m NOT able to save downloads in another folder than /home, unless i run “sudo snap connect chromium:removable-media”…

Does it mean that a user with a fresh install will have to do this for every app coming as snap (LibreOffice etc…) or will there be a workaround allowing by default other places - and what does it mean for security ?

Thanks !

We have consistently said that we cannot forsee the deb-based desktop going away. I still can’t see that happening. Debs are an integral part of the way the desktop is built. It’s just not feasible / desirable to make the desktop be “all snap”. That said, there have in the past been projects to try and make such a variant “Ubuntu Personal” and the currently available “Ubuntu Core” can have some limited graphical environment installed on it via Mir Kiosk and friends. But I still can’t see the “traditional” deb-based desktop going away, even if a proportion of the default applications are offered as snaps as time goes on.

I also can’t envisage a system where it’s not possible to add debs via PPAs to a traditional desktop. It’s certainly not on any roadmap I’m aware of. Bear in mind all planning right now is with the upcoming 20.04 LTS in our sights, even if these things are being planned for 19.10. I don’t know what’s planned for 22.04 LTS (that feels so far away!) but I cannot forsee dropping debs by then. So for the foreseeable future, with our current planning, I can confidently say the deb based desktop isn’t going anywhere.

For the removable-media issue we could lobby the security team to request that it’s auto-connected on install. I personally think that’s reasonable given it’s a Canonical managed snap and it’s a reasonable expectation that someone might save/load files from a USB drive these days.

The same goes for any application requiring access to resources outside the default confinement.

Worth noting,though, that you can enable that switch in Ubuntu Software, so you don’t have to use the command line…


If you understand French (otherwise use “google translation” or “deepl”) you will see that many users are not happy with the Snaps on the French forum:

Not to mention beginners who don’t understand why they have problems with their software (when you realize after discussing that they installed it by mistake and without knowing it in a snap package…)

For more details, ask Didier Roche in your team, he is aware of the criticisms.

Thanks a lot for the clarification !

So I hope Chromium will be back soon as deb, in official packages or via ppa.

I understand snaps can be very useful for old LTS, and practice for developers, but as a user always on the last Desktop version, I prefer debs.

Also, as said sibe39, on the French Ubuntu forum, we have lots of users who installed snap instead of deb and are blocked by this “removable-media issue” : so yes, if you can disable it by default for the official snap store applications distributed by Canonical, it would be good :wink:

Repeatedly posting in this thread that there are problems, won’t actually get anything fixed.

While I can appreciate there are a some issues. The best place to let the developers know, and track those bugs is in the bug tracker. There are hundreds of forums online, all over the place in many languages. We can’t be expected to read all of them. Anyone with a launchpad ID (thus, anyone who has an account on this discourse instance) has the capability to file a bug. I’d strongly recommend doing so, for each specific issue.

Taking just a few minutes to do that will help tremendously.


Frankly, if the Ubuntu Desktop team “switch” from making a deb of Chromium to making a snap, I doubt they’d switch back. It’s a tremendous amount of work for developer(s) to maintain numerous debs across all supported releases. Maintaining a single snap is just practically and financially more sensible.

Other people outside the Ubuntu Desktop team are welcome to maintain unofficial Chromium debs, given it’s open source software, and there are build services available. But don’t expect that Canonical will be doing that. If there was a Chromium PPA it wouldn’t be easy to discover for new users (exactly those cited on the forum) and may not even be kept up to date with security notices. So it could put users in a worse position than they are now.

It’s all very well telling Canonical what to do, but someone needs to pay those developers for their time. It’s not free.

1 Like

Debs won’t go away, until Debian would stop using debs, or Ubuntu would using some other base. Debian wouldn’t embrace snaps, so not a big problem atm. So, just uninstall snaps and go with debs, that is if you are using Ubuntu as a desktop. There is still a calculator deb, so nothing much to worry. Some apps would come default, nothing much to do against that, find your way out of the problem.

If the question is about Chromium, download the deb package for the last deb and then upgrade. The guys won’t create a deb package, for Ubuntu want to prove how good are snaps, and if you don’t have a deb one working, you wouldn’t know the difference. Also, Chromium is not a default app, and ppas are “sort of” unofficial. :slight_smile:

Yes, I fully understood that it would not be Canonical who will maintain Chromium (and perhaps other apps in the future) as deb, but you reassure us that debs and ppa will still be available and part of Ubuntu Desktop (at least until 20.04 LTS, and hopefully further).

So as chanath just said, Debian teams will continue to package Chromium, and that was my question : how much work does it take to adapt it to Ubuntu, just for the last LTS and last current versions, for a ppa ? Perhaps not so much (I don’t know, I’m not a dev), and thus if regularly updated, no security issue - and it’ll be for advanced users who know where to find it. So we’ll see if someone does it !

1 Like