Linux often gets a bad reputation when it comes to installing software, and this is because we have so many different application distribution formats. Most of them also are misunderstood, or have preconceived notions attached to them, so I think it’s time to take a look at the differences among the different packaging formats!

DEB and RPM Packages

The two most popular package formats are the DEB and RPM. Debian and derivative distros like Ubuntu use Debs, while Fedora, Red Hat, and OpenSUSE use RPMs. You can pull the Packages from their distribution’s repositories or installed them. They contain a pre-compiled or a binary version of the application or library you’re trying to install for your system’s architecture.

These packages come with a descriptive file with all the various libraries and other applications your program needs to run.

Since the DEB and RPM packages are pre-compiled for your architecture, they’re quicker to install. They pull all your dependencies immediately if they’re available. Since these packages are distro-specific, developers need to package their app for various distros, versions, and architectures.

Flatpaks

The Flatpak format is here to fix these problems. While Flatpaks come as binaries, so no compilation needed, they embark on all the libraries required in the package. They can use shared libraries provided in other Flatpaks.

Flatpaks are quick to install from repositories called remotes. The largest available repository is Flathub, which sources the most available Flatpak applications. They also provides an interface for granting and revoking permissions.

Flatpaks may introduce security issues: while Flatpaks sandboxes itself, they still can provide outdated libraries and can consume larger storage than their DEB and RPM relatives. Flatpaks can run on any distro that has the flatpak package installed and most distro’s software centers have added the flathub remote.

Snaps

Snaps have an interesting difference though: they can also ship server stuff. While Flatpaks focuses on graphical applications, snaps can contain pure command line packages. Another difference is that Snaps can be automatically updated without user intervention and can receive delta updates.

Snaps can also revert to the previous version. Snaps do have some problems though: first, they don’t make use of the system theme. Second, they can’t use external repositories: all snaps come through snapcraft, which is the “official” distribution center for these. Snaps also tend to be bigger, and slower to launch than Flatpaks or regular packages. Snaps can run on any distro that has access to snapd, the backend part of snaps.

AppImages

AppImages are yet another way to distribute applications in a single contained package. They use the “one app one file” method: AppImage ships all the files needed, and all the libraries as well, in a single file. An AppImage app is a single executable file (similar to Windows .exe files). They are not downloaded from a repo, but there is AppImage hub, a website that lists most if not all the available AppImages. AppImage has lowest app size footprint compared to Snaps and Flatpaks, most probably because it serves binaries in compressed format.

You can immediately start using them once they’re downloaded, regardless of the path on the system. No need to install runtimes, or shared components like Snaps or Flatpaks, you can put your AppImages anywhere and run it. This means that AppImages are super portable: to keep all your apps, you can copy/paste the AppImages and you’re good to go. This a big advantage, but there are some issues there as well. First, you can’t update an AppImages without downloading the new version yourself, much like apps on windows.

AppImages also don’t respect the system’s theme at all and can get pretty big, since they don’t make use of share runtimes at all. AppImages can run on any distro, they don’t need any specific plumbing to work. 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. They also don’t support granular permission controls.