Snaps. Why? Please Stop
Linux users weigh the trade-offs between Canonical’s Snap packages and traditional distro-managed formats like .deb, Flatpak, AppImage, and Docker. Critics of Snap cite large disk footprints, performance issues, opaque and centralized infrastructure, and Ubuntu’s tendency to replace native packages (e.g., Firefox, Chromium) with snaps, while supporters argue that self-contained, auto-updating bundles reduce dependency hell and shift maintenance to upstream developers. The broader tension is over who should control packaging and updates—distributions or application vendors—and how to balance security, convenience, openness, and system resource constraints.
Age and context of discussion
- Thread centers on why Snaps exist and whether they’re a good idea, with many comparisons to Flatpak, AppImage, Docker, and traditional distro packaging.
- Several comments note the original forum post is from 2019–2021, but issues are still seen as relevant.
Disk space, storage, and performance
- Major concern: Snaps consume a lot of disk space due to bundling dependencies and retaining multiple versions per package.
- Examples: core and GNOME base snaps replicated across versions; small apps ballooning to hundreds of MB or more.
- This is viewed as especially problematic on cheap laptops with small, often non‑upgradeable storage.
- Some report snapd causing constant high CPU load and large logs.
Hardware upgradability debate
- One side claims “many laptops” now have soldered or eMMC storage, making space at a premium.
- Others argue these are still a minority and most laptops use easily replaceable SSDs.
- Extent of eMMC usage in consumer laptops is disputed and left essentially “unclear”.
Packaging models & developer burden
- Strong argument that traditional distro packaging doesn’t scale: expecting vendors to ship .deb/.rpm for every distro is unrealistic.
- Others counter that tools (e.g., Open Build Service) and standard build systems already make multi‑distro packaging manageable.
- Some argue packaging should remain a distro responsibility; others say it should be pushed upstream to app developers.
Perceived advantages of Snaps
- Cross‑distro packaging and easier distribution for commercial and third‑party software.
- Automatic updates and strict sandboxing are seen as big wins for servers and some self‑hosted services (e.g., Nextcloud).
- Some consider Snaps a better fit for “modern apps” with many dependencies, avoiding library conflicts.
Major criticisms of Snaps
- Forced use in Ubuntu (e.g., Firefox/Chromium via Snap even when installed with apt).
- Closed-source backend, hard‑coded Canonical store, and perceived centralization/gatekeeping.
- Large disk footprint, slow startup, multiple retained versions, and mount pollution with many loop devices.
- Integration/sandbox issues: trouble with VPN DNS, smart cards/YubiKey, CUPS, and other system resources.
- Some see Snap as “half‑baked Canonical tech” and an attempt to copy mobile/app‑store economics.
Flatpak, AppImage, Docker, Nix, etc.
- Flatpak is preferred by some for GUI apps; still reports of permission, theming, and runtime bloat issues, though improving.
- AppImage praised for simplicity, but lack of automatic updates is both a drawback and a feature depending on workflow.
- Docker/Podman often used instead for “bleeding edge” or server workloads.
- Nix/Guix and immutable distros mentioned as more principled alternatives for dependency control.
Traditional package managers & stability
- Several long‑time Debian/Ubuntu users say dependency hell is mostly a solved problem if you stay within official repos or use proper pinning.
- Others insist dependency hell still exists, especially with third‑party repos and PPAs.
- Some move away from Ubuntu (to Debian, Arch, Mint, Pop!_OS) mainly to avoid Snaps and Ubuntu’s extra tooling/ads.
- Ongoing tension: desire for stable, distro‑integrated packages vs “fix‑forward” mentality and rapid auto‑updates.