2 ms·

"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

"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

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