
Snaps are universal Linux packages - GutenYe
https://github.com/snapcore/snapd
======
matthewbauer
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.

~~~
qznc
FlatPak is intended for Desktop only. "is not a good match for a server"
[http://flatpak.org/faq.html](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/](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](http://flatpak.org/apps.html)

FlatPak does not provide a central repository, while Snap has
[https://uappexplorer.com/](https://uappexplorer.com/). After install flatpak,
it takes three (!) commands (on cli) to install LibreOffice.
[http://flatpak.org/apps.html](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.

~~~
ugos
"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

~~~
StavrosK
Isn't that the same as apt and PPAs?

~~~
ugos
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

------
jcoffland
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.

~~~
flukus
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.

~~~
notatoad
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.

~~~
slitaz
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.

------
indolering
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.

~~~
pjmlp
> 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.

~~~
flukus
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.

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

~~~
seenitall
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.

~~~
vetinari
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.

~~~
mhall119
s/tough luck/patches welcome/

~~~
vetinari
Patches here:
[https://github.com/flatpak/flatpak](https://github.com/flatpak/flatpak) ;)

------
CaliforniaKarl
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...](https://www.tacc.utexas.edu/research-
development/tacc-projects/lmod)), 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!

~~~
nextos
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/](https://nixos.org/)

~~~
sliken
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.

~~~
stubish
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)

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

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

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

------
banterfoil
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?

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

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

------
k_sze
I don't understand what's with this issue:
[https://github.com/snapcore/snapd/pull/2236](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?

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

------
chris_wot
Can snaps be updated automatically?

~~~
mectors
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.

------
jryan49
Do the snaps use shared libraries?

~~~
matthewbauer
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...](http://askubuntu.com/questions/787149/how-do-snap-packages-
handle-shared-dependencies)

~~~
seenitall
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.

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

~~~
angryteabag
Philosophy, desktop environment and pre-installed packages probably.

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

~~~
pjmlp
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.

