Why Flatpak apps use so much disk space on Linux

“Storage is cheap” goes the saying. Other people’s storage has a cost of zero, so why not just fill it up with 100 copies of the same dependency.<p>These package formats (I’m looking at you snap as well) are disrespectful of users’ computers to the point of creating a problem where due to size, things take so long and bog the computer down so much, that the resource being used is no longer storage, but time (system and human time). And THAT is not cheap at all.<p>Don’t believe me, install a few dozen snaps, turn the computer off for a week, and watch in amazement as you turn it back on and see it brought to its knees as your computer and network are taxed to the max downloading and applying updates.

I use flatpaks daily but not many apps. Because I&#x27;ve been on Atomic Linux for a couple years now flatpak has become part of my daily life.<p>On this work laptop I have three flatpaks, Signal, Chromium and Firefox. They all take 1.6GiB in total.<p>On my gaming PC I have Signal, Flatseal, Firefox, PrismLauncher, Fedora MediaWriter and Steam, and obviously they take over 700G because of the games in Steam, but if I count just the other flatpaks they&#x27;re 2.2GiB.<p>So yeah, not great, but on the other hand I don&#x27;t care because I love the packaging of cgroups based software and I don&#x27;t need many of them. I mean my container images take up a lot more space than my flatpaks.

I hope articles like this can at least provide some hints when the size of a flatpak store grows without bound. It is definitely more involved than &quot;it bundles everything like a node_modules directory hence...&quot;<p>[Bug]: &#x2F;var&#x2F;lib&#x2F;flatpak&#x2F;repo&#x2F;objects&#x2F; taking up 295GB of space: <a href="https:&#x2F;&#x2F;github.com&#x2F;flatpak&#x2F;flatpak&#x2F;issues&#x2F;5904">https:&#x2F;&#x2F;github.com&#x2F;flatpak&#x2F;flatpak&#x2F;issues&#x2F;5904</a><p>Why flatpak apps are so huge in size: <a href="https:&#x2F;&#x2F;forums.linuxmint.com&#x2F;viewtopic.php?t=275123" rel="nofollow">https:&#x2F;&#x2F;forums.linuxmint.com&#x2F;viewtopic.php?t=275123</a><p>Flatpak using much more storage space than installed packages: <a href="https:&#x2F;&#x2F;discussion.fedoraproject.org&#x2F;t&#x2F;flatpak-using-much-more-storage-space-than-installed-packages&#x2F;67970" rel="nofollow">https:&#x2F;&#x2F;discussion.fedoraproject.org&#x2F;t&#x2F;flatpak-using-much-mo...</a>

“ The name &quot;Flatpak&quot; is even a nod to IKEA&#x27;s flatpacking,”<p>Which is hilarious: an IKEA flat pack takes up less space than the finished product. Linux flatpack is the exact opposite.

The article mentions that Flatpack is not suitable for servers because it uses desktop features.<p>Does anyone know what those features are or have more details?<p>Linux generally draws a thin line between server and desktop, having “desktop only” dependencies is unusual less it’s something like needing the KDE or Gnome GUI libraries?

I can&#x27;t really comment about snap since I don&#x27;t use Ubuntu but I thought flatpaks would work similar to how portable apps on windows do. Clearly I&#x27;m wrong, but how is it that windows can have portable apps of a similar size to their installable versions and Linux cannot? I know I&#x27;m missing something fundamental here, like how people blame Linux for lack of hardware support without acknowledging that hardware vendors do the work for windows to work correctly.<p>Either way disk space is cheap and abundant now. If I need thenlastest version of something I will use flatpaks.

That was so useless and the style was so bad, I’m pretty sure it was written with (if not by) LLMs. Not even sure if I’m disappointed finding this low effort content here, or rather not surprised at all. I wish the content here would be more interesting, but maybe I’d want to find some other community for that.<p>I mean, the comments are much more interesting than this piece of content, but the content itself is almost offending. At least the discussion is much more valuable than what I’ve just read by following that link.

Why does it seems that we try to both avoid and reinvent the static linker poorly with every new technology and generation. Windows has been fighting with dll hell for 30 years now. Linux seems to not be able to produce alternative to dll hell. Not sure how osx world is.

If you are space concious, you should try to select Flatpak apps that are using the same runtime (Freedesktop, GNOME or KDE), and make sure all of them are using exactly the same version of runtime. Correct me if I&#x27;m wrong, but only two versions of Flatpak runtimes are supported at a time - current and previous. So during times when transitioning happens to newer runtime, some application upgrades are not done at once, and user ends up using more than one (and sometimes more than two) runtimes. In addition to higher disk space usage, one must account for usual updates too. The more programs and runtimes you have, more updates to download. Good thing, at least updates are partial.

I don&#x27;t know much about package managers, but instead of demanding every app uses the same version of every library, or including all libraries in every app, wouldn&#x27;t it make more sense to allow different versions of libraries to exist next to each other, and every app simply picks the more up to date version that it supports?<p>I think that&#x27;s how npm does it. Not that npm doesn&#x27;t have its own dependency hell, but that&#x27;s because different dependencies within the same application can end up requiring different versions of the same sub-dependency. But that&#x27;s a problem only for developers.

I&#x27;ll repeat myself, but this is because Docker (and all its descendents) didn&#x27;t understand my work (or at least took the easy way out).<p><a href="https:&#x2F;&#x2F;www.usenix.org&#x2F;conference&#x2F;usenix-atc-10&#x2F;apiary-easy-use-desktop-application-fault-containment-commodity-operating" rel="nofollow">https:&#x2F;&#x2F;www.usenix.org&#x2F;conference&#x2F;usenix-atc-10&#x2F;apiary-easy-...</a><p>I argued (and built years prior to docker), a container oriented file system infrastructure that combined the best of linux style package management and union file systems. Where instead of &quot;packages&quot;, you had &quot;layers&quot; (analogous to packages) and an &quot;image&quot; that was just a set of layers. I imagined, instead of a linux distribution having an archive of installable packages, it would provide a mirror of usable layers (and PoCd this by converting a large enough set of Debian packages into layers to cover the applications needed for my PoC).<p>In such a world, you don&#x27;t waste (directly at least) any additional space, as you are sharing the packages directly (and therefore the underlying files, which can also have memory benefits in terms of easier sharing of ro code pages, due to being the same page on disk).<p>You do still have a concept of version sprawl, as different images can be using different versions of the same package, but its not very visible. Each image enumerates directly what &quot;shared&quot; components its using. One could argue that just like upgrading a regular deb&#x2F;rpm environment is relatively straight forward, &quot;upgrading&quot; (or in reality, creating a new image version from an existing version) in such a world is also easy. Just upgrade the shared layer versions in the image manifest&#x2F;definition.<p>I was trying to create a world where you could upgrade the container easily (ex: move the running container&#x27;s private RW layer to a new container on upgrade, or in a sense resolve the container&#x27;s layers from version A to version B by swapping around the layers that have changed), but one might argue that today that isn&#x27;t viewed as valuable, and I might agree. I was trying to demonstrate a system that supported what I called persistent and ephemeral containers, with persistent containers being what became called pets and ephemeral containers being what became called cattle and the world today wants everything to be cattle.

Something I have been wondering with Flatpak is about Ram usage. As sharing dynamic libraries allow loading it into RAM only once, while if I use Signal, Chromium and different others Flatpaks, all libs will be loaded multiple times (often with their own version). So maybe disk is cheap but RAM may be more limited, which looks kind of a limit in the generalization of this method of distribution. (You could tell me it&#x27;s the same with containers)<p>Am I right to think that? Has someone measured that difference on their workstation?

It feels, to me, like the Linux desktop has become an overly complicated behemoth, never getting anywhere due to its weight.<p>I still feel the pinnacle for modern OS design might be Horizon, by <i>Nintendo</i> of all people. A capability-based microkernel OS that updates in seconds, fits into under 400 MB (WebKit and NVIDIA drivers included), is fast enough for games, and hasn’t had an unsigned code exploit in half a decade. (The OS is extremely secure, but NVIDIA’s boot code wasn’t.)<p>Why can’t we build something like that?

What made Flatpaks more popular than Appimage? I thought the latter is &quot;vastly&quot; superior and really portable?

They took the “works on my computer - then we’ll just ship my computer” meme literally

[flagged]