14 ms·

KDE Applications in Ubuntu Snap Store

44 points by elopio 10y ago

pantalaimon 10y ago
Do you really need sudo to install these? Doesn't that defeat the point of Snap?
- markshuttle 10y ago
  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.
  - moosingin3space 10y ago
    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?
    - curt15 10y ago
      Flatpak supports per-user app installations. Snap currently does not.
  - xori 10y ago
    I think you should be able to download a calculator app without admin approval when the application is self contained.
    - _joel 10y ago
      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....
      - derefr 10y ago
        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.)
      - lima 10y ago
        You can add .desktop files to .local/share/applications hust fine and the gnome registry is user-specific, not global.
        _joel 10y ago
        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)
seiferteric 10y ago
I still don't understand why Ubuntu is going with snaps instead of something like guix/NixOS?
- jhasse 10y ago
  Vendor lock-in into their Ubuntu Store.
  - _joel 10y ago
    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 10y ago
      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 10y ago
        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 10y ago
        > 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/
tapoxi 10y ago
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 10y ago
  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.
- mhall119 10y ago
  They both evolved in parallel from previous technology
lighttower 10y ago
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 10y ago
  AFAIK AppImage's sandbox (Firejail) is very permissive and not enabled by default. Flatpak is more restrictive and also supports no-sudo installations.
  - bkor 10y ago
    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-security-model-part-3-the-long-game/ https://blogs.gnome.org/alexl/2017/01/24/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/20/the-flatpak-securit... https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-security-model-part-1-the-basics/ 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).

44 points by elopio 10y ago

pantalaimon 10y ago

Do you really need sudo to install these? Doesn't that defeat the point of Snap?

markshuttle 10y ago
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.
- moosingin3space 10y ago
  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?
  - curt15 10y ago
    Flatpak supports per-user app installations. Snap currently does not.
- xori 10y ago
  I think you should be able to download a calculator app without admin approval when the application is self contained.
  - _joel 10y ago
    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....
    - derefr 10y ago
      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.)
    - lima 10y ago
      You can add .desktop files to .local/share/applications hust fine and the gnome registry is user-specific, not global.
      - _joel 10y ago
        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)

seiferteric 10y ago

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

jhasse 10y ago
Vendor lock-in into their Ubuntu Store.
- _joel 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        > 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/

tapoxi 10y ago

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 10y ago
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.
mhall119 10y ago
They both evolved in parallel from previous technology

lighttower 10y ago

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 10y ago
AFAIK AppImage's sandbox (Firejail) is very permissive and not enabled by default. Flatpak is more restrictive and also supports no-sudo installations.
- bkor 10y ago
  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-security-model-part-3-the-long-game/ https://blogs.gnome.org/alexl/2017/01/24/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/20/the-flatpak-securit... https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-security-model-part-1-the-basics/ 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).