To be fair, he appears to be arguing for the current model, where armies of distro volunteers review and manually package up debs and rpms (granted that on smaller distro teams, this may be less thorough). There is an actual third party involved in this explicit review step. With flatpak the developer has a direct route to the user without any intermediary or checks.
I think your reading of the author's argument is correct. To that I would counter that you can have just the same with Flatpak, it just depends on the Repository you are pulling your packages from.
It would be awesome if Flathub were to offer some kind of process to validate the packaged applications.
> Size
As the author mentions, many users uses budget computers or something like a raspberry pi and not a big gaming rig, but you also have to consider the network usage, all that data needs to be downloaded, that in it self is a cost for the network for every computer running that distro.
I work from my laptop when I'm traveling, I use my phone as wifi hotspot, download gigabytes of data for installing some small app is not feasible.
And you also have to consider poor countries, in poor countries you don't have infinite downloads nor the largest drives.
I remember the old days of the critique against Windows from the Linux community, Windows forces you to constantly upgrade hardware even though that old machine still works fine. I guess this is now true for Linux too.
However; when compared to other operating systems - like Windows - these space requirements are negligible: a full installation of Window 11 takes north of 30GB, so even with five years of accumulated flatpak runtimes, this is still less than a third of a Windows installation.
Even budget computers can satisfy this. And once the runtimes are installed, your mostly good - there are only so many runtimes[0].
With regards to raspberry pi; yes, that's not what Flatpaks are aimed at, at least not now.
[0] https://docs.flatpak.org/en/latest/available-runtimes.html
Distributing applications with multiple architecture binaries and the correct one selected at run time is a solved problem. The original MacOS did it as far back as the 68k/PPC transition and the concept has been supported by NeXT/MacOSX Application Bundles since the beginning.
I think I know what you want to say (please correct me if I'm wrong); you can always provide more formats or reduce dependencies and go deeper.
But to me there's no reason to do that. Some infrastructure is always required, even if you just reduce it to the kernel. Demanding that a piece of software be installable without any (p)requirements whatsoever seems not something that is demanded from anything besides Flatpak (or Snap). So to complain that Flatpaks require a specific service is not a valid complaint.
Given how common Flatpak nowadays is - almost all distros support it out of the box - I would even say that this complaint is not even valid with regards to Flatpaks.
Yes it does, because you end up loading multiple versions of the shared libraries.
There is also the memory used by the flatpack/snap daemons. Snapd is quite big since it is written in Go.
Given that not all applications necessarily use the same libraries and versions, that's an issue you cannot avoid even with shared libraries.
So, yes are right; it could be an issue. But it doesn't strictly have to do with the containerization.
To be thorough, let me qualify my statement:
Neither Flatpak nor Snap do necessarily result in an increased memory usage because of containerization.
> Snapd is quite big since it is written in Go.
Yes, that's true. Go probably wasn't the best idea for a system daemon.
Let's go through some of the issues:
> Size
My /var/lib/flatpak is 13 GB in size. That's a lot of space. On the other hand; that's about one game with content and textures, so I'm not sure that is too much of an issue. With more and more applications agreeing on the base systems, I expect this to get smaller
> Memory Usage, Startup times
Snap is ungodly slow at starting up applications and that's broken and that is a fundamental design flaw. This issue, however, is not at hand with Flatpak; it doesn't have a startup problem.
Neither Flatpak nor Snap have increased memory usage because of containerization.
> Drivers
Yes, Nvidia sucks. Do you hear, Nvidia? Mainline your driver already.
> Security
> "Flatpack and Snap apologists claim that some security is better than nothing. This is not true."
That's debatable. The same argument was made against seatbelts, child-proof pill bottles or guard-rails on cliff streets and I don't think it holds up. Even if seatbelts don't protect you from any harm, they protect you against some harm.
Currently, Linux desktop software offers no security against malicious code. The only protection the 'traditional' Linux desktop offers against malicious code is user separation, which is no protection at all. Before full security can be offered, applications need to be migrated to safer practices.
> Permissions and Portals
This doesn't seem to be a critique of any user-packaging-format but rather of how GTK implements interactions with Portals.
> Identifier Clashes
That's a problem that arises from Flatpaks decentralized nature; everyone can create a repo and add packages of any names there. I agree that it would be nice to not have these clashes. Notice that this is not an issue with Snaps, since with Snaps there's a central authority assigning the identifiers.
> Complexity
Some of the complexity cannot be avoided. Either for backward compatibility or for security. I pretty much doubt that Flatpak this will be reason that civilization collapses. (That would be shortsighted greed and NIMBYism)
> All of these app packaging systems require the user have some service installed on their PC before any packages can be installed
All app packaging systems require at least some installed component. There's no way you can make a software run on all systems without requiring at least some infrastructure. Do you want your 64-bit AppImage to install everywhere? To bad! it requires 64-bit glib to be installed.
> App stores
> [...] This is the reason Ubuntu wants everyone to use Snap [...]
This seems to limited to Snap. Again, not a fundamental design issue.
> Backward compatibility
> Forcing Distributions to Maintain Compatibility
> I believe this is partly due to a militant position on free software.
This sounds like he wants to dictate FOSS developers how to develop their software? See, I understand your frustration - but that's not how FOSS works. You cannot force anyone to spend time on stuff they don't want to do.
There's some valid criticism in there, but it just reads like an angry rant. I think the author could do better by making individual articles about the shortcomings of both Snap and Flatpak, instead of just lumping them together. Snap and Flatpak are just too different.
In the end, Flatpak is the future. No one is going to package their software for the nth minor distribution and I rather have a slightly (size)-inefficient system of packaging software rather than not have access to that software. Distributions have started to recognize that they cannot package everything and have started to reduce focus to a smaller set of core packages that work well together.