Snap or Flatpak on Linux: Why You Might Want to Avoid Them
If you use Ubuntu or one of its derivatives, you have likely come across Snap or Flatpak as convenient package formats for installing software. While they offer certain advantages—such as simplified dependency handling and the ability to sandbox applications—there are compelling arguments for why you might want to avoid using them. Below is an extensive discussion that delves into some of the concerns regarding Snap and Flatpak, particularly around security, performance, and the pitfalls of relying on large, static binaries.
1. Centralization and Vendor Lock-In
Snap: Controlled by Canonical
Snap is developed and maintained by Canonical, Ubuntu’s parent company. Critics argue that it centralizes application distribution too heavily, since by default, Snap is tied to the Ubuntu Store. This means that one entity can effectively control which packages appear, how they are updated, and under what policies. While official Ubuntu channels often cite “security benefits” and convenience, users seeking more openness sometimes find that Canonical’s centralized approach undermines the broader spirit of open-source distributions.
Flatpak: Freedesktop Initiative but Flathub-Centric
Flatpak, on the other hand, is sponsored by the Freedesktop organization and is somewhat more decentralized. However, in practice, many users end up relying on Flathub for the majority of Flatpak packages. If Flathub becomes the de facto single source, you end up with a similar type of centralization, though arguably less strict than Snap.
2. Security Concerns
Sandboxing Isn’t Foolproof
Both Snap and Flatpak utilize container-like sandboxing to isolate applications from the rest of the system, which in theory adds a layer of security. However, sandboxing alone does not eliminate all security risks. A flaw within the Snap or Flatpak runtime itself, or misconfiguration in the sandbox, can potentially allow attackers to exploit privileged code, especially if the distribution channels fail to vet each package properly.
Delayed Security Patches
Because Snap and Flatpak applications are often distributed with their own libraries, security patches that apply to a certain library may not be immediately propagated to every Snap or Flatpak containing that library. This introduces a lag between when a vulnerability is discovered in a shared library and when individual packages update their bundled dependencies. Traditional package management systems using shared libraries allow an update in one library to immediately secure all applications that depend on it.
3. Performance and Resource Overhead
Bigger Footprint
One of the defining aspects of Snap and Flatpak is that each application bundles the dependencies it needs. This results in larger disk usage because you potentially have multiple copies of the same library across different snaps or flatpaks. On a system with limited storage, these extra copies can quickly add up.
Extra Runtime Layers
Snap and Flatpak both require a runtime engine. This can lead to slower startup times, especially on lower-end hardware. Desktop applications packaged as snaps are often noted to start more slowly compared to their .deb equivalents, primarily because the system needs to mount the snap, launch the appropriate runtime, and then start the app.
4. Static Binaries and Patch Management
Why Static Linking Can Be Problematic
Many packages in Snap and Flatpak use static linking. While static linking simplifies portability by compiling all dependencies into the executable, it also means that every application includes its own copy of the libraries it needs. If a vulnerability is discovered in one of those libraries, each application must be individually rebuilt and updated. On traditional systems that rely on shared libraries, updating a single library can fix the vulnerability for every application that depends on it.
Missed or Late Security Updates
When every application depends on its own statically compiled dependencies, there is a higher risk that a maintainer might miss a critical update. Even if the update is eventually noticed, users are exposed until the developer pushes an updated version of the snap or flatpak.
5. Limited Integration With the System
Themability and Theme Support
Applications packaged as snaps or flatpaks may not always integrate seamlessly with your system themes, especially if they rely on a runtime or platform theme that isn’t aligned with the native environment. Users can experience odd-looking interfaces, missing icons, or inconsistent behavior compared to applications installed via the native package manager.
Lack of Advanced Configuration
Many power users rely on advanced configuration and custom patches, which can be more challenging to implement when software is packaged as a containerized unit. Traditional package managers integrate deeply into the system, making advanced customizations more straightforward.
6. Philosophical and Practical Considerations
Open-Source Philosophy
A key point of contention is whether Snap’s and Flatpak’s container-based distribution model aligns with the traditional open-source philosophy of shared resources and system transparency. Some developers and users prefer the transparency and “do one thing well” approach of native package managers (apt, dnf, pacman, etc.), arguing that containerized packaging is less aligned with Unix/Linux design principles.
Community vs. Corporate Control
The open-source community typically thrives on decentralized contribution. A format like Snap, which is heavily steered by Canonical, can feel more like a corporate endeavor than a community-driven one. Flatpak’s governance is more community-centric, but widespread reliance on Flathub still raises some questions about potential gatekeeping or policy enforcement.
7. Conclusion
Choosing whether to use Snap or Flatpak on Ubuntu or any of its derivatives is not a black-and-white decision; however, there are notable reasons to be cautious. Potential security delays caused by bundled libraries, the extra footprint, performance overhead, and centralization concerns are all valid criticisms. Static binaries can lead to outdated software if maintainers do not promptly rebuild packages with the latest security patches. While snaps and flatpaks are convenient, especially for newer Linux users or for those who value sandboxing and easy installs, more traditional package managers and shared libraries often provide a cleaner, more transparent solution with immediate, system-wide security updates.
If you prioritize tight system integration, immediate security patching for libraries, and a decentralized approach to package distribution, you may wish to rely on native .deb packages (or other traditional formats) instead of Snap or Flatpak. At the very least, being aware of the potential drawbacks will help you make a more informed decision about how best to install and maintain software on your Ubuntu-based system.