The Sandboxed Application Model
Chapter 9
Other Package Managers Overview
Snap, Flatpak, and pacman — a different philosophy of packaging, and when each genuinely makes sense over apt/dnf
Chapters 2-8 covered the traditional model — apt and dnf, both installing system packages that share libraries with the rest of the OS. A newer generation of tools takes a genuinely different approach: bundling an application with its own dependencies, isolated from the rest of the system.
The Sandboxed Application Model
Two genuinely incompatible versions of the same library, coexisting peacefully — exactly the dependency conflict scenario from Chapter 8, structurally impossible here
Snap (Canonical/Ubuntu)
$ sudo snap install spotify
$ snap list
$ sudo snap remove spotify
$ snap list
$ sudo snap remove spotify
Developed by Canonical, deeply integrated into Ubuntu by default — automatic background updates, built-in sandboxing/permission system, and its own centralised store (the Snap Store).
Flatpak (Community/Red Hat-Backed)
$ # Typically needs Flathub added as a remote first
$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
$ flatpak install flathub com.spotify.Client
$ flatpak list
$ flatpak uninstall com.spotify.Client
$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
$ flatpak install flathub com.spotify.Client
$ flatpak list
$ flatpak uninstall com.spotify.Client
Distribution-agnostic by design — works essentially identically on Fedora, Debian, Ubuntu, Arch, and most other Linux distributions, with Flathub as the dominant central app store, similar in role to Snap's own store.
pacman (Arch Linux)
$ # Arch's own traditional (non-sandboxed) package manager — closer in spirit to apt/dnf
$ sudo pacman -S nginx # install
$ sudo pacman -R nginx # remove
$ sudo pacman -Syu # sync repos and upgrade everything
$ sudo pacman -S nginx # install
$ sudo pacman -R nginx # remove
$ sudo pacman -Syu # sync repos and upgrade everything
pacman is genuinely a different category from snap/flatpak — included here for completeness
Unlike Snap and Flatpak's sandboxed-bundle philosophy, pacman is a traditional system package manager, conceptually much closer to apt/dnf — shared system libraries, no sandboxing by default. It's covered here purely because Arch is common enough to be worth recognising, not because it shares the sandboxing model the rest of this chapter focuses on.
Comparing the Sandboxed Approaches
📦 snap
Background auto-updates by default; strong Ubuntu integration; some reports of slower startup times for sandboxed apps due to the compression format used.
📐 flatpak
Distribution-agnostic; Flathub has a genuinely large catalogue; updates are user-triggered by default rather than automatic background updates.
When Sandboxed Packages Genuinely Make Sense
| Situation | Use |
|---|---|
| A specific app's official repo package is genuinely outdated | Snap/Flatpak often has a much newer version maintained directly by the app's developer |
| Two apps need genuinely incompatible library versions | Sandboxing sidesteps the conflict structurally — exactly Chapter 8's conflict problem, avoided |
| Day-to-day system tools, services, server software | Stick with apt/dnf — better integration, no sandboxing overhead, the tools this whole course is built around |
| A desktop app you want tightly system-integrated | The native distro package, if available and current, usually integrates more smoothly than a sandboxed equivalent |
Sandboxed packages trade some integration and disk space for isolation
Because each bundle includes its own copies of shared libraries rather than using the system's, total disk usage across several sandboxed apps is generally higher than the equivalent traditional packages — and desktop integration (themes, file dialogs, notification styling) is sometimes subtly less seamless. A reasonable, deliberate trade-off for specific apps, not a wholesale replacement for apt/dnf on a server or for core system tools.
Chapter 9 Quick Reference
- Snap/Flatpak — bundle an app with its own dependencies, sandboxed, structurally avoiding Chapter 8's dependency-conflict problem
- snap install/remove/list — Canonical's tool, deep Ubuntu integration, auto-updates by default
- flatpak install/uninstall/list — distribution-agnostic, Flathub as the dominant store, user-triggered updates by default
- pacman — Arch's traditional (non-sandboxed) package manager; conceptually closer to apt/dnf than to snap/flatpak
- Use sandboxed packages for: outdated repo versions, genuine library conflicts; stick with apt/dnf for system tools and servers
- Trade-off: isolation and version freedom, at the cost of disk space and sometimes slightly less integration
- Next chapter (final): practical workflows — auditing installed packages, cleaning up unused dependencies, keeping systems updated safely