I was using Flatpak and Toolbx exclusively until I discovered Nix. It's much better than using those two.

i avoided flatpacks before.
but now that i tried out silverblue and had to rely heavily on them,
i have to admit that flatpacks are not nearly as bad as i thought.

the only issues i encountered are with steam (might not start propperly on first launch)
and with ides(terminal starts inside the sandbox)

other than that it works great.

I use flatpaks mostly. Flatpak dependencies (runtimes) are stored separately from the host system so and don't bloat my system with unwanted libraries and binaries. App data and configs are stored separately and better organized. Everything runs in sanboxes. I use overrides extensively. All these are very convenient for me.

I use system packages for everything unless I need a newer version of a specific package for some reason.

No

In place of snap OF COURSE.

I can state without any doubt that i had problems with 80% of the programs coming from snap..

I didn’t like them before I used flatseal. Now I love them.

I prefered AppImages, but now that I'm on Nix, I've gone back to native. Native packages work well in the NixOS ecosystem.

Definitely not me. I am on LiveUSB right now which makes my disk volume limited. And native packaging satisfies my needs (even when packages are old)

Absolutely not, and this article goes into quite a few reasons why:

https://blog.brixit.nl/developers-are-lazy-thus-flatpak/

Sadly there's reality. The reality is to get away from the evil distributions the Flatpak creators have made... another distribution. It is not a particularly good distribution, it doesn't have a decent package manager. It doesn't have a system that makes it easy to do packaging. The developer interface is painfully shoehorned into Github workflows and it adds all the downsides of containerisation.

While the developers like to pretend real hard that Flatpak is not a distribution, it's still suspiciously close to one. It lacks a kernel and a few services and it lacks the standard Linux base directory specification but it's still a distribution you need to target. Instead of providing seperate packages with a package manager it provides a runtime that comes with a bunch of dependencies.

If you need a dependency that's not in the runtime there's no package manager to pull in that dependency. The solution is to also package the dependencies you need yourself and let the flatpak tooling build this into the flatpak of your application. So now instead of being the developer for your application you're also the maintainer of all the dependencies in this semi-distribution you're shipping under the disguise of an application. And one thing is for sure, I don't trust application developers to maintain dependencies.

Even if there weren't so many holes in the sandbox. This does not stop applications from doing more evil things that are not directly related to filesystem and daemon access. You want analytics on your users? Just requirest the internet permission and send off all the tracking data you want.

Developers are not supposed to be the ones packaging software so it's not hard at all. It's not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in.

Another issue is with end users of some of my Flatpaks. Flatpak does not deal well with software that communicates with actual hardware. A bunch of my software uses libusb to communicate with sepecific devices as a replacement for some Windows applications and Android apps I would otherwise need. The issue end users will run in to is that they first need to install the udev rules in their distribution to make sure Flatpak can access those USB devices. For the distribution packaged version of my software it Just Works(tm)

For me the perfect example is GNOME Builder (I use KDE Plasma) but this package has it all. No, you dont need to download any dependencies, the sandbox handles it all!

Flatpaks are my second choice when there isn't a recent enough version in the repos. They're fine but take 1. too much storage space, and 2. are usually slower