16 ms·

Snaps are universal Linux packages

117 points by GutenYe 10y ago

CaliforniaKarl 10y ago
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-projects/lmod https://www.tacc.utexas.edu/research-development/tacc-projec...), 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 10y ago
  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/
  - tornadoboy55 10y ago
    Snaps (and Flatpaks) are awesome for publishers of apps and laypersons though. There's a reason the average person sees the macOS style of installation (and removal) as the gold standard.
    - toyg 10y ago
      Gold standard? Mac apps, when uninstalled naively, leave lots of stuff around under /Library (or worse, if they had a .pkg). Then you have the Frameworks complications, plist-caching hell... Just because Mac apps don't use a central registry it doesn't mean they are so much better than Windows ones. In comparison, apt-get is not bad at all: you install and uninstall anything with one command and --purge gives you you decent guarantees that it will all go away, including config files.
      - seenitall 10y ago
        Snaps can be 'strictly confined' which means all their reading and writing happens in a limited set of directories exclusively for their use. So 'snap remove' cleans everything up perfectly. Ask your upstream for a strictly confined snap, it's a bit more work but once they have done it everybody wins.
      - tornadoboy55 10y ago
        Note that I said average person. They will never touch a command line, so apt-get is out, and the Ubuntu Software Center is buggy as hell. Compare that to macOS: Drag app in .dmg to 'Applications' folder: installed. Drag app from 'Applications' folder to trash: uninstalled. Need to remove all settings? remove the apps' concerning folder in ~/Library/Application Support and plist in ~/Library/Preferences. Yeah, I'd say that's pretty simple. And although the Mac App store has its flaws (draconian sandboxing) it also works like a charm.
  - sliken 10y ago
    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.
    - Lintaris 10y ago
      You can get the snapcraft.yaml con fig of the app and recreate the snap with your modifications and adaptations.
    - stubish 10y ago
      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)
  - pzone 10y ago
    VLC, Blender and Krita are not small applications. For the past decade these applications have been plagued by inconsistent, outdated and broken packaging. The distribution level cadence of one stable release every 2 years versus modern app cadence of an important release every few weeks leads to a neverending clash. Releasing with Appimage is not laziness, it's an escape from a Sisyphean task.
  - mangecoeur 10y ago
    > Snaps are just glorified Mac app bundles. AppImages even more so then. For the end user though either are simpler and allow people to get up to date versions of their apps, which is difficult when using shared libraries. Plus Snaps are also cross-distro which saves a lot of work for authors.
  - mangecoeur 10y ago
    > Snaps are just glorified Mac app bundles. AppImages even more so then. For the end user though either are simpler and allow people to get up to date versions of their apps, which is difficult when using shared libraries. Plus Snaps are also cross-distro which saves a lot of work for authors.
  - willtim 10y ago
    Yes I think Snap empowers the app vendor at the expense of the sysadmin. I think Nix is a much better approach for servers.
  - bloodearnest 10y ago
    Some good points, but just to clarify snaps current behaviour re libssl et al: Snap makes a distinction between a minimal set of critical core system dependencies, and application dependencies. So on every system with a snap, there is also a 'core' snap, which has the base root fs, including glic, libssl, bash, etc. This core snap is updated regularly by its publisher (just Canonical's ubuntu core snap right now, but nothing stopping some other core snap). So a lot of critical updates are applied by default, as per normal distro policy, but just in a better way (rollback, transactional, qa, etc). The application snap is only responsible for keeping its own dependencies up to date, it uses the base libraries from the core snap. It's distinct from docker in this way, it tries to define a line between core and app dependencies, to get the best of both worlds. I.E. critical components are updated ASAP by the disro security team, but apps are free to use a specific version of a library (e.g gnome, qt) that they want to use, rather than being stuck on the distro maintained version. Which, of course, they can still use if they want :) It does push the burden on updating libraries to the app vendor, but on the flip side, snaps run in a very confined environment, which mitigates the scope of most CVEs there might be in an older library. A lot of careful trade-offs considered and involved in the design - we'll see they're the right trade offs or not :)
    - mmarx 10y ago
      > It's distinct from docker in this way, it tries to define a line between core and app dependencies, to get the best of both worlds. I.E. critical components are updated ASAP by the disro security team, but apps are free to use a specific version of a library (e.g gnome, qt) that they want to use, rather than being stuck on the distro maintained version. And then as soon as an app decides to not use the base version of a library, it will still be vulnerable when you update the base snap, so you still need to check every app for updates. That's not an improvement at all.
      - mhall119 10y ago
        It's not a regression either, if an app developer wants to use their own version of base libraries they will already be doing that in their .deb, .rpm or .tgz packages.
dberg 10y ago
I found this confusing given all the Snapchat IPO noise today. Coincedence ?
- boomboomsubban 10y ago
  Probably, or the poster also saw the noise and it led them to think about snaps.
  - notatoad 10y ago
    There's a comment at the bottom of the snapchat $2Bn google cloud thread wondering why a package manager needs that much cloud infrastructure :)
- Lintaris 10y ago
  Snapchat is based on Ubuntu servers. http://www.omgubuntu.co.uk/2016/04/ubuntu-infographic http://www.omgubuntu.co.uk/2016/04/ubuntu-infographic Coincidence?
banterfoil 10y ago
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 10y ago
  It might have been in development and/or internal use for a long time before being released to the public.
  - itomato 10y ago
    It was the package mechanism for the phone project, so that makes sense.
- jlarocco 10y ago
  Stars are useless and don't mean anything except a lot of people have starred the repo. Anyway, it's not too hard to see why they have so many commits: https://github.com/snapcore/snapd/commits/master?after=Y3Vyc29yOiuZmoBnS3D5flJ0LL31daMhYG30KzY5 https://github.com/snapcore/snapd/commits/master?after=Y3Vyc... They're taking "make lots of tiny commits" advice to an almost comical extreme. And they also have terrible commit messages.
jryan49 10y ago
Is this the first step towards a cross-distro package manager? If so, what's the point of distros anymore?
- angryteabag 10y ago
  Philosophy, desktop environment and pre-installed packages probably. From my understanding it is, in fact, a cross distro/cross version package manager.
  - pjmlp 10y ago
    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.
- evand 10y ago
  There's so much more to a distribution than how the software is packaged. Elementary is a great example: https://elementary.io/ https://elementary.io/ Yes, snaps make it so that the upstreams don't have to worry about repackaging their app for every distro. Just makes a snap and your app instantly works in a growing list of places: https://snapcraft.io/docs/core/install https://snapcraft.io/docs/core/install But it also simplifies the work for distros. You don't need careful human review of every upload when you can trust that the app is adequately sandboxed. You don't turn away upstreams because your distro is frozen for release. Much as I use Ubuntu myself, I find it sad that its success has created a high bar for smaller distros: the bulk of software vendors provide an Ubuntu-specific repo and nothing else (hello Spotify). Hopefully snaps will give distros broader reach and free them to innovate in more interesting areas.
jryan49 10y ago
Do the snaps use shared libraries?
- matthewbauer 10y ago
  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-handle-shared-dependencies http://askubuntu.com/questions/787149/how-do-snap-packages-h...
  - seenitall 10y ago
    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.
matthewbauer 10y ago
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.
- ffuugoo 10y ago
  I'd not compare Nix to other three. Yes, you are right, it is kind of "distro-agnostic/sandboxed/multiple-versions", it "need to install to a root directory" and does not "need a runtime daemon", but otherwise it is totally different and much more than others.
  - chriswarbo 10y ago
    I mostly agree, but there is a similarity in that the Nix build/CI server "Hydra" puts a "One click install" link on build outputs (e.g. http://hydra.nixos.org/build/47550492 http://hydra.nixos.org/build/47550492 )
- PutinIsEvil 10y ago
  Thanks for the summary. I'd suggest everyone to stay away from Snaps. This is Ubuntu being heavyhanded. I've used AppImage and like it because I literally didn't have to do anything. But the application that I used (powershell) takes a bit to load. Could be powershell, could be AppImage.
- huevo5050 10y ago
  What about Chef's Habitat [0], is playing the same league? [0] http://habitat.sh http://habitat.sh
- 10y ago
indolering 10y ago
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.
- daveguy 10y ago
  > 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. Is security compatibility the primary advantage over docker? When I see these I always think, why not docker? Git like distribution, pick underlying / roll your own. I'm not sure why these are better than a docker or rkt.
  - gjjrfcbugxbhf 10y ago
    Docker doesn't work for desktop gui apps. Also it doesn't provide great security sandboxing. Also docker is not the first containerisation solution why not LXC?
    - fulafel 10y ago
      It works for GUI apps, see eg. https://hub.docker.com/r/tomparys/skype/ https://hub.docker.com/r/tomparys/skype/
      - satai 10y ago
        X11 only, no Wayland :-/
jcoffland 10y ago
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.
- matthewbauer 10y ago
  What makes things a little easier is they can be installed along with your standard package manager.
- flukus 10y ago
  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 10y ago
    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 10y ago
      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.
- Lintaris 10y ago
  I think it is the hard work of the maintainers to ensure quality that makes .deb stand out.
chris_wot 10y ago
Can snaps be updated automatically?
- mectors 10y ago
  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.
lowry 10y ago
@matthewbauer there's also pkgsrc which tries to be OS-agnostic. That is, targeting most of the *nixes
k_sze 10y ago
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?

117 points by GutenYe 10y ago

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-projects/lmod https://www.tacc.utexas.edu/research-development/tacc-projec...), 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 10y ago
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/
- tornadoboy55 10y ago
  Snaps (and Flatpaks) are awesome for publishers of apps and laypersons though. There's a reason the average person sees the macOS style of installation (and removal) as the gold standard.
  - toyg 10y ago
    Gold standard? Mac apps, when uninstalled naively, leave lots of stuff around under /Library (or worse, if they had a .pkg). Then you have the Frameworks complications, plist-caching hell... Just because Mac apps don't use a central registry it doesn't mean they are so much better than Windows ones. In comparison, apt-get is not bad at all: you install and uninstall anything with one command and --purge gives you you decent guarantees that it will all go away, including config files.
    - seenitall 10y ago
      Snaps can be 'strictly confined' which means all their reading and writing happens in a limited set of directories exclusively for their use. So 'snap remove' cleans everything up perfectly. Ask your upstream for a strictly confined snap, it's a bit more work but once they have done it everybody wins.
    - tornadoboy55 10y ago
      Note that I said average person. They will never touch a command line, so apt-get is out, and the Ubuntu Software Center is buggy as hell. Compare that to macOS: Drag app in .dmg to 'Applications' folder: installed. Drag app from 'Applications' folder to trash: uninstalled. Need to remove all settings? remove the apps' concerning folder in ~/Library/Application Support and plist in ~/Library/Preferences. Yeah, I'd say that's pretty simple. And although the Mac App store has its flaws (draconian sandboxing) it also works like a charm.
- sliken 10y ago
  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.
  - Lintaris 10y ago
    You can get the snapcraft.yaml con fig of the app and recreate the snap with your modifications and adaptations.
  - stubish 10y ago
    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)
- pzone 10y ago
  VLC, Blender and Krita are not small applications. For the past decade these applications have been plagued by inconsistent, outdated and broken packaging. The distribution level cadence of one stable release every 2 years versus modern app cadence of an important release every few weeks leads to a neverending clash. Releasing with Appimage is not laziness, it's an escape from a Sisyphean task.
- mangecoeur 10y ago
  > Snaps are just glorified Mac app bundles. AppImages even more so then. For the end user though either are simpler and allow people to get up to date versions of their apps, which is difficult when using shared libraries. Plus Snaps are also cross-distro which saves a lot of work for authors.
- mangecoeur 10y ago
  > Snaps are just glorified Mac app bundles. AppImages even more so then. For the end user though either are simpler and allow people to get up to date versions of their apps, which is difficult when using shared libraries. Plus Snaps are also cross-distro which saves a lot of work for authors.
- willtim 10y ago
  Yes I think Snap empowers the app vendor at the expense of the sysadmin. I think Nix is a much better approach for servers.
- bloodearnest 10y ago
  Some good points, but just to clarify snaps current behaviour re libssl et al: Snap makes a distinction between a minimal set of critical core system dependencies, and application dependencies. So on every system with a snap, there is also a 'core' snap, which has the base root fs, including glic, libssl, bash, etc. This core snap is updated regularly by its publisher (just Canonical's ubuntu core snap right now, but nothing stopping some other core snap). So a lot of critical updates are applied by default, as per normal distro policy, but just in a better way (rollback, transactional, qa, etc). The application snap is only responsible for keeping its own dependencies up to date, it uses the base libraries from the core snap. It's distinct from docker in this way, it tries to define a line between core and app dependencies, to get the best of both worlds. I.E. critical components are updated ASAP by the disro security team, but apps are free to use a specific version of a library (e.g gnome, qt) that they want to use, rather than being stuck on the distro maintained version. Which, of course, they can still use if they want :) It does push the burden on updating libraries to the app vendor, but on the flip side, snaps run in a very confined environment, which mitigates the scope of most CVEs there might be in an older library. A lot of careful trade-offs considered and involved in the design - we'll see they're the right trade offs or not :)
  - mmarx 10y ago
    > It's distinct from docker in this way, it tries to define a line between core and app dependencies, to get the best of both worlds. I.E. critical components are updated ASAP by the disro security team, but apps are free to use a specific version of a library (e.g gnome, qt) that they want to use, rather than being stuck on the distro maintained version. And then as soon as an app decides to not use the base version of a library, it will still be vulnerable when you update the base snap, so you still need to check every app for updates. That's not an improvement at all.
    - mhall119 10y ago
      It's not a regression either, if an app developer wants to use their own version of base libraries they will already be doing that in their .deb, .rpm or .tgz packages.

dberg 10y ago

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

boomboomsubban 10y ago
Probably, or the poster also saw the noise and it led them to think about snaps.
- notatoad 10y ago
  There's a comment at the bottom of the snapchat $2Bn google cloud thread wondering why a package manager needs that much cloud infrastructure :)
Lintaris 10y ago
Snapchat is based on Ubuntu servers. http://www.omgubuntu.co.uk/2016/04/ubuntu-infographic http://www.omgubuntu.co.uk/2016/04/ubuntu-infographic Coincidence?

banterfoil 10y ago

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 10y ago
It might have been in development and/or internal use for a long time before being released to the public.
- itomato 10y ago
  It was the package mechanism for the phone project, so that makes sense.
jlarocco 10y ago
Stars are useless and don't mean anything except a lot of people have starred the repo. Anyway, it's not too hard to see why they have so many commits: https://github.com/snapcore/snapd/commits/master?after=Y3Vyc29yOiuZmoBnS3D5flJ0LL31daMhYG30KzY5 https://github.com/snapcore/snapd/commits/master?after=Y3Vyc... They're taking "make lots of tiny commits" advice to an almost comical extreme. And they also have terrible commit messages.

jryan49 10y ago

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

angryteabag 10y ago
Philosophy, desktop environment and pre-installed packages probably. From my understanding it is, in fact, a cross distro/cross version package manager.
- pjmlp 10y ago
  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.
evand 10y ago
There's so much more to a distribution than how the software is packaged. Elementary is a great example: https://elementary.io/ https://elementary.io/ Yes, snaps make it so that the upstreams don't have to worry about repackaging their app for every distro. Just makes a snap and your app instantly works in a growing list of places: https://snapcraft.io/docs/core/install https://snapcraft.io/docs/core/install But it also simplifies the work for distros. You don't need careful human review of every upload when you can trust that the app is adequately sandboxed. You don't turn away upstreams because your distro is frozen for release. Much as I use Ubuntu myself, I find it sad that its success has created a high bar for smaller distros: the bulk of software vendors provide an Ubuntu-specific repo and nothing else (hello Spotify). Hopefully snaps will give distros broader reach and free them to innovate in more interesting areas.

jryan49 10y ago

Do the snaps use shared libraries?

matthewbauer 10y ago
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-handle-shared-dependencies http://askubuntu.com/questions/787149/how-do-snap-packages-h...
- seenitall 10y ago
  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.

matthewbauer 10y ago

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.

ffuugoo 10y ago
I'd not compare Nix to other three. Yes, you are right, it is kind of "distro-agnostic/sandboxed/multiple-versions", it "need to install to a root directory" and does not "need a runtime daemon", but otherwise it is totally different and much more than others.
- chriswarbo 10y ago
  I mostly agree, but there is a similarity in that the Nix build/CI server "Hydra" puts a "One click install" link on build outputs (e.g. http://hydra.nixos.org/build/47550492 http://hydra.nixos.org/build/47550492 )
PutinIsEvil 10y ago
Thanks for the summary. I'd suggest everyone to stay away from Snaps. This is Ubuntu being heavyhanded. I've used AppImage and like it because I literally didn't have to do anything. But the application that I used (powershell) takes a bit to load. Could be powershell, could be AppImage.
huevo5050 10y ago
What about Chef's Habitat [0], is playing the same league? [0] http://habitat.sh http://habitat.sh
10y ago

indolering 10y ago

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.

daveguy 10y ago
> 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. Is security compatibility the primary advantage over docker? When I see these I always think, why not docker? Git like distribution, pick underlying / roll your own. I'm not sure why these are better than a docker or rkt.
- gjjrfcbugxbhf 10y ago
  Docker doesn't work for desktop gui apps. Also it doesn't provide great security sandboxing. Also docker is not the first containerisation solution why not LXC?
  - fulafel 10y ago
    It works for GUI apps, see eg. https://hub.docker.com/r/tomparys/skype/ https://hub.docker.com/r/tomparys/skype/
    - satai 10y ago
      X11 only, no Wayland :-/

jcoffland 10y ago

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.

matthewbauer 10y ago
What makes things a little easier is they can be installed along with your standard package manager.
flukus 10y ago
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 10y ago
  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 10y ago
    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.
Lintaris 10y ago
I think it is the hard work of the maintainers to ensure quality that makes .deb stand out.

chris_wot 10y ago

Can snaps be updated automatically?

mectors 10y ago
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.

lowry 10y ago

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

k_sze 10y ago

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?