Well, one could argue, that it is safer to run a proprietary app in a conainerized form like flatpak, where it has only a few / defined ābreakout pointsā - that is - access to only some folders on your disk. Think of spotify or the like. Being installed from the aur - sure, you can look at the pkgbuild and see where the (binary) file comes from and how it gets installed. But how much of help ist this? Do i trust that app? Installed as flatpak, it is containerized, having only access to what it really needs on your disk (your Music Folder for example - but nothing else ā āminimum principleā).
Or a browser, if you look at it as an attack surface while browsing the web. If you happen to catch some kind of malware while surfing, it could help if your browser is containerizedā¦
Not advocating here
I just do see a purpose in using flatpaks in some cases.
The problem I have with flatpak containerization is that it often isnāt granular enough to be useful. You often need to provide access to much more than it needs to get it access to what the one thing you want it to have access to.
Hmm, i donāt know about that. Donāt have used them much myself. But to be fair, that would be at least only a flaw in the implementation - not in the principle of containerization itself
But i guess a big part of that topic is always the question of - trust - . Do i trust the source (flathub, AUR, etc.)? Do i trust the app? I think i have read something like that from you somewhere as well, @dalto, but canāt remember⦠So just rephrasing your wise words
Itās maintained by some weird odd random maintainer named moson, TOTALLY donāt trust them at all, but I canāt deny the package they pull from the source ( https://github.com/moson-mo/pacseek ) is a pretty legit and useful little program
(this is just poking a little fun fyi, happy friday! )
This pacseek maintainer idiot I wonāt trust at all. Every ābitā is a disaster
In this case though, you can see how the binary is built:
(I first built it myself, put tons of malware in itā and uploaded it. Now itās being done with a github action, which is way more transparent)
There are pros and cons. I generally stick to AUR, becouse I do trust that, and I got more control, but when it comes to programs that I really want up to date like Gimp, and in particular Spotify (which is hit or miss in the AUR) I do chose Flatpak.
More choises is not the end of the world, guys/guyettes.
No idea, I donāt use flatpaks my package management is either repos of whatever distribution I am using, AUR if Iām using Arch, or otherwise compiling from source (mostly for older versions of software that I prefer to newer versions)
Trust. Now there is a thing! FUD continues to affect our decisions. If you/we use the AUR then itās up to us. As a user of an Arch-based distro I prefer to use the AUR than resorting to Flatpaks or Snaps. It fits better with the package management whist using pacman and yay (or whatever).
Snaps & Flatpak. For me it seems like an easy way out. If anyone is interested in how things work in computing, or indeed life, then itās worth learning about the processes involved. Update and install with a terminal and look at the output. Look and learn. Iām currently messing about with a āfrom scratchā BSD install on a spare machine. Itās up and running and Iāve already learnt things about Linux/BSD/Unix from it. It wonāt be my daily driver, thatās EnOS. If your local store (not you hopefully!) runs out of ready meals can you cook?
As a former flatpak user, I found it had one advantage over AUR/Snap: I could install the packages on a per-user basis, which kept the root partition out of the loop. This also made a reinstall that much faster as the flatpaks were already there and ready to go (assuming that /home was its own partition/subvolume).
So yeah keeping the root partition out of the loop means you have control, but maintaining it means what? And as you said, why would you take the AUR every time? Definitely /home on itās own thing.
That one advantage was not worth for me in the long-run. Maintenance is not any different than installing it normally, you just use a different repo location: $HOME/.local/share/flatpak instead of /var/lib/flatpak. All you need to do is add a user version of the system repo, then specify that when you install; unless, of course, you remove the system repo, then the default install repo will be the user oneā¦
Are we talking user groups here? I am slightly confused. I get the repo thing, but adding it to the repos follows the usual thing in mirrors. Install has nothing to do with anything, itās just configs and updating mirrors.
When you add a Flatpak repo (known as a remote) to your system, you specify whether itās for everyone (system) or the current user (user). For example, the default Flatpak repo is added like this:
This adds the system remote called āflathubā. If you add --user to the aforementioned command, youāll get a user remote (also called āflathubā). When you run flatpak remotes, youāll see where each remote is pointing to.
Mirrors arenāt part of the equation here; once youāve configured a remote, it points to a single location that canāt be changed. Yes, there are other remotes available - Fedora has one, I think thereās still a beta channel as well - but itās out of your control.
So as I understand it, it remains itās in a user space rather than in a whole system wide thing? That is is just like an AppImage. It just lives in /home/user/
Thanks mate! As spoken before if we installed applications without the correct package manager then it is up to up to us. Freedom, but share knowledge!
The whole it lives in the home directory thing is why they recommend installing flatpaks on the steam-deck since they made the root file system is immutable by default.