[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Flatpak memory usage



On Mon, 13 Feb 2023 09:35:34 -0500
<paulf@quillandmouse.com> wrote:

>Am I correct in assuming that package formats like Flatpak, Snap and
>Appimage, because they package up everything with the executable, would
>consume more system memory? One of the reasons to use these formats is
>to avoid library version mismatches, and peg the libraries which
>accompany an executable at a certain version. But if this is true, then
>it stands to reason that the executable would use, for example, GNOME
>libraries which aren't the same as what's on your system being shared
>by other software. Thus, when you launch X flatpak, it must load its
>own version of the GNOME libraries. Which would take up more system
>memory.
>

Flatpak is the odd one out and doesn't exactly work like this. Rather
than completely self-contained images, the packages aren't that much
different from what we have in Debian. The difference being that as for
dependencies it's more of an all or nothing affair. Or what's called a
"runtime", basically a small userland mostly tied to specific desktop
environments. Clearly not as economical, especially if all you need is
a single app, which to be fair isn't Flatpak's intented use case, or
everything you're using needs a different runtime. It's also simpler
though. With nothing but, say, GTK software you might always get away
with a single runtime. I do, although with very few apps installed.
Yes, if you're then also running something installed via Debian, or yet
another package manager, with the same dependencies, there's
redundancy, this is true even where versions match. I wouldn't rack my
brains on that however, modern loaders are quite intelligent and
dynamic linking is selective in a sense. I guess it's quite attractive
for people like me who are not even using one of the full-blown DEs
like GNOME, so there's little that must be resident all the time and
I'm more flexibel in "load balancing" if need be, which should be
almost never considering today's memory supplies. And I don't think any
of these solutions is specifically catering to resource-constrained
systems. With that you're probably always better off with installing
from a single source.

Oliver


Reply to: