The Snap Controversy: Why a Part of the Linux Community Rejects Canonical's Package Format
When Canonical introduced Snap packages, the goal was ambitious and seemingly noble: to create a universal package format that would allow developers to deploy their applications across any Linux distribution easily and reliably. The promise was a world with fewer dependency headaches and more up-to-date software for everyone. Yet, years later, Snaps have become one of the most divisive topics in the Linux community.
While the technology has its merits, a significant portion of users and even some distributions actively avoid it. But why? The criticism isn’t just about technical details; it’s about philosophy, control, and user experience.
The Proprietary Backend: A Philosophical Clash
The most significant and principled argument against Snap is its proprietary backend. The Snap Store, the central repository from which all Snaps are distributed, is a closed-source, walled garden controlled exclusively by Canonical. You cannot create your own independent Snap store or federate with the main one.
This goes directly against the grain of the open-source philosophy that underpins the entire Linux ecosystem. For a community built on freedom, transparency, and decentralization, being locked into a single, corporate-controlled vendor for software distribution feels like a step backward. Alternatives like Flatpak, by contrast, are fully decentralized, allowing anyone to host their own repository (like Flathub, which is itself community-driven).
Performance and System Integration Issues
On a more practical level, users frequently report that Snap applications are noticeably slower than their native or even Flatpak counterparts. The initial startup time for a Snap can be frustratingly long as the system mounts the compressed application image and its dependencies.
Furthermore, Snaps can feel like alien applications on the desktop. They often fail to respect system-wide themes, leading to a jarringly inconsistent look. They also create numerous “loop” devices in the system’s mount list—a cosmetic but annoying side effect of how they are sandboxed. This lack of seamless integration makes the desktop experience feel less cohesive.
Forced, Uncontrollable Updates
Snaps update automatically in the background, and by default, the user has very little control over this process. While automatic updates can be good for security, the inability to defer or disable them is a major point of contention.
A forced update can break a user’s workflow if it introduces bugs or unwanted changes. It can also consume significant bandwidth at inconvenient times. For users who value control over their system—a core tenet of the Linux experience—this lack of agency is a deal-breaker.
Canonical’s Heavy Hand
Adding fuel to the fire is the perception that Canonical has been aggressively pushing Snaps onto its users. In Ubuntu, attempting to install certain applications like Firefox or Chromium using the traditional apt command will, by default, install the Snap version instead.
This move was seen by many as a betrayal of trust, overriding the user’s explicit command-line instructions. It led to a significant backlash and prompted distributions like Linux Mint to completely disable the Snap store by default.
A Solution in Search of a Problem?
While Snaps do solve real problems for developers, many users feel they create more problems than they solve. The combination of a proprietary backend, performance overhead, and a heavy-handed corporate push has alienated a large part of the community.
For many, the beauty of Linux lies in its choice and openness. In a world with excellent traditional package managers and a more open universal alternative in Flatpak, Snap often feels like an unnecessary and overly restrictive compromise.
