I’m not new new, but I need this like, the simplest terms
When attempting to install a new piece of software, if I see both AUR and flatpack Versions, which version should be best to install?
My current understanding is that flatpacks are created and maintained by the original software developer, whereas AUR is often NOT, (usually created and maintained by some wonderful, thankless, person whom I have the utmost respect for, that just felt it needed to be done)
Most of the time, there is no need to use Flatpak at all. Most software, especially if free and open source, is available on the AUR.
The AUR has the advantage that it is a fully transparent system. You build the package on your machine, so you can know where the software is sourced from and exactly what goes into the package. That’s very safe.
Flatpaks have two disadvantages: 1) they are statically linked (which means they 1a) take up a lot of disc space, and 1b) may contain older versions of dependencies which may have security flaws not yet fixed), and 2) you don’t know where the software is sourced from (you have to be very careful where you download the flatpak from, to make sure it’s a trustworthy source).
True, anyone can upload anything to the AUR, so if you are not careful, on very rare occasions, you can find something untrustworth or even malicious there (usually, it is a malicious command in the PKGBUILD file). But if you’re careful and inspect the PKGBUILD file, that’s not a big concern.
There is no absolute answer to this question. It depends on the situation and your preferences.
My personal preference is the AUR over the flatpaks due to the transparent nature of AUR packages.
This is not true. flatpaks may or may not be created by the developer/publisher and the same is true of the AUR. It is probably true that it is more common for a developer/publisher to create a flatpak than an AUR package.
Like @dalto already wrote, it’s not true. Take PHPStorm by Jetbrains, for example. The Flathub page is mentioning: “NOTE: This wrapper is not verified by, affiliated with, or supported by JetBrains s.r.o.”
My question would be why would Flatpak be so low compared to Appimage. IMO, Flatpak is FAR more desirable than doing things the Windows way. Download this random binary from this random location…and just TRUST that it’s what it says it is and hasn’t been infected. It won’t be run with any security, or any sandboxing, so you just need to be trusting that it’s not actually malware!! Nope, give me Flatpak ANY DAY over that.
I am pretty sure he wasn’t implying that you should download appimages from random locations.
Not to mention that the same issue exists with flatpaks…they can come from anywhere. You can add any repo you want.
flatpak is still a binary format which can have malware in it the same as any other binary. Not to mention that unless you manually modify it, the flatpak itself defines the level of sandboxing it receives so trusting that blindly doesn’t help anything.
In the end, regardless of which software package format you use, you still need to make smart , informed decisions about your own security.
From the security standpoint, Flatpaks and Appimages they are about equally risky. I placed Appimage above git, simply due to convenience: some software takes ages to build, though building the program yourself from a git repository is, of course, much safer. If security is a big concern concern, just switch the points 3 and 4.
Appimages have all the downsides of Flatpaks, except they are slightly more convenient to use, hence I ranked them a bit higher.
In practice, the only use I have for Appimages is when I need an old version of some program. And, in my opinion, the only practical use for Flatpaks is (though, of course, this is risky on multiple levels and I do not advise it).
I actually find flatpak easier to use. Appimages GENERALLY just don’t work for me. Also they don’t (automatically) integrate into the menu. Also they don’t install in a logical location (since they can be run anywhere), so Appimage I loathe more than snap actually. OK, maybe that’s a bit of an exaggeration.
I guess that’s just a consequence of us having different uses for Appimages/Flatpaks. For me, they are not used for the type of software I’d like to have integrated into my menus. It’s mostly for when I need some old proprietary program to do a task and then discard it.
And if I’m worried about safety, I just boot up a live image of the OS, download the Appimage, run it there, and do what I have to do without any risk to my installed OS. And when I’m done, the Appimage gets deleted. For this use, it is more convenient than a Flatpak.
I have nothing against Flatpaks on their own, it’s just the whole alternative package management system on top of distro’s own package management system that I find a bit too much.
In any case, it’s been probably over a year that I needed an Appimage or a Flatpak for anything. Pretty much all of the software I use is in the AUR (or the repos).
The only exception, i.e. a program I use on a regular basis that is not in the AUR, that I can think of the top of my head (apart from the stuff I programmed for myself, of course) is JSesh, which is a Java app, so I just download the .jar files and run it.
1: I’ve learned a lot, thank you everyone
2: I love that EndeavourOS is one of the few communities I’ve ever been a part of where this sort of discussion does not devolve into an argument and flame wars. I love you guys
If you use appimagelauncher it will both automatically integrate them into the menus and move them to a central location.
Personally, I don’t use it because I prefer to manage those things myself but it is an option if that is something you want.
Another reason I tend to prefer appimage over flatpak is theming. With appimage, it can inherit system theming. With flatpak it relies on the theme being available as a flatpak which the ones I generally use are not.
As for me, I just use 3 of them, firstly the eos repositories, then flatpak and snap, it is simple and have no huge update procedures, and also I think using AUR might bring you eventually a multilib system…