Flatpak Is Not the Future
Don&#x27;t know what to think about this blog post; it&#x27;s not a very coherent critique, since it throws together various issues of user-packaging-formats that mostly specific to only one of the formats. And these don&#x27;t seem to be &#x27;inherent&#x27; in their design. Well, one is.<p>Let&#x27;s go through some of the issues:<p>&gt; Size<p>My &#x2F;var&#x2F;lib&#x2F;flatpak is 13 GB in size. That&#x27;s a lot of space. On the other hand; that&#x27;s about one game with content and textures, so I&#x27;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<p>&gt; Memory Usage, Startup times<p>Snap is ungodly slow at starting up applications and that&#x27;s broken and that <i>is</i> a fundamental design flaw. This issue, however, is not at hand with Flatpak; it doesn&#x27;t have a startup problem.<p>Neither Flatpak nor Snap have increased memory usage because of containerization.<p>&gt; Drivers<p>Yes, Nvidia sucks. Do you hear, Nvidia? Mainline your driver already.<p>&gt; Security<p>&gt; &quot;Flatpack and Snap apologists claim that some security is better than nothing. This is not true.&quot;<p>That&#x27;s debatable. The same argument was made against seatbelts, child-proof pill bottles or guard-rails on cliff streets and I don&#x27;t think it holds up. Even if seatbelts don&#x27;t protect you from any harm, they protect you against some harm.<p>Currently, Linux desktop software offers no security against malicious code. The only protection the &#x27;traditional&#x27; 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.<p>&gt; Permissions and Portals<p>This doesn&#x27;t seem to be a critique of any user-packaging-format but rather of how GTK implements interactions with Portals.<p>&gt; Identifier Clashes<p>That&#x27;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&#x27;s a central authority assigning the identifiers.<p>&gt; Complexity<p>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)<p>&gt; All of these app packaging systems require the user have some service installed on their PC before any packages can be installed<p>All app packaging systems require at least <i>some</i> installed component. There&#x27;s no way you can make a software run on all systems without requiring at least <i>some</i> infrastructure. Do you want your 64-bit AppImage to install everywhere? To bad! it requires 64-bit glib to be installed.<p>&gt; App stores<p>&gt; [...] This is the reason Ubuntu wants everyone to use Snap [...]<p>This seems to limited to Snap. Again, not a fundamental design issue.<p>&gt; Backward compatibility<p>&gt; Forcing Distributions to Maintain Compatibility<p>&gt; I believe this is partly due to a militant position on free software.<p>This sounds like he wants to dictate FOSS developers how to develop their software? See, I understand your frustration - but that&#x27;s not how FOSS works. You cannot force anyone to spend time on stuff they don&#x27;t <i>want</i> to do.<p>There&#x27;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.<p>In the end, Flatpak <i>is</i> 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.