Snap: The Hated Technology That Saved Linux Software Distribution
This article analyzes Snap's origins to solve dependency hell and fragmentation, details Ubuntu's controversial implementation choices that alienated users, compares Flatpak's community-driven approach with shared runtimes and open governance, and concludes that both technologies now serve distinct niches—Snap for servers/IoT, Flatpak for desktop apps, and traditional packages for system components.
1. The Problem Snap Set Out to Solve (2014)
Linux software distribution has long suffered from three core problems:
Dependency Hell : Traditional .deb (Ubuntu/Debian) and .rpm (Fedora/RHEL) packages declare dependencies but do not bundle them. Installing an application requires all declared libraries to be present at compatible versions. Version conflicts produce errors such as 依赖: libssl3 (>= 3.0) 但是 1.1.1 正要被安装.
Distro Lock-in : The same application (e.g., Firefox) must be packaged separately for each distribution release because underlying library versions differ. Developers bear high maintenance costs; users often receive outdated versions from distro repositories.
Canonical's Maintenance Burden : For Chromium, Canonical had to maintain a separate package for every Ubuntu release because library incompatibilities prevented a single binary from working across versions.
Snap's core idea: bundle an application with all its dependencies into a single self-contained compressed image, enabling one build to run everywhere.
Technical implementation: A Snap is a SquashFS compressed image containing binaries, libraries, and runtime. It runs inside a sandbox hardened by AppArmor + seccomp, managed by the snapd daemon which handles installation, updates, and rollbacks.
This design genuinely solves the three problems: dependencies ship with the app (no dependency hell), the same Snap runs on any distro (cross-distro), sandboxing improves security, and automatic updates with one-click rollback protect against broken upgrades.
2. Why Users Resent Ubuntu's Execution
The backlash centers on how Snap was deployed, not why . Seven concrete pain points:
Visible cold-start latency : Each launch mounts the SquashFS image. Firefox cold start: ~1.2 s (native deb) vs ~3.5–4 s (Snap). The gap is especially noticeable on older hardware.
Mandatory automatic updates with no off switch : snapd checks for updates up to four times daily. The only control is snap refresh --hold to delay. After 14 days of continuous runtime, snapd forcibly terminates the process to apply updates — unacceptable for servers.
Bloated disk usage : Every Snap bundles a full dependency set even when identical libraries exist on the system. Two retained revisions for rollback multiply consumption; dozens of apps can consume tens of gigabytes.
df -h output pollution : Each mounted Snap appears as a /dev/loopN device, cluttering disk-usage listings.
Poor desktop integration : Strict sandboxing often prevents Snap apps from respecting system themes, cursors, and icons.
Closed, centralized store : The Snap client is open source, but the Snap Store backend is proprietary and operated solely by Canonical. Third-party repositories are not officially supported — a "walled garden" contrary to Linux's decentralized ethos.
Silent replacement of deb packages : Since Ubuntu 19.10, apt install chromium-browser delivers a Snap; since 22.04, Firefox defaults to Snap. Users typing familiar apt commands receive a Snap wrapper without explicit consent.
Points 2, 6, and 7 share a common thread: they remove user control — the value Linux veterans prize most.
3. Flatpak's Divergent Approach
Flatpak (led by Red Hat and GNOME) targets the same goals — sandboxed, cross-distro app distribution — but with opposite governance:
Open store & decentralized repos : Flathub is open-source and community-governed; anyone can add remotes or self-host.
Shared runtimes via OSTree : Instead of per-app duplication, Flatpak uses common runtimes (e.g., org.gnome.Platform ~800 MB). Ten GNOME apps share one runtime; OSTree provides content-addressed deduplication.
Portals permission model : Access to files, camera, microphone is granted via system dialogs at runtime, not through manual interface connections ( snap connections).
Incremental updates : Delta downloads (5–50 MB) vs. Snap's full-image re-download (50–300 MB).
Cross-distro sandbox : Bubblewrap + Portals work on any distribution; Snap's AppArmor profiles are Ubuntu-specific.
Ecosystem traction : By late 2025, Flathub surpassed 5 billion cumulative downloads and 3,400+ applications. Major upstream projects (GIMP, LibreOffice, Inkscape, OBS, Blender) now publish official Flatpaks maintained by their own developers.
Performance comparison (Firefox cold start): Snap ~4.1 s, Flatpak ~2.4 s.
4. Nuanced Reality: Neither Is Perfect
Snap's irreplaceable niche: servers and IoT . Flatpak is designed for desktop GUI apps. Snap excels at system-level services and daemons: snap install lxd, snap install microk8s, snap install multipass. Ubuntu Core (Canonical's IoT OS) is built entirely on Snap — automatic updates and strict confinement are exactly what embedded devices need. Snap's focus shifted from desktop to server/edge years ago.
Flatpak's shortcomings : Manual updates (less friendly to novices), similar theming friction, sandbox permission issues for certain system integrations, and virtually no support for server/CLI tools.
Debunking a rumor : Claims that Ubuntu 26.04 LTS will drop Snap are false. 26.04 still defaults to Snap for Firefox, Thunderbird, and Chromium. The change is that App Center gains the ability to manage deb packages — a concession, not an abandonment.
5. 2026 Landscape: Coexistence by Use Case
The fiercest "Snap wars" have cooled. Mozilla now offers an official Firefox .deb PPA; Google Chrome remains .deb; Chromium is available via community PPAs and Flathub. Users can pin deb versions and avoid Snap entirely.
A pragmatic three-way split has emerged:
Server / IoT / system services → Snap (near-unique fit)
Desktop GUI applications → Flathub (upstream-maintained, better integration)
Core system components & tools needing deep integration → traditional apt / deb All three can coexist on a single Ubuntu desktop.
6. Practical Guidance by User Profile
Beginners : Stick with Snap. Ubuntu works out of the box; automatic updates are a feature, not a bug. Re-evaluate only when a concrete problem appears.
Power users (care about startup speed, disk, control) : Prefer Flatpak from Flathub for desktop apps, manage permissions with Flatseal, switch Firefox to Mozilla's official .deb. Running sudo apt remove --purge snapd yields a quieter system.
Server operators / developers : Embrace Snap for lxd, microk8s, etc. Automatic updates and rollback outweigh the few seconds of cold-start overhead. Don't project desktop frustrations onto server workloads.
7. One-Sentence Summary
Snap is criticized because it uses forced, closed, centralized methods to solve a real problem; Flatpak solves the same problem with open, community-driven, optional methods — and won the community's trust.
Understanding this distinction prevents simplistic "Snap out of Linux" slogans. The controversy Snap sparked forced Linux software distribution to evolve to its current, more mature state.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Ubuntu
Focused on Ubuntu/Linux tech sharing, offering the latest news, practical tools, beginner tutorials, and problem solutions. Connecting open-source enthusiasts to build a Linux learning community. Join our QQ group or channel for discussion!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
