Linux

In general I agree, though had something to add regarding these points:

by defaults the sandbox is pretty good

This is a rather major problem with Flatpak; the maintainer decides what permissions they need by default, not the user. The user needs to retroactively roll them back or specify global options and manually override them per-app, but that's not user-friendly at all. Though many Flatpaks do have good permissions because Flathub maintainers step in and offer suggestions before approving the Flatpak for publication, there are a number of Flatpaks that punch big holes in the sandbox; so much so that they might as well be unsandboxed.

But Bottles has a great sandbox, for instance, which is just what you'd want when running lots of proprietary Windows applications you maybe don't trust as much as your Linux-y software.

It's better than what we have with traditional packages but it can sometimes get in the way and not all beginners can easily figure out how to fix permissions issues with Flatseal. This will probably improve as we get more portals built.

some apps are less maintained and use EOL runtimes etc

Not much is different for distribution-maintained packages, either. See TheEvilSkeleton's post about how there are over 1200 unmaintained packages in the Debian repositories, and even over 400 in Arch's much smaller repositories that are outdated (!). At least Flathub applications are usually maintained by upstream, and so are usually as up to date as they can be.

not suited for some apps like terminal apps or system stuff

This isn't really true. It's only true when terminal applications need privileged access to something. Flathub ships Mesa userpace drivers and NVIDIA's proprietary userspace drivers just fine. You can package something like yt-dlp in Flatpak just fine with --filesystem=host. Hell, they've even got Neovim on Flathub. Sure, it's a little more cumbersome to type, but you can always create an alias.

Flatpak is not suitable for all graphical applications, either. Wireshark's full feature-set cannot be supported, for example.

I would add that:

• You can easily rollback Flatpaks to a previous version (even from a long time ago) with flatpak update --commit. Much harder with traditional package systems, and you'll probably need to downgrade shared libraries too.
• You get a consistent build environment with Flatpak manifests. If you want to build a newer version of a stable package you're using straight from master or with a few patches, all you really need to do is clone it from flathub/whatever, change a few lines, and it has a very high chance of building properly. No need to figure out dependencies, toolchains, or sane build options. And it's all controlled from an easy-to-read and modify file.

I like flatpak as it helps me keep bloat down. I always find that native packages eventually pollute the system. Flatpaks do somewhat as well but I can manually delete the app storage if necessary

The steam flatpak can't install udev rules. It works if you install a packacke such as steam-devices on your host system. See https://github.com/flathub/com.valvesoftware.Steam/wiki#my-controller-isnt-being-detected

The good news is that flatpak and XDG portals are progressing

Steam's flatpak also can't access libraries on other hard drives.

they are extra heavy in disk space

While they use more disk space than most native packages, this point is often exaggerated. Flatpak uses deduplication and shared runtimes if multiple apps use the same runtime.

If I developed a Linux app I would absolutely package it as a flatpak. If a package is in pacman, however, I see no reason to use the flatpak version instead.

Huh. I didn't even realize that you can use flatpaks with arch. I've only ever used pacman and yay.

Most Flatpaks depend on the Freedesktop Platform runtime, or GNOME/KDE runtimes, which are derived from it. This contains several hundred common dependencies and librarires programs need, like gcc and python. When you update the runtime (change it from 22.08 to 23.08 in the manifest), all the dependencies are updated too. Many simple applications don't depend on many more dependencies than are available in the runtime. Some...have more complicated dependency trees.

But counterpoint: the developer will update the dependencies when they are known to work properly with the application. Upgrading GTK3 to GTK4 in the GIMP flatpak will just break the application. Same thing with Krita and the dozens of patches to libraries it depends on. If you upgrade the application in the name of security before it's compatible, all you end up with is a broken application. Which I guess is more secure, but that's not helpful to anyone.

Common libraries like OpenSSL are usually bundled in runtimes. So if my application uses e.g. org.gnome.Platform, I don't have to update my application if there is a fix in a library of that runtime, I just need to update the runtime.

The runtime is also shared by all applications that use this runtime.

FYI: Flatpaks can share some dependencies and duplicate files.

That flatpak benefit doesn't even mean anything though. It can happen that the library included won't work with your system and therefore the program itself won't either, and fixing it isn't as easy as installing an updated library deb package.

I won't use flatpak, snap, etc for that reason. If someone only makes their program buildable in to one I just won't be using that program. I don't have the time or desire to pick out binaries and resolve all dependencies manually for something that should at minimum have a basic "make install" function.

It isn't bad if you have a bunch of flatapaks as they share dependencies. For install the first install might be huge but the second app that also uses the same framework will be much smaller

Honestly you should (flatpak that is)

Flatpaks are nice and provide isolation so installed apps do not add bloat to the core system.