This article will list the main differences between these three packaging formats from end users’ perspective. Differences in packaging architecture and ease of packaging from developers’ point of view won’t be covered here.
The table below summarizes the main differences between Snap, Flatpak and AppImage file formats. Most of them are self-explanatory, other points have been explained below the comparison table.
| Snap | Flatpak | AppImage | |
| Android Like Permission Controls Toggles (GUI and CLI) | Yes | Yes | No |
| Sandboxing Support | Yes | Yes | Yes |
| Sandboxing Mandatory | Yes | Yes | No |
| Native Theme Support | Yes (with caveats) | Yes (with caveats) | Yes (with caveats) |
| Support for Bundled Libraries | Yes | Yes | Yes |
| App Portability | Yes (with caveats) | Yes (with caveats) | Yes |
| Fully Contained Single Executable Support (similar to .exe files in windows) | No | No | Yes |
| Online App Store | Yes | Yes | Yes |
| Plugins for Desktop App Store Software | Yes | Yes | No |
| Multi-version Parallel Apps Support | Yes | Yes | Yes |
| Automatic Updates | Yes | Yes | Yes (with caveats) |
| Chrome OS Support (through Crostini containers) | Yes | Yes | Yes |
| App Size | Varies but higher than AppImage | Varies but higher than AppImage | Lowest |
| Number of Apps Available in the App Store | Highest | Lowest | Somewhere in-between |
Permission Controls for Users
Snap provides both graphical and command line interfaces for user controlled permissions. You can use the preinstalled “Ubuntu Software” app to manage permissions of a snap app.
To see permissions of a snap app using command line interface, run the command below:
Replace “chromium” with the name of your snap app.
To see a list of all installed snap apps, run the command below:
To grant camera permission to chromium snap, use the command below:
To revoke the camera permission, run the command below:
Appropriate commands for permission management can be found in “Plug” column (shown in the screenshot above).
Flatpak also provides an interface for granting and revoking permissions. You can use GNOME Software app (requires GNOME 3.32.x) to manage permissions using a graphical method. To see permissions of a flatpak app, run the command below:
Replace “org.kde.Platform” with the name of your Flatpak app.
To view a list of all flatpak apps installed on your system, run the command below:
To change the permissions of a flatpak app, you have to change the values of variables shown in the screenshot above. For example, the command below will make entire filesystem available to a flappak app:
AppImage doesn’t support granular permission controls as of now, but developers have hinted that Android style permission controls may be implemented in the future.
Sandboxing
Snap, Flatpak and AppImage support sandboxed app environments out of the box. A sandbox is an environment (or container / filesystem / archive) that is completely isolated and aloof from the host system. Any interaction with host system is done using limited API and permission controls. Some of these permissions explicitly require opt-in by users or can be disabled completely by end users. A sandboxed app is secure than any other app that has full access to the host system. All Android apps run in a sandbox and these three packaging format work on similar idea.
Native Theme Support
All three packaging formats support native look and feel for GTK and Qt apps, albeit with some limitations. For instance, Snap and Flatpak require system themes to be packaged in their respective formats. If you are using third party themes and icons packs, you may not get correct theme, cursor and app icons. The integration has improved overtime but they slightly fall short in comparison with apps installed from official package manager of a distribution.
App Portability
An AppImage app is a single executable file (similar to Windows’ .exe files). You can easily share it between systems or upload to cloud. Snap and Flatpak apps can be made portable by including the app itself, as well as child repositories that the app depends upon. However, the process is not as easy as AppImage and requires using multiple commands to achieve the same results.
Automatic Updates
Snap and Flatpak apps are installed from centralized application repositories and apps can be automatically updated without user intervention. AppImage lacks a robust automatic update mechanism. Users have to manually download new AppImage binary and replace existing one to install updates. AppImage app maintainers sometimes include their own update mechanism that periodically checks updates availability on their servers or requires user intervention. Recently, AppImage developers provided a tool to update existing binaries by providing delta updates. However, it still requires downloading the update tool and manually using it with an existing AppImage binary. There is no hands-free update mechanism available for AppImage yet.
App Size
AppImage has lowest app size footprint, most probably because it serves binaries in compressed format. Snap and Flatpak app sizes vary greatly from app to app and it is difficult to ascertain which provides lower installation size. Just for reference, Inkscape AppImage at the time of writing this article was around 98 MB, Snap was around 183 MB and Flatpak was around 109 MB.
Conclusion
Universal app packages are a win-win situation for both developers and end users. These packaging formats allow much faster delivery of secure apps. They also open doors for developers who have been shying away from Linux because of different packaging standards used in different distributions. There are some issues that need to be ironed out in these three packaging formats. However, they all are under active development and these issues will be fixed overtime. Universal cross-distribution packages are the future and their adoption will increase. Slowly but steadily, distributions may move to Snap, Flatpak or AppImage builds in future except for core libraries and essential packages that are needed for the OS to work.
from Linux Hint https://ift.tt/2G5EN3a
0 Comments