Why Flatpak apps use so much disk space on Linux

Original Article ↗ Hacker News Discussion ↗

Why Flatpaks Use More Disk than Native Packages (and Windows Portable Apps)

  • Windows apps can assume a large, stable user‑space platform: Win32, WinRT, .NET, GUI toolkits, networking, graphics, etc. are always present with stable ABIs. Installers/“portable” builds often differ mostly in where they write state.
  • Desktop Linux has only a stable syscall ABI. Toolkits, media stacks, desktops, and even libc vary by distro and version; multiple libcs exist (glibc, musl).
  • Traditional Linux package managers (apt, dnf, pacman, etc.) solve this by sharing distro‑curated libraries and usually shipping only one version, so apps themselves are small.
  • Flatpak inverts this: it lets each app pick its own versions of libraries and toolkits, then tries to recover space via:
    • Shared “runtimes” (GNOME, KDE, Freedesktop) that multiple apps can depend on.
    • File‑level deduplication across apps.
  • In practice, multiple runtimes and versions coexist, so sharing is limited and disk usage grows.

Flatpak vs Other Formats (Snap, AppImage, Traditional Packages)

  • Compared to snaps:
    • Both can bundle full dependency stacks; both now have shared runtimes/content snaps.
    • Snaps historically did less deduplication; Flatpak’s OSTree layout deduplicates more aggressively.
  • Compared to AppImage:
    • AppImages behave more like Windows portable EXEs: single file, chmod +x, run; no sandbox by default, no central store, minimal integration.
    • Flatpak emphasizes sandboxing, automatic updates, portals, and runtimes; more complex but more “desktop‑like” and cross‑distro.
  • Some commenters prefer AppImages or source builds to avoid Flatpak’s size and complexity; others see Flatpak as the only realistic way to ship third‑party desktop apps consistently across many distros.

Servers, Sandboxing, and “Desktop‑Only” Features

  • Flatpak relies heavily on desktop services like D‑Bus and xdg-desktop-portal; access to files and devices is mediated by the desktop (powerbox dialogs, portals).
  • CLI apps technically work, but running them headless (SSH, TTY) is awkward, so Flatpak is seen as desktop‑focused and ill‑suited to servers.

Storage, Updates, and Security Debates

  • Critics argue that “storage is cheap” ignores:
    • Huge on‑disk footprints (including a reported 295GB Flatpak repo bug).
    • Heavy update traffic when many sandboxed apps auto‑update, impacting I/O and time.
  • Supporters respond that:
    • Containers already normalized shipping entire stacks; Flatpak is similar for desktop apps.
    • Disk is usually cheaper than developer and user time lost to dependency hell.
  • Security arguments cut both ways:
    • Pro: Flatpak’s sandbox and permissions model (Android‑like) improves safety vs. curl | sudo or arbitrary third‑party repos.
    • Con: Multiple bundled copies of sensitive tools (e.g., sudo inside snaps) create many potential vulnerable binaries, though they may be de‑privileged (no SUID).

Versioning, Dependency Hell, and Alternatives

  • Many comments frame Flatpak/Snap as a reaction to:
    • Distro “stable” branches freezing library versions for years, frustrating upstream developers whose bugfixes don’t reach users.
    • Users filing upstream bugs against ancient distro versions.
  • Some advocate a “middle ground”:
    • More standardized, stable ABIs for key Linux user‑space components.
    • Possibly pushing more functionality behind stable IPC instead of shared libraries.
  • Others note this is fundamentally hard at Linux’s scale (many distros, many apps) and see per‑app bundling as the only pragmatic answer.

Space and RAM in Practice

  • Flatpak does share runtimes and deduplicate at the file level; advice includes:
    • Choose apps using the same runtime and version to reduce footprint.
    • Expect extra space while runtimes transition between supported versions.
  • Concern about RAM duplication (same libraries loaded multiple times across Flatpaks) was raised; replies argue that browser‑based apps dominate RAM anyway and that code pages can still be shared when underlying files match, but no hard measurements were provided.