I’m wondering if a package manager like flatpak comes with any drawback or negatives. Since it just works on basically any distro. Why isn’t this just the default? It seems very convenient.
I believe it’s the packaging process. It favors the standatd procedure of builds, and does not take account of various build systems (Seems C-centered). Seems this is why many apps end up providing AppImages instead.
I don’t think anyone dislike this comment is really correct: When they said you can use flatseal, they are making user become security expert overnight.
Too much for anyone claim themselves “practical” “security”
VSCode’s flatpak version won’t let you use certain packages because they’re installed on the system and flatpak is a sandbox with no access. You need to enable some stuff but I’m far too lazy to troubleshoot that shit.
Generally using only a few flatpaks is where it’s generally “bloaty”. Adding more actually balances out the equation ans you have more apps using generally shared runtimes.
There’s still a few edge cases that Flatpak is not great for. The Flatpak version of Kdenlive video editor can’t see Whisper, which it uses to generate subtitles. The Appimage and native builds work flawlessly.
I’m assuming these problems will be addressed eventually but it takes time.
I ran into an issue with flatpak version of Kdenlive that it would render only the topmost V track if it was a simple still image.
Preview worked fine.
Luckily, someone in Kdenlive’s Matrix suggested that I use an appimage. I used my distro’s version and the final render was fine.
Other than that I had positive experience with flatpaks in general.
I personally don’t really like it, since it sidesteps what is supposed to be the all-in-one package manager for the system, and integration can be poor.
It’s an alright idea, but I like the native package managers better. We’re not Windows, we don’t need so many different places to download our stuff.
Bloated and unnecessary if freeSW or openSW. That’s what system shared libraries are for. If sandboxing is a thing, then firejail is availble, which can be combined with apparmor if looking for extra MAC security.
If you have an unusual setup, it can be annoying trying to give programs permissions and sometimes it just outright doesn't work. For example, I mainly game on a laptop which has a pretty small hard drive, so I tend to put most of my games on an external hard drive. Flatpak really doesn't play well with that.
The worst part of flatpaks is that they don’t get to see the actual path of files that they open. Instead, they get a /var/run/1000/blah proxy. The proxy is forgotten after you reboot, so any flatpak that memorized that path is holding a bunch of dead links.
the main drawbacks I see are related to the sandboxing of apps, e.g. that several firefox addons that I just, such as the KeePassXC connector don’t work in flatpak packaged firefox, because they require native messaging support which is unavailable in flatpak. There is a three year old bug report on this at github, and an even older bug report in the Firefox bugzilla. Unfortunately, there seems to be no capacity to solve this or this is not a priority, although this problem affects quite a few users. I have similar issues with the Flatpak packages Nextcloud client: Do to the poor system integration, neither autostart works not integration with Nautilus or other file managers, unless you do some manual tinkering (which isn’t particularly difficult, but with native packages it will just work™ out of the box.) These issues have been known for many years, yet there seems to be no activity to solve them.
All that was said here, plus sometimes they don’t work. I’ve reported a bug where the kdenlive flatpak version doesn’t render titles or fades - and that’s on Debian Testing, Arch, and Asahi Fedora. Native version works perfectly, but forces me to download an untidy amount of KDE stuff on my gnome installs ; flatpak would’ve been a cool solution to that.
I am yet to report another where Ardour nukes pipewire, at least on Asahi, but on Arch it was misbehaving also. Native, distro-provided version works perfectly.
I don’t trust flatpak because no one single publisher can test every possible config, and I’m afraid distros become “lazy” and stop packaging native versions of stuff since it’s a lot of work.
I’ve used flatpak for a while because it’s the default ob Fedoras GUI Software Center, but I’ve recently switched back to dnf and native packages where I can.
The thing is, that I have a shitty 500GB SSD with a shitty 50Mbit Internet connection (which is closer to 30Mbit because my house still has lead cables instead of copper). So downloading 300+ MB of libraries for a 2MB Program is just not feasible for me.
It does not. Flatpak uses the full platforms, the native package manager will install the individual libraries that are needed. This is technically a flathub thing and could be implemented more granularly, but I don’t think that is going to happen.
I’ve started getting warnings about deprecated platforms but flathub is very slow to update the packages that use them (even with reports), which is unfortunate too and not something I’ve encountered in my distro repository.
Yes, of course. But afaik the idea of flatpak is, that every program has a list of libraries and versions of them that it wants. So when program X was built with libfoo version 1 and program Y needs libfoo version 2, you basically download the library twice.
When you go through the package manager, you just download the current version that’s in the repository. This can lead to problems when a program expects some functionality that has since been deprecated, but I never actually had issues with that.
Also, a lot of the libraries a flatpak downloads are already installed on the system, just in a different version, I noticed.
I’m on a home computer that I use by myself, mind you. So if something breaks, it’s just my own problem. If I were to use software in production or even just administer the computer of a tech-unsavy relative, I’d likely use flatpaks or similar for stability and security reasons.
Add comment