Hacker News Reader

Comment by smacktoward | Hacker News Reader

What's the benefit to me as a user to installing it via snap, instead of via the traditional methods of apt-get/the Ubuntu software app?

View on HN

Generally the snap will be much more up to date.

Installing from the Ubuntu Archive with apt-get means you get the version that was released with that version of the OS, say Ubuntu 16.10, sometimes with minor updates. With Snaps you get the version that the software developer pushes to you which could be their latest stable software released just yesterday (there is a concept of Snap channels that open up things like beta/candidate/daily builds e.t.c. but that is another topic).

Snaps can also update themselves, allow dependency bundling, are confined in sandboxes e.t.c. but for a user, it means you get very fresh software on your device. You can read more about them at https://snapcraft.io/

That does sound pretty compelling!

Are there risks/potential issues with having snap-based apps and apt-based apts coexist on the same installation of Ubuntu? I know there's now "Ubuntu Core" which replaces apt with snap for everything, but if you're just using plain old Ubuntu on a workstation or server, how safe is it to dip a toe in with a few snaps while leaving everything else managed with apt?

(Apologies if these are dumb questions, I just haven't been able to find much messaging on snaps that speaks to end-user concerns instead of developer ones...)

No problem at all, snaps will happily co-exist alongside debs or any other package format for that matter :-)

Exactly, you can even have the same application as a snap and a deb. PATH resolution will call the first one defined in your environment but that can be obviously be changed and when you are happy with the snap-only offering you can remove the deb if necessary (or visa-versa).

This is a solved problem with ppa's.

Decide for yourself, here are links to the LibreOffice snapcraft.yaml and the Debian packaging. Snaps are far, far simpler.

## Snapcraft

https://git.launchpad.net/~bjoern-michaelsen/df-libreoffice/...

## Debian

https://anonscm.debian.org/git/pkg-openoffice/libreoffice.gi...

Not if the ppa depends on a system library not available on your release. Then you need to go hunting for more ppas, until you eventually need to up/downgrade your entire system.

Yes, you're right, the originator of the package actually has to release PPAs that work on your release.

That's a perfectly manageable issue.

But don't claim snap's are the only solution to the problem of getting up-to-date software. That's not at all true. We've been solving this problem for far longer than Ubuntu has been around, and their approach is hardly a panacea. For example, it can and will result in additional memory and on-disk bloat as a consequence of duplicated dependencies across packages until de-duplication is implemented.

You only get a single duplicate of the library no matter how many things depend on it. That is the whole point of snaps over just statically linking.

Well, that and the sandbox features, so that they can't interfere with the rest of the system.

You only get a single duplicate of the library no matter how many things depend on it.

Huh?

If a snap includes version 1.0.0 of libxyz, and another does the same, you have two copies. If a third snap comes along and uses version 1.0.0 libxyz, you now have three.

Snaps do not automatically de-duplicate today.

That means two copies of the library living on disk and in memory at run-time.

That would be the same with any platform that does not use some kind of explicit linking/sharing of resources. Snaps have a sharing mechanism called interfaces but yes, the software author has to declare they want to use it, no magic there.

Snaps have a sharing mechanism called interfaces but yes, the software author has to declare they want to use it, no magic there.

So, they've reinvented dependencies (though, to their credit, they gave them a different name), one of the very things snaps were intended to alleviate?

Look, don't get me wrong, snaps have some interesting advantages (sandboxing being the one major selling point, IMO). But, again, they're no panacea.

Snaps are apps in a container. Why bother with docker containers to run services while you can install everything together on a single computer? Each docker replicates the same rooted again and again.

Just like docker, snaps make sense even if there is some duplication of the libraries. Other benefits outweigh the extra size.

The advantage is that there are no dependency collisions. With apt/yum I can't have multiple versions of the same library installed at the same time. Snaps fix this.

Snap has a feature called content sharing which enables a snap to connect to assets (which can be data, shared objects, anything) in another snap.

That's only true if they share a run-time/platform snap. AKA, they each have a dependency on a shared snap.

If only there was some existing solution for packaging and deploying software where you could declare dependencies between shared resources...

It's not solved when any PPA I add can replace any system package simply by using a higher version number.

PPAs were good for some things, but they require you to package the software as a deb, which is a lot more work than to make a snap. And during the installation of a deb coming from a PPA, the user is at risk because it is being installed with root permissions. snaps are much more secure, during installation they are just unpacked into their confined space.

Heck, I will be happy if snaps just eliminate having to go back and re-enable all my PPAs by hand after doing a dist-upgrade...

Rejoice. The same snap will work in trusty, xenial, yakkety and zesty. You don't have to do anything, and the developer doesn't have to do anything either.

Darn, saying it like that, you're going to make me blush :-D

Reply on news.ycombinator.com