Skip Navigation

Is there a downside to Flatpak?

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.

171 comments
  • 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.

    • The double-edged sword of isolation.

      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.

    • Thanks for your comment! Both positive and negative for sure.

    • The reason I don't wanna use flatpack

  • 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.

  • It's great for user apps, gui apps, and sandboxing. It's terrible for cli apps, libraries, development, and integration.

  • 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

  • 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.

  • Others have mentioned disk usage and desktop integration. There is some truth to them, but shared runtimes keeps disk uasge down (although worse than native apps). Desktop launchers now search /var/lib/flatpak/exports/share/applications by default, but I'm still having issues with themes in one or two niche apps.

    Trust is the big one. The benefit of your distro's packages is that they are maintained by a limited number of maintainers. Flatpaks have a much, much larger number of maintainers, which is where sandboxing comes in. Flathub now marks apps with lax permissions as "potentially unsafe", which is a huge step in communicating this to the average user.

    Most desktop apps can get away with having next to no access, as long as they support the appropriate XDG desktop portals.

    Ultimately, your mileage will vary, as there are many classes of application which are ill-suited to being sandboxed. Program launchers, programming languages, IDEs, file managers are a few.

  • Yes, the confusion that results when things don't work because of isolation.

  • 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.

    • Flathub is just one place. But it has verified apps, so you have no distro packaging issues, which is a Linux/BSD only problem.

  • 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.

171 comments