Snaps are universal Linux packages | Hacker News Reader

Snaps are universal Linux packages

github.com

117 pointsGutenYe97 comments

Open articleView on HN

So there are a couple of different projects trying to be distro-agnostic/sandboxed/multi-version package managers:

- Snappy

- FlatPak

- AppImage

- Nix

Snappy is an Ubuntu/Canonical project and FlatPak is a Fedora/RedHat/FreeDesktop project. Snappy and FlatPak are remarkably similar and kind of mirror the DEB/RPM spit. Nix and AppImage are independent.

AppImages resemble macOS's app bundles in that they can be run directly without installation. Snappy, FlatPak, and Nix need to install to a root directory, /snap, /var/lib/flatpak/, and /nix respectively. FlatPak and Snappy need a runtime daemon but Nix and AppImage don't.

AppImage, Snappy, and FlatPak include all of the dependencies in one package. Nix packages just include hash names and install as needed.

I'd not compare Nix to other three. Yes, you are right, it is kind of "distro-agnostic/sandboxed/multiple-versions", it "need to install to a root directory" and does not "need a runtime daemon", but otherwise it is totally different and much more than others.

I mostly agree, but there is a similarity in that the Nix build/CI server "Hydra" puts a "One click install" link on build outputs (e.g. http://hydra.nixos.org/build/47550492 )

What about Chef's Habitat [0], is playing the same league?

[0] http://habitat.sh

> Snappy is an Ubuntu/Canonical project and FlatPak is a Fedora/RedHat/FreeDesktop project. Snappy and FlatPak are remarkably similar and kind of mirror the DEB/RPM spit.

This isn't actually a good analogy, because Flatpak was designed from the ground-up to be vendor-neutral. For example, the "runtimes" that provide the virtual Linux distribution for applications to work in are built with packages and tools from the Linux Foundation's Yocto project. Similarly, the code is deliberately hosted on GitHub with no CLA so that all contributors are on neutral ground (there is at least one Debian developer involved). The main developer is a Red Hat employee, and could have used Fedora or CentOS packages, tools and infrastructure, but explicitly chose not to do that, to protect Flatpak's neutrality. He also builds Flatpak for Ubuntu, Arch and other distributions, so that people can freely use Flatpak on their systems even where it isn't currently supported by their distribution of choice.

  > because Flatpak was designed from the ground-up to be vendor-neutral

As have all the others, hence the "distro-agnostic" part of Matthew's comment.

True Snap are technically distro-agnostic but still Snap is surrounded by a "brought to you by Canonical™" feeling.

Even if you look at the terms used : https://snapcraft.io/docs/core/store :

"The main way of distributing snaps to snapd systems is through the Ubuntu Store"

So indeed there is the "other store" section which mention you can host your own store but it's clearly not emphasized.

Even the term of Snap "store" vs Flatpack "repo" seems to indicates a more decentralized/agnostic direction of Flatpack.

On flatpak.org/apps.html you can see LibreOffice hosted by documentfoundation.org and MonoDevelop hosted by mono-project.com. They're not all hosted by their respective foundation/website, but still it kinda seems like it is the direction flatpack is pushing for.

So "technically" they all are distro-agnostic, but in terms of distribution system one is pushing for a centralized Canonical-hosted store while the other seems to be going towards a "each foundation will host their app"

Omg! How dare an open source project, led by Canonical, have a "brought to you by Canonical" feeling! That's just awful. Did you know that Canonical also doesn't contribute upstream, and instead uses that time to club baby seals for fun! I seen em!

IMO Flatpak has a pretty "brought to you by GNOME/Fedora" feeling.

GNOME and Fedora are definitely further ahead, since the lead developer for Flatpak is a long-time GNOME contributor as well as a Red Hat employee. There are Flatpak contributors focusing on other things: at least two developers are working on KDE integration, and a Debian developer at Collabora maintains the Flatpak package that is currently in Debian testing for release in Debian 9.0.

> Snappy, FlatPak, and Nix need to install to a root directory

Not sure about Snappy and FlatPak, but Nix can use any directory as its "root"; users can run it from somewhere in their home directory without any need for admin rights.

The downsides to doing that, compared to a global /nix directory, are a) waste of disk space if multiple users have Nix running from their home directories and b) having to build stuff locally, since the official binary caches are built with /nix as the root.

Also, there are other distro-agnostic package managers like 0install, Autopackage and Listaller; packagekit is arguably related, as it provides a distro-agnostic abstraction layer; systemd's "portable services" are another recent addition to this space.

I don't know of anyone running nix with the nix store being in their home directory, as it would require recompiling the entire world and receiving no benefit of the pre-built cache. Much more commonly the user will install a "single-user" mode nix, where the nix store is still located at `/nix/store` (in the root,) where it could possibly be that multiple users share it.

It does seem to be much less common, but the home directory based nix install is extremely useful if you don't actually have admin rights on the machine. I.e. in basically any institutional system. I have a very handy nix install in my home directory on a university supercomputing cluster. As annoying as it is to have to compile everything it's much better than not having that software at all or having to go though the sys admins to maybe get something installed a month later.

FlatPak is intended for Desktop only. "is not a good match for a server" http://flatpak.org/faq.html

In contrast, Snappy aims for much more "Package any app for every Linux desktop, server, cloud or device" https://snapcraft.io/

I cannot find how many packages they have currently. I hope that FlatPak has more than the 11 applications listed on the website. http://flatpak.org/apps.html

FlatPak does not provide a central repository, while Snap has https://uappexplorer.com/. After install flatpak, it takes three (!) commands (on cli) to install LibreOffice. http://flatpak.org/apps.html

Snap has stuff like pulseaudio (audio daemon) or ogre (rendering engine) in the repo. That seems weird, because these are not applications. The first belongs into the base system, the second into a development environment.

pulseaudio and similar exist for things like Ubuntu Core which only works with snaps.

One would hope that Ubuntu eventually exercises some quality control over the snaps in their store. Otherwise what's the point of a centralized store? Currently uappexplorer shows a whole bunch of "hello world" apps.

We don't plan to restrict publishing of apps, but we can be judicious in which ones we promote on the front-end

"FlatPak does not provide a central repository"

This is something I particularly like about FlatPack. I hope we can go towards a decentralized package distribution system where the app store just has a list of official flatpack repos. You update the latest Firefox from the repo at mozilla.org, the latest Blender from blender.org, etc... of course this needs mozilla, blender.org, etc... to package the app (but they already do it for win, mac and .deb anyway). So you always have the latest version and it is provided by the official website and not a central Canonical repo

Isn't that the same as apt and PPAs?

yep indeed, so to me (but I don't know if I'm interpreting all this correctly) Flatpack seems to push towards a PPA like system for distribution but with a SandBoxed App over one or multiple Runtime for execution

The problem is installing always takes at least two steps: Add repo, install package. Maybe even a third: Verify/add key.

Snaps are usually published by the official upstream, not by Canonical. The Snap store allows them to upload their binary packages directly and immediately. That means you get the latest official releases without having to find out where to get the latest official releases.

> FlatPak [..] need to install to a root directory

You can install flatpaks locally without root.

Haiku package manager really shines here, since you can directly run a package without installation, INCLUDING THE KERNEL.

A good package management system is a very important part of a Linux distro. What's much harder to achieve is a large and well maintained collection of up to date packages. You can have the best tools in the world but if they aren't backed up by well maintained packages then those tools are pretty use less.

This is why Debian has dominated Linux distros for decades. Debian's apt-get is a good package management system. Not perfect, not the best, but good. But, no one can compete with Debian for quality and quantity of well maintained packages.

Only time will tell if any of these next-gen package managers will succeed.

What makes things a little easier is they can be installed along with your standard package manager.

I love apt, but the release policy isn't at all suitable for desktop use. You get stuck with the same bugs for at least 6 months, even if the developer has released a fix.

that's not a flaw of apt, it's just a policy of the distros that use apt. Even on ubuntu, some apt packages (notably chrome and firefox) release major updates independent of the distro's release cycle.

apt packages are so stable because it takes so much effort and time to make them. For example, a new apt package may be pending just because enough time has not passed since it was created.

I think it is the hard work of the maintainers to ensure quality that makes .deb stand out.

Snaps are Canonical's choice for "cross distro" package management that they are trying to force on everyone else. They came out of nowhere and it doesn't play well with other distros.

If you want a nice-from-first-principals approach to package management for desktop apps, Flatpak is the shit: it uses a Git-like distribution system that's specifically built for operating system size snapshots. You get to pick your underlying distribution (or roll your own) and the sandboxing mechanism just wraps around secomp-bfp so it stacks well with SELinux or AppArmor or whatever.

But now we are going to have yet-another-bifurcation of OSS solutions: RPM vs DEB, KDE vs GNOME, Wayland vs Mir.

Canonical, stop trying to be Apple, please.

> it uses a Git-like distribution system that's specifically built for operating system size snapshots. You get to pick your underlying distribution (or roll your own) and the sandboxing mechanism just wraps around secomp-bfp so it stacks well with SELinux or AppArmor or whatever.

Is security compatibility the primary advantage over docker? When I see these I always think, why not docker? Git like distribution, pick underlying / roll your own. I'm not sure why these are better than a docker or rkt.

Docker doesn't work for desktop gui apps. Also it doesn't provide great security sandboxing. Also docker is not the first containerisation solution why not LXC?

It works for GUI apps, see eg. https://hub.docker.com/r/tomparys/skype/

X11 only, no Wayland :-/

OK but now you've forwarded your x you're not really containing the gui app very strongly anymore.

Docker doesn't support user namespaces properly so this is the situation anyway. Good reason to use LXD - or to run Docker under LXD[1] :)

[1] https://insights.ubuntu.com/2016/04/13/stephane-graber-lxd-2...

It was far too laggy for real use when I tried with Firefox a couple of months ago.

That might be XQuartz's fault rather than Docker's - I only tried on macOS.

> why not LXC

The git-like version control available with docker or rkt (and apparently these package manager based systems too).

> Canonical, stop trying to be Apple, please.

I love that they try to be Apple, before them only Mandrake and SuSE cared for what actually matters to desktop users.

As for "yet-another-bifurcation of OSS solutions", that is the nature of the game.

Isn't that what so many praise about FOSS?

Welcome to the UNIX wars, re-edited as GNU/Linux wars.

They have a serious case of NIH though. They put a lot into desktop linux but most of it seems to be a replication of effort.

Didn't Snap appear first? Why is FlatPak not an example of NIH?

Exactly. Snaps grew out of the work to make Ubuntu mobile phone apps secure and easy to update. They are a great way to publish software, worth creating regardless of all the anti-canonical trolling. And they work fine across distros except where RH has actively tried to cripple them. That's their right, but wow, toxic.

> RH has actively tried to cripple them

Source?

Snaps require AppArmor which is used by Ubuntu and openSUSE. This makes it harder to integrate Snaps into Red Had (SELinux) distros, but I wouldn't say that this is something RH does actively to cripple them.

Snaps need a security backend like AppArmor in order to run in confinement. Without it, they can still be run unconfined. And while AppArmor+seccomp is the only working security backend, snapd is designed to support alternate backends, so one could be made for SELinux, we just need someone with SELinux experience to write it (our in-house expertise is in AppArmor)

Snap is not vendor neutral - it has hard coded dependence on Canonical infrastructure. If you want to provide your own, tough luck.

Calling to attention about that is not anti-canonical trolling. It's avoiding creating a dependence on a third-party.

s/tough luck/patches welcome/

Patches here: https://github.com/flatpak/flatpak ;)

It is rare to see something come out of Fedora that is not NIH.

As for all the mentioned package/image managers, IMO they all bring more problems then solutions (except maybe nix). Dependency resolution brings sloppiness and keeping the programs dependencies up to date would kill the internets and hard drives (compared to a normal package manager). They should just build a build bot and amen (or just not do anything). The only "problem" they solve is proprietary program distribution, and that is solved by a Filesystem Hierarchy Standard (and fd.o) compliant installer such as MojoSetup (as used by GoG).

Yeah, my worry is that when a vulnerability hits libc we have to download all the snaps again and the vulnerable libc is still there in the abandoned snaps. There are many other libraries used by many programs that would suffer from the same problem. I'm thinking about openssl.

Edit: somebody answered to my doubts in a comment here https://news.ycombinator.com/item?id=13559060

FlatPak is a rename of xdg-app, which is the successor of Glick2, which is the successor of Glick, which was released in 2007, all by the same author.

I sympathize with them more than I used to. I attended a meeting of the Linux Standard Base working group back when systemd was truly awful compared to it's current state, and the main item on the agenda from employees of the other major Linux companies was how they were going to force Debian / Ubuntu to go along with systemd so LSB didn't have to shrink their scope or not apply to them. I no longer blame them for not wanting to play politics to be part of a community like that. I don't really like Ubuntu's style personally anymore, but for what they're trying to do, going with everyone else's solutions is probably a good thing to avoid.

My impression is the other way around... ish. Canonical tends to release their own solution to problems that the broader community is trying to solve, but not fast enough for their liking. Hence Mir before Wayland, upstart before systemd, etc.

You could call the broader community's refusal to adopt the Canonical solution NIH too, but my view is more that Canonical's shipped - but usually inferior for non-Ubuntu users - solutions prompt the community to stop trying to perfect their version's architecture and just polish and release it already.

There are two ways this has played out over the last 13 years. a) Canonical develops an open source solution to a real problem but RH and others choose not to contribute or adopt (e.g. bzr, Launchpad, upstart, Mir, Unity, LXD, Juju, Snaps, et al.). Or b) Canonical adopts open source tech from RH or others and works hard to deliver it nicely for Ubuntu users (e.g. KVM, Compiz, systemd, Ceph, etc.). Either way, inevitably Canonical is perceived as evil by an unweilding segment of the tech community, for either not adopting RH's solution or not contributing enough to RH's solution. How much should Canonical care about the unreasonable opinions of a handful of noisy Fedora fans?

How is it that Canonical is accused of NIH, but literally NO ONE ELSE IS?

Because Mir.

And upstart maybe. And Unity.

Because they have their own stuff and no one else has, roughly speaking (there's no Fedora desktop environment, no RedHat init system, okay, now there's systemd, but that's seen as Lennart's not RH's, or whatever).

Also, it's mostly noise, don't take it too seriously.

Newsflash: Canonical want the 'desktop' to die.

This is not what I expect to read on HN. Take your anti-Ubuntu zealotry elsewhere.

"Snaps are Canonical's choice for "cross distro" package management that they are trying to force on everyone else."

How are they trying to force it on anyone?

I understand that there is a Canonical / Red Hat rivalry. But I think language like this adds more heat than light to the discussion which should really be about the merits of the different solutions.

They supposedly put words into Red Hat's mouth by saying Snappy had support it clearly didn't have.

Having tried Elementary OS, various versions of Fedora, Suse, and even Mageia and Bodhi (e17 desktop), I have never found a compelling story away from Ubuntu's overwhelming advantage in online resources for non-greybeards like me. Last night, compiling mesa, with all the weirdo dependencies, this was brought home to me as half the time as I typed in an obscure package that I had to find, Google was autocompleting it with "ubuntu" appended on it. Says it all. And in my mind, snap is already gaining massively more mind-share than flatpak and everything else and that's why it's almost certain to win. And that's a good thing. It's good because Ubuntu does desktop awareness better than anyone else, in my opinion, and of course, half the battle is community building. Not just the tech.

That said, I will hand it to Fedora on ARM, where I use it quite extensively on dev boards.

I understand that Canonical proposes Snaps as a standard, but can you be specific about how they are trying to force it on everyone else?

Competition between every one of those projects have made each of them better.

As an HPC sysadmin, this interests me. However, there are two things I'd need, and I wonder if snap could be made to do it:

- Loadable versions. We use lmod (https://www.tacc.utexas.edu/research-development/tacc-projec...), so we can provide multiple versions of software for end users to leverage (they run a command like 'module load sas/4'). The user's environment then gets modified appropriately. Can snap do something like that?

- Driver dependencies are annoying. For example, TensorFlow requiring a specific CUDA, the packages for which require a specific version of the nvidia driver.

If Snap could help with those issues, that would be great!

Snap scares me a bit. Package managers are so great because we have explicit control over everything running in a system. Snaps are just glorified Mac app bundles.

Snaps might be good for deploying big complex things. But in case of smaller "apps" like some featured in their site (VLC, Blender, Krita...) this seems like a lazy solution. Lazy because we loose control over knowing which libraries are running in our system.

For example, if there's a security issue with libssl, I can quickly patch my libssl instances with apt, pacman or whatever my system uses. But with snap?

I think the way forward is the nix way [1]. It's a bit harder, but it pays off. Some big HPCs use it already, and it seems to work quite well.

[1] https://nixos.org/

Snaps (and Flatpaks) are awesome for publishers of apps and laypersons though. There's a reason the average person sees the macOS style of installation (and removal) as the gold standard.

Gold standard? Mac apps, when uninstalled naively, leave lots of stuff around under /Library (or worse, if they had a .pkg). Then you have the Frameworks complications, plist-caching hell... Just because Mac apps don't use a central registry it doesn't mean they are so much better than Windows ones. In comparison, apt-get is not bad at all: you install and uninstall anything with one command and --purge gives you you decent guarantees that it will all go away, including config files.

Snaps can be 'strictly confined' which means all their reading and writing happens in a limited set of directories exclusively for their use. So 'snap remove' cleans everything up perfectly. Ask your upstream for a strictly confined snap, it's a bit more work but once they have done it everybody wins.

Note that I said average person. They will never touch a command line, so apt-get is out, and the Ubuntu Software Center is buggy as hell. Compare that to macOS: Drag app in .dmg to 'Applications' folder: installed. Drag app from 'Applications' folder to trash: uninstalled. Need to remove all settings? remove the apps' concerning folder in ~/Library/Application Support and plist in ~/Library/Preferences. Yeah, I'd say that's pretty simple. And although the Mac App store has its flaws (draconian sandboxing) it also works like a charm.

As a fellow California HPC admin I definitely like the idea of something like SNAP. But I would want full control over it, can't have production systems down because some infrastructure somewhere else in the world is down.

Of the ones I looked at NIX looks particularly promising, having dependencies based on checksums sounds pretty cool.

You can get the snapcraft.yaml con fig of the app and recreate the snap with your modifications and adaptations.

If you install snaps from the Canonical snap store, and it is down, your systems keep running. Just that updates won't happen, and new installs will fail (well, maybe that will all work too if you have a well configured web cache in between)

If you don't like that, you can install snaps from a local file (in which case you need to handle updates yourself), or run your own snap store (I think some assembly still required)

VLC, Blender and Krita are not small applications. For the past decade these applications have been plagued by inconsistent, outdated and broken packaging. The distribution level cadence of one stable release every 2 years versus modern app cadence of an important release every few weeks leads to a neverending clash. Releasing with Appimage is not laziness, it's an escape from a Sisyphean task.

> Snaps are just glorified Mac app bundles.

AppImages even more so then. For the end user though either are simpler and allow people to get up to date versions of their apps, which is difficult when using shared libraries. Plus Snaps are also cross-distro which saves a lot of work for authors.

Yes I think Snap empowers the app vendor at the expense of the sysadmin. I think Nix is a much better approach for servers.

Some good points, but just to clarify snaps current behaviour re libssl et al:

Snap makes a distinction between a minimal set of critical core system dependencies, and application dependencies.

So on every system with a snap, there is also a 'core' snap, which has the base root fs, including glic, libssl, bash, etc. This core snap is updated regularly by its publisher (just Canonical's ubuntu core snap right now, but nothing stopping some other core snap). So a lot of critical updates are applied by default, as per normal distro policy, but just in a better way (rollback, transactional, qa, etc).

The application snap is only responsible for keeping its own dependencies up to date, it uses the base libraries from the core snap. It's distinct from docker in this way, it tries to define a line between core and app dependencies, to get the best of both worlds. I.E. critical components are updated ASAP by the disro security team, but apps are free to use a specific version of a library (e.g gnome, qt) that they want to use, rather than being stuck on the distro maintained version. Which, of course, they can still use if they want :)

It does push the burden on updating libraries to the app vendor, but on the flip side, snaps run in a very confined environment, which mitigates the scope of most CVEs there might be in an older library.

A lot of careful trade-offs considered and involved in the design - we'll see they're the right trade offs or not :)

> It's distinct from docker in this way, it tries to define a line between core and app dependencies, to get the best of both worlds. I.E. critical components are updated ASAP by the disro security team, but apps are free to use a specific version of a library (e.g gnome, qt) that they want to use, rather than being stuck on the distro maintained version.

And then as soon as an app decides to not use the base version of a library, it will still be vulnerable when you update the base snap, so you still need to check every app for updates. That's not an improvement at all.

It's not a regression either, if an app developer wants to use their own version of base libraries they will already be doing that in their .deb, .rpm or .tgz packages.

I found this confusing given all the Snapchat IPO noise today. Coincedence ?

Probably, or the poster also saw the noise and it led them to think about snaps.

There's a comment at the bottom of the snapchat $2Bn google cloud thread wondering why a package manager needs that much cloud infrastructure :)

Snapchat is based on Ubuntu servers. http://www.omgubuntu.co.uk/2016/04/ubuntu-infographic

Coincidence?

The ratio of stars of commits is interesting here. I realize that its not a really fair way to look at the project, but I wonder why are there are so many commits?

It might have been in development and/or internal use for a long time before being released to the public.

It was the package mechanism for the phone project, so that makes sense.

Stars are useless and don't mean anything except a lot of people have starred the repo.

Anyway, it's not too hard to see why they have so many commits: https://github.com/snapcore/snapd/commits/master?after=Y3Vyc...

They're taking "make lots of tiny commits" advice to an almost comical extreme.

And they also have terrible commit messages.

I don't understand what's with this issue: https://github.com/snapcore/snapd/pull/2236

What does Intel RealSense have to do with any of this?

Is it a GitHub bug, showing an issue from another repo?

@matthewbauer there's also pkgsrc which tries to be OS-agnostic. That is, targeting most of the *nixes

Can snaps be updated automatically?

Yes, by default 4 times a day the OS looks if there are updates. Manually you can do snap refresh as well. If an update fails you can rollback transactionally.

Do the snaps use shared libraries?

They are currently just included in the package. In the future, they may be shared.

Stackoverflow question: http://askubuntu.com/questions/787149/how-do-snap-packages-h...

Snaps can now export libraries, so you can get a shared Qt framework for example if you don't want to bundle that. Up to you how much you trust the library snap publisher not to break you.

Is this the first step towards a cross-distro package manager? If so, what's the point of distros anymore?

Philosophy, desktop environment and pre-installed packages probably.

From my understanding it is, in fact, a cross distro/cross version package manager.

Snaps are also sandboxed apps, that is the goal.

To have something on GNU/Linux similar to what the mainstream desktop and mobile platforms already offer.

There's so much more to a distribution than how the software is packaged. Elementary is a great example: https://elementary.io/

Yes, snaps make it so that the upstreams don't have to worry about repackaging their app for every distro. Just makes a snap and your app instantly works in a growing list of places: https://snapcraft.io/docs/core/install

But it also simplifies the work for distros. You don't need careful human review of every upload when you can trust that the app is adequately sandboxed. You don't turn away upstreams because your distro is frozen for release.

Much as I use Ubuntu myself, I find it sad that its success has created a high bar for smaller distros: the bulk of software vendors provide an Ubuntu-specific repo and nothing else (hello Spotify). Hopefully snaps will give distros broader reach and free them to innovate in more interesting areas.

Reply on news.ycombinator.com