The argument at s3kshun8.games is blunt in the way arguments only get when the outcome is already settled: serious money has gone into the Linux desktop ecosystem through Valve’s Steam Deck platform, and large parts of the Linux community have spent the same years relitigating system-level architecture choices that will not change and do not affect anyone shipping or running desktop applications.
The provocative framing fits, because the underlying claim is accurate.
How Steam Deck Forced the Question
The Steam Deck runs SteamOS 3, an immutable Arch Linux-based system with a read-only root filesystem. The desktop environment is KDE Plasma. The supported mechanism for installing non-Steam applications is Flatpak, through KDE Discover, with Flathub configured as the default remote on first boot. The reason is architectural rather than preferential: when the root filesystem is read-only and replaced atomically on each update, traditional package managers cannot install software into /usr, and any files written to writable paths survive only until the next system update resets them.
Valve shipped this to millions of customers. Sales estimates put the Steam Deck at somewhere between three and five million units by 2025, and SteamOS 3 has been extended to third-party hardware including the ASUS ROG Ally and Lenovo Legion Go through Valve’s SteamOS expansion program. Every system running that OS has a Flatpak-by-default desktop, in living rooms rather than development labs.
This matters because scale creates facts. When millions of users install applications through Flathub, software developers have a concrete incentive to ship there. The feedback loop runs: more users means more developer attention, which means more applications, which means more users choosing platforms where Flatpak works well. Fedora Workstation, openSUSE Tumbleweed, Linux Mint, Bazzite, and the entire family of immutable Fedora spins have all made Flatpak the recommended or default mechanism for desktop application delivery. Each decision was made independently, and each reinforces the others.
What Valve Actually Funded
The gaming layer of Valve’s Linux investment is more visible than the desktop packaging layer, but the two connect through the immutable OS model. Valve employs developers who contributed the futex_waitv system call, which landed in Linux 5.16 and improved performance for high-frequency mutex workloads common in games running under Proton. The gamescope micro-compositor is open-source and now ships in Bazzite, ChimeraOS, and other gaming-oriented Linux distributions as a standard component. Valve has funded Mesa driver work through Collabora and through direct employment of graphics engineers, and Proton’s Wine and DXVK contributions have raised the compatibility baseline for anyone running Windows software on Linux.
None of this is Flatpak funding in a direct, line-item sense, but the effects are inseparable from Flatpak’s adoption trajectory. The immutable OS design that makes Flatpak mandatory on Steam Deck is an intentional architectural commitment, and the rest of the Linux ecosystem has observed the results and drawn conclusions. The immutable Linux distribution pattern, once a niche choice for Fedora Silverblue users, is now mainstream enough that Bazzite claims hundreds of thousands of installs and is routinely recommended as a gaming desktop over traditional mutable distributions.
Why the Architecture Was Right
Flatpak’s design choices look obvious in retrospect, but they were contested when Alexander Larsson began the project (then called xdg-app) around 2015. The core idea is that applications ship as self-contained bundles with a declared runtime dependency rather than assuming the host system has the right library versions installed. This directly addresses the problem that made “it works on my machine” a punchline for Linux desktop software for two decades.
The distribution layer runs on OSTree, a content-addressable versioning system for filesystem trees. OSTree also powers atomic OS updates in Fedora Silverblue, Fedora Kinoite, and SteamOS 3, which creates a useful coherence across the immutable Linux ecosystem: the same mechanism that delivers OS updates delivers application updates. Delta updates compute binary diffs between commits, keeping update bandwidth reasonable even for large applications like LibreOffice or GIMP.
Sandboxing runs through a combination of Linux namespaces, seccomp filters, and the xdg-desktop-portal framework. Portals are the mechanism by which sandboxed applications interact with the host desktop: file access through a native file chooser dialog, screen capture, camera input, printing, notifications, global keyboard shortcuts, and background process access are all mediated through portals rather than direct filesystem or device access. Each portal type has a backend implementation tied to the current desktop environment, so an application running on GNOME gets GNOME-native file choosers and one running on Plasma gets Plasma-native file choosers, with no desktop-specific code inside the application binary.
This abstraction is real and it works. Applications can be packaged once and behave correctly across multiple desktop environments, with user-visible permission dialogs that make the sandbox legible rather than invisible.
Snap’s Structural Problem
Canonical’s Snap format approached the same problem space and made one architectural choice that has not aged well: the Snap Store is closed-source and operated exclusively by Canonical. Third parties cannot run a compatible store. The tooling for submission, review, and distribution is Canonical’s property.
In 2021, Linux Mint blocked Snap packages at the repository level after Canonical silently redirected the Firefox APT package to a Snap installation, routing users to the proprietary Snap Store without their knowledge. Mint’s blog post explaining the decision was measured but unambiguous: the packaging system was being used as a distribution channel that Canonical controlled, and Mint considered this a violation of user expectations and trust.
Snap startup performance has improved since then, and the daemon overhead is lower than it was in 2021. But the governance model is unchanged. Flathub runs on open tooling against an open OSTree repository format, accepts community contributions for packaging, and has implemented a verified developer badge system alongside an automated malware scanning pipeline. Any sufficiently motivated group can audit, fork, or federate from the Flathub infrastructure. The Snap Store offers none of that surface area.
The Portal Gaps That Actually Matter
The one place where “Flatpak has won” overstates the situation is portal completeness. The USB device portal, which would allow sandboxed applications to access USB devices without --device=all (a flag that grants full device access and largely defeats the sandbox model), has been under development for several years and has not reached a shipped state that applications can take a hard dependency on. Audio and MIDI applications, hardware controllers, and developer tools that need device access routinely use --device=all as a workaround, which means the sandbox offers weaker guarantees for precisely the class of applications that users trust enough to grant hardware access.
Screen recording is in better shape: the PipeWire-backed ScreenCast portal works reliably on both GNOME and Plasma, and applications like OBS Studio and Kooha ship functional Flatpak builds. Applications needing ongoing background access have a patchier story. The Background portal exists and handles the common case of media players that should keep running after the window closes, but support across desktop environment backends is uneven, and some common applications still request persistent process permissions in ways the portal model does not cleanly accommodate.
User-facing permission management falls to third-party tools like Flatseal, which exposes and edits the Flatpak override files that control what each application is permitted to access. GNOME Software and KDE Discover surface some permission information at install time, but ongoing auditing of what a running application is allowed to do is not part of any major desktop’s settings UI. For a security model whose value depends partly on users understanding what they have granted, this gap is worth closing before the user base grows much larger.
These are tractable engineering problems. The portal framework has clear direction, active maintainers across the freedesktop.org ecosystem, and documented incremental progress. The USB portal will ship; the question is when.
Where the Energy Should Go
The original article invokes the init system debate because it represents a class of argument: technically interesting to the participants, passionately contested, and almost entirely disconnected from whether a user can run the application they need on the hardware they own.
The systemd transition on mainstream desktop distributions is complete. Fedora, Debian, Ubuntu, Arch, openSUSE, and their derivatives use it. Devuan and Void Linux serve the users who need alternatives, and those distributions work well for that purpose. The question of which init system runs under a Linux desktop has no practical consequence for a developer packaging a GTK application for Flathub, or for a Steam Deck owner who wants to install Inkscape.
The questions with remaining practical consequence are more specific: when will the USB portal reach a state where hardware-access applications can drop the sandbox-defeating workaround, what does federated Flatpak distribution look like as OCI-based delivery matures and more registries consider hosting Flatpak content, and whether the verified developer trust model Flathub has built scales gracefully as the application catalog expands beyond its current few thousand entries.
Valve settled the packaging question the way hardware manufacturers settle software questions: by shipping a product at scale with a specific architecture baked in, and leaving the ecosystem to catch up. The catching up has mostly happened. The remaining work is in the portals.