TL;DR: check out Nix (<a href="https://nixos.org/nix/" rel="nofollow">https://nixos.org/nix/</a>)<p>To anyone interested in addressing dependency hell with as small a footprint as possible, I encourage you to check out Nix and NixOS. Flatpak, Docker, and Ubuntu Snappy all take a slightly different bite out of the problem but still rely on imperative provisioning of a stateful system, and this comes with costs in system size, system indeterminancy, or both. The Bundles and Runtimes in Flatpak are treated the same in Nix: a package's dependencies are specified in a configuration file, and these files are composable so that shared dependencies are not replicated (as they are in the container model) and the dependency footprint is minimized. A package exists in a directory identified by a cryptographic hash of its build input, so if the input (the package) ever changes then this change will be transparent to other packages, avoiding name conflicts and allowing multiple versions of an application to exist without breaking other applications that depend on them. This means sandboxing comes for free without any of the overhead of a container. The Nix package repo is pretty impressive given how small the mindshare is compared to dpkg, RPM, etc. I am frequently surprised at how many small and lesser used applications have been packaged.
As someone that maintains a huge selection of packages, and an automated installer, for a very complex and interdependent set of OS vendor and third party packages, I think this is amazingly cool.<p>This solves nearly all of the problems with container-based distributions of software (like Docker), while providing all of the benefits. It doesn't give up the capabilities of traditional package managers (which are very good for their purpose and in the right place), nor does it impose downloading huge image files for every new thing you install (no matter how small they make the container OS, it's still bigger than being able to share a few and having filesystem level de-dup and snapshot capabilities).<p>I'm going to start working on a Flatpak version of our installation pretty much immediately (or, next week, once I get some other stuff rolled out). It is potentially a huge long-term time-saver for me, and a nice improvement for our customers, too, in that it would make every deployment look identical.
Flatpack is the new name for xdg-app, which has been under development by Gnome/Fedora since 2014.<p><a href="https://lists.freedesktop.org/archives/xdg-app/2016-May/000204.html" rel="nofollow">https://lists.freedesktop.org/archives/xdg-app/2016-May/0002...</a>
The problem with all of these app bundle systems is that you end up with 500 MB - 2 GB binaries for every app. Because dependencies in OSS are generally quite coarsed grained, you end up pulling in almost the entire user space of an operating system into your app.<p>Disk space, memory space (process size and lack of page sharing), and the size of app updates are all an issue (you don't want gigabytes of app updates every night).<p>Moreover, there is no standard format for dependencies -- that is completely distro dependent, or you have to grovel through the README of every project and hand-tune it (boiling the ocean).<p>Does Flatpak address this problem at all?<p>A couple years ago I was trying to write a system that addressed this. You basically use content addressed storage and chroots in the fashion of Plan 9 namespaces. And you can also use differential compression for slim network updates.<p>But I ran into the problem of boiling the ocean... I wrote like 2000-4000 lines of shell scripts just to build one kind of app (involving R, which involves Fortran...). I had to duplicate all the work of groveling through the dependencies, which is more difficult than you'd think for any non-trivial application. Debian dependency metadata is full of surprised like virtual packages and all that. The algorithm is to enumerate them is not straightforward and generates huge app bundles. Also many projects have non-trivial build time config options and downstream patches.<p>Is anyone else working on an app bundle system that solves the problems of disk space, memory size, and update size, as well as versioned dependency specification and resolution?<p>To me Docker seems to punt most of the problem on to the user, and then everybody ends up with OS-sized applications because they can't be bothered to trim dependencies. This isn't good for many reasons, but it's particularly bad for security. Then you have to pile hacks upon hacks and try to scan containers for vulnerabilities that you shouldn't have put there in the first place.<p>EDIT: I haven't looked in more detail, but it seems like Flatpak creates an artifical separation between "runtimes" and "bundles". Maybe that is a little hack that will work in practice -- my suspicion is that this will simply recapitulate the dependency versioning problem at a more coarse grained level. The natural tendency is for the runtimes to become bloated and thus require frequent updates.
These are all admirable goals and line up very well with my priorities, but I'm not sure why one wouldn't simply use static linkage for everything. The notion of a single, versioned "runtime" for each app is a good one; perhaps narrowing the scope of dynamic linkage down to that makes the concept useful again.<p>"Flatpak" is certainly a better name than "xdg-app".
This seems like it's just part of the general trend of abandoning dynamic libraries (or bundling them with each app, which is almost the same thing).
I believe when time allows I'll hack xombrero to allow size limits for mime-types. E.g. it'll disallow loading a image/* bigger than half-a-meg.