Flathub aims to be the place to get and distribute apps for Linux. It is powered by Flatpak which allows Flathub apps to run on almost any Linux distribution.
How does it stack up against traditional package management and others like AUR and Nix?
Some of the under-the-hood implementation of Flatpak irritates me, like why the hell are we installing software in /var? Using it with the terminal is a pain because of the org.something.SomeThing shit it does, and I think Flatpak gives you all the drawbacks of app sandboxing with none of the benefits. It likes to not see the whole file structure; for instance I found the Flatpak version of Steam to be unusable because it wouldn’t see anywhere I wanted to put my games library. That needs to be fixed.
That said, I think it’s the better of the three all-distro package managers, it’s got a central repository and package manager unlike Appimage so it’s a place to publish and get stuff, and it’s not tied to Canonical so it’s obviously better than Snap.
if you want to change app permissions, use Flatseal and add the needed directory. This is very easy. If it is something all users generally need, open a bug on their repo.
Installing a separate program to make the first program work the way it should in the first place, and opening bugs in repos, is abolutely 100% things end users are willing to do.
KDE has flatpak settings included, GNOME is doing their thing with unix philosophy and all. Flatseal works fine.
As I said, you should not need to edit those settings, maybe you need to, and if it generally makes sense (for example GNUmeric only has documents access, nothing else) this needs to be fixed.
The state of flatpak permissions currently is like that. They can never read each others storage, much like on Android with /storage/emulated/0/Android/data. So it you keep stuff stored inside these apps its safe.
Until they can use portals, many have permissions to read/write everything
It likes to not see the whole file structure; for instance I found the Flatpak version of Steam to be unusable because it wouldn’t see anywhere I wanted to put my games library. That needs to be fixed.
Some of the under-the-hood implementation of Flatpak irritates me, like why the hell are we installing software in /var? Using it with the terminal is a pain because of the org.something.SomeThing shit it does, and I think Flatpak gives you all the drawbacks of app sandboxing with none of the benefits. It likes to not see the whole file structure; for instance I found the Flatpak version of Steam to be unusable because it wouldn’t see anywhere I wanted to put my games library. That needs to be fixed.
That said, I think it’s the better of the three all-distro package managers, it’s got a central repository and package manager unlike Appimage so it’s a place to publish and get stuff, and it’s not tied to Canonical so it’s obviously better than Snap.
https://github.com/trytomakeyouprivate/flatalias
Try this script I wrote and help improve it!
if you want to change app permissions, use Flatseal and add the needed directory. This is very easy. If it is something all users generally need, open a bug on their repo.
Installing a separate program to make the first program work the way it should in the first place, and opening bugs in repos, is abolutely 100% things end users are willing to do.
KDE has flatpak settings included, GNOME is doing their thing with unix philosophy and all. Flatseal works fine.
As I said, you should not need to edit those settings, maybe you need to, and if it generally makes sense (for example GNUmeric only has documents access, nothing else) this needs to be fixed.
Will not happen often for common apps
Reminds me of this XKCD.
The state of flatpak permissions currently is like that. They can never read each others storage, much like on Android with
/storage/emulated/0/Android/data. So it you keep stuff stored inside these apps its safe.Until they can use portals, many have permissions to read/write everything
That has been fixed with the introduction of Portals: https://docs.flatpak.org/en/latest/portal-api-reference.html