
Canonical’s Snap: The Good, the Bad, and the Ugly - slyall
http://thenewstack.io/canonicals-snap-great-good-bad-ugly/
======
cs702
The technical criticisms here are not really directed at Snap, but at the
trade-offs inherent to the sandboxed-application packaging model in general.

Speaking as day-to-day desktop Linux user, a working sandboxed-app model would
be a BIG improvement over rpms and debs. I would LOVE to be able to install
any version of any application, or multiple versions, independently of OS and
library versions, without having to compile from source code, grapple with
conflicting dependencies, etc.

Are there any F/LOSS alternatives to Snap that are as widely used and tested?
If there aren't any, Snap is really our "least worst" alternative.

~~~
reacweb
As a Linux user since many years, I like very much the traditional package
management. I think the efforts should be put on reliability and hardware
handling. I have migrated from 14.04 LTS to 16.04 recently. I am using a NAS
drive. After my do-release-upgrade -d, internet was not working anymore
because of systemd circularity problem. I had to learn how to create systemd
configuration files to describe remote filesystem mounts.

The focus when clicking on chrome did not work anymore
([http://askubuntu.com/questions/760654/cick-to-focus-is-
not-w...](http://askubuntu.com/questions/760654/cick-to-focus-is-not-
working-16-04/789056#789056)).

When my computer enters in sleep mode, I can wake it with a press on enter.
The next time, it enters in sleep mode, I can not wake it up anymore.

I have fixed the two first issues and worked around the third one. I dream
ubuntu becomes more used, but these kind of issues is blocking.

~~~
blacksmith_tb
I agree that it should get easier, from release to release, to upgrade, but I
am not surprised by the bugs you encountered. On the plus side, the first
'really stable' Xenial release is due soon [1] though I can't say that would
guarantee your bugs will be squashed, even then - however, it is important to
log them [2] to make sure they get some attention.

1:
[https://launchpad.net/ubuntu/+milestone/ubuntu-16.04.1](https://launchpad.net/ubuntu/+milestone/ubuntu-16.04.1)
2:
[https://help.ubuntu.com/community/ReportingBugs](https://help.ubuntu.com/community/ReportingBugs)

------
throw2016
This unfortunately reads like a hit piece with no information of Snap at all.
It's like the author did not even install Snap raising questions about the
premise and purpose of the article. Where is the good, bad and ugly?

For instance branding Ubuntu initiatives like Snap or Mir as 'NIH' and leaving
Redhat supported ones like XDG, Flatpak, Systemd etc is itself an act of
politics and manipulation.

This leaves little room for informed discussion. Linux is heavily politicised
with tons of vested interests and thousands of folks and projects sponsored by
or in the employment of various players.

Maybe its time to stop tiptoeing around the politics and let it out in the
open so there can be more informed discussion and less of the simplistic PR
driven fantasy narratives like 'fedora is independent but Ubuntu is not' that
this article pushes.

------
danieldk
This piece is only about politics, which is the usual drama: most players have
an NIH-attitude and we'll end up with three different standards. No one is
helped except for news outlets who can proceed to construct a nice dramatic
'he said, she said' story.

It would be more interesting to see an in-depth technical comparison of Linux
app container implementations, so that an outsider can make an informed
choice.

~~~
bkor
Politics are quite important to do right and politics is different from NIH.
The article notes two important things:

1) Canonical wanting to do big announcements. This causes problems if you want
to work with communities. They'll try and work and get support, but one person
per distribution isn't the same as working with the entire community. So when
the announcement implies that there's broad support, the communities feel like
it is a big lie. That'll destroy the willingness to cooperate.

2) Canonical likes to keep control. E.g. the CLA. Canonical has special rights
nobody else will have. Companies don't like this at all, it changes the
working together into helping a competitor. It doesn't make business sense.
Canonical tries to solve things by e.g. saying you keep the copyright, but
that is just ignoring the actual issue. This CLA has been an issue for various
Canonical projects for many years. An "we might change this" I don't trust.
Similarly, Canonical rolled this out while the code only supports the
Canonical proprietary app store. Someone else now made a open/free source (not
sure which) store, but at the moment the experience quite assumes just one app
store.

Those two things together make people want to refrain from spending time
(doesn't matter much if they're paid or not).

Note: I'm biased and I like Flatpak as well as AppImage. I don't see the
problem in having multiple standards. Canonical is IMO very good at having a
great Ubuntu experience. They're (again IMO) terrible at doing cross
distribution work due to reasons explained above.

~~~
cbHXBY1D
I too am leaning toward Flatpak. I expect it, like other products from Red Hat
(systemd, pulseaudio) will eventually be the winner in the end.

------
IshKebab
That didn't really give any details about what is good, bad or ugly about
Snap.

------
dkarapetyan
This is again more political bullshit. I know exactly what is going to happen.
We are again going to have 3 different ways to package containerized
applications and someone is going to come along and create another `fpm` but
this time for containerized applications. I'm going to go back to pretending
that `deb` and `rpm` don't exist and my packaging format is `fpm`.

~~~
em3rgent0rdr
[https://xkcd.com/927/](https://xkcd.com/927/) "How Standards Proliferate" :P

------
joveian
"Snap is the equivalent of static linking". So why not statically link?
Encouraging software to work with static linking would be helpful for
unikernels also.

With delta compression, I think my weekly updates on Arch are at least 200MiB,
not even counting particularly large packages. Over a month, nearly half the
system is replaced. For static linking (or equivalent) to be practical for
those of us with limited bandwidth connections there would need to be some
excellent cross-binary delta compression. In some situations it is useful, but
for a general purpose system I think shared libraries make more sense.

OpenPandora's PND system is another example of prior art.
[http://pandorawiki.org/Introduction_to_PNDs](http://pandorawiki.org/Introduction_to_PNDs)

------
marcoceppi
> CoreOS and Red Hat are sponsors of The New Stack.

------
jhasse
Is it correct that I'll need to login with an Ubuntu One account to install a
Snap package?

~~~
dkarapetyan
Of course not. That wouldn't make any sense. Do you need to log into any
account to install rpm or deb package?

------
SFJulie
systemd a superior solution ?

Guh.

If we had not systemd and had kept it simple stupid, there would be no need
for snap: \- you compile the application in static (à la windows) \- and you
do a chroot (or as they call it a namespace).

Ksss, I am wrong, I see it.

But then, when you make a multi-tiers architecture, how do you make stuff
communicate? Well, easy, web services.

But how do you know where they are? How do you print? How do you register
PlayMediaKey as a way to start your application? How do you make sure the
«right application» can set the time (ntp/system preferences) while other
applications are kept away?

Guh ....

registry base? Autodiscovery? You need a bus? An IPC?

And what of the mess of Xorg? How do I prevent applications to see or
intercept informations they should not see?

Most engineers have troubles with a basic group/permission model already and
OSX/AD have proven that a more complex schema based on a complex namespace
often in practice results to poorer results.... how do we make access secured?

Oh! you still have the "one application in foreground has all rights"... the
kind of tablet model à la iOS. But then, we are losing the advantage of
multitasking... like listening to music while writing or playing games.

So back again in square one of being confined BUT able to cooperate.

JAVA and its JVM was a way to answer this problem: let's forget all of this
and control at the application layer of the JVM.

But then, how do you talk to hardware?

java or not, application needs to know about the hardware, but we have no
fixed address for HW devices (minor/major nodes are long gone, and PCI/USB
vendor id are not pointing to a single HW target since long)

So maybe we could have a virtual HW that talks to the real HW with a
translation in the middle ? (VMware, Xen...)

Ho! But I want to make sure I develop for a single target!

Well, good luck unifying games dev in a single image while making sure the
screensaver don't override it, while not preventing security applications to
do emergency locks... and still having the right level of acceleration...

And then, the world of confinment is biting his tails always asking itself the
same questions.

For the old persons, let's just accept that easy image deployment could be
like on Amiga/C64/amstrad &al: a unique HW, with a single application. You
jump to org and execute the ASM in single mode. Problem solved.

But the more we expect from easy to code with cooperation (wouldn't it be
ridiculous to put printer/HD/SD driver in a text application,
network/audio/video driver in a browser) the more our apps are dependent from
an ecosystem that is a moving target.

Basically there can be no easy confinement (application snapshot) without a
unified abstraction of HW and services as well of their properties whereas the
complexity of OS is growing (more HW, more protocols, more "required
dependencies" à la systemd).

Basically confined image deployment on heterogeneous system/HW is a chimera
unless you confine yourself to very basic tasks that requires no dependencies
(like mono post calculus in FORTRAN using stdin/stdout).

We are just in the hell of the dependencies. And I don't think there is any
silver bullet for this situation. This problem grows more than linearly in
complexity as a cross product of all the potential differences in the
configuration space.

Let's forget about chimeras.

The complexity is dooming the costs model of application development. As the
HW/OS landscape is splitting in different direction with legacy systems still
needing updates, development has to face the world of a constant
progress/obsolescence where devs are told to forget about past platforms to be
hype, and customers have the need to keep their legacy systems in production.

Sometimes there is no solutions to a problem.

