from Hacker News

Snaps are universal Linux packages

by GutenYe on 2/3/17, 2:16 AM with 97 comments

• by matthewbauer on 2/3/17, 4:25 AM

  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.

• by jcoffland on 2/3/17, 5:26 AM

  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.

• by indolering on 2/3/17, 5:23 AM

  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.

• by CaliforniaKarl on 2/3/17, 2:41 AM

  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!

• by dberg on 2/3/17, 3:57 AM

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

• by banterfoil on 2/3/17, 4:02 AM

  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?

• by k_sze on 2/4/17, 1:26 AM

  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?

• by lowry on 2/3/17, 7:48 AM

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

• by chris_wot on 2/3/17, 6:27 AM

  Can snaps be updated automatically?

• by jryan49 on 2/3/17, 4:16 AM

  Do the snaps use shared libraries?

• by jryan49 on 2/3/17, 4:11 AM

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