Flatpak Is Not the Future

The most important takeaway from this is, to me, the need to separate sandboxing from dependency management.

However, as can be seen with AppImage, which seems to be strictly focused on dependency management, that results in bloat.

It would be great if we could have a sandboxing solution that ignores the dependency management altogether.

The problem is not with Flatpak or Snaps (or Docker). The problem is that the fragmentation in the actual, live-deployed Linux system runtime is huge. At one point, I know Canonical suggested a common, shared baseline for all LTS editions of all distributions at some point, but there was no interest from Red Hat in particular (the other "largest" player). It's not too surprising, since Red Hat is the biggest contributor to the base GNU/Linux system, so it can decide how it deals with it and push it onto others.

Backwards compatibility is hard in software in general, but I think simple extensions of tools like apt and apt archives (like Launchpad PPAs) would have allowed binary distribution of software in an already familiar way where dependency management is not a solved problem per se, but has all the familiar gotchas.

As for app stores, that's surely an effort to extract some profits, but it's also what big customers are asking for for their IoT solutions.

> You can't do that with a .deb!

Pretty sure you can by doing "dpkg --root=$HOME -i mypackage.deb" or something like that, long time ago I used dpkg, but it should be possible with some flag.

Otherwise I agree, Flatpak is a breath of fresh air!

Put me in the screenshot sideways!

(For clarification, this is bot spam, and in a couple minutes this will be [dead] and unrepliable. So... hi, world, while I can. :P)

Don't know what to think about this blog post; it'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't seem to be 'inherent' in their design. Well, one is.

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.

From my subjective (user) point of view, flatpak is pretty fine. Yes, I do get annoyed whenever I run flatpak update and see 5-10 updates to drivers or runtimes in the range of ~100MB each. But I also want applications to be "just working".

What kinda annoys me though is that file dialogs open in the background. Now I am used to check for it, but when the main window is still in front, yet blocked, because focus is in the file dialog modal, that can get confusing for a moment.

AppImage is ok for me too, the application needs to be "complex" enough to justify the download size though. Precisely what the KCalc example from the article does not do. I didn't even know there is a daemon thingy that auto-integrates them, usually I put them in a folder, grab an icon somewhere and place it next to it with same name, then add an entry in OS manually, so it appears in app starter, can be placed on task bar, etc.

It's just a few clicks and if I ever get annoyed by it because I find myself doing it several times a day, I should ask myself if I am maybe just installing way too much stuff? :)

Edit:

Wanted to mention there is an application called "FlatSeal" that lets you view and (to a degree) edit permissions of Ftatpak Apps. https://github.com/tchx84/flatseal (I use it for spectating only on occasion, because too much fiddling will probably break the app at some point).