back to article Linux devs open up universal Ubuntu Snap packages to other distros

The Snap application container system released in April with Ubuntu 16.04 is now going to be opened up to many other Linux distros after a surprise discovery by developers. In a press call to journalists, Canonical founder Mark Shuttleworth (accompanied at times by a rather excitable Labrador) explained that shortly after the …

  1. thames

    Snap basically bundles all the dependencies in with each app, instead of sharing common files. This results in much large package sizes than deb or rpm. The main beneficiary of this will be with proprietary applications or other people who don't want to follow each distro's release schedule. Another advantage is that Snap adds more sandboxing, which may help more exposed things like web browsers, and it also limits what proprietary apps can get access to. Much of the work on Snap came out of the work that Canonical has done with Ubuntu Phone packaging.

    Generally, it's a good idea to have this as an option. Deb and rpm will still be the standard way of distributing most distro packages. I can't honestly see much advantage for things like Libreoffice. I've no real desire to get the very latest bleeding edge version, so I can wait for the normal distro upgrade schedule for that.

    1. Flocke Kroes Silver badge

      What is the advantage of snap over static linking?

      Decades ago, static linking included only the parts of each library that an application used, and as it was not limited to position independent code, the compiler could pick a more efficient sequence of instructions. Also, when a flaw was found in a library, each application that was statically linked to it had to recompiled against the updated library instead of just updating a shared library that applications linked to at run time.

      Now we have snap, developers can combine all the disadvantages of static and shared linking. Why bother?

      1. Grifter

        Re: What is the advantage of snap over static linking?

        >> Why bother?

        Because it makes certain things easier. Not all things. Certain things.

      2. Doctor Syntax Silver badge

        Re: What is the advantage of snap over static linking?

        The other side of the coin is that dynamic linking introduces dependency hell (Windows users will be familiar with the DLL equivalent) when trying to use something that wasn't in the distro. Compiling WonderPackage requires some library at a later version than the distro. Installing that version promptly breaks the distro.

        A current solution to this is to install the package and its dependencies in /opt. I currently have several such examples. Snaps seem to combine the principle of this approach with the isolation of Qubes. Now if we could see this extended to controlled access to files...

    2. stizzleswick

      The way I understand what was announced by Canonical, containers will share identical libraries, so the storage overhead will be greatly reduced. At the same time, different versions of libraries will be used by the appropriate applications, so there will be fewer problems with library updates.

      It's not a fix-all, but it sounds sensible to me so far. Let's see how it works in real life.

      1. Tom 38 Silver badge

        The way I understand what was announced by Canonical, containers will share identical libraries, so the storage overhead will be greatly reduced. At the same time, different versions of libraries will be used by the appropriate applications, so there will be fewer problems with library updates.

        It's still dynamically linked static linkage. If you have the same library at the same version with the same patches built with the same options in multiple snaps, then the storage overhead is managed, but if one snap uses different functionality/build options, you don't.

        One snap gets updated because a library has a security vulnerability, whilst the other snaps don't, and then you have multiple copies of the library, plus apps that run but are still vulnerable. I think I'd prefer apps that don't run to apps that are vulnerable.

        You can't really have both everything being isolated and distinct and continues to work after updates, and security holes fixed by updating one package.

        PS: PC-BSD PBI. Just saying.

        1. Fungus Bob

          "PS: PC-BSD PBI. Just saying."

          Beat me to it. So Canonical re-invents PortableApps which re-invented the PCBSD PBI package. Who says innovation is dead?

          OTOH, Canonical's Big-Haired Marketing Weirdos did invent a Snappier name...

    3. Doctor Syntax Silver badge

      " I can't honestly see much advantage for things like Libreoffice. I've no real desire to get the very latest bleeding edge version"

      Currently Debian LTS is on LO 3.5. The current stable, not bleeding edge, version is 5.1. I'm not sure of the distro verison of QGIS but it might be around 1.7 and the current stable version is 2.8, bleeding edge 2.10 last time I looked. So there's some merit in ignoring distro versions of packages like that where there are stable versions which the distro maintainers are ignoring.

    4. Havin_it

      >I can't honestly see much advantage for things like Libreoffice.

      Well for starters it'll mean I can actually install the bastard on my unstable Gentoo lappy - more than I've been able to do for a loooong time because I don't have two days spare to compile it and the prebuilt binary version is perennially ruled-out by DLL-hell (OK, SO-hell but you get me).

      I'm not sure who I blame more for this: LO devs for linking to flaky bleeding-edge libraries, or the devs of those libs (icu, poppler and harfbuzz seem to be prime offenders, whatever the hell they are for anyway) for breaking their ABIs with every fscking point-release (grr).

      DLL hell can be a real PITA for some packages on Gentoo, so I'm not surprised their devs have been all over this.

      1. sed gawk Silver badge

        Fellow Gentoo user here,

        1) try a binhost, there are X86 and AMD64 binhosts available, if you run a stable amd64 without too many tweaks, everything from base-layout to KDE is available without direct compilation.

        2) ICU is support for internationalization, harfbuzz is for font rendering, as it happens I have only two packages that rely on harfbuzz (TeX-Live and Wt), and these applications can be installed in isolation in gentoo by specifying the ROOT environment variable when emerging, e.g. ROOT=/opt/vendor-application emerge -k tex-live

  2. a_yank_lurker Silver badge

    What Linux needed?

    This might be the key to make Linux a more common platform users. Packages are written for one installer and can be installed on any supporting distro.

    What is interesting is that Snap was written by Canonical for their purposes but released as FOSS so others could use it. This Linux users can still have our cake and eat it too. Many distors with effectively one package manager for the applications.

  3. Justicesays

    Static linking returns...

    essentially. Sounds like a good idea until your "Snap-app's" each with their own SSL library set etc. are updated at various frequencies (or more likely infrequencies) and your security scans look like Swiss cheese.

  4. tom dial Silver badge

    Before retiring, one of my least favorite activities was sorting through the security issues from old, decrepit, and buggy versions of Java that vendors had bundled with their application. They typically promised to support only the version they bundled, and as we were a US DoD agency, we were required to have support for niceties like security issues. This was not a problem until a vendor's favorite java became an unsupported product, at which point we had to start writing POA&M or Acceptance of Risk documents about the Java that Sun or Oracle no longer supported. Sometimes we had four or five versions, of which two or three no longer had support. That left us in a bind: replacing the unsupported Java gave us an unsupported Java application. Explaining that to the CIO was not pleasant, who was extremely averse to signing an Acceptance of Risk.

    Snap appears to be a codification into open source of this noxious practice.

    1. phuzz Silver badge

      I guess you can mitigate it to some extent by making sure that the snap application using the old version of Java only has access to the files it needs. So, if your (eg) Jenkins install gets popped, you only have to worry about the files that it can access, secure in the knowledge that other applications on the same machine are using their own versions of Java (which may or may not be secure).

      That's only a little bit better really isn't it?

  5. s2bu


    Snaps seem to be basically the same thing as PBIs in PC-BSD. Except PBIs were discontinued.

  6. frank ly


    "I'm sure that Microsoft will want that for their Ubuntu compatibility layer."

    Is this significant or is it old news that I hadn't noticed before?

    1. bazza Silver badge

      Re: Interesting?

      Surely you can't have missed the news about MS implementing a Linux system call subsystem for Windows 10 and bolting Ubuntu bash and apt on top?

      Still work in progress, but looking pretty good...

      1. frank ly

        Re: Interesting?

        Ok, I remember the bash part but forgot the Ubuntu part. This is happening more often nowadays, I just can't keep up with events.

        1. Doctor Syntax Silver badge

          Re: Interesting?

          "I just can't keep up with events."

          It gets worse as you get older.

      2. Doctor Syntax Silver badge

        Re: Interesting?

        "Still work in progress, but looking pretty good"

        Apart from the Windows 10 part.

  7. Christian Berger

    It's a stupid idea

    It gives the illusion of security by sandboxing. This illusion creates the illusion that you can simply run "apps" from untrusted sources. This means that people will just download whatever "app" they find which means they will enter "$programname free download" into a search engine and click the first link... which likely isn't the trustworthy source... and likely is malware, reducing security to a sandbox which only pretends to work against certain problems and probably will even fail at that.

    Typical problems I see are something called "Abofalle" in German, where you think you download some free software, but instead sign a contract forcing you to pay money to some criminal. There probably will be downright malware in those packages, too. After all, if the user wants to execute a certain program, they will give it all the rights it want. A rights system only works if the application cannot determine if it got the rights or not and I can always edit the list of rights the application has.

    We live in a sad age when people just write code without thinking about it first.

    1. gv

      Re: It's a stupid idea

      Anybody running "apps" from untrusted sources probably deserve whatever mess they end up in.

      1. Ken Hagan Gold badge

        Re: It's a stupid idea

        "Anybody running "apps" from untrusted sources probably deserve whatever mess they end up in."

        Yes ... but no. Snap makes it more likely that the app will work, so it lets the (clearly naive) user get further into trouble before the symptoms start showing.

        1. Christian Berger

          Re: It's a stupid idea

          Furthermore it'll create a simple way to install such images. While before downloading a Debian package with your web browser will just give you a file you then need to install manually, it's likely that those new packages will be installed automatically as they are supposed to be "secure".

  8. Jay 2

    One one hand it may be useful for environments where you're running a stable enterprise Linux (RedHat/CentOS/etc) which traditionally has older versions of software, but the devs are claiming that they really need the very-very-bleeding-edge-latest-version which will almost always end up in library/binary dependency problems.

    But I'm still a bit concerned that then you'll end up with an almost parallel software/repository system lurking, which is bound to cause problems somewhere down the line.

  9. paulf

    Off topic but... (Bees)

    When I saw that picture of Oprah, all I could think of was this.

    Icon - special clothing for the apiary!

    1. DropBear

      Re: Off topic but... (Bees)

      Just make sure it's the heavy rubber version not the vanilla thin latex, bees might still get through that one...

  10. Bronek Kozicki

    Red Hat

    Red Hat is also listed as validating the system, but Shuttleworth said progress has been comparatively slow.

    why, of course Red Hat needs more time - they need to find a way to integrate snapd into systemd first!

    1. Doctor Syntax Silver badge

      Re: Red Hat

      Why the joke alert?

      1. Bronek Kozicki

        Re: Red Hat

        Because RedHat stands behind competing technology and yes, it relies on systemd. They will are unlikely to invest much, if anything, into Snap.

  11. Anonymous Coward
    Anonymous Coward

    Great, so a common library gets a security upgrade and we have to update every single package....

    1. Justicesays

      Of course not. Common library gets a security upgrade and you'll be lucky if half your packages ever get updated!

    2. Doctor Syntax Silver badge

      "Great, so a common library gets a security upgrade and we have to update every single package"

      Looking through ls -R /lib /lusrlib leads to the thought of "do I really need all that stuff?" (running ls -R /lib /usr/lib|wc -l returns 67257 on my Debian LTS). And I have to conclude that I don't know. What I do know is that a good many of "every single package" are there to provide those libraries just in case I happen to run some application that calls them and that updates to those, whether I ever execute them or not, are part of the overall updating.

      Given a system where the core is truly minimal and I only have the application package I want a good deal of those libraries and the packages which provide them might not be there. So I'm by no means convinced that the update frequency and volume would be greater than at present; it might be less.

  12. keithpeter Silver badge

    A new standard for packages?

    As others have posted already, I imagine that the success of the format will depend on the effectiveness of the sandboxing and the degree to which upstream providers who wish to distribute snapped versions of their software can agree to maintain a common repository with the usual sum checks and signing.

    I'm wondering if one could set up a very minimal Linux distro and then install all of one's applications as snapped packages? Sort of a sandboxed system on the fly? For desktop use I imagine minimal Debian with wayland and a simple window manager.

    The Coat: Currently compiling sagemaths on Slackware so off out for a three course meal and a visit to an art gallery in a bit.

    1. Doctor Syntax Silver badge

      Re: A new standard for packages?

      "I'm wondering if one could set up a very minimal Linux distro and then install all of one's applications as snapped packages?"

      Canonical were there ahead of you. It's called Ubuntu core.

  13. Doctor Syntax Silver badge

    I must admit that when I first saw the announcements I thought it was just an extension of keeping applications and dependencies together in /opt. I'd missed out the containerisation. On the whole it seems like a step forward. However, as Matthew Garrett has pointed out in relation to X there's a vulnerability where containerised applications still depend on a leaky common service. It's not yet clear to me how much sharing of common libraries will continue. I suppose the answer is to look at the Pi version of Ubuntu Core. Another thing to do when I get a round tuit.

  14. Rabayn

    I'm glad to see this.

    I really don't buy the downsides against this.

    "If you have multiple copies of dependencies, all the apps that depend on it won't get security fixes when a single dependency is updated."

    This seems to be a nice goal, but doesn't seem to work in the real world. Dependencies in distros seem to stagnate a bit as apps progress. Dependencies/Apps don't get updates because of conflicts so NO ONE gets the new security update because versions are locked to avoid conflicts.

    I guess I'm just really tired of seeing a new version of software I use (or new software that I WANT to use) on the developers web site with lots of additions I really want. Then realizing the version I have on my distro of choice is ancient, and there are no binaries for my distro. So, I grab the code and build it. Only to find out it requires a library version that is also not in my distro. Sigh, so I grab and build that. Then realize that library won't build with the gcc version on my distro. So, I go grab that, and so on until I finally have a nice blob sitting out on /opt for the app. I am a developer for a living, and I get enough of building software at work. When I want to use an app I just want to hit install and be done.

    And finally, if a library in a distro is not frequently updated, snap packages would actually be more likely to be newer, more secure, versions with bug fixes, because the developer himself can keep the package updated as he develops the app. I would much rather have 3 out of 5 snap packages with the newest code/dependencies than have 5 standard debs all on old versions because their dependencies don't play nicely with all of the apps, or the volunteer packager didn't feel like taking the time to update the library.

    Now, I won't call this a silver bullet to replace all things binary distribution. But, it sure looks to fix a really big issue that is widespread on Linux. Allowing the developer himself to "easily" package his latest and greatest version for a smattering of distros seems like a good idea to me.

    1. Bronek Kozicki

      Re: I'm glad to see this.

      yup, know the feeling ... :( That's why I think everyone should have their own distro. With minimum effort. And pigs will fly.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021