Flatpak memory usage

[pa...@quillandmouse.com]

Folks:

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.

Am I correct about this, or is there something I'm missing?

Paul

--
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

[Greg Wooledge]

On Mon, Feb 13, 2023 at 09:35:34AM -0500, pa...@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?

"Yes, but it depends."

Let's say you have two applications linked with libjpeg -- one regular
Debian package, which uses the Debian dynamic libjpeg, and one flatpak
thing that's either statically linked with its own libjpeg, or brings
along its own dynamic libjpeg.

If you run both of those at the same time, then you'll have two different
versions of libjpeg in memory.

However, if you only run *one* of them at a time, then there'll only be
one instance of libjpeg in memory.

[Oliver Schoede]

On Mon, 13 Feb 2023 09:35:34 -0500
<pa...@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

[pa...@quillandmouse.com]

On Tue, 14 Feb 2023 23:55:03 +0100
Oliver Schoede <oliver...@online.de> wrote:

> On Mon, 13 Feb 2023 09:35:34 -0500
> <pa...@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?

[snip]

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

I principally wanted to confirm my suspicions about memory usage.
There's been increasing usage of Flatpaks, Snaps and Appimages. As
though it's a solution to the "problem" of distributions' own package
management systems. And now Fedora is openly embracing Flatpaks.

I find the trend disturbing. If you have a lot of apps running, and
they're all these types of packages, you're going to be using
considerably more memory. The alarming increase in the size of the
Linux kernel is yet another symptom of this idea that, because memory
is cheap, we simply use more. In my mind, it's a little like having
access to unlimited amounts of water and thus using all of it you can.
Or gasoline/petrol. Or food.

I don't have a problem with Debian's packaging system, and am generally
satisfied with the stable but older versions of Debian packages. They
get the job done.

Maybe I'm weird.

[to...@tuxteam.de]

On Tue, Feb 14, 2023 at 10:36:12PM -0500, pa...@quillandmouse.com wrote:

[...]

> I find the trend disturbing. If you have a lot of apps running, and
> they're all these types of packages, you're going to be using

> considerably more memory [...]

I'm not a friend of flatpaks and similar concepts, either. For me,
it's not memory use, but the shifting of power from a distrubution
model to single applications. I find that makes software less "free".

In a distro, applications have to get along with each other, agree
on a common set of libraries, file system layout, etc. I think this
is a Good Thing. Every app carrying its own little distro is like
neoliberal hell. No wonder it uses up more resources ;-D

> Maybe I'm weird.

I seem to be even weirder :)

Cheers
--
t

[pa...@quillandmouse.com]

I'd forgotten about that angle. IIRC, snaps are controlled by
Canonical. Flathub controls flatpaks. Appimages can be built by anyone,
but they are one file with *everything* in them.

I trust Debian to audit and ensure my packages are secure and
interoperable. I don't necessarily trust Canonical or Flathub.

[Nicolas George]

to...@tuxteam.de (12023-02-15):

> I'm not a friend of flatpaks and similar concepts, either. For me,
> it's not memory use, but the shifting of power from a distrubution
> model to single applications. I find that makes software less "free".
>
> In a distro, applications have to get along with each other, agree
> on a common set of libraries, file system layout, etc. I think this
> is a Good Thing. Every app carrying its own little distro is like
> neoliberal hell. No wonder it uses up more resources ;-D

I agree with that. The memory impact of code is probably not that big
compared to the carelessness of applications with their memory
management for data.

But there is an even worse side to these pseudo-package managers:
updates.

Now that everybody is responsible for packaging there own applications
with all its libraries, if a bug is found in an application, you can
hope its author will issue an updated package.

But do you trust the developers of all the applications you use to make
updates every time a bug, including a security issue, is found in any of
the embedded libraries?

Yeah, me neither.

And that is not counting the fact that every time a new bug is found in
OpenSSL or libxml2 we would have to update the dozens of packages that
embed them.

Regards,

--
Nicolas George

[Stefan Monnier]

> I'm not a friend of flatpaks and similar concepts, either. For me,
> it's not memory use, but the shifting of power from a distrubution
> model to single applications. I find that makes software less "free".

Indeed. These end up reproducing the black-box model "it just works".
If you like that, then you presumably don't care what's inside the box.
It might as well be iOS, Windows, Oracle, ...


Stefan

[to...@tuxteam.de]

I think it's interesting how history repeats here. This development
resembles much Windows's answer to "DLL hell" back in the 1990s: every
application comes with its own versions of DLLs.

Cheers
--
t

[to...@tuxteam.de]

On Wed, Feb 15, 2023 at 01:34:11AM -0500, pa...@quillandmouse.com wrote:

[...]

> I trust Debian to audit and ensure my packages are secure and
> interoperable. I don't necessarily trust Canonical or Flathub.

That's a very good condensate. That's my take, too.

Cheers
--
t

[to...@tuxteam.de]

On Wed, Feb 15, 2023 at 09:13:06AM +0100, Nicolas George wrote:

[...]

> > In a distro, applications have to get along with each other, agree
> > on a common set of libraries, file system layout, etc. I think this
> > is a Good Thing. Every app carrying its own little distro is like
> > neoliberal hell. No wonder it uses up more resources ;-D
>
> I agree with that. The memory impact of code is probably not that big
> compared to the carelessness of applications with their memory
> management for data.

Right: this was stretching the analogy a bit. In real life, that's
what happens to resources, too.

> But there is an even worse side to these pseudo-package managers:
> updates.
>
> Now that everybody is responsible for packaging there own applications
> with all its libraries, if a bug is found in an application, you can
> hope its author will issue an updated package.
>
> But do you trust the developers of all the applications you use to make
> updates every time a bug, including a security issue, is found in any of
> the embedded libraries?

Yes, that's another technical aspect. Imagine you have 17 slightly
different versions of libc spread across your Flatlands. Imagine
further that some big, fat CVE turns up, affecting 15 of those 17
(the other two are perhaps too old).

Of those 15, two upstream "vendors" have gone bust, another one was
a private person and has lost interest. Another was picked up by
some sleazy malicious actor who is eagerly waiting for you to push
the update button (yeah, that does happen [1] in npm world!).

All that said, I was more interested in the sociological structure
of the whole thing, because it looks like a mirror image of that
"collective" vs. "individual" from political life, which we as
humankind haven't managed to solve for the last millenia, take or
give :-)

Cheers

[1] https://www.synopsys.com/blogs/software-security/malicious-dependency-supply-chain/
--
t

[Jeffrey Walton]

And the distro no longer has administrative control over the package.
The programs do not go through distro-based end-to-end testing or
security testing and evaluation.

Knowing a distro performs end-to-end testing, monitors security events
and performs patching is the reason I use distros. The distro owned it
and took care of it.

Now each user owns it. The user is responsible for ensuring the code
is fit for installation.

Jeff

[pa...@quillandmouse.com]

This brings up another tangent. Bob, a Debian user, is using a
flatpak version of the Snorgistic package, and something goes wrong. He
gets on the Debian user list for support. He's not thinking about where
his package came from, and we don't realize it's a flatpak. We try to
help him, to no avail. A waste of community and Bob's time as well.

[Oliver Schoede]

On Wed, 15 Feb 2023 07:11:02 +0100
<to...@tuxteam.de> wrote:

>I'm not a friend of flatpaks and similar concepts, either. For me,
>it's not memory use, but the shifting of power from a distrubution
>model to single applications. I find that makes software less "free".
>

Not sure about the others, but at least Flathub doesn't even limit
itself to free software, even packages up proprietary stuff, like
VSCode. So the point is kind of moot, besides, not all distributions do
either. ;) With Debian being famously adamant in this respect we likely
all agree it's a good thing, in ideal theory if not actual practice.
But we likely also all agree we're not the whole world, and probably
shouldn't be.

And we are a tiny, tiny part. A snug niche (distribution) inside a
niche (Linux desktop) inside a niche (non-mobile platform). With each
of them by now probably shrinking, in users, developers, everything and
whether in numbers absolute or relative. Hmm. Now, cross-distribution
package managers are obviously an attempt, or invitation, at joining
forces at the second tier. Flatpak in particular is by no means a good
answer, it's horrible, but at least some people (why not in companies?)
are trying to give one. Provided you can see the problem, at least in
the long(ish) run, have you seen any obviously superior solutions?

Free is great but it also means a great amount of work. Oh and speaking
of work, Firefox 109.0 is known vulnerable. As of this writing Unstable
has 109.0. My flatpak'd Firefox on Debian is at 110.0, updated more
than 24 hours ago, actually taking less time than something of
comparable size via apt. Yes, ESR is patched, but I'm not talking about
it. ;) There's obviously a whole bunch of other problems with Flatpak,
security and otherwise, I'm not even recommending it if you can do
without and/or sometimes older versions. Nor is any of this seriously
intended to replace distributions. At best I think they might take away
a little work from them some day, or better yet (re)join and unite
efforts in some fashion. As things stand though everyone keeps rolling
their own userlands. I just doubt it's a plausible future for the Linux
desktop, if there is one. Cross your fingers.


Oliver