A docker image runs a full operating system. There are some light OSs for docker, but that's still heavier than a snap.
The snap runs directly on your host, with a different kind of isolation to make it secure. So it also makes easy other kinds of communication between apps, like unix sockets or dbus.
Then there's the great feature of autoupdates. If the openstack developers push a new version, it will reach all the users within 4 hours. On a docker container you can have the same problems you have in classic distros. You'll get an old version by default, and you have to apply hacks or accept other risks if you want to get a newer.
What would be awesome is to be able to run snaps inside docker containers. That will be a mix of both worlds, docker for replication and adding or removing new machines as the load changes; snaps for getting the software into those machines. We can currently do that with linux containers, maybe at some point docker will support them too.
And we have snaps for docker and lxd, make sure to give them a try:
To what extent is snap a new package manager and to what extent is it a security mechanism? Does it actually prevent the application from getting full access to the user's home directory?
It's a new package manager that implements existing linux security mechanisms. It will use apparmor to confine the snap to the directories that it is allowed to read and write. By default, $HOME/snap/snap-name/
Cool, though it seems to be "insecure by defualt". I presume that there will be some clear way to say "I don't trust this snap, dissable everything like gsettings, pulseaudio microphone support, ect. that I wouldn't want some random untrusted code to access..."
I didn't know that DBUS supported selectively allowing access to selected services. I thought that was a new feature in the non-accepted kdbus. That was certainly what the redhat folks wrote. They wrote that it isn't possible to secure dbus without kdbus...
I saw it in the docs, but my question was how did they do it when this is a missing feature in DBus... So Canonical added this feature to dbus but it hasn't made its way upstream or redhat chooses to ignore the new feature so that they have a reason to promote kdbus. OK.
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.
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.
