KDE Applications in Ubuntu Snap Store | Hacker News Reader

KDE Applications in Ubuntu Snap Store

apachelog.wordpress.com

44 pointselopio29 comments

I still don't understand why Ubuntu is going with snaps instead of something like guix/NixOS?

Vendor lock-in into their Ubuntu Store.

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

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

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

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

> 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

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/

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.

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

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.

snapd could be pointed to another store if somebody wanted to make one. But the Ubuntu Snap Store is free to use and open to anyone, and having them all in one location makes discovery so much easier.

The limitation on snapcraft is technical, not intentional, and it's being worked on to make snapcraft itself distributable as a snap, so it will work on any distro that snaps work on.

The support on non-Ubuntu distributions differ. The sandboxing requires AppArmor. Various distributions use SELinux and that support isn't there (obviously on the todo). Further, heard that even with AppArmor a distribution needed to apply some AppArmor patches to the kernel.

They run on various distributions, but not in the same way.

Agreed, but not quite the same as saying it's vendor lock-in, is it.

I did not claim that, I merely added something to your statement.

With Snaps too easily the caveats are ignored. Theoretically you could run your own store. Practically it needed an environment variable, plus (at least at that time) the server code wasn't open.

Snaps are IMO quite a success (seems more used than Flatpak& AppImage), but always find a bit unfortunate that its limitations aren't mentioned. E.g. only today I learned that it doesn't do user installation. Similarly the sandboxed and running on multiple distributions.

Understood, apologies if the comment seemed terse.

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.

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

To read more about Flatpak security system, please check https://blogs.gnome.org/alexl/:

https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-securit...

https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-securit...

https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-securit...

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

Do you really need sudo to install these?

Doesn't that defeat the point of Snap?

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.

I was under the impression that Snap and Flatpak were similar in that they made it possible to run containerized, sandboxed apps without needing root privileges. Am I wrong?

Flatpak supports per-user app installations. Snap currently does not.

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

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

They could just copy OSX's approach: a privileged system search-indexer daemon "discovers" new app bundles users have plopped onto the disk, and then it tells a privileged "Launch Services" daemon about those bundles, which extracts their metadata and sticks it into its registry. (This is why e.g. filetype associations for apps get registered on OSX the moment you extract the app to disk; or, more recently, the moment you de-quarantine the app from its internet origin.)

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

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)

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

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.

They both evolved in parallel from previous technology

Reply on news.ycombinator.com