4 ms·

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 insta

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.

timw4mail 4y ago
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.
deleted 4y ago
[deleted]
2OEH8eoCRo0 4y ago
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.
- Havoc 4y ago
  Docker does that, but I had understood flatpak to be closer to a VM. i.e. not layered in the same way
- deleted 4y ago
  [deleted]
- akvadrako 4y ago
  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.
- hotpotamus 4y ago
  And thus we re-invent shared libraries? Like that's not even really a snarky question; isn't that sort of restarting the cycle?
  - 2OEH8eoCRo0 4y ago
    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.
    - hotpotamus 4y ago
      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.
    - Brian_K_White 4y ago
      So we reinvented static binaries, except 500x worse.
kirbyfan64sos 4y ago
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).
- blendergeek 4y ago
  Wait ... they don't get removed automatically? Is my system is guaranteed to fill up completely if I don't run that command regularly?
  - MayeulC 4y ago
    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 https://github.com/flatpak/flatpak/issues/2639 Related blog entry: https://blogs.gnome.org/mwleeds/2021/01/11/cleaning-up-unused-flatpak-runtimes/ https://blogs.gnome.org/mwleeds/2021/01/11/cleaning-up-unuse... Remove EOL automatically: https://github.com/flatpak/flatpak/pull/3871 https://github.com/flatpak/flatpak/pull/3871
ilovecaching 4y ago
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.
- nikau 4y ago
  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.
  - 29083011397778 4y ago
    Regarding Docker more than Flatpak, but this is precisely what your comment reminded me of: https://xkcd.com/1988/ https://xkcd.com/1988/

timw4mail 4y ago

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.

deleted 4y ago

[deleted]

2OEH8eoCRo0 4y ago

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.

Havoc 4y ago
Docker does that, but I had understood flatpak to be closer to a VM. i.e. not layered in the same way
deleted 4y ago
[deleted]
akvadrako 4y ago
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.
hotpotamus 4y ago
And thus we re-invent shared libraries? Like that's not even really a snarky question; isn't that sort of restarting the cycle?
- 2OEH8eoCRo0 4y ago
  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.
  - hotpotamus 4y ago
    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.
  - Brian_K_White 4y ago
    So we reinvented static binaries, except 500x worse.

kirbyfan64sos 4y ago

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).

blendergeek 4y ago
Wait ... they don't get removed automatically? Is my system is guaranteed to fill up completely if I don't run that command regularly?
- MayeulC 4y ago
  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 https://github.com/flatpak/flatpak/issues/2639 Related blog entry: https://blogs.gnome.org/mwleeds/2021/01/11/cleaning-up-unused-flatpak-runtimes/ https://blogs.gnome.org/mwleeds/2021/01/11/cleaning-up-unuse... Remove EOL automatically: https://github.com/flatpak/flatpak/pull/3871 https://github.com/flatpak/flatpak/pull/3871

ilovecaching 4y ago

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.

nikau 4y ago
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.
- 29083011397778 4y ago
  Regarding Docker more than Flatpak, but this is precisely what your comment reminded me of: https://xkcd.com/1988/ https://xkcd.com/1988/