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-the-future.html 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
