Snaps are universal Linux packages

So there are a couple of different projects trying to be distro-agnostic&#x2F;sandboxed&#x2F;multi-version package managers:<p>- Snappy<p>- FlatPak<p>- AppImage<p>- Nix<p>Snappy is an Ubuntu&#x2F;Canonical project and FlatPak is a Fedora&#x2F;RedHat&#x2F;FreeDesktop project. Snappy and FlatPak are remarkably similar and kind of mirror the DEB&#x2F;RPM spit. Nix and AppImage are independent.<p>AppImages resemble macOS&#x27;s app bundles in that they can be run directly without installation. Snappy, FlatPak, and Nix need to install to a root directory, &#x2F;snap, &#x2F;var&#x2F;lib&#x2F;flatpak&#x2F;, and &#x2F;nix respectively. FlatPak and Snappy need a runtime daemon but Nix and AppImage don&#x27;t.<p>AppImage, Snappy, and FlatPak include all of the dependencies in one package. Nix packages just include hash names and install as needed.

A good package management system is a very important part of a Linux distro. What&#x27;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&#x27;t backed up by well maintained packages then those tools are pretty use less.<p>This is why Debian has dominated Linux distros for decades. Debian&#x27;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.<p>Only time will tell if any of these next-gen package managers will succeed.

Snaps are <i></i>Canonical&#x27;s<i></i> choice for &quot;cross distro&quot; package management that they are trying to force on everyone else. They came out of nowhere and it doesn&#x27;t play well with other distros.<p>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&#x27;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.<p>But now we are going to have yet-another-bifurcation of OSS solutions: RPM vs DEB, KDE vs GNOME, Wayland vs Mir.<p>Canonical, stop trying to be Apple, please.

As an HPC sysadmin, this interests me. However, there are two things I&#x27;d need, and I wonder if snap could be made to do it:<p>- Loadable versions. We use lmod (<a href="https:&#x2F;&#x2F;www.tacc.utexas.edu&#x2F;research-development&#x2F;tacc-projects&#x2F;lmod" rel="nofollow">https:&#x2F;&#x2F;www.tacc.utexas.edu&#x2F;research-development&#x2F;tacc-projec...</a>), so we can provide multiple versions of software for end users to leverage (they run a command like &#x27;module load sas&#x2F;4&#x27;). The user&#x27;s environment then gets modified appropriately. Can snap do something like that?<p>- Driver dependencies are annoying. For example, TensorFlow requiring a specific CUDA, the packages for which require a specific version of the nvidia driver.<p>If Snap could help with those issues, that would be great!

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

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?

I don&#x27;t understand what&#x27;s with this issue: <a href="https:&#x2F;&#x2F;github.com&#x2F;snapcore&#x2F;snapd&#x2F;pull&#x2F;2236" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;snapcore&#x2F;snapd&#x2F;pull&#x2F;2236</a><p>What does Intel RealSense have to do with any of this?<p>Is it a GitHub bug, showing an issue from another repo?

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

Can snaps be updated automatically?

Do the snaps use shared libraries?

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