3 ms·

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

by chubot 11y 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 11y 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.
- chubot 11y ago
  Yeah, I just noticed that and edited my comment. To me, that just makes the dependencies more coarse-grained -- now you have this artifical 2-level system of apps and runtimes. You've just recreated the same problem again with bigger blobs. So I can't see right now how it's going to work. I feel like it will flame out. But this kind of thing involves a lot of social problems in addition to technical problems, so you never know. EDIT: A more concrete example. Apache, nginx, Python, Ruby, Perl, node.js, Erlang web servers, etc. all depend on OpenSSL. OpenSSL is 500K lines of code. When an important update inevitably comes out for it, what happens? Are you now updating 10+ runtimes that are 1+ GB each? Do they use differential compression at all? I don't see how the two-level hierarchy really solves any problems. It could be the worst of both worlds (very fine-grained sharing vs. duplicating all dependencies)
  - SwellJoe 11y ago
    "OpenSSL is 500K lines of code. When an important update inevitably comes out for it, what happens? Are you now updating 10+ runtimes that are 1+ GB each? Do they use differential compression at all?" Yes. The images are being updated via snapshot (transparent to the user). Just as RPMs can currently be updated with delta RPMs. The Poettering blog post about it that someone linked in another thread is really helpful: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu... It's not an amateur attempt at the problem. It may not be perfect (it probably is far from it for the next several years), but it does seem to have addressed the biggest issues in a reasonable way. We definitely need a way forward beyond the current generation of package managers; Nix has a really cool solution (and I would be happy with Nix getting more traction), and Guix does, too. Docker, on the other hand, which is the currently fashionable option for solving these problems, leaves a lot to be desired, and does fall prey to some of the concerns you raise.
- spraak 11y ago
  Thanks for sharing your understanding - it helped me grasp it too
alkonaut 11y ago
Isn't .5-2GB apps without any shared dependencies (outside a core system) pretty much how it has always worked on iOS, Android and Windows? That model seems pretty successful?
- chubot 11y ago
  Good question... Windows doesn't have this model, because it has "DLL hell". Windows was a ad hoc solution partway between "fine-grained curated shared dependencies" (Debian) and "duplicate all your dependencies" (App Bundles/Docker). The solution was up to each individual app author -- you could choose to bundle DLLs, but mostly you didn't bundle "system" DLLs, if you judged them to be low level enough, widely deployed enough, etc. Installers on windows also listed MANUAL prerequisites that users had to install, so they are punting on a big part of the problem (give me a the name of a thing to install and make it magically work; don't make me manually resolve dependencies.) There was no real consistent model on Windows, and if you were completely consistent with sharing everything, you would have an even more fragile mess than Windows apps were already. iOS and Android are successful app bundle ecosystems, and something that these Linux app bundle are explicitly trying to emulate. The apps end up around 50 MB or so, not 500 MB to 2 GB. The reason for that is basically that the apps are less rich and featureful (think Photoshop or OpenOffice or a browser), and that they ship lots of high level libraries with the OS. Stuff like video codecs are part of the OS/hardware in iOS/Android, whereas in Debian and Windows they are applications. Stuff like browser UI views are part of the OS as well. Android is an entire OS, with apps, built from a single Makefile! So there is less versioning skew and fragmentation than in Debian/Windows (believe it or not). iOS has some issues with app compatibility across OS versions that Windows definitely doesn't. Anyway, iOS and Android are definitely the models to emulate in terms of usability and stability. But I don't think they have completely solved the problems because the ecosystems aren't as rich as Debian or Windows yet.
  - alkonaut 11y ago
    I think the Windows story is becoming more robust by using mostly isolated apps. Very little is shared these days and dll-hell isn't really and issue any more. The only shared libraries are things like C++ run times, directX etc which are basically optional OS components since they are also made by Microsoft. Even those are moving towards "isolated deploy" modes where you should ship a .NET runtime as a deployed dependency instead of using a shared prerequisite. This is much more robust but also wasteful and harder to patch of course. > The apps end up around 50 MB or so, not 500 MB to 2 GB. They try to accomplish much less and of course have fewer enormous apps dragging the average up (try the latest doom at 50GB!). The average app sizes should be counted relative to the average device space. A desktop system has 200-2000GB and a mobile device 16-128GB so around one order of magnitude is a reasonable difference.

by chubot 11y ago

SwellJoe 11y 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.

chubot 11y ago
Yeah, I just noticed that and edited my comment. To me, that just makes the dependencies more coarse-grained -- now you have this artifical 2-level system of apps and runtimes. You've just recreated the same problem again with bigger blobs. So I can't see right now how it's going to work. I feel like it will flame out. But this kind of thing involves a lot of social problems in addition to technical problems, so you never know. EDIT: A more concrete example. Apache, nginx, Python, Ruby, Perl, node.js, Erlang web servers, etc. all depend on OpenSSL. OpenSSL is 500K lines of code. When an important update inevitably comes out for it, what happens? Are you now updating 10+ runtimes that are 1+ GB each? Do they use differential compression at all? I don't see how the two-level hierarchy really solves any problems. It could be the worst of both worlds (very fine-grained sharing vs. duplicating all dependencies)
- SwellJoe 11y ago
  "OpenSSL is 500K lines of code. When an important update inevitably comes out for it, what happens? Are you now updating 10+ runtimes that are 1+ GB each? Do they use differential compression at all?" Yes. The images are being updated via snapshot (transparent to the user). Just as RPMs can currently be updated with delta RPMs. The Poettering blog post about it that someone linked in another thread is really helpful: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu... It's not an amateur attempt at the problem. It may not be perfect (it probably is far from it for the next several years), but it does seem to have addressed the biggest issues in a reasonable way. We definitely need a way forward beyond the current generation of package managers; Nix has a really cool solution (and I would be happy with Nix getting more traction), and Guix does, too. Docker, on the other hand, which is the currently fashionable option for solving these problems, leaves a lot to be desired, and does fall prey to some of the concerns you raise.
spraak 11y ago
Thanks for sharing your understanding - it helped me grasp it too

alkonaut 11y ago

Isn't .5-2GB apps without any shared dependencies (outside a core system) pretty much how it has always worked on iOS, Android and Windows? That model seems pretty successful?

chubot 11y ago
Good question... Windows doesn't have this model, because it has "DLL hell". Windows was a ad hoc solution partway between "fine-grained curated shared dependencies" (Debian) and "duplicate all your dependencies" (App Bundles/Docker). The solution was up to each individual app author -- you could choose to bundle DLLs, but mostly you didn't bundle "system" DLLs, if you judged them to be low level enough, widely deployed enough, etc. Installers on windows also listed MANUAL prerequisites that users had to install, so they are punting on a big part of the problem (give me a the name of a thing to install and make it magically work; don't make me manually resolve dependencies.) There was no real consistent model on Windows, and if you were completely consistent with sharing everything, you would have an even more fragile mess than Windows apps were already. iOS and Android are successful app bundle ecosystems, and something that these Linux app bundle are explicitly trying to emulate. The apps end up around 50 MB or so, not 500 MB to 2 GB. The reason for that is basically that the apps are less rich and featureful (think Photoshop or OpenOffice or a browser), and that they ship lots of high level libraries with the OS. Stuff like video codecs are part of the OS/hardware in iOS/Android, whereas in Debian and Windows they are applications. Stuff like browser UI views are part of the OS as well. Android is an entire OS, with apps, built from a single Makefile! So there is less versioning skew and fragmentation than in Debian/Windows (believe it or not). iOS has some issues with app compatibility across OS versions that Windows definitely doesn't. Anyway, iOS and Android are definitely the models to emulate in terms of usability and stability. But I don't think they have completely solved the problems because the ecosystems aren't as rich as Debian or Windows yet.
- alkonaut 11y ago
  I think the Windows story is becoming more robust by using mostly isolated apps. Very little is shared these days and dll-hell isn't really and issue any more. The only shared libraries are things like C++ run times, directX etc which are basically optional OS components since they are also made by Microsoft. Even those are moving towards "isolated deploy" modes where you should ship a .NET runtime as a deployed dependency instead of using a shared prerequisite. This is much more robust but also wasteful and harder to patch of course. > The apps end up around 50 MB or so, not 500 MB to 2 GB. They try to accomplish much less and of course have fewer enormous apps dragging the average up (try the latest doom at 50GB!). The average app sizes should be counted relative to the average device space. A desktop system has 200-2000GB and a mobile device 16-128GB so around one order of magnitude is a reasonable difference.