Why Most Linux Users Avoid Flatpak: The Honest Technical Case Against Universal Packaging

Why Most Linux Users Avoid Flatpak: The Honest Technical Case Against Universal Packaging

TL;DR: Most experienced Linux users avoid Flatpak because it trades the distro-managed dependency model that made Linux secure and lean for bundled runtimes that bloat disk usage, lag on security updates, ship a sandbox that is easily escaped in practice, break desktop integration, and complicate CLI workflows. Native packages (apt, dnf, pacman) remain faster, smaller, better integrated, and faster patched. Flatpak is a useful fallback for proprietary or fast-moving GUI apps, not a default.

Walk into any Linux forum, Reddit thread, or distro mailing list today and you will find the same argument running on a loop. Someone asks whether they should install an application from the distribution repository or grab the Flatpak from Flathub. Within ten replies the thread splits cleanly into two camps: the people who call Flatpak the future of the Linux desktop, and the people who uninstall it on principle. The second camp is larger than the first, and it isn’t made up of greybeards clinging to the 1990s. It is made up of users who have measured the trade-offs and decided the costs aren’t worth the convenience.

This article is a long, honest, technically grounded look at why that second camp exists, why it is growing, and what the actual objections are. It isn’t a hit piece. Flatpak solves real problems. But it also introduces real costs, and pretending those costs don’t exist is how you end up with a 256 GB SSD that is 40 percent full of NVIDIA GL runtimes.

Last updated: August 2026.

What Is Flatpak?

Flatpak is a containerised application packaging and distribution system for Linux, originally developed under the name xdg-app by Alexander Larsson at Red Hat and first released in 2015. Each Flatpak application runs inside a sandbox built on OSTree, bubblewrap, and the freedesktop.org runtime, with dependencies provided by shared platform runtimes (Freedesktop, GNOME, KDE) rather than by the host distribution. Applications are distributed through remotes, with Flathub acting as the de facto central repository, and declare their permissions (filesystem access, network, devices, D-Bus talk names) in a manifest that is supposed to be enforced at runtime.

The promise is seductive: build once, run on any Linux distribution, sandboxed for security, with the application developer in full control of the dependency stack. The reality, as years of production use have shown, is more complicated.

How We Got Here: The Problem Flatpak Was Built To Solve

To understand the backlash, you have to understand the problem. Linux desktop software distribution has always been fragmented. Debian uses .deb and apt. Fedora uses .rpm and dnf. Arch uses pacman and PKGBUILDs. Gentoo builds from source. Each distribution curates its own repository, patches upstream software to fit its policies, and ships a frozen snapshot on a release cycle. If you are an application developer and you want your program to run on every Linux desktop, you historically had to package it six different ways and submit it to six different repositories, each with its own review process and release cadence.

Worse, applications depend on libraries. If your application needs GTK 3.24 but Debian Stable ships GTK 3.22, your application can’t run on Debian Stable without backporting, static linking, or waiting for the next release. This is “dependency hell,” and it’s the single biggest reason commercial vendors historically avoided the Linux desktop. MacOS and Windows solved this decades ago by letting developers ship their own dependencies in their own installer. Linux, by design, refused.

Flatpak, Snap, and AppImage are the three mainstream answers to that refusal. They all bundle the application with its dependencies, in varying degrees, so the developer ships one artifact that runs everywhere. Flatpak in particular targets GUI desktop applications and leans on shared runtimes to reduce the bundling penalty. It’s the answer the GNOME and Fedora ecosystems rallied behind, and it’s now the default application source on Fedora Silverblue, Endless OS, and Linux Mint.

So why do so many Linux users refuse to use it?

Reason 1: Disk Space Bloat and Runtime Duplication

This is the objection that hits first and hits hardest. Flatpak is fundamentally a bundling system, and bundling costs disk space. The shared runtime model is supposed to mitigate this, and OSTree’s content-addressed deduplication does share identical files across applications and runtimes. In practice, the savings are real but partial, and the runtimes themselves are large.

A single Freedesktop Platform runtime weighs around 500 MB. The GNOME 41 runtime weighs around 715 MB, of which roughly 388 MB is shared with the Freedesktop 21.08 runtime it derives from. The KDE runtime is similar, around 900 MB per branch. Each major version of each runtime is a separate branch, and applications pin to specific branches. Install five GUI applications that happen to target five different runtime branches and you can easily accumulate 3 to 5 GB of runtimes before you have installed a single megabyte of actual application code.

The NVIDIA driver situation is worse. Flatpak ships NVIDIA GL runtimes as separate per-driver-version extensions, each around 300 to 400 MB. When the host NVIDIA driver updates, Flatpak pulls down a new matching GL runtime. The old ones aren’t removed automatically, and flatpak uninstall --unused has historically listed them all as “in use” even when they aren’t, a long-standing bug (flatpak/flatpak issue 5261) that has left many systems with a dozen stale 300 MB NVIDIA runtimes sitting on disk.

For users on 128 GB or 256 GB SSDs, especially laptops and cheap machines sold in lower-income markets, this isn’t a theoretical concern. It’s the difference between a system that boots and a system that throws “no space left on device” in the middle of an update. The standard reply, “just buy more storage,” is dismissive and wrong. Not everyone has that luxury.

Native packages share dependencies at the system level. One libgtk, one libssl, one libstdc++, used by every application that needs them. The total installed footprint of a typical desktop is dramatically smaller under apt/dnf/pacman than under Flatpak, and the gap widens the more applications you install.

Reason 2: The Sandbox Is Security Theatre In Practice

The security argument is Flatpak’s strongest marketing claim and its weakest real-world property. The theory is sound: each application runs in a bubblewrap container with declared permissions, mediated by xdg-desktop-portal for filesystem, device, and desktop integration access. In principle this is more isolation than a native package gets.

In practice, the sandbox leaks. A 2024 LWN.net analysis surveyed 53 Flatpak applications and found that only 5 had a useful sandbox, assuming --share=network doesn’t expose the abstract Unix socket escape. On Arch Linux, where the trivial escape appears to be reachable, only one application had a useful sandbox. The Flatpak permission UIs don’t list all granted permissions (for example --talk-name=org.freedesktop.secrets is invisible), and the UI is actively misleading: it will say “No Network Access” while another permission grants a trivial sandbox escape that gives the application the network anyway.

The deeper problem is that most useful desktop applications need broad access to be useful. A file manager needs the filesystem. A browser needs the network and the GPU. An IDE needs the home directory, the network, and the ability to spawn shells. The moment you grant the permissions an application actually needs to function, the sandbox is doing very little. Users are trained to click “allow” on every permission dialog, which is the same trained-approval-ignoring behaviour that makes Windows UAC ineffective. The red security badge becomes visual noise.

The Linux distribution model was, historically, the opposite of this. Distributions didn’t sandbox applications. They curated them. A package maintainer reviewed the source, patched known vulnerabilities, and shipped a binary that ran with the user’s full permissions but had been vetted by a trusted intermediary. Centralised curation plus shared dependency patching is, arguably, a stronger security model than per-application sandboxing done badly. When a critical openssl vulnerability drops, your distribution pushes a single update and every application is fixed. Under Flatpak, every application that bundles its own openssl has to wait for its upstream maintainer to rebuild and republish, which may take weeks or never happen at all.

Reason 3: Slower Startup and Runtime Cold Loads

Native applications start fast because their libraries are already loaded, shared, and cached by the dynamic linker. Flatpak applications pay an extra layer of indirection: the bubblewrap sandbox setup, the runtime mount, the portal initialisation, and frequently the first-time decompression of OSTree objects. Cold start times are noticeably longer, especially after a reboot before the page cache is warm.

The gap isn’t enormous for a single application, but it compounds. A desktop that launches ten Flatpak applications at login feels sluggish in a way the same desktop launching ten native applications doesn’t. On low-spec hardware the difference is more than cosmetic. AppImage, by contrast, often has the fastest cold launch of the three universal formats because it mounts a single squashfs image via FUSE and executes directly, with no runtime negotiation.

Reason 4: Permission Management Is Hostile To Real Users

Flatpak permissions are declared in a manifest and enforced at runtime, but the user-facing tools for inspecting and changing them are poor. The command-line interface requires typing long reverse-DNS application IDs like org.gnome.Calculator or com.spotify.Client for every operation. There’s no flatpak install spotify; there is flatpak install flathub com.spotify.Client. For terminal applications this is actively painful, and most users end up writing shell aliases for every Flatpak they install, which defeats the convenience argument.

Flatseal is the recommended GUI permission manager and it is genuinely useful. But its existence is itself an admission: the built-in permission UI isn’t good enough. A security model that requires a third-party graphical tool to manage correctly isn’t a security model that ordinary users will manage correctly.

The reverse-DNS naming convention also leaks into the desktop. Application desktop files, icon names, and config directories all use the long org.gnome.Calculator style identifiers, which makes manual configuration, scripting, and log reading harder than it needs to be.

Reason 5: Stale Dependencies And Slow Security Updates

This is the objection that security-conscious users care about most. Under the native package model, when a library vulnerability is disclosed, the distribution’s security team patches the library and ships an update. Every application that links against that library is instantly patched, because they all share the system copy. The turnaround is often hours.

Under Flatpak, the application bundles its own dependencies (or pins to a runtime branch that may itself be slow to update). When openssl or curl or libxml2 has a critical CVE, the Flatpak application is vulnerable until either the runtime is updated and the application is rebuilt against it, or the application’s bundled copy is updated by the upstream maintainer. Upstream maintainers are volunteers or commercial vendors with their own priorities. They frequently don’t release mid-cycle security updates. The application stays vulnerable.

The distro repository model exists precisely to solve this. Distributions exist so that security patching doesn’t depend on every upstream author doing the right thing on the right schedule. Flatpak inverts that contract and hands responsibility back to the upstream, which is the model Windows and macOS use and which Linux distributions were explicitly created to improve upon.

Reason 6: Desktop Integration And Theming Breakage

Flatpak applications run against their own runtime, not the host desktop. This means they use the runtime’s version of GTK or Qt, the runtime’s icon theme, the runtime’s font configuration, and the runtime’s file picker. The visual result is often jarring: a Flatpak application launched on a carefully themed GNOME desktop looks slightly wrong, with different fonts, different cursor handling, and a file dialog that doesn’t match the rest of the system.

Font rendering in particular is a recurring complaint. Subpixel hinting, fontconfig overrides, and locally installed fonts frequently don’t propagate into the sandbox correctly, leaving Flatpak applications with visibly worse text than their native equivalents. Theming patches exist but are fragile and break on runtime updates.

The file picker issue is especially annoying. The Flatpak portal file picker is a separate dialog that doesn’t always respect recently-used lists, bookmark locations, or custom path bars the user has configured in their native file manager. For users who live in the file dialog, this friction adds up.

Reason 7: Browsers And Heavy Applications Misbehave

Browsers are the canonical case where Flatpak is actively discouraged. Firefox in Flatpak can’t properly isolate tabs because the sandbox-in-sandbox model conflicts with Firefox’s own content sandbox, weakening the very security model Firefox is built around. Chromium-based browsers have similar issues. The Fedora community consensus is to install browsers from the native RPM repository, not Flathub, specifically for security reasons.

Other heavy applications have Flatpak-specific bugs that don’t exist in the native version. GNOME Connections has keyboard mapping issues under Flatpak. GNOME Boxes doesn’t support USB passthrough under Flatpak. OBS Studio had a widely reported ordeal where the Flatpak build couldn’t access PipeWire cameras and plugins correctly for an extended period. These aren’t Flatpak’s fault in the strict sense, they are integration bugs caused by the sandbox boundary, but from the user’s perspective the Flatpak version is simply broken where the native version works.

The practical advice that emerges in every forum thread is the same: use native packages for browsers and anything that touches hardware directly, use Flatpak only for self-contained GUI applications. Which is to say, use Flatpak for a minority of your software, and accept that you now run a mixed packaging system with two update mechanisms, two permission models, and two sets of integration quirks.

Reason 8: Mixed Packaging Creates A Boundary Problem

Once you run both native and Flatpak applications, you have a boundary problem. Native applications see the full filesystem. Flatpak applications see a composed view that includes the sandbox and a slice of the host exposed via portals. When a native application and a Flatpak application need to share files, the Flatpak side needs explicit permission to access the directory the native application wrote to. When a native helper script needs to launch a Flatpak application, it has to invoke flatpak run with the full reverse-DNS ID. When a Flatpak application needs to call a native CLI tool, it generally can’t, because the tool isn’t inside the sandbox.

The result is that the “clean boundary” between native and Flatpak that proponents recommend is hard to maintain in practice. Real workflows involve pipelines: a browser downloads a file, a script processes it, an editor opens it, a CLI tool uploads it. If any of those steps is a Flatpak, the pipeline needs permission grants and workarounds. Users who want a clear boundary end up either going all-Flatpak (Silverblue model) or all-native (traditional distro model). The mixed middle ground is where the friction lives, and most users are forced into the mixed middle ground because some applications are only available one way.

Reason 9: CLI And Terminal Applications Are Second-Class

Flatpak was designed for GUI desktop applications. The permission model, the portal system, and the runtime model all assume a graphical desktop with a D-Bus session bus. Terminal applications work, but they are awkward. You can’t just type flatpak run com.example.tool; you have to remember the full ID, and the application runs inside a sandbox that may not see your current working directory, your shell environment, or your PATH.

For users who live in the terminal, developers, sysadmins, ham radio operators running logging and digimode software from the command line, Flatpak is actively unhelpful. Native packages, AUR PKGBUILDs, pipx, cargo install, and go install are all better fits for CLI workflows because they integrate with the shell environment directly. The universal packaging formats add a layer of indirection that buys nothing for a CLI tool and costs integration.

Reason 10: Centralisation And The Flathub Monopoly

Flatpak is technically decentralised. Anyone can run a Flatpak remote. In practice, Flathub is the only remote that matters. Almost every Flatpak installation has Flathub configured, and almost every Flatpak application is published there. This creates a single point of failure and a single point of control that mirrors the Snap Store criticism levelled at Canonical.

The difference is that Flathub is governed by a non-profit (the GNOME Foundation spun out the Flathub stewardship into a dedicated entity) and isn’t vendor-locked the way the Snap Store is. But the centralisation concern remains: one repository, one set of upload policies, one takedown authority, one infrastructure that has to stay up for the ecosystem to function. Users who chose Linux specifically to avoid app-store centralisation are unimpressed.

Reason 11: The NVIDIA Driver Runtime Churn

Worth its own section because it affects a large slice of the Linux gaming and workstation population. Flatpak applications that need GPU acceleration depend on a Flatpak NVIDIA GL runtime that matches the host NVIDIA driver version exactly. Every time the host driver updates, Flatpak pulls a new GL runtime. The old runtimes aren’t removed automatically, and as noted above, flatpak uninstall --unused has historically failed to identify them as unused.

On a system that updates the NVIDIA driver every few months, this means a steady accumulation of 300 to 400 MB GL runtimes. Users have reported 5 to 10 GB of stale NVIDIA runtimes on systems that otherwise have no obvious disk hog. The fix is manual cleanup with flatpak uninstall --unused and occasionally direct removal by version, which is exactly the kind of maintenance burden Flatpak was supposed to eliminate.

AMD and Intel users avoid this specific problem because the Mesa GL stack is part of the Freedesktop runtime and updates with it. But the NVIDIA case is common enough that it dominates Flatpak disk-usage complaints in practice.

Comparison: Native Packages vs Flatpak vs Snap vs AppImage

The honest summary of this table: native packages win on every dimension except “runs the latest version of an app the distro does not ship.” Flatpak wins that one dimension. Whether that one dimension outweighs everything else is the entire argument.

When Flatpak Is Actually The Right Choice

This article isn’t “never use Flatpak.” Flatpak is the correct tool in several specific situations:

• Proprietary applications that the distro won’t ship. Spotify, Discord, Slack, Zoom, and proprietary games are good Flatpak candidates. The distro can’t curate them, the vendor won’t build six native packages, and the sandbox at least limits the damage a closed-source binary can do.
• Fast-moving GUI applications on stable distros. If you are on Debian Stable and want the latest Blender, Krita, or OBS Studio without backporting, Flatpak is reasonable. The runtime bloat is the price you pay for not running a rolling release.
• Immutable OSTree distributions. On Fedora Silverblue, Endless OS, and similar systems, the base OS is read-only and applications must live in containers. Flatpak is the supported application layer there, and the trade-offs are baked into the distro choice.
• Testing an application without polluting the system. Flatpak’s isolation is useful for trying software you don’t trust, even if the sandbox is imperfect. A leaky sandbox is still more isolation than no sandbox.

Outside those cases, the default should be the native package. It is smaller, faster, better integrated, faster patched, and supported by the distribution’s own security team. That isn’t nostalgia. That’s the design intent of the Linux distribution model, and it still works.

Practical Recommendations For A Lean Linux System

If you want to keep your system lean and avoid the common Flatpak pitfalls, the following workflow works well across Debian, Fedora, Arch, and their derivatives:

1. Default to native packages. Install from apt, dnf, or pacman first. The distro repository is curated, patched, and integrated.
2. Use Flatpak only for what native doesn’t provide. Spotify, Discord, proprietary games, and the latest version of a fast-moving creative app are legitimate Flatpak use cases.
3. Don’t Flatpak browsers. Install Firefox and Chromium-based browsers from the native repository. The security model is stronger and the integration is correct.
4. Periodically clean unused runtimes. Run flatpak uninstall --unused after major updates. On NVIDIA systems, manually check for stale GL runtimes with flatpak list --runtime | grep nvidia and remove old versions explicitly.
5. Keep a clear boundary. Decide whether a category of software (browsers, IDEs, media tools) lives in native or Flatpak, and stick to it. Mixing per-application creates the boundary problem.
6. Consider AppImage for portable one-offs. If you need a single application for a single task and don’t want to install a runtime, an AppImage is a single file that runs without installation and deletes cleanly.
7. On low-storage hardware, avoid Flatpak entirely. A 64 GB eMMC Chromebook-style device has no room for runtime accumulation. Native packages, or a rolling release with a tight repository, are the right choice.

Frequently Asked Questions (FAQ)

Is Flatpak bad for Linux?

No, but it is oversold. Flatpak solves real dependency-hell and proprietary-app distribution problems. Its costs (disk bloat, slow security updates, leaky sandbox, integration breakage) make it a poor default for software the distro already ships natively.

Does Flatpak use more disk space than native packages?

Yes, significantly. Each runtime (Freedesktop, GNOME, KDE) is 500 MB to 900 MB per branch, and applications pin to specific branches. NVIDIA GL runtimes add 300 to 400 MB per driver version and accumulate without automatic cleanup.

Is the Flatpak sandbox secure?

In theory yes, in practice often no. A 2024 LWN survey of 53 Flatpak apps found only 5 had a useful sandbox, and the permission UI hides critical grants and mislabels others. Useful desktop apps need broad access, which limits the sandbox’s real isolation.

Should I install Firefox as a Flatpak?

Generally no. Firefox’s own content sandbox conflicts with the Flatpak sandbox, weakening tab isolation. Most Fedora and Arch users install Firefox from the native RPM repository for stronger security and better integration.

When should I use Flatpak instead of a native package?

Use Flatpak for proprietary apps the distro won’t ship (Spotify, Discord, Zoom), for the latest version of fast-moving GUI apps on a stable distro (Blender, Krita), and on immutable OSTree systems like Fedora Silverblue where Flatpak is the supported application layer.

Summary: The Default Should Stay Native

Flatpak is a useful tool that has been marketed as a universal default. It isn’t. The Linux distribution model, where a curated repository shares patched libraries across every application and a security team pushes fixes within hours, remains the leanest, fastest, best-integrated, and most responsive way to run Linux software. Flatpak trades all of that for the ability to run the latest version of an application the distro hasn’t yet packaged, and for sandboxing that is weaker in practice than in theory.

Most experienced Linux users avoid Flatpak for software their distribution already provides, and reach for it only when the native option doesn’t exist or is badly outdated. That isn’t conservatism. That’s a measured response to a packaging system whose costs are real and whose benefits are narrower than its proponents claim. Use native packages by default. Use Flatpak where it earns its place. Clean up your runtimes. And don’t let anyone tell you that buying a bigger SSD is the answer to a design problem.

73 from 9M2PJU.

Sources and Further Reading

• Flatpak permissions don’t provide informed consent (LWN.net): https://lwn.net/Articles/987586/
• Flatpak, Snaps falling flat, packing bugs (LWN.net): https://lwn.net/Articles/1014249/
• Kevin Boone: Are Flatpak, et al., saving or drowning the Linux desktop?: https://kevinboone.me/flatpak.html
• AksDev: My thoughts on Flatpak (that nobody asked for): https://akselmo.dev/posts/my-thoughts-on-flatpak-that-nobody-asked-for/
• Fedora Discussion: Should I avoid using Flatpak for all apps on Fedora?: https://discussion.fedoraproject.org/t/should-i-avoid-using-flatpak-for-all-apps-on-fedora-or-is-it-okay-to-continue-using-them-for-most-apps/146343
• Will Thompson: On Flatpak disk usage and deduplication: https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/
• Alexander Larsson: On application sizes and bloat in Flatpak: https://blogs.gnome.org/alexl/2017/10/02/on-application-sizes-and-bloat-in-flatpak/
• Phaedrus Leeds: Cleaning up unused Flatpak runtimes: https://blogs.gnome.org/mwleeds/2021/01/11/cleaning-up-unused-flatpak-runtimes/
• Flatpak GitHub issue 5261: Multiple NVIDIA runtimes on every update: https://github.com/flatpak/flatpak/issues/5261
• Flatpak official documentation, Under the hood (OSTree and hardlinks): https://docs.flatpak.org/en/latest/under-the-hood.html
• Baeldung: Comparison Between Snaps, Flatpak, and AppImage Packages: https://www.baeldung.com/linux/snaps-flatpak-appimage
• Engineered.at: AppImage, Snap, and Flatpak, The Honest Review: https://engineered.at/articles/appimage-snap-and-flatpak-the-honest-review
• HamRadio.my, Amateur Radio Resources, Tools and Reviews: https://hamradio.my/
• About 9M2PJU, Malaysian Amateur Radio Operator: https://hamradio.my/about-9m2pju-malaysian-amateur-radio-operator/