Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not sure if you misunderstand what Flatpak is or if you are really suggesting to ship a entire distribution for your users to install if they want to use the application you're delivering to them.


A typical system will end up with 10 versions of some .so library on disk. Sometimes more. Disk usage waste everywhere. You're better off having a package manager that can link multiple versions at the same time to the programs that need it instead of bundling.


But you're confusing what sides of the developer/user aisle you're on.

Yes, there are probably a better distribution for the user to use if they want to save disk space. But Flatpak is not a distribution, it's a delivery mechanism. Are you really gonna tell people "Hey, don't use $YOUR-CURRENT-DIST, use Gentoo instead if you want to use my application" if your goal is to provide value for as many users as possible?

It's simply not possible to ask people to change their distribution because you as a developer prefers a different one. Flatpak is for all distributions, and doesn't require someone to change from what they know and use already, it'll work for everyone equally.


it’s been tested and almost all library packages are only used by one other package on the system. And almost all of the sharing comes down to a very limited set of libraries.

Flatpak solves this with platforms. You can base a package on the gnome platform for example and get a whole bunch of the most used libraries.

But even without platforms, disk space is one of the most abundant resources right now. You could install millions of libraries in the space of a single AAA game.


IIRC Flatpak actually deduplicates all platform runtime and apps on file level automatically due to the backing storage being an ostree. The same thing also gives flatpak efficient diff updates for apps and platform runtime.


> it’s been tested and almost all library packages are only used by one other package on the system.

I have a KDE desktop, are you trying to imply that only one of the dozens of applications provided by it actually use Qt? That only one of the dozens of image related programs use libpng, libtiff,libjpeg, etc. ? Or are you just citing a highly misleading statistic?


GTK, QT and the core C stuff make up almost all of the shared library usage. Some obscure png cropping library will basically never end up shared even with dynamic linking. Flatpak does a great job of sharing the 1% that make up the 99% of usages while allowing version locking and bundling of that 1mb binary used by only one program.


Qt in your case is one of the exceptions, just like GTK for Gnome users.


Any application that depends on either of those indirectly depends on libpng and dozens of others. Its a dependency tree, just cutting it of after the first dependency does not make sense in any context and even less so in a context that claims to measure package reuse.


The KDE and GNOME platforms contain all of those indirect packages. They contain basically everything generic that you need to build a GUI app. Then when you go off in to the specific little tools you need, you bundle those in.


Exactly. The situation is the same on Windows and macOS: the platform contains the vast majority of dependencies that might be shared across apps. Beyond that, apps bundle whatever they specifically need.


Oh, I thought that the claim was that there was zero package reuse with linux package managers. Not that there was zero package reuse with flat pack.


Ex-(long time)-Gentoo user here. Linux packaging is insane without resorting to something like this. The problem could be fixed but it would require coordinating long-term-stable (like: 5 years, minimum) versions of an entire, fairly large set of basic libraries, across (at least) every distro that matters. For desktops this would probably have to extend to long-term-stable versions of X/Wayland and their related libs, plus QT and GTK.


Is that bad because you don't have the space to store it or is it bad because you don't like it in principle?

If its the former then its a non issue. Storage is cheap and plentiful and code takes up little space relative to other assets such as multimedia content.

If its the latter then I don't know what to tell you other than practical issues are more important than style ones when making practical software. The community has voted and decided that classic package management doesn't cut it and easy of installing software is important.

And I have to agree with them. Time and time again we've been shown that friction to users doing whatever it is they want is the biggest barrier to adoption. Its easy for tech types like ourselves to get stuck in the weeds of the computer. But to most its a means to an end and if it isn't facilitating that then they will find another.


Just use a deduplicating filesystem. Both btrfs and xfs can deduplicate identical files.


This is misleading. While btrfs and xfs have some dedup functionality, it must be invoked explicitly (e.g. by using `cp` with the `--reflink` argument). For application installation to benefit from this, business logic would have to pre-identify identical files and make such references.

There have been some experiments in btrfs to enable inband dedup on arbitrary writes, but nothing that made it in there as yet.

Note however that the discussion misses on the fact that Flatpak itself does perform dedup by using ostree for on-disk storage. ostree implements data structures and ideas very similar to git sans the version control.


Dedup can be run periodically, with crontab or systemd timers. Here's an example of that: https://aur.archlinux.org/packages/duperemove-service


Snaps can do this




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: