What kind of image format does snap use? Is packaging complicated? I've noted that flatpak is a nightmare to package for.
I created subuser <subuser.org> which runs on top of Docker, and of course, packaging is as simple as it is with Docker... The big problem is that when you want to update something, it is hard to do so without making everyone have to download a huge image all over again. Of course, you can try to prevent this with layers, but usually updates don't just touch the top layer :( ... So what I really want in the future is to be able to use IPFS or some kind of bittorrent-like download interface for images, so that when you update an image, you only have to download the parts that changed. There is a GREAT demo by a guy named Mathias Buus on this very topic here https://www.youtube.com/watch?v=2Sc6_XgNXyk which really gives you a feel for the awsome that would be deduplicated content addressed Docker.
Flatpak has something sorta similar, they use OSTree under the hood. https://github.com/ostreedev/ostree which is basically git annex for people who like incompatible redhat/freedesktop specific implementations of generic algorithms. It also does dedup, but at the file level not the block level, and so flatpak should be better at handling updates than subuser/Docker. Then again, who wants to repackage everything with their weird "standard" overcomplicated image format when you can just use Docker and throw anything you like into the image, however you like to throw it....
We use ansible to generate small inremental updates of docker images. The ansible takes any base image and put it into desired state. We feed it a milestone image to generate a small layer over it.
Thanks for the link. I'm not going to provide an opinion in a HN/while-on-the-front-page timescale, because I'd like to actually study the system that you use and come to an educated conclusion.
Your meaning of everywhere is by having 3rd party non official repos that ship small copy of ubuntu core.
Remind me why do steam do have to ship ubuntu's version of heavily patched libraries instead of using system upstrean version shipped by archlinux for example?
If snap is not a vendor lockin trap what is the vendor lockin trap?
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.
Your example runs 'openstack' in a container. The snap runs 'openstack' without a container. The question really is what does the container do for you to justify adding it to the stack?
