The Linux community has treated the application packaging question as a persistent open argument for the better part of a decade. Flatpak, Snap, and AppImage each had their advocates; comment threads and forum posts ran long with comparisons of sandboxing models, store centralization, startup latency, and philosophical positions on freedom versus convenience. A recent piece cuts through the noise with a blunt observation: Gabe Newell has directed enormous sums of money toward Linux desktop infrastructure, and the shape of that investment is Flatpak. The argument is correct. It also undersells the mechanism.
The more precise claim is that Valve shipped a hardware product built on an operating system architecture that makes Flatpak not a preference but a structural necessity. The money followed the architecture, not the other way around.
The Immutable Root Problem
SteamOS 3, which runs on every Steam Deck, uses a read-only image-based root filesystem derived from Arch Linux. The system ships as a complete signed image; Valve updates it atomically and rolls back automatically on failure. A user who installs packages with pacman in a terminal session will find those changes gone after the next OS update, because the root is not theirs to modify persistently. This design is shared by ChromeOS, Fedora Silverblue and Kinoite, and the broader family of atomic Linux distributions.
An immutable root creates an immediate, concrete problem: where do user-installed applications live? The base OS is sealed, so you need a separate writable layer for application software that persists across OS updates, does not interfere with the signed system image, and is manageable by an ordinary user. Flatpak is the answer to that problem. On Steam Deck’s Desktop Mode, KDE Discover backed by Flathub is the documented, officially supported installation path for third-party applications. The architecture chose Flatpak before any community vote was held.
This is the part the packaging debate usually misses. The question was never purely “which format is technically superior.” It was “which format does a hardware platform at scale ship.” Valve answered that question with several million Steam Decks.
What Flatpak Actually Does
Flatpak’s distribution mechanism runs on libostree, a versioning system for filesystem trees that works conceptually like git applied to the OS layer. When an app updates, OSTree computes binary deltas between the old and new versions and downloads only the changed objects. A full AppImage must be replaced in its entirety on every update; a Flatpak transmits only the diff. For a 500 MB application runtime, the difference between a 10 MB delta and a 500 MB full download compounds significantly at scale.
The shared runtime model multiplies this advantage. All GTK applications share the GNOME Platform runtime; Qt applications share the KDE Platform runtime. Install five GTK apps and you download the ~700 MB GNOME Platform runtime once. Subsequent apps using the same runtime cost almost nothing in disk terms, and because Linux loads shared libraries via copy-on-write memory mapping, the runtime is also shared in RAM across all running Flatpak apps simultaneously.
Sandboxing runs through bubblewrap (bwrap), which creates unprivileged Linux namespaces for mount, PID, network, and IPC isolation. Applications declare their permissions in a manifest using flags like --filesystem=xdg-documents, --device=dri, or --share=network. The XDG Desktop Portals layer sits above this: a D-Bus interface that lets sandboxed apps open file chooser dialogs, access the camera, print, share the screen, and interact with the desktop without direct filesystem or device access. The portal backends vary by desktop environment, with xdg-desktop-portal-gnome and xdg-desktop-portal-kde handling their respective environments.
The sandbox has real gaps. Many game launchers and some legacy applications request --filesystem=host, which grants access to the entire home directory and substantially reduces isolation. This is a genuine criticism. It is also the right tradeoff for gaming software, which needs to reach saves, mods, and Wine prefixes scattered across arbitrary paths. The sandbox model is a dial, not a binary, and the ecosystem has been consistently tightening it. The USB portal, added in recent portal versions, allows hardware tools and audio software to access USB devices without --device=all, closing one of the larger holes. Work on a camera portal and improved Bluetooth portal access has progressed through 2024.
What Canonical Got Wrong
Snap is technically comparable to Flatpak on most axes and superior on a few. The squashfs-based image format is straightforward. The security model is thorough. Ubuntu’s integration is seamless. The decision that ended Snap’s chances in the broader ecosystem was making the Snap Store a proprietary, centralized service. Flatpak remotes are open: anyone can run a Flatpak repository, and Flathub is simply the most popular one. Third-party remotes like elementary’s AppCenter or GNOME’s Nightly builds work with the same tooling. Nothing in the Flatpak protocol requires Flathub specifically.
The Snap Store has no equivalent openness. There is one store, Canonical controls it, and there is no supported mechanism for running an alternative. This made Snap effectively non-adoptable for any distribution that was not Ubuntu or a Ubuntu derivative. Fedora, openSUSE, Arch, and every other major non-Ubuntu distribution was never going to ship a packaging format whose infrastructure was proprietary to a competitor.
Canonical then compounded the problem by replacing the Firefox and Chromium packages in Ubuntu 22.04 with Snap versions, without an easy way to revert. The Firefox Snap launched with measurably slower startup times than native Firefox; community benchmarks in 2022 documented initial launch times roughly twice as long on slower hardware. The performance gap has narrowed in subsequent releases, but the move generated substantial ill will and gave Snap a reputation for slowness that continues to color perception regardless of current performance.
The Immutable Distro Effect
The Steam Deck did not invent immutable Linux distributions, but it normalized them for a non-enthusiast audience. Fedora’s atomic variants, Silverblue and Kinoite, predate the Steam Deck. What the Deck did was demonstrate that an immutable OS with Flatpak as the user application layer was a workable, shippable product for people who do not know what an init system is and do not need to.
The community took that lesson and ran with it. Bazzite, a gaming-focused immutable distribution based on Fedora’s Universal Blue project, became one of the fastest-growing Linux distributions in 2024 measured by community uptake. It ships with Flatpak and Flathub configured by default and targets exactly the Steam Deck use case on arbitrary hardware. Fedora Kinoite provides the same architecture for KDE users. The uBlue project offers a catalog of pre-built Fedora Atomic image variants covering dozens of use cases.
All of these distributions converge on the same application model: immutable base, Flatpak on top, Flathub as the primary repository. The convergence happened without central coordination. It happened because the architecture solves a genuine problem and the tooling is good.
Where the Numbers Sit
Flathub had approximately 2,500 applications listed as of late 2024, with monthly install and update counts in the range of 100 to 150 million operations. Cumulative installs crossed 1 billion in 2023. GNOME Software 45 and KDE Discover in Plasma 6 both treat Flathub as a first-class, default-enabled software source. The Flathub verification program, introduced in 2023, allows upstream maintainers to claim their apps with a verified badge, addressing the historical problem of third-party packagers shipping stale or misconfigured builds.
These are self-reported figures derived from OSTree pull counts and should be read as approximations. They nonetheless indicate an ecosystem with real volume, not a boutique project.
The Debate That Already Ended
Arguing about Linux packaging formats in 2025 is roughly equivalent to arguing about smartphone operating systems in 2013. The network effects have consolidated. The major desktop environments default to Flathub. The immutable distros depend on Flatpak by construction. The hardware platform that normalized Linux gaming ships Flatpak in its official documentation.
AppImage retains a durable niche for developers who need single-file distribution without installation, and for audio production software where sandbox restrictions are genuinely incompatible with JACK and ALSA routing requirements. That niche is real and will persist. It is not a competing answer to the same question.
Snap will continue in Ubuntu and in IoT and server contexts where Canonical’s control of the store is an advantage rather than a liability. It is not coming for the desktop ecosystem outside Ubuntu’s perimeter.
Flatpak won the way most infrastructure arguments end: not through a decisive technical proof, but through being embedded in something that shipped and scaled. Valve built an operating system that needed a specific kind of application layer. The application layer that fit was Flatpak. Several million Steam Decks later, the rest of the ecosystem noticed which direction things were already moving and followed.