Valve's Read-Only Root and the Flatpak Question That Answered Itself

The Linux packaging debate ran for years on forums and mailing lists. People published benchmarks, wrote manifestos, and argued in comment threads about sandboxing models and daemon overhead. None of that settled it. What settled it was Valve shipping millions of Steam Decks running an operating system with a read-only root filesystem, where the only supported path for installing a third-party application was Flatpak.

That’s the argument this piece on s3kshun8.games is making, and it’s mostly correct. But the interesting story isn’t just about money or market share. It’s about why SteamOS 3’s specific architectural choices made Flatpak a structural requirement rather than a preference, and how the same conclusion arrived independently across the broader Linux ecosystem through the immutable distro movement.

What an Immutable Root Actually Means

SteamOS 3, released alongside the Steam Deck in February 2022, is based on Arch Linux with one significant departure from standard Arch: the root filesystem is mounted read-only. The /usr partition is immutable at runtime. Valve uses an A/B partition scheme for OS updates, similar to how Android and ChromeOS handle system updates: one partition is live, the other receives the new image atomically, and a reboot switches between them. If the new image fails health checks, the system can roll back to the previous partition.

This is a sound engineering decision for a consumer device. It means OS updates cannot partially apply and leave the system in an inconsistent state. It means a crashed update doesn’t brick the device. It means Valve can guarantee the OS image on a given Deck matches their test environment.

The consequence is that pacman is effectively not available for user-facing app installation. Pacman exists on the device, and users can run steamos-readonly disable to make the root writable, but this is officially unsupported and gets wiped on the next OS update. Valve’s documentation is explicit: install third-party applications through KDE Discover, which ships with Flathub pre-configured.

When an immutable OS ships to millions of users, Flatpak isn’t a recommendation. It’s the only path that survives a reboot.

The Technical Foundation

Flatpak’s architecture fits this model cleanly because it was designed around the same constraints that immutable systems expose. Applications install to /var/lib/flatpak (system-wide) or ~/.local/share/flatpak (per-user), both of which are on writable partitions. The base OS never changes to accommodate an app.

The storage layer uses OSTree, a content-addressed object store that deduplicates shared data across runtimes. If you install three GNOME apps, they all share a single copy of the org.gnome.Platform runtime. OSTree handles this through hardlinks across the repository, so disk usage scales with unique content rather than with app count.

Sandboxing is handled by bubblewrap, which creates Linux namespaces (mount, PID, network, IPC) to give each application an isolated view of the filesystem. Apps run against a curated filesystem image, not the host’s /usr or /etc. Syscalls are filtered via seccomp rules. The sandbox is not perfect, but it’s a real security boundary, and it’s been the focus of sustained engineering effort for several years.

The piece that makes sandboxing usable on the desktop is xdg-desktop-portal. Portals are D-Bus services that mediate access to host resources on behalf of sandboxed applications. When a sandboxed app wants to open a file, it calls the FileChooser portal, which presents a native host-side dialog and returns a file descriptor rather than a path. The app never learns the filesystem location. The ScreenCast, Camera, Location, and Print portals follow the same pattern: the app asks, the host decides, a minimal capability is granted. This is the architecture that makes Flatpak’s sandboxing practical rather than constantly infuriating, and it’s a genuine contribution to the Linux desktop stack that outlives any one packaging format.

Why Flathub’s Scale Matters

Flathub passed one billion total downloads in 2023 and had over 2,500 applications by 2024. The app catalog includes Firefox, Chromium, GIMP, Inkscape, LibreOffice, OBS Studio, Blender, Krita, Slack, Discord, Spotify, Signal, and VS Code. Verified publisher badges (blue checkmarks for official maintainers) arrived in 2022, and Flathub introduced direct payment infrastructure for developers in 2023, making it possible to monetize applications through the platform.

This is a functioning software distribution ecosystem, not a packaging experiment. The governance is notable: Flathub is not owned by a single company. The GNOME Foundation and KDE e.V. are both involved, and the submission process runs through a public GitHub organization where app manifests are reviewed via pull requests and built by CI. Any developer can submit an application. No one company controls what appears in the store.

What Snap Got Wrong

The comparison with Snap is instructive precisely because Snap is technically competitive in several areas. Canonical has invested real engineering effort in it. But Snap carries two structural problems that have limited its reach outside Ubuntu.

The first is governance. The Snap Store is a proprietary service controlled by Canonical. The client is open source, but there is no documented protocol for running a third-party Snap store, and no independent store has emerged. When you install a Snap, you are dependent on Canonical’s infrastructure and Canonical’s publication decisions. Fedora, Arch, openSUSE, and most distributions outside Ubuntu’s orbit have declined to ship snapd by default, and many users actively avoid it. The contrast with Flathub’s community governance is stark.

The second is the Firefox incident. When Canonical replaced Firefox’s native .deb package with a Snap in Ubuntu 22.04, users encountered slower startup times due to squashfs decompression overhead on mount, automatic updates that could replace a running browser between sessions, and general friction that hadn’t existed with the native package. The backlash was significant and long-running. It crystallized for a lot of users the concern that Canonical’s interests and users’ interests don’t always align.

AppImage is a different category entirely: a portable binary format with no sandboxing, no daemon, no store, and no shared runtimes. It solves a specific problem (ship a self-contained application that runs anywhere without installation) and solves it well. It’s not competing with Flatpak for the same role.

The Immutable Distro Movement Arrived Independently

Valve’s choice wasn’t made in isolation. The same architectural reasoning has driven a parallel movement in the Linux distribution space. Fedora Silverblue and Kinoite use OSTree for the base system with Flatpak for user applications, and Fedora 38 (2023) enabled Flathub by default in Fedora Workstation. The uBlue project builds on Fedora Atomic to produce a family of immutable desktops with Flatpak as the first-class application layer. Vanilla OS takes this further with a declarative immutable base. Linux Mint 21.3 added Flathub as a default source in its Software Manager, a significant signal given Mint’s historically conservative approach to new technology.

All of these projects arrived at Flatpak through the same constraint: if you want an immutable base, you need an application layer that doesn’t require writing to the root filesystem. Flatpak satisfies that constraint. It’s the only format in widespread use that does.

What the Debate Was Actually About

The Linux packaging debate was never purely technical. It was also about who controls the infrastructure, what trust model governs updates, and whether Linux desktop distributions could agree on anything. Flatpak addressed the technical requirements adequately and the governance question correctly: community ownership, open submissions, no single vendor with veto power.

The Steam Deck provided something arguments couldn’t: deployed scale. Several million devices shipped with Flatpak as the only supported application installation method. Every one of those users who installs an app in Desktop Mode is using Flatpak, most of them without knowing or caring what it is. That’s the shape of a format that has won: it becomes infrastructure.

The remaining criticisms of Flatpak are real. Theming support is awkward because sandboxed apps can’t freely read ~/.themes. Some applications ship with overly broad finish-args permissions that defeat the purpose of sandboxing. Bundle sizes can be large for apps that don’t share a common runtime. These are solvable engineering problems, and the project has been making incremental progress on them. They are not reasons to reopen a debate that infrastructure decisions have already closed.