I’ve found flatpak to have taken several design decisions that almost seem tailor made to make it hard to use. I use an app launcher as I use I3 to run apps, except I can’t use it for flatpak because it doesn’t just make stuff available on the path, I’d have to make a wrapper script or something at which point I’ve decided to use another app or package. It also had an issue where everytime I got a gpu driver update it updated every single flatpak fair enough but it kept all the old versions! It was using double digit percentage of my disk for no reason, and the response on issue for this on the repo was just this is intended behaviour.
If it wants to get mass adoption they need to work on letting it get out of the way of people trying to use it.
Right, to have the installed packages in the $PATH they need either to appended to the path or linked any directory available in the path.
One of the major positive things is the user space Flatpaks are running in.
Since I wrote a script doing the latter I am very happy with Flatpak.
One of the downsides seems like since the developer packages everything together, I’m reliant on them to push out changes. For example if some dependency needs a critical security update then I’m relying on every flatpak author to apply that change and push out a new version. But if I’m installing packages directly, I can update that one package and be done with it across my system.
In theory, the CI/CD would generate the package automatically when the git repo get tagged for release if they do configure for it, so it should be able to release it rather quickly. For instance, I get endless amount of update from Kate editor on Flatpak, because it constantly get tagged for minor releases.
I think my biggest issue with flatpak is still the attitude it and its proponents have towards disk space. The idea that space usage isn’t really a concern, and it’s okay to require users to download 2GB of platform libraries that they probably already have to install their first flatpak boggles my mind. Because of this, it always seemed hostile towards distro packagers. (If you just used more flatpaks, the bloat will be amortized!)
I am usually not a huge fan of such tools but I am kinda ok with flatpak. The fact that it doesn’t need a daemon (or even root) and the relatively sane CLI makes it passable and I use it when the alternative is more painful.
One particularly fitting use case seems to be managing non-Steam packages on the Steam Deck. It funny to see non-Linux users managing to install and use all kinds of stuff through it.
I think Flatpak is already good enough to be useful, and improving fast enough that it might be viable as the default way to distribute graphical apps for the majority of distros in the nearish future. I personally still prefer native apps, but I recognize those inherently involve massive duplication of effort, and that effort could be much better used in other places. If we’re going to move to a universal packaging format, then for me personally Flatpak seems like the clear winner already, and that gulf is only widening. I just hope it doesn’t stay so centralized around Flathub.
The permission popups on gnome a recent thing?, i know you get popups on both kde and gnome for screensharing. But i haven’t heard about this and the last time i used gnome was about 3 months ago
Yeah, permission popups are absolutely a thing. The system for that is called Portals: https://docs.flatpak.org/en/latest/portal-api-reference.html. The idea is an application asks for the tightest sandbox it needs to run, and then uses the Portal API to request capabilities at runtime, such as access to specific files or permission to start automatically. The catch is you can’t just make legacy applications magically use an API like that: it requires work on both ends. But it’s certainly happening, bit by bit :)
