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.
Problem I have with Flatpak is their way of naming packages which makes them very akward to run in a WM. That’s basically the only reason why I haven’t used Flatpak since I switched to WMs, pacman and AUR also work really well so there isn’t even a reason to use something else.
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.
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.
On the one hand, poor communication between apps and waste of storage.
On the other, relative safety from malicious applications, or from otherwise-safe applications built on top of a thousand libraries none of which have been audited by the dev.
I don’t know how it’s going to go down, but I suspect something will come along to address these issues and snatch the market away from Flatpak.
but I suspect something will come along to address these issues and snatch the market away from Flatpak.
I believe it could only be fixed by a team from GNOME or KDE, they’re the one in a position to develop something like Flatpak but deeply integrated with the system instead of trying to get around it.
For what’s worth Apple did a very good job when it came to the isolation and containerization of desktop applications, but again only possible because they control both sides.
Apple enforces a LOT of isolaton, they call it sandboxed apps and it is all based on capabilities, you may enjoy reading this. Applications get their isolated space at ~/Library/Containers and are not allowed to just write to any file system path they want.
A sandboxed app may even think it is writing into a system folder for preference storage for example - but the system rewrites the path so that it ends up in the Container folder instead. For example under macOS apps typically write their data to ~/Library/Application Support. A sandboxed app cannot do that - and the data is instead written beneath the ~/Library/Containers/app-id path for that app.
And here’s how good Apple is, any application, including 3rd party tools running inside Terminal will be restricted:
I bet most people weren’t expecting that a simple ls would trigger the sandbox restrictions applied to the Terminal application. The best part is that instead of doing what Flatpak does (just blocking things and leaving the user unable to to anything) the system will prompt you for a decision.
I believe this was the best way to go about things but it would require to get a DE team to make it in a cohesive and deeply integrated with the system. Canonical could do it… but we all know how Canonical is.
The best part is that instead of doing what Flatpak does (just blocking things and leaving the user unable to to anything) the system will prompt you for a decision.
No, Flatpak isn’t the problem here, portals for these things exist. The problem is that apps would have to use them, and unlike Apple, there’s noone restricting the old / unrestricted ways of doing things… So apps usually don’t port over to the portals.
Even where the unrestricted APIs stop working, like with screen capture and Wayland, apps are excruciatingly slow to port over, because they don’t get kicked from app stores for it, and because many users can still fall back to using the old system.
While what you say is true, the “portals” were an afterthought, an imposition to developers and a cumbersome and poorly documented solution. Just like the theming and most other things.
Instead of bluntly blocking things why can’t Flatpak just simulate a full environment and just prompt the user whenever some application wants to read/write to file / unix socket at some path? A GUI capable of automatically enumerating those resources and a bunch of checkboxes like "app X and Y both have access to socket at /var/run/socketY would also solve most of the issues.
Instead of bluntly blocking things why can’t Flatpak just simulate a full environment and just prompt the user whenever some application wants to read/write to file / unix socket at some path?
Because the user getting a hundred popups on app start for various files the app needs isn’t exactly a usable experience. Also, blocking the app’s main thread (which is the only way you could do this) is likely to break it and cause tons of user complaints too.
Aside from apps using the APIs meant for the purpose of permission systems, there’s no good way to make it work.
Because the user getting a hundred popups on app start for various files the app needs isn’t exactly a usable experience
It doesn’t but until apps can declare on a simple config file what paths they require that’s the way things should work. I guess that would motivate the developers who are packing into Flatpaks to properly list whatever files the application requires. If they don’t, then the application will still work fine but be a bit annoying.
Also, blocking the app’s main thread (which is the only way you could do this) is likely to break it and cause tons of user complaints too. Aside from apps using the APIs meant for the purpose of permission systems, there’s no good way to make it work.
Yet, macOS does and things don’t go that bad, on the example how do you think they do it for command line tools? The system intercepts the request, show the popup and wait for the user input. I’ve seen the same happening with older macOS applications that aren’t aware it could happen and yes, the main thread is blocked and the application seems to crash.
I thinks it’s way better doing it this way and still have a somewhat productive container and isolation experience than just bluntly blocking everything - something that also breaks apps sometimes.
until apps can declare on a simple config file what paths they require
They can, and always could. Apps aren’t doing it, most Flatpaks have just blanket “allow ~/Downloads” or “allow all of home” permissions by default - or no file permissions, and you have to go grant them manually yourself.
Again, unless apps actually support it, no matter how good the security system is, it won’t work out.
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?
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.
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.
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.
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.
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.
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.
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)
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.
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”
Probably JSON. I haven’t been involved in Flatpak for a long time but I’ve never seen XML. JSON is quite close to XML in it’s layout sometimes I find so easily mistaken.
I’m using KDE and when I download a flatpak it automatically creates a .desktop file. I think gnome does this too if I’m not mistaken. I do have to restart or relogin for it to put the file there but that’s not that bad IMO.
I think I’ve been having an issue with the Steam Flatpak where after updating, the .desktop file breaks. If not, my icon is broken for different reasons. Either way, I’ve been running Steam through the command line for ages.
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.
Add comment