7 ms·

Flatpak: Standalone apps for Linux

75 points by hernantz 10y ago

digi_owl 10y ago
Thanks but no thanks.
cyberpunk 10y ago
Maybe I'm missing something but didn't we solve this problem already?
- hernantz 10y ago
  You can refer to this post by Lennart Poettering to get more insight of the goal of this project: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu...
  - yarrel 10y ago
    More systemd bloat. I guess Windows adding an app store made cargo cutting that approach irresistible.
  - cyberpunk 10y ago
    Urgh. It's a lecture from a desktop Linux Dev on what I'm supposed to want. As someone who runs stuff at stupid (not fb or google, but not tiny) scale, this just annoys me. He's right, in some ways.. But.. How many more layers do we need? Who will sign up for this? No one. I'm getting close to the point where I just can't take it anymore. I keep deleting mesos and kubernetes setups and replacing them with 200 line shell scripts at startups with no ops team who are sold lies... Maybe I'll become a pig farmer or something. Open a pub. There's a backlash coming, and we deserve it.
    - cyberpunk 10y ago
      I'd really be less offended by this whole thing if every example wasn't about running gnome. This is the guy driving the userland for most of us? Doesn't he realise that no one gives a shit about Linux desktop apps? Sure there are some, we should be more focuses on the needs of people who are deploying 1000s of jvms or node apps or ruby or whatever though... Shouldn't we?
      - jsnell 10y ago
        There are already plenty of people focused on those needs. In fact your previous comment seemed to be complaining about there being too many solutions already. Why are you so offended that some people are trying to solve a real problem they have, instead of piling into the server use case that's already very crowded?
      - tdkl 10y ago
        > Doesn't he realise that no one gives a shit about Linux desktop apps? That explains the sad state of Linux on the desktop.
  - dTal 10y ago
    I was with him 100% right until "as part of the systemd project". This isn't even about politics anymore, what the hell does application distribution have to do with init daemons? Is systemd just a dumping ground for whatever idea they currently think is great? One gets the impression that if Poettering wrote Pulseaudio today, he'd roll it into systemd...
- digi_owl 10y ago
  One million times over...
sciurus 10y ago
Flatpack is the new name for xdg-app, which has been under development by Gnome/Fedora since 2014. https://lists.freedesktop.org/archives/xdg-app/2016-May/000204.html https://lists.freedesktop.org/archives/xdg-app/2016-May/0002...
- SwellJoe 10y ago
  Flatpak is a much better name. Also, better name than dnf or apt-get or rpm or dpkg, too. (But, not a better name than yum, which I'm still bitter about the Fedora/RH folks changing.)
  - digi_owl 10y ago
    Dunno, to me it brings to mind the meme of complicated to follow IKEA assembly instructions.
marssaxman 10y ago
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. "Flatpak" is certainly a better name than "xdg-app".
- pjmlp 10y ago
  Because an application is also composed of resources and each distribution has its own directory tree, configuration scripts, init system,....
  - Spivak 10y ago
    Yes, which is why self-contained statically-linked packages should be placed in a directory away from the system libraries in their own directory/namespace. We could call it "Program Files" or "Program Files (x86_64)".
    - marssaxman 10y ago
      Or, more simply, we could put each package in its own directory. Such application package directories could perhaps be marked with a distinctive type-extension, for example ".app".
- parenthephobia 10y ago
  One good effect of dynamic linking is that you don't have to recompile all your binaries when it turns out a widely-used library has a gaping security hole. Dynamic linking is also more storage efficient. If the contents of my /bin were statically linked, it'd take up 76GB. With dynamic linking, the binaries and their libraries take up 4GB. This also matters at run-time, if I'm not writing single-binary apps: a Unix pipeline of 8 50MB binaries, say, is taking up 400MB of cache just for the code. On a 1GB server, that's a big deal.
  - 10y ago
forgotmypassw 10y ago
So how does that differ from either static linking or dynamic linking and providing the .so files combined with LD_PRELOAD startup script?
- suprjami 10y ago
  This has a trendier name and a website
- digi_owl 10y ago
  Never mind actually using soname... https://en.wikipedia.org/wiki/Soname https://en.wikipedia.org/wiki/Soname Frankly this is not actually about libs, but about package manager dependencies. DEBs and RPMs are overly rigid by design. Because of how they track packages, you can't have two versions of the same package name installed at the same time. If you want to have two versions of a lib installed, you have to rename one of them to avoid a name collision. Even though the files inside the packages would never overlap.
SwellJoe 10y ago
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. 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). 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.
chubot 10y ago
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. 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). 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). Does Flatpak address this problem at all? 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. 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. 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? 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. 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.
- SwellJoe 10y ago
  "Does Flatpak address this problem at all?" Yes, it seems to. As I understand it, there's the concept of a runtime, which is kinda like an OS installation (but it's an immutable image type thing that gets distributed identically to everyone who wants that runtime), which packages can be built against, meaning the application package only needs to include its own specific dependencies that aren't part of the runtime. So, similar to how one might build for Fedora 24 now, one could build for a Fedora runtime, and any user who had that runtime wouldn't need that image to be downloaded...they would already have it. So, if you only installed packages provided by your OS vendor, the size of things wouldn't change much. Where things begin to look different is that any Flatpak can be installed on any system that has Flatpak. So, don't have a runtime that an app you want is built against? No problem, this'll grab it and set it up, transparent to the user. And, next time you want another package built against that runtime, it won't need to add it. This is like being able to install anything from Debian repos on CentOS, or vice versa; it's also like being able to install from Debian stable, unstable, and testing all willy-nilly without fear of it breaking other packages. At least, that's how I understand it...but, that'll be many years coming. This is such a fundamental shift in how we think about packages that it's unlikely to catch on quickly. But, I'm a package manager nerd, and I can't believe I didn't realize this was underway; I would have started following it earlier. I love this idea.
secstate 10y ago
And so the poettering of Linux continues unabated. You know, Windows once had a really solid way to install apps across Windows version too ...
- elktea 10y ago
  a byzantine horror of per-application hacks?
- SwellJoe 10y ago
  Package management on Windows has historically been awful (and remains awful, in the general case), and bears no resemblance to this project.
davidgerard 10y ago
The way to get actual standalones is to run a Windows binary under Wine.
api 10y ago
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).
- SwellJoe 10y ago
  I don't think that's the case here. Many of your dynamic libraries will exist in the runtime (which is a mini-OS image). And, as dependencies shift, snapshots of that runtime will allow packages to keep talking to the dynamic libs they need, while others that may upgrade to require newer deps will get a new OS image. Snapshots allow them to be small (a fedora-24 and a fedora-24.1 image might only need 1.1 times the space of fedora-24 alone, and adding fedora-24.2 might only need another 5% of space). I think folks are thinking this is like Docker. It isn't. It has surface level similarities, but it seems to be trying to solve the kinda of problems that Docker does not attempt to solve, and attempts to keep many of the good ideas from past package managers that Docker (and the like) have thrown away.
  - digi_owl 10y ago
    And the problem has been solved multiple times over. https://en.wikipedia.org/wiki/Soname https://en.wikipedia.org/wiki/Soname This is just another case of having a hammer (cgroups, containers) and seeing every problem as nails. The problem is not at the kernel or OS level, it is that package manager have historically been overly rigid with regards to dependencies. And it will not surprise me at all if app devs start stuffing their "flatpaks" with all manner of libs because runtimes are not changing fast enough, or to ensure their special snowflakes get just the right environment.
    - the_why_of_y 10y ago
      Let's assume that a developer wants to distribute a binary build of their application that uses the OpenSSL library that runs on every GNU/Linux system released in the last 5 years. As you might know, OpenSSL releases a new ABI-incompatible version of their library every other year or so, and so there are at least 3 different OpenSSL ABIs / SONAMEs available in the distributions the binary build should run on. So far the only choices available (edit: for desktop applications) are either static linking OpenSSL, or abandon the idea of distro independent binaries. With FlatPak, OpenSSL can be bundled in the runtime, so multiple applications can depend on the same runtime and share one dynamic library, and benefit from the runtime getting security updates for the monthly OpenSSL CVEs instead of doing that themselves.
ramblenode 10y ago
TL;DR: check out Nix (https://nixos.org/nix/ https://nixos.org/nix/) 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.
- gkya 10y ago
  There's also the GuixSD: http://www.gnu.org/software/guix/ http://www.gnu.org/software/guix/. Same thing with a touch of Lisp.
  - zzzcpan 10y ago
    Is guix as rough on the edges as nix? I have nixos installed in qemu, but so far don't find the experience to be pleasant. The ideas are great though, definitely the direction to move for all package managers.
    - gkya 10y ago
      I've no experience with Nix, but I tried guix package manager and it was fine. I didn't hit any edge cases, but I didn't dive deep. I tried installing GuixSD (the OS) too, but failed, and because I was in a hurry, couldn't investigate much. But I did hit a critical issue: scarse docs. It's nowhere near FreeBSD where docs indeed help you out without a google search.
gkya 10y ago
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.
andmarios 10y ago
10+ years ago... https://en.wikipedia.org/wiki/Klik_(packaging_method) https://en.wikipedia.org/wiki/Klik_(packaging_method)
- the_why_of_y 10y ago
  There were numerous previous attempts to do something like this, including Klik, its successor Klik2, AutoPackage, 0install, Glick, and its successor Glick2 (the latter two by the lead developer of FlatPak). http://klik.atekon.de/wiki/index.php/Klik2 http://klik.atekon.de/wiki/index.php/Klik2 http://autopackage.org/ http://autopackage.org/ http://0install.net/ http://0install.net/ https://people.gnome.org/~alexl/glick/ https://people.gnome.org/~alexl/glick/ https://people.gnome.org/~alexl/glick2/ https://people.gnome.org/~alexl/glick2/ However these all remained pretty obscure. AFAIK all of them only tried to solve the problem of how to install stuff on the end user's system, but ignored the problem of how developers can build binaries that actually run on multiple version of multiple distributions, which XdgApp/FlatPak solves with its "runtimes" and corresponding SDKs.
  - knocte 10y ago
    You seem like the perfect lad to answer my question: http://stackoverflow.com/questions/37426833/sandboxing-technologies-in-linux-snappy-vs-flatpak-comparison http://stackoverflow.com/questions/37426833/sandboxing-techn... :P

75 points by hernantz 10y ago

digi_owl 10y ago

Thanks but no thanks.

cyberpunk 10y ago

Maybe I'm missing something but didn't we solve this problem already?

hernantz 10y ago
You can refer to this post by Lennart Poettering to get more insight of the goal of this project: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu...
- yarrel 10y ago
  More systemd bloat. I guess Windows adding an app store made cargo cutting that approach irresistible.
- cyberpunk 10y ago
  Urgh. It's a lecture from a desktop Linux Dev on what I'm supposed to want. As someone who runs stuff at stupid (not fb or google, but not tiny) scale, this just annoys me. He's right, in some ways.. But.. How many more layers do we need? Who will sign up for this? No one. I'm getting close to the point where I just can't take it anymore. I keep deleting mesos and kubernetes setups and replacing them with 200 line shell scripts at startups with no ops team who are sold lies... Maybe I'll become a pig farmer or something. Open a pub. There's a backlash coming, and we deserve it.
  - cyberpunk 10y ago
    I'd really be less offended by this whole thing if every example wasn't about running gnome. This is the guy driving the userland for most of us? Doesn't he realise that no one gives a shit about Linux desktop apps? Sure there are some, we should be more focuses on the needs of people who are deploying 1000s of jvms or node apps or ruby or whatever though... Shouldn't we?
    - jsnell 10y ago
      There are already plenty of people focused on those needs. In fact your previous comment seemed to be complaining about there being too many solutions already. Why are you so offended that some people are trying to solve a real problem they have, instead of piling into the server use case that's already very crowded?
    - tdkl 10y ago
      > Doesn't he realise that no one gives a shit about Linux desktop apps? That explains the sad state of Linux on the desktop.
- dTal 10y ago
  I was with him 100% right until "as part of the systemd project". This isn't even about politics anymore, what the hell does application distribution have to do with init daemons? Is systemd just a dumping ground for whatever idea they currently think is great? One gets the impression that if Poettering wrote Pulseaudio today, he'd roll it into systemd...
digi_owl 10y ago
One million times over...

sciurus 10y ago

Flatpack is the new name for xdg-app, which has been under development by Gnome/Fedora since 2014. https://lists.freedesktop.org/archives/xdg-app/2016-May/000204.html https://lists.freedesktop.org/archives/xdg-app/2016-May/0002...

SwellJoe 10y ago
Flatpak is a much better name. Also, better name than dnf or apt-get or rpm or dpkg, too. (But, not a better name than yum, which I'm still bitter about the Fedora/RH folks changing.)
- digi_owl 10y ago
  Dunno, to me it brings to mind the meme of complicated to follow IKEA assembly instructions.

marssaxman 10y ago

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. "Flatpak" is certainly a better name than "xdg-app".

pjmlp 10y ago
Because an application is also composed of resources and each distribution has its own directory tree, configuration scripts, init system,....
- Spivak 10y ago
  Yes, which is why self-contained statically-linked packages should be placed in a directory away from the system libraries in their own directory/namespace. We could call it "Program Files" or "Program Files (x86_64)".
  - marssaxman 10y ago
    Or, more simply, we could put each package in its own directory. Such application package directories could perhaps be marked with a distinctive type-extension, for example ".app".
parenthephobia 10y ago
One good effect of dynamic linking is that you don't have to recompile all your binaries when it turns out a widely-used library has a gaping security hole. Dynamic linking is also more storage efficient. If the contents of my /bin were statically linked, it'd take up 76GB. With dynamic linking, the binaries and their libraries take up 4GB. This also matters at run-time, if I'm not writing single-binary apps: a Unix pipeline of 8 50MB binaries, say, is taking up 400MB of cache just for the code. On a 1GB server, that's a big deal.
- 10y ago

forgotmypassw 10y ago

So how does that differ from either static linking or dynamic linking and providing the .so files combined with LD_PRELOAD startup script?

suprjami 10y ago
This has a trendier name and a website
digi_owl 10y ago
Never mind actually using soname... https://en.wikipedia.org/wiki/Soname https://en.wikipedia.org/wiki/Soname Frankly this is not actually about libs, but about package manager dependencies. DEBs and RPMs are overly rigid by design. Because of how they track packages, you can't have two versions of the same package name installed at the same time. If you want to have two versions of a lib installed, you have to rename one of them to avoid a name collision. Even though the files inside the packages would never overlap.

SwellJoe 10y ago

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. 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). 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.

chubot 10y ago

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. 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). 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). Does Flatpak address this problem at all? 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. 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. 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? 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. 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.

SwellJoe 10y ago
"Does Flatpak address this problem at all?" Yes, it seems to. As I understand it, there's the concept of a runtime, which is kinda like an OS installation (but it's an immutable image type thing that gets distributed identically to everyone who wants that runtime), which packages can be built against, meaning the application package only needs to include its own specific dependencies that aren't part of the runtime. So, similar to how one might build for Fedora 24 now, one could build for a Fedora runtime, and any user who had that runtime wouldn't need that image to be downloaded...they would already have it. So, if you only installed packages provided by your OS vendor, the size of things wouldn't change much. Where things begin to look different is that any Flatpak can be installed on any system that has Flatpak. So, don't have a runtime that an app you want is built against? No problem, this'll grab it and set it up, transparent to the user. And, next time you want another package built against that runtime, it won't need to add it. This is like being able to install anything from Debian repos on CentOS, or vice versa; it's also like being able to install from Debian stable, unstable, and testing all willy-nilly without fear of it breaking other packages. At least, that's how I understand it...but, that'll be many years coming. This is such a fundamental shift in how we think about packages that it's unlikely to catch on quickly. But, I'm a package manager nerd, and I can't believe I didn't realize this was underway; I would have started following it earlier. I love this idea.

secstate 10y ago

And so the poettering of Linux continues unabated. You know, Windows once had a really solid way to install apps across Windows version too ...

elktea 10y ago
a byzantine horror of per-application hacks?
SwellJoe 10y ago
Package management on Windows has historically been awful (and remains awful, in the general case), and bears no resemblance to this project.

davidgerard 10y ago

The way to get actual standalones is to run a Windows binary under Wine.

api 10y ago

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).

SwellJoe 10y ago
I don't think that's the case here. Many of your dynamic libraries will exist in the runtime (which is a mini-OS image). And, as dependencies shift, snapshots of that runtime will allow packages to keep talking to the dynamic libs they need, while others that may upgrade to require newer deps will get a new OS image. Snapshots allow them to be small (a fedora-24 and a fedora-24.1 image might only need 1.1 times the space of fedora-24 alone, and adding fedora-24.2 might only need another 5% of space). I think folks are thinking this is like Docker. It isn't. It has surface level similarities, but it seems to be trying to solve the kinda of problems that Docker does not attempt to solve, and attempts to keep many of the good ideas from past package managers that Docker (and the like) have thrown away.
- digi_owl 10y ago
  And the problem has been solved multiple times over. https://en.wikipedia.org/wiki/Soname https://en.wikipedia.org/wiki/Soname This is just another case of having a hammer (cgroups, containers) and seeing every problem as nails. The problem is not at the kernel or OS level, it is that package manager have historically been overly rigid with regards to dependencies. And it will not surprise me at all if app devs start stuffing their "flatpaks" with all manner of libs because runtimes are not changing fast enough, or to ensure their special snowflakes get just the right environment.
  - the_why_of_y 10y ago
    Let's assume that a developer wants to distribute a binary build of their application that uses the OpenSSL library that runs on every GNU/Linux system released in the last 5 years. As you might know, OpenSSL releases a new ABI-incompatible version of their library every other year or so, and so there are at least 3 different OpenSSL ABIs / SONAMEs available in the distributions the binary build should run on. So far the only choices available (edit: for desktop applications) are either static linking OpenSSL, or abandon the idea of distro independent binaries. With FlatPak, OpenSSL can be bundled in the runtime, so multiple applications can depend on the same runtime and share one dynamic library, and benefit from the runtime getting security updates for the monthly OpenSSL CVEs instead of doing that themselves.

ramblenode 10y ago

TL;DR: check out Nix (https://nixos.org/nix/ https://nixos.org/nix/) 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.

gkya 10y ago
There's also the GuixSD: http://www.gnu.org/software/guix/ http://www.gnu.org/software/guix/. Same thing with a touch of Lisp.
- zzzcpan 10y ago
  Is guix as rough on the edges as nix? I have nixos installed in qemu, but so far don't find the experience to be pleasant. The ideas are great though, definitely the direction to move for all package managers.
  - gkya 10y ago
    I've no experience with Nix, but I tried guix package manager and it was fine. I didn't hit any edge cases, but I didn't dive deep. I tried installing GuixSD (the OS) too, but failed, and because I was in a hurry, couldn't investigate much. But I did hit a critical issue: scarse docs. It's nowhere near FreeBSD where docs indeed help you out without a google search.

gkya 10y ago

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.

andmarios 10y ago

10+ years ago... https://en.wikipedia.org/wiki/Klik_(packaging_method) https://en.wikipedia.org/wiki/Klik_(packaging_method)

the_why_of_y 10y ago
There were numerous previous attempts to do something like this, including Klik, its successor Klik2, AutoPackage, 0install, Glick, and its successor Glick2 (the latter two by the lead developer of FlatPak). http://klik.atekon.de/wiki/index.php/Klik2 http://klik.atekon.de/wiki/index.php/Klik2 http://autopackage.org/ http://autopackage.org/ http://0install.net/ http://0install.net/ https://people.gnome.org/~alexl/glick/ https://people.gnome.org/~alexl/glick/ https://people.gnome.org/~alexl/glick2/ https://people.gnome.org/~alexl/glick2/ However these all remained pretty obscure. AFAIK all of them only tried to solve the problem of how to install stuff on the end user's system, but ignored the problem of how developers can build binaries that actually run on multiple version of multiple distributions, which XdgApp/FlatPak solves with its "runtimes" and corresponding SDKs.
- knocte 10y ago
  You seem like the perfect lad to answer my question: http://stackoverflow.com/questions/37426833/sandboxing-technologies-in-linux-snappy-vs-flatpak-comparison http://stackoverflow.com/questions/37426833/sandboxing-techn... :P