Timothée Ravier wrote:
The two articles mentioned above all full of errors and
misconceptions
about how Flatpak and Flathub works.
See
https://theevilskeleton.gitlab.io/2022/05/16/response-to-flatpak-is-not-t...
Oh, I know that "response". That response fails to convincingly address any
of the criticism in the "Flatpak is not the Future" article.
Let me just go through the first section, "Size":
Section introduction:
* The response first tries to explain away the problem, trying to tell us
why it is so bad to use host libraries (contrary to the best practices
Fedora has been trying to promote all this time).
* Then it explains that we do not in fact have a 900 MB calculator, but
"only" a 550 MB calculator, as if that were any more acceptable.
Sharing Runtimes:
The response seriously tries to sell us "113 MB out of 498 MB were
deduplicated" (less than ¼) and "388 MB out of 715 MB were deduplicated"
(about half) as a success of deduplication. (That is still a 75% resp. 50%
space waste compared to having just one runtime.)
Storage Usage:
"Only 13.07 GB are used with deduplication", LOL, enough said! Though, if
you insist on percentages, "13.07 GB are used with deduplication" vs.
"36.22
GB without" means that 64% are saved and 36% are still used if you have an
incredible "57 runtimes". (Fewer runtimes also mean less opportunity to
deduplicate.) Still, 57 times 36% is still a factor of more than 20, i.e.,
the proliferation of runtimes means you need 20 times the space for runtimes
that a single shared runtime (as in the RPM world) would need.
"Disk space is cheap!":
* The criticism was that this no longer holds, which seems obvious looking
at current prices. Yet, the response still tries to explain that away by
claiming that "flash storage have higher physical density than hard drives
because of built-in compression and deduplication". But no amount of
compression and deduplication can increase the worst-case size of the disk
that can be relied on, because it only works on data that is compressible
or duplicate.
* The response then proceeds to showing gains on Flatpak data from
partition-level deduplication and compression (which is not actually a
feature of flash storage at all, but of the in-kernel file system). That
there is anything to be gained at all from partition-level deduplication
just shows that Flatpak's own deduplication is nowhere near as effective
as advertised. And partition-level compression is 1. slow and 2. can also
be done just as effectively on software installed from RPMs (so it is not
fair to compare compressed Flatpak installations with uncompressed RPM
installations for size).
Memory Usage, Startup Time:
The response starts with "This is assuming the user has the same
applications installed on the system and as a Flatpak and wants to load
both.", which is a false assertion. In order to share libraries in memory,
the applications need not be the same, they just need to use the same
libraries, e.g., Qt, GTK, etc., and they typically do. So the whole two
response paragraphs that follow are invalid (due to being deduced from this
false premise).
I can take apart the rest when I have more time, but you should get the
idea.
Kevin Kofler