That is a long posting, and TBH I did not read it all.
I take issue with most of the arguments, that are brought up, because I think they are a bit in bad faith or deliberately ignoring some counterarguments.
Core library developers are finally seeing the benefits of maintaining compatibility.
Despite this, many developers are not interested in depending on a stable base of libraries for binary software.
Why has the author such a contemptuous tone?
As if developers would like to bloat the system out of spite.
Unstable ABIs is still a problem, as I linked.
Flatpak is a solution to most of those stability problems.
There are a lot more weak arguments in this article.
Sharing runtimes is a bit similar to existing package managers.
If I install KCalc under Gnome, it pulls also a lot of dependencies under classical package managers.
Sure, it is worse under Flatpak, but kind of similar.
If storage is too much of a problem, then package maintainer will use only a few different runtimes.
Otherwise, Flatpak will just not be usable.
Sandboxing is not perfect, but we have to start somewhere.
Android fox example has a very sophisticated sandboxing and package mangers like Flatpak can get there too.
Yes, it still has its problems, but they are solvable.
All in all, most problems with Flatpak are problems, that can be solved.
I really dislike the tone of the author.
Flatpaks are not from the devil, they are here to solve problems.
I am interested in a constructive discussion, not this.
All in all, most problems with Flatpak are problems, that can be solved
No, flatpak and similar things are designed to bypass the relation of trust between end users and Linux distributions.
Users are required to either blindly rely the upstream authors with the sandboxing, privacy, legal compliance and general quality or do extensive vetting and configuration by themselves.
Additionally the approach of throwing every dependency in one big blob removes the ability to receive fast, targeted security updates for critical libraries (e.g. OpenSSL). And there is no practical way to receive notifications for vulnerabilities and to act on them for the average user.
Traditional Linux distributions carefully backport security fixes to previous releases, allowing users to fix vulnerabilities without being force to upgrade their software to newer releases.
New releases might contain unwanted features or be too heavy for older hardware, or break backward compatibility.
With Flatpak, even if the upstream developer forever releases new packages every time a vulnerability is found in the entire blob, end users are forced to choose between keeping the vulnerable version or update it. Plus, the authors might simply abandon the project.
Furthermore, Flatpak, Snap etc and similarly Docker do not require 3rd party / peer review of the software. Given the size of the blobs it would very impractical to review their contents even if it was required.
That is a long posting, and TBH I did not read it all. I take issue with most of the arguments, that are brought up, because I think they are a bit in bad faith or deliberately ignoring some counterarguments.
This might be true, but true is also that just recently a change in Glibc broke a some games on Steam.
Why has the author such a contemptuous tone? As if developers would like to bloat the system out of spite. Unstable ABIs is still a problem, as I linked. Flatpak is a solution to most of those stability problems.
There are a lot more weak arguments in this article.
Sharing runtimes is a bit similar to existing package managers. If I install KCalc under Gnome, it pulls also a lot of dependencies under classical package managers. Sure, it is worse under Flatpak, but kind of similar. If storage is too much of a problem, then package maintainer will use only a few different runtimes. Otherwise, Flatpak will just not be usable.
Sandboxing is not perfect, but we have to start somewhere. Android fox example has a very sophisticated sandboxing and package mangers like Flatpak can get there too. Yes, it still has its problems, but they are solvable.
All in all, most problems with Flatpak are problems, that can be solved. I really dislike the tone of the author. Flatpaks are not from the devil, they are here to solve problems. I am interested in a constructive discussion, not this.
No, flatpak and similar things are designed to bypass the relation of trust between end users and Linux distributions. Users are required to either blindly rely the upstream authors with the sandboxing, privacy, legal compliance and general quality or do extensive vetting and configuration by themselves.
Additionally the approach of throwing every dependency in one big blob removes the ability to receive fast, targeted security updates for critical libraries (e.g. OpenSSL). And there is no practical way to receive notifications for vulnerabilities and to act on them for the average user.
Traditional Linux distributions carefully backport security fixes to previous releases, allowing users to fix vulnerabilities without being force to upgrade their software to newer releases. New releases might contain unwanted features or be too heavy for older hardware, or break backward compatibility.
With Flatpak, even if the upstream developer forever releases new packages every time a vulnerability is found in the entire blob, end users are forced to choose between keeping the vulnerable version or update it. Plus, the authors might simply abandon the project.
Furthermore, Flatpak, Snap etc and similarly Docker do not require 3rd party / peer review of the software. Given the size of the blobs it would very impractical to review their contents even if it was required.