
KDE Applications in Ubuntu Snap Store - elopio
https://apachelog.wordpress.com/2017/01/30/kde-applications-in-ubuntu-snap-store/
======
seiferteric
I still don't understand why Ubuntu is going with snaps instead of something
like guix/NixOS?

~~~
jhasse
Vendor lock-in into their Ubuntu Store.

~~~
_joel
Apart from snaps run on a plethora of distributions. Arch, Fedora, Debian,
Ubuntu... even OpenWRT. I'm not sure how you can call that vendor lock-in

~~~
jhasse
When you run `sudo snap install kblocks` it uses the Ubuntu Snap Store.

Also to create a snap you have to use Ubuntu 16.04+ (or run its image via
Docker).

~~~
_joel
16.04 is the latest long-term support, brought out last April. If you actually
want the latest snapd, you are best with 16.10 or using xenial-proposed.

Using `sudo snap install {thing}` definitely doesn't use the store. I just
installed openstack command line tools on a headless box.
[https://github.com/openstack-snaps/snap-
openstackclients](https://github.com/openstack-snaps/snap-openstackclients)

To create a snap, you use snapcraft.. basically YAML specification. I don't
know where you are getting your detail there.

~~~
jhasse
> Using `sudo snap install {thing}` definitely doesn't use the store. I just
> installed openstack command line tools on a headless box.
> [https://github.com/openstack-snaps/snap-
> openstackclients](https://github.com/openstack-snaps/snap-openstackclients)

I don't mean the store GUI application, but Canonical's servers / repository.

> To create a snap, you use snapcraft.. basically YAML specification. I don't
> know where you are getting your detail there.

ATM you still have to run snapcraft on Ubuntu 16.04+. Source:
[http://snapcraft.io/docs/build-snaps/](http://snapcraft.io/docs/build-snaps/)

~~~
_joel
Ok, so as noted, the backend canonical servers are for easy of use. It's
possible to use another service if one was inclined. Still don't see what's
specific about vendor lockin. If you couldn't run your own service and change
the default provider, then I could agree that it's vendor lock-in but it needs
(currently) a ubuntu or docker to _build_ the snaps. I still don't class that
as vendor lock-in. It's just missing effort in terms of multi-distro support.
Saying it's vendor lock-in throws up fairly draconian images in my head and
that's far from the case.

~~~
jhasse
Well, if one really wanted to use a different store, they'd have to change
hard-coded URLs in snapd's source code (for example `snap login`), set up all
the stuff (which was only tested on Ubuntu) and then ship these new tools. I
doubt that Canonical would let you keep the "snap" name by then ...

~~~
mhall119
Somebody who wants to setup their own store can send a pull request making the
changes they need to snapd to make it easier to configure. Right now it's
unclear if a "different store" would use the same data and protocol or would
want to do something entirely different. In the end it's just a means of
getting a .snap downloaded, so it can be as similar or different as the
implementer wants.

------
lighttower
Didn't AppImage solve the problem of no-sudo containerized apps already? I
tried AppImage following a post on HN recently, all you need to do is download
your desired program, it's just one file, call it `filename` then `chmod a+x
filename` and `./filename ` that's it. I can finally run Google Earth without
crashes under Linux.

~~~
jhasse
AFAIK AppImage's sandbox (Firejail) is very permissive and not enabled by
default. Flatpak is more restrictive and also supports no-sudo installations.

~~~
bkor
To read more about Flatpak security system, please check
[https://blogs.gnome.org/alexl/](https://blogs.gnome.org/alexl/):

[https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-
securit...](https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-security-
model-part-3-the-long-game/)

[https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-
securit...](https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-security-
model-part-2-who-needs-sandboxing-anyway/)

[https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-
securit...](https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-security-
model-part-1-the-basics/)

Flatpak supports Portals. So it can be restrictive, then on a toolkit level
it'll automatically allow certain things based upon user interaction. E.g.
it'll securely allow a user to select a file. Therefore the sandboxed app gets
access to that file.

Practically, because some things are on a toolkit level sandboxing can take a
bit longer. E.g. 'gimp' uses gtk+2.x, I'm guessing (though no clue), that the
Portal is only for gtk+3.something. If you cannot nicely sandbox then
meanwhile there's only one solution: almost no sandbox (e.g. still have access
to the home directory.. which gives way too many options to break the
sandbox).

------
pantalaimon
Do you really need sudo to install these?

Doesn't that defeat the point of Snap?

~~~
markshuttle
Administration of the machine - installing and removing software- generally
requires proof of admin rights at some stage. Using the apps daily does not
require admin rights. That's quite sensible.

~~~
xori
I think you should be able to download a calculator app without admin approval
when the application is self contained.

~~~
_joel
You need to write to a form of registry, there's no way to do that currently
without proper privileges.

Granted for some applications there may not need to be heavy CAPS
requirements, perhaps group membership is sufficient.

Maybe long-term (I don't know, not associated with snap development in
anyway). There will be a way to install as a user, perhpas with all config
under a ~/.snap dir or something. Until then....

~~~
lima
You can add .desktop files to .local/share/applications hust fine and the
gnome registry is user-specific, not global.

~~~
_joel
Well, sure, but that's not currently the way it works. I'm sure the use of
sudo could be designed away. I think it's worth mentioning that it's not just
for desktop apps too, services have been ported too it as well as cli centric
programs (in fact, I've personally only used those)

------
tapoxi
Is there a significant difference between snap and flatpak or is it just
another case of "not invented here" by one of the distros?

~~~
_joel
They were both initiated at approximately the same time (git commits at the
end of 2014), so no I don't personally think it's NiH syndrome.

I quite like the manifest approach to snaps(snapcraft) as oppposed to a tree
approach in flatpak but that could be personal preference. In reality there is
little difference to the end user, they get apps delivered. From a developer
perspective slight difference.

