Consider the following: I need a reliable way to deploy my app to clients.
The popular options are: 1) Source code + Configuration system (automake for example) 2) Binaries built for popular platforms (debs, rpms, exes) 3) Docker Image
Source code means that the client needs the whole build tool chain, which might be quite + computationally expensive (especially on mobile)
packages have to be built and maintained, and don't fully solve the dependancy issues (IE I might expect Ubuntu 14.04 to have a specific version of libc, but the user might have upgraded it, and I can't install my own incompatible version)
and of course docker, ship my clients a operating system and require them to have and know how to configure the runtime so they can run my 1mb compiled binary. Also doesn't work on embedded devices.
Ideally, in the future most distributions will move to functional package managers, and at least for mobile will have binaries for every possible version of dependencies available, but at the moment that's just a pipe dream and things like snappy don't get us any closer to that
I feel that once a user circumvents the package system, it is unreasonable for that user to expect that the package system will continue to work correctly. In that case, the user has taken over some of the responsibilies of the package system, and software vendors should feel no obligation to ensure compatibility with such changes.
Also don't forget architecture... you want that binary in 32 bit i386, 64 bit amd64, or arm?
I need to think about that a bit more instead of solving the actual product problem at hand. :-/
[1] http://0install.net [2] https://wiki.gnome.org/Projects/SandboxedApps [3] https://nixos.org/nix/
If anything, we should be lauding Canonical for keeping to themselves in their corner instead of seeking greater validity across the ecosystem with half-baked ideas.
1) Build obtain node for your platform (and now you've hit the exact problem I'm talking about) 2) install npm (which I can't really define as a dep, you're just expected to have it) 3) install all the deps I've defined and hope they all work on the version / configuration of node you have (execjs only works on node 0.10 but you have v4? Too bad! You didn't apply the increased memory patch before building node? Too bad!)
The ideal here to reiterate is given nothing but your installed OS, I should be able to give you a file that will go from nothing to a running app, and from the running app to a clean system if you decide to remove it, without you having to have any prerequisites (no node, no chef, no docker, etc)
If you insist of using a specific library version, there is nothing stopping you from including it in your package , like snappy's.
Lastly, when you include libc a million times, or static compile your binaries, the size goes up and storage/bandwith also becomes an issue.
I agree that Snappy solves some problems, but introduces new serious ones as well.
Fortunately, the creators of Snappy thought of that and included an atomic/delta update system. So when you have 100 packages that need to be updated because of a common dependency you only need to download 100 binary diffs instead of 100 full-size snap packages.
Unfortunately packaging appears to be a paradox of sorts: Either your app lives in an environment of shared libraries where you have no control or your app lives inside a container of some sort that bundles copies of all those libraries. You can't have both.
That's not really a solution though, just a mitigation.
Updating a single package for security fixes or other changes instead of a 1,000 is still vastly more efficient and faster.
Unfortunately packaging appears to be a paradox of sorts: Either your app lives in an environment of shared libraries where you have no control or your app lives inside a container of some sort that bundles copies of all those libraries. You can't have both.
That's because the solution alone can't be through packaging; it requires changes at every level of the stack.
The system needs to provide robust backwards-compatibility and sane packaging.
Applications need to use interfaces responsibly, pick dependencies carefully, and use a sane build environment.
When developers attempt to solve everything with the blunt hammer of packaging, they end up with a lot of "bent nails".
And this is the back-and-forth problem that nobody has the answer for. Do we make this one app fail, because the maintainer for it isn't updating for library updates? or do we cause system-wide insecurity because we need that one app to work?
I'm in favor of the former, but I think both sides have good arguments.
An insecure app may have mitigations available that don't reduce its usefulness. A broken app is just broken and useless.
This is, of course, the core of linux containers. But I don't need to deploy a system image to run an Android application.
1. Physical appliances.
2. Virtual machine images.
3. Docker images.
4. Snappy packages (and similar)
At the top we have an actual physical piece of vendor-chosen hardware that "contains" a vendor-controlled application and execution environment. The end user has almost no control.
Then comes virtual machine images which "contain" a vendor-controlled application inside a vendor-chosen operating system.
Up next we have Docker images which "contain" a vendor-chosen execution environment and application but run inside the end user's chosen operating system (in a special sandbox).
Lastly we have Snappy packages which "contain" an application and it's build/run time dependencies but run just like a regular application with user-controlled restrictions (via AppArmor).
They seem to have some overlap and I've heard good things about NixOS, I like the theory behind it, but I find its Haskell-based configuration language hard to understand.
http://en.community.dell.com/techcenter/os-applications/f/46...
I'll still buy the things, because it's important to me to put my money where my mouth is, but it looks like it could use some significant investment to make it a better product.
