Basically title.
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.
Yes, I love it and don’t get me wrong but there are many downsides and they all result from poor planning and/or bad decisions around how flatpak was built. Here are a few:
- Poor integration with the system: sometimes works against you and completely bypasses your system instead of integrating with it / using its features better. To me it seems more like the higher levels are missing pieces to facilitate communication between applications (be it protocols, code or documentation) and sometimes it is as simple as configuration;
- Overhead, you’ll obviously end up with a bunch of copies of the same libraries and whatnot for different applications;
- No reasonable way to use it / install applications offline. This can become a serious pain point if you’re required to work in air gapped systems or you simply want to level of conservation for the future - it doesn’t seem reasonable at all to have to depend on some repository system that might gone at some point. Note that they don’t provide effective ways to mirror the entire repository / host it locally nor to download some kind of installable package for what you’re looking for;
- A community that is usually more interested in beating around the bush than actually fixing what’s wrong. Eg. a password manager (KeePassXC) and a browser (Firefox/Ungoogled) both installed via flatpak can’t communicate with each other because developers seem to be more interested in pointing fingers on GitHub than fixing the issue.
Flatpak acts as a restrictive sandbox experience that is mostly about “let’s block things and we don’t care about anything else”. I don’t think it’s reasonable to have situations like applications that aren’t picking the system theme / font without the user doing a bunch of links or installing more copies of whatever you already have. Flatpak in general was a good ideia, but the system integration execution is a shame.
Thanks for your comment! Both positive and negative for sure.
To the duplicate libraries
Do you know if flatpak leverages the memory side of this? With shared libs, you only keep one copy in memory, regardless of how many applications use it. Makes application launch faster, and memory usage lower.
For flatpak, it of course will load whatever it needs to load, but does it manage to avoid loading stuff across other flatpaks?
Thats a good question that came to my mind too, idk
1- It takes a lot of space. jUsT bUy a bIgGeR dRiVe --stfu I’m not going to spend money for you to waste it
1- a) Everyone assumes you’re an American with 20Gbps symmetrical fiber optic. My internet can’t handle 2+ Gb downloads for a fucking 50 Mb app bro
2- Duplicate graphics drivers. Particularly painful with Nvidia
3- It puts a lot of security work with distro library trees straight into the shitter
4- Horrendously designed system for CLI apps (
flatpak run org.whocares.shit.app)5- Filesystem isolation has many upsides for security but also it can cause some pain (definitely nitpicking)
Where in America is there 20Gbps symmetrical fiber? Everywhere I know tops out at 1gbps if you are lucky that your ISP isn’t shit, and lots of areas are still on slow cable.
In my area my options are 200mbps cable or 100mbps ADSL (which inexplicably costs more than the cable Internet)
Lived in 8 different states in the US - never had anything above 1 Gbps. Typically been 300-500 mbps, with only the past and current state state where I’ve gotten 1gbps. Poster is just assuming because we’re a first world country that we have good internet. We don’t. I hear Europe has better speeds than us.
All of this. Plus often it just doesn’t work.
And no. I do not want to blind fiddle with the permissions to fix it.
For me it’s lacking in user friendliness. Go easy on the downvotes if I’m doing it the hard way.
- Flatpaks aren’t really single-executables. You have to use to the
flatpakcommand to run them. - I can’t just say
flatpak run firefox, I have to use the full app-id which could be quite long.
Yes, I could make this simpler with scripts or aliases but how hard would it have been for Flatpak to automatically do this for me?
- Flatpaks aren’t really single-executables. You have to use to the
It’s great for user apps, gui apps, and sandboxing. It’s terrible for cli apps, libraries, development, and integration.
deleted by creator
Startup time and disk space.
It’s HUGE. That’s the biggest downside for me. I’m always use a deb/native package first because they are way smaller.
I’ve had my first downside with flatpak.
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.
I got the Snap version so I’m ready for the hate.
Yes. That’s quite a downside actually!
I use the ssh plug in to connect with local.
- no OS level components
- duplicate libraries as some core apps (editor, filemanager, Desktop) cannot be flatpaks (yet?)
- old runtimes etc. dont force developers to keep them updated. Often thats because or 3rd party packagers though
- complicated packaging, I heard that the Flatpak builder is better for certain languages.
- theming issues I heard (on Fedora Kinoite Wayland it just works, and I can also force themes per app)
- bad permissions by default (best we have though)
- bad run commands (this could easily be fixed, and I have a script for it)
For OS components / packaging every part, Snaps may work, but for GUI apps they seem subpar and nobody really cares.
Nix may be way better for installing just anything compartimentalized, but there is no permission system (thats why packaging is easier).
But Flatpaks are really great overall, Bubblewrap, KDE Settings / Flatseal, Portals, official app support. Its really really important.
IMO yes but it might not be an issue for you, flatpaks work like windows standalone executables where each app brings all their dependencies with them, the advantage is the insane stability that method provides, the downside is the huge size the app will ultimately take, flatpaks are compressed and they don’t really bring all their dependencies with them (because they can share runtimes) but the gist of it is a flatpak is usually much heavier than a system (.deb .rpm .PKG) package.
If you are ok with tweaking I recommend nix pkgs as they work on any distro and only take slightly more space than system packages. I have a terrible connection and low disk space, flatpaks aren’t something I can use on the long run.
Oh and if you’re wondering flatpak >>>> snap > appimages (IMO)
flatpak >>>> snap > appimages
I didn’t know we were ranking the horsemen of the apocalypse. Leave room for shitty supply-chain victims like cpan/composer/npm and other irresponsible shortcut tools that throw security out the window.
In the case of NPM (don’t know enough about the others) it’s not a general purpose package manager, it’s only for node related packages.
And yes I think ranking them is relevant Appimages are pretty terrible security wise(let’s download random executables on the internet yayyy!), snaps are getting better but used to be really terrible and to be fair NixPkgs aren’t that safe either.
Flatpaks are pretty secure, they work well, the stack is fully open source and allows you to host your own flatpaks repos, as well as manage sandboxing parameters. If only they were lighter I could easily see them become the “Linux executable format”
flatpaks work like windows standalone executables where each app brings all their dependencies
No thats appimage. Flatpaks run on shared libraries and even different runtimes containing the same packages share those using deduplication
https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker
A Flatpak is exactly as heavy as a system app, just that on the system you already have some libraries installed.
Initial download size is bigger, okay. And in general more downloads, I guess the deduplication happens on the disk.
Its like, shared runtimes but also not. Its a bad situation tbh.
I think using AppImage like Flatpak is silly. It is perfect for keeping some programs on a USB drive for example, but not as a way of installed software.
No proper estimate of download size.
To say nothing of a signed manifest of contents. It’s like 1995-era package management was lost on the kids who built this dreck.
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.
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.
IPC and the correct location may be able to fix that. Have you opened an issue?
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.
Have you reported that bug?
Appimages are pretty bad
It ruins single source of truth for apps and their installed state. It hides installed state from standard enterprise tools.
That seems like a shortcoming in those tools, that I’d expect them to fix as Flatpaks are pretty commonplace.
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.
Yes. It is not pacman
