Linux

This is misleading.

Flatpak installs sandboxed libraries and then shares them between different apps as you install them. The first app installed may seem big but often the next app will use many of the same libraries rather than redownload/reinstall them.

Appimage does not share libraries. Each Appimage is a complete image, libraries included and compressed out of necessity. It can be targeted at systems to reduce library bloat but it's often easier just to shove everything in to ensure it works. Also that compressed file system needs to be decompressed which causes further overhead. Simple apps with few dependencies will be small, but big apps can bloat massively particularly if they're not targeted (and that's common as they're treated as run-anywhere solutions for developers).

Plus Appimage can include security flawed libraries - the significance of that will depend on the App being exposed to them. I wouldn't want to run a web browser using a poorly maintained appimage for example, but I'd consider running a random small tool or utility if that was the only option.

Both models are flawed compared to native apps - not quite to the point of installing an entire distro but close. But Flatpak installs one shared set sandboxed environment, while every AppImage is crudely it's own distro.

Appimages also install another distro onto your system. May be small, but you have no deduplication at all. Flatpak could do a better job at enforcing the use of very few runtimes, but at least it is transparent what is used, unlike with Appimages (where you have no idea if any app has a runtime with a vulnerability etc).

If they use compression, you replace disk space with CPU power.

You might want to check flatpak disk usage using this tool

Mine is

28,88 GB "naive"
21,57 GB with deduplication
16,24 GB with compression

For all my apps, including a ton of stuff I just test. And that on a 1TB drive is just not important.

Appimages can be placed in ~/.local/bin/ which makes them kinda okay for terminal use. But none of the formats is terminal friendly. Flatpak has a veeeery descriptive syntax, which makes sense but for sure it is a pain to write.

There are easy workarounds for that though, like this aliasing script

But yes, CLI stuff is not covered but that is also okay. Flatpak deals with all the huge GUI apps, the distros can take care of the small rest.

Of course thats not perfect, but snaps have no sandboxing without apparmor (with patches) and appimages have no sandboxing at all, ignoring firejail which is a root binary and has had security vulnerabilities in the past, making it basically a privilege escalator.

Yes they break that strange XDG idea, and that makes sense. Every app is a container, and if you delete that app directory, all its settings are reset etc. It is a huge advantage for a clean system.

For sure the directories are long as f*ck but that is an okay drawback for having the ability to control the app data so easily.

Wow you are really trying to mislead here.

No, Firefox doesn't take up multiple gigabytes of space. It shares a runtime with a bunch of other programs. So yeah if you literally install one Flatpak, it'll prompt you to download a bunch of extra stuff, but after that it won't. Most people don't only install one program on their PCs, so it's not much of an issue.

Flatpak has deduplication, which appimages doesn't have. If you install a load of appimages and a bunch of flatpaks, the flatpaks should take up less space, because Flatpak uses deduplication (i.e. only one copy is actually stored) and appimages don't, it has several copies of the same dependencies.

Appimages also sometimes don't even contain everything your system needs to run them, which can cause issues if the host system doesn't have it. So it can frequently fail at the main touted usecase: portability!

And don't get me started on stuff like theming, lack of app updates, worse Wayland support (the main dev even flat out refusing to merge Wayland fixes as he is ideologically opposed to it), and downloading programs via a browser like on a Windows system.

Not to mention having to browse to a specific folder and running the appimage every time, unless you do tedious work to add them to your app launcher, or you have a program that acts as an appimage launcher, which is again more tedious setup.

To me, those aren’t real Flatpak issues. Yeah the CLI interface is clunky, but why would I care when the XDG desktop file path is being added automatically and Flatpak is for desktop apps, not for CLI. It only matters when debugging broken application, but at the same time it's not that hard. Overall that also gives us ability to have multiple instances of the same app installed multiple times from different sources.

Flatpak can easily work on anything that has it in its repo and usually the setup is piece of cake. I had much worse time dealing with some AppImages due to its wild guesses about what the host system is, like libfuse version. Desktop integration is really meh imho and I could never figure out how to use it effectively without some lost desktop files here and there I had to clean manually (haven’t tried in a couple of years now, it could be better now).

Wayland support is intentionally broken by AppImage creator/maintainer just to be able to point finger at Wayland ecosystem and say: look - unfixable. Lately the same dude wanted to propose collection of out-of-tree Wayland protocols to make it more like X11, which is horrible idea and no actual Xorg/Wayland dev would have any interest in doing, because it defeats the decade long efforts to change how the graphics stack works.

AppImage maintainers also showed their disappointing attitude when trying to get OBS to use it, assuming everyone will be interested in having that package format published on official projects website, while conforming to all requirements and doing the work of adjusting app to that format. To no surprise, OBS was horribly broken when built that way, and they demanded OBS devs to fix it, not getting how could they possibly not be interested in having app image, while already having well built (I use it myself, it’s great) Flatpak package.

Flatpak does sandboxing with fine tuning abilities (using something like Flatseal or new KDE's built-in KCM) + there is actual verification process at least for new apps on Flathub. I don’t say it’s 100% safe, but compare that to AppImages which is just running randomly downloaded binaries from the web with full filesystem access.

Please be aware that you just commented on some of the points.

Madaidan is often criticised and debunked, and that "linux is insecure" post is pretty old.

They say that many flatpakked apps have broad permissions, which is not a flatpak issue, because those are simply legacy apps that are often huge, dont support Flatpak at all and often also dont care.

I maintain a list of modern apps, that do not need broad permissions like that

They mention the "badness enumeration" like restricted syscalls, which is really problematic and seems to still be used. This is really bad and I hope it gets fixed, will open an issue about that.

But dont forget: flatpak apps may have broad permissions, but native apps have all permissions, appimages too. They have unrestricted syscalls, if not changed in the system itself.

So these might be valid points, but not a defense of Appimages at all.

Thats why you should only use flatpakked wine wrappers like Bottles. Bottles has no filesystem permissions at all, everything uses portals. So I suppose (apart from maybe privileged syscalls?) Viruses would be harmless