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.
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.
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.
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.
One may notice that for every new method, the old ways stay around, possibly forever. It is not the default because there were things that worked prior to flatpak. The distros that from before flatpak have likely added the capability, but won’t likely change their default for another decade, or more.
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.
They dont integrate well into your system like they should, (theming, bookmarks, storage, etc), and to fix that you gotta do some work arounds that should be done automatically
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”
I wish there was an option for an android style system where, when an application wants to use a permission for the first time, you get a pop up asking you to grant that permission.
Or, more generally, just some way to ensure that (a) a flatpak isn’t granted the permissions it wants automatically and (b) I can then manually grant those permissions as conveniently as possible
Flatpak has runtimes, which is where most shared libraries are. There’s a common base one called Freedesktop, a GNOME runtime, a KDE runtime , an Elementary runtime, and more. (The GNOME and KDE ones are built on top and inherit from the Freedesktop base runtime.)
Additionally, at least for Flathub, they have shared modules for commonly used libraries that aren’t in runtimes. (Many are related to games or legacy support like GTK2.)
Lastly, some distributions are building their own runtimes and apps on top, so the packages they build are available as flatpaks as well. This is the case for Fedora, Elementary, Endless, and others.
That’s exactly how flatpaks work if the library you need is not in the runtime. Which is very often the case.
I know because I made one for my personal use and the package was not available elsewhere.
Additionally, at least for Flathub, they have shared modules for commonly used libraries that aren’t in runtimes. (Many are related to games or legacy support like GTK2.)
So we’re just reinventing the wheel with more bloat? Brilliant.
Yeah, that’s a big, weird if though. Most modern apps can rely on the runtimes for their dependencies and not have to ship their own custom dependencies.
It’s different from something like AppImage, where everything is bundled (or Snap, where a lot more needs to be bundled than a typical Flatpak, but not as much as with an AppImage).
Additionally, there’s always some level of sandboxing in Flatpaks (and Snap packages) and none at all for RPMs, Debs, or AppImages.
Also, Flatpak dedupicates common files shared across flatpak apps and runtimes, so there isn’t “bloat” like what you’re talking about.
I think bringing in an entire operating system, which may well include libraries and other files that I already have installed, to run something small can be considered bloat.
I currently have multiple versions of Nvidia’s libraries installed for some reason on my system through flatpak. I have no idea why that’s necessary but if I don’t allow this to happen I get dropped down to software rendering.
It sells security through isolation, but packages are not cryptographically verified after download. This is done in package managers like apt, but not flatpak
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.
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.
Add comment