Flatpaks consume significant disk space because they bundle all their dependencies, including libraries and runtimes, within each application. This avoids dependency conflicts but leads to redundancy, especially when multiple Flatpaks share common libraries. While deduplication efforts exist at the file system level with OSTree, and some shared runtimes are used, many applications still ship with their own unique copies of common dependencies. This "bundling everything" approach, while beneficial for consistent performance and cross-distribution compatibility, contributes to the larger storage footprint compared to traditional package managers that leverage shared system libraries. Furthermore, Flatpak stores multiple versions of the same application for rollback functionality, further increasing disk usage.
The article "Why Flatpak Apps Use So Much Disk Space on Linux" on OSTechnix explores the reasons behind the seemingly large disk space consumption of Flatpak applications compared to traditional Linux packages. It begins by acknowledging the user perception of Flatpak's disk usage, explaining that while a Flatpak application might appear to be significantly larger than its traditional counterpart, the reality is more nuanced.
The core of Flatpak's disk usage lies in its fundamental design principle: application isolation. Unlike traditional packages that often share libraries and dependencies system-wide, Flatpaks bundle almost everything an application needs to run within its own self-contained environment. This includes libraries, runtimes, and other dependencies, leading to a larger initial download and installation size. The article explains that while this approach appears redundant – having multiple copies of the same library on the system – it provides key benefits like enhanced security and stability by preventing conflicts between applications and the host system, and ensuring consistent execution across different Linux distributions.
The article then delves into the concept of runtimes, which are pre-built sets of common libraries bundled together. Applications built for the same runtime can share these libraries, thus minimizing redundancy and reducing overall disk space usage. This mechanism is analogous to a foundation upon which multiple applications can be built. While the initial download of a runtime can be substantial, subsequent applications utilizing that same runtime only need to download the application-specific components, minimizing the incremental disk space impact.
The concept of deduplication is also explained, highlighting that while multiple applications may install the same runtime or libraries, the underlying file system often employs mechanisms to avoid storing multiple physical copies of these identical files. Instead, hard links or similar techniques are used to point multiple applications to the same physical data blocks on the disk, significantly reducing the actual disk space consumed.
Furthermore, the article contrasts Flatpak's approach with traditional package managers, which often scatter dependencies across the file system. It argues that while Flatpak's self-contained bundles appear large, they actually offer a more organized and manageable approach to dependencies, simplifying updates and removal. With Flatpak, uninstalling an application removes all its associated files completely, leaving no orphaned dependencies behind, unlike traditional package management where leftover dependencies can accumulate over time.
Finally, the article touches on the trade-off between disk space and the benefits offered by Flatpaks. While acknowledging the larger initial download size, it emphasizes the advantages of isolation, security, cross-distribution compatibility, and cleaner application management, concluding that the extra disk space usage is often a reasonable price to pay for these benefits in the modern Linux ecosystem.
Summary of Comments ( 1 )
https://news.ycombinator.com/item?id=43887073
HN commenters generally agree that Flatpak's disk space usage is a valid concern, especially for users with limited storage. Several point out that the deduplication system, while theoretically efficient, doesn't always work as intended, leading to redundant libraries and inflated app sizes. Some suggest that the benefits of Flatpak, like sandboxing and consistent runtime environments, outweigh the storage costs, particularly for less experienced users. Others argue that alternative packaging formats like .deb or .rpm are more space-efficient and sufficient for most use cases. A few commenters mention potential solutions, such as improved deduplication or allowing users to share runtimes across different distributions, but acknowledge the complexity of implementing these changes. The lack of clear communication about Flatpak's disk usage and the absence of easy tools to manage it are also criticized.
The Hacker News post "Why Flatpak Apps Use So Much Disk Space on Linux" generated a robust discussion with several compelling comments. Many users chimed in with their perspectives and experiences regarding Flatpak disk usage.
A significant number of commenters agreed with the article's premise, noting the often-redundant nature of runtime dependencies leading to wasted space. Some users shared anecdotes of surprisingly large disk space consumption by seemingly small applications. The observation about separate runtimes for even minor version differences between dependencies was a recurring theme, with many echoing the frustration of having multiple copies of essentially the same libraries.
Several commenters delved into the tradeoffs inherent in Flatpak's design. While acknowledging the disk space issue, they highlighted the benefits of application isolation and predictable execution environments provided by Flatpak. The discussion touched upon the advantages of this approach for software distribution and maintenance, especially regarding dependency management and avoiding conflicts. Some argued that the disk space tradeoff is acceptable in exchange for the stability and ease of use Flatpak offers.
Some users offered potential solutions and mitigating factors. The potential for deduplication of runtime files was mentioned, as was the relatively low cost of storage these days. Others suggested that the issue might be less pronounced with more widespread adoption of Flatpak, as more applications would share common runtimes.
A few commenters compared Flatpak to other packaging formats like Snaps, drawing parallels and highlighting differences in their approaches to dependency management and disk usage. The relative merits and drawbacks of each system were debated, with no clear consensus emerging.
A smaller subset of the comments questioned the article's methodology or argued that the issue was exaggerated. They pointed out that the disk space used by runtimes is often shared between multiple applications, mitigating the overall impact. Others suggested that the article focused on extreme cases and didn't represent typical Flatpak usage.