Hacker News Reader

Comment by blendergeek | Hacker News Reader

I owned a Librem 5 phone and used it as my daily driver for a few months. During this time I exclusively used Flatpaks for my apps that I installed. After installing about 15-20 apps, the 32 GB of internal storage were completely full and my phone stopped working. I had no clue how huge Flatpak apps are.

Even worse, I could not find out which apps to delete. All the space was taken up by excess "runtimes" I don't know or care what a runtime is but I never intentionally installed them. Why are there five different Freedesktop and Gnome runtimes installed? Which app do I delete to get rid of them?

I need to be able to easily answer the questions: "Which app(s) do I delete to free up space?" and "how much space will be freed by deleting app X?"

On flatpak those questions required dark magic beyond my understanding to answer.

View on HN

This is especially relevant on devices with limited storage, like the Steam Deck.

Keeping dependencies with applications does have a lot of advantages, especially for applications that need incompatible versions of the same libraries. But, having every application with its own full set of dependencies seems quite wasteful.

The problem is that system libraries DO solve a problem that docker recreates - the kernel can efficiently map in a virtual address range for shared libraries and then add the map to all of the tasks that are using the same library, and the disk space is minimal because you only have maybe a few copies of the same lib. For some pieces like glibc, that's huge savings system wide.

With container images you're bundling your app with exactly the libraries it needs at the exact versions you want. This means that the kernel is loading all of this auxiliary pieces for you, distinct copies, that then have to reside in their own mappings, so you get no saving there (it's actually slower in terms of program startup), and then you also are wasting tons of disk space to have all of these duplicate dependencies lying around.

Really, the idea of duplicating an entire os tree for containers is just a bad idea, and it leads to lots of super vulnerable images and destroys the whole concept of sharing a system base for performance and storage wins.

Containers have never been about system efficiency, rather admin/developer efficiency - lower skilled staff can pump out a working product cheaper.

Need to run 2 separate apps that both need to use the same userid/filesystem path/network listener port? No problems.

Need to have different library versions? No worries.

Sure you can workaround all this stuff with ld preloads and other things, but that requires more skill than copying a base dockerfile from a google search and putting in a bunch of RUN commands.

There should certainly be more tooling around finding these things out, but one thing worth noting is that you can `flatpak uninstall --unused` to remove old, unused runtimes (the runtime environments for apps).

Wait ... they don't get removed automatically?

Is my system is guaranteed to fill up completely if I don't run that command regularly?

Unused End-of-Life runtimes get removed automatically now (as of 1.9.1), but the answer is a bit more nuanced than that, especially if there are multiple users on the same system (that could have user-specific flatpaks that use system runtimes).

It could also benefit users that have more disk space than bandwidth (I was in that situation for a while, though a mechanism for sharing runtimes with LAN peers would be nice).

Discussion: https://github.com/flatpak/flatpak/issues/2639

Remove EOL automatically: https://github.com/flatpak/flatpak/pull/3871

Could this be solved by smarter layering? I've read that Flatpaks are just container images under the hood and I'm sure many of those share the same base layers.

Docker does that, but I had understood flatpak to be closer to a VM. i.e. not layered in the same way

Flatpak is even better than layering. All the files are stored in OSTree, a git-like repo, and hard-linked under the root for each app. So duplicate files don't take up space.

And thus we re-invent shared libraries? Like that's not even really a snarky question; isn't that sort of restarting the cycle?

Good point. Yes. But there are too many versions and varieties. In the same vein there is a lot of variety of image layers. What problem does Flatpak solve? I assume it's because it's tough to create Linux desktop applications when you have no idea what shared libraries, compiler, or version expect.

I always thought of containers as essentially a universal linux package manager. If you ever yum install something and see it pull in dependencies, it's not like there's an elegant software solution that makes that happen; it's work done by people who maintain lists of what each package requires and compatible versions. Red Hat puts considerable effort into that, and it's work duplicated by other distros, each with their own packaging idiosyncrasies.

So we reinvented static binaries, except 500x worse.

Reply on news.ycombinator.com