Clone this wiki locally
An AppImage is basically a self-mounting disk image that contains an application and everything the application needs to run on the target systems.
This pages compares various similar systems to AppImage. Of course, each system was build toward its own specific objectives. This page is intended illustrate the points that were important in the AppImage design, and similarities as well as differences to other systems.
"Revisiting How We Put Together Linux Systems"
Revisiting How We Put Together Linux Systems (Lennart Poettering)
In this frequently cited post, Lennart outlines the conceptual framework for a new way of distributing software, both in the system and the application layers.
We want an efficient way that allows vendors to package their software (regardless if just an app, or the whole OS) directly for the end user, and know the precise combination of libraries and packages it will operate with.
AppImage, in contrast, has a more concise scope: it is only concerned with (mainly add-on, third-party) applications intended to run on top of various base operating systems. In this regard, the AppImage concept resembles other successful desktop operating systems like Windows and OS X where there is a clear separation between a fixed set of what comes with the base operating system (system layer), and everything else that comes from third parties and runs on top of it (application layer). As of today, this model is still "owning" the desktop by far in terms of market share.
We want to allow end users and administrators to install these packages on their systems, regardless which distribution they have installed on it.
AppImages are also designed to run on top of various distributions, but they do not need to be installed.
We want a unified solution that ultimately can cover updates for full systems, OS containers, end user apps, programming ABIs, and more.
These are ambitious goals which significantly exceed the scope of AppImages. The AppImage format does not try to reinvent the world, but rather provide a simple solution for directly distributing upstream applications to as many end users as possible easily. (Although there is a sister project, SystemImageKit, that adds toward a "unified solution" (covering the system layer) which works today, albeit in a completely different way.
We want our images to be trustable (i.e. signed)
AppImages can be checksummed and signed, although this has not been implemented in AppImageKit so far.
we need to make sure we make distributions relevant again for all use-cases, not just those of highly individualized systems.
AppImage instead takes the distributions as a "black box" and provides a way "around them" for directly distributing applications to end users, rather than waiting for them.
Of course, we are developers of the systemd project. Implementing this scheme is not just a job for the systemd developers. This is a reinvention how distributions work, and hence needs great support from the distributions.
While technically way more sophisticated than AppImage in several ways, it is the "great support from the distributions" that would be required for this to happen which makes it interesting to see whether this will catch on.
Flatpak (renamed from "xdg-app")
GitHub (Alexander Larsson)
There are two main goals with this project. 1. We want to make it possible for 3rd parties to create and distribute applications that works on multiple distributions. 2. We want to run the applications with as little access as possible to the host. (For example user files or network access)
AppImageKit shares (and cares deeply about) #1, and is beginning to consider #2 as the infrastructure provided by the kernel and other parts of the system (like overlayfs, systemd, cgroups, namespaces, kdbus, etc.) fall into place.
Application deployment framework for desktop apps
While the name implies a cross desktop environment solution, current work seems to be mostly focused on GNOME as evidenced by the fact that its homepage seems to be https://wiki.gnome.org/Projects/SandboxedApps.
A runtime provides a well-defined environment that an app can run in. Examples would be "GNOME 3.14" or "KDE 5.6". A runtime can be thought of as a /usr filesystem with fixed contents. When a bundled app gets run, the runtime it needs gets mounted at /usr.
This means that in addition to the base operating system, a rootfs called the "runtime" is required. Unlike AppImages, which bundle all the dependencies that are not part of the base operating system, applications packaged for xdg-app bundle the dependencies that are not part of the Yocto-generated "runtime" rootfs. While this a very clean concept, this seems to be overkill for many scenarios in practice. Runtimes are MB-heavy. As this catches on, multiple runtime versions will be needed for the different runtimes, which will add to the storage requirements. Imagine you want the latest version of Firefox. But that requires a newer GTK runtime than what you currently have... All of this is not helped by the fact that the runtimes, like the applications, are not single files (like AppImages) but everything is spread out into individual files - so forget about easily downloading a file and putting it on a USB stick.
Downloads the individual parts of the apps (each file separately). While this is efficient, it creates the need for, well, not package but file-level management. So with xdg-app, you end up with 2 managers: one package manager in the base operating system and one "ostree manager" provided by xdg-app. In contrast, AppImages are designed to have no dependencies that are not part of the base operating system. So you do not need additional software to download and run them.
https://wiki.gnome.org/Projects/SandboxedApps/Sandbox describes the sandbox. Here is a quick overview of how this (supposedly) works: Essentially the
xdg-app-helper is a runtime that needs to be installed on the host system with elevated rights (e.g., suid - isn't this a bad idea?) that sets up a tmpfs for / and bind-mounts stuff into it (although without an overlayfs so far). All of this is done with CLONE_NEWFS ("unshared namespace") so that other processes on the system don't see this, only the app in question.
In contrast, AppImages are designed not to need root or suid helpers and have no dependencies beside the base operating system. But we can run AppImages inside the same sandbox that is also used by Flatpak: https://github.com/probonopd/AppImageKit/tree/master/sandbox
Also, Firejail has native AppImage support.
As of March 2016, xdg-app does not run on live systems which use tmpfs (like Ubuntu and Fedora Live ISOs). Bummer.
GitHub (Matthias Klumpp)
Limba provides developers with a way to easily create software bundles for their applications which run on multiple Linux distributions. It provides atomic upgrades of software, simultaneous installation of multiple software versions and a simple way to obtain and upgrade software. Limba is based on ideas of Glick2 and Listaller, and uses modern Linux kernel features to allow applications to share libraries and other components, reducing the amount of duplicate software components running on a Linux system.
Motivation: "Many of you know Lennart’s famous blogpost on how we put together Linux distributions. (...) The proposed solution, however, is not something which I am very excited about, at least not for the use-case of installing a simple application (...) the solution outlined by Lennart basically bypasses the distribution itself, instead of working together with it. This results in a duplication of installed libraries, making it harder to overview which versions of which software component are actually running on the system. (...) I wanted to explore a different approach of managing 3rd-party applications on Linux systems, which allows sharing as much code as possible between applications.
So unlike AppImage, Limba tailors software installations to the base operating system. In contrast to Limba, AppImage totally "bypasses the distribution itself, instead of working together with it".
Unlike AppImageKit, Limba allows applications to have dependencies to other packages. That creates the need for package management. So with Limba, you end up with 2 package managers: one in the base operating system and one provided by Limba. In contrast, AppImages are designed to have no dependencies that are not part of the base operating system. So you do not need a package manager to download and run them.
Limba uses OverlayFS to combine an application with its dependencies before running it, as well as mount namespaces and shared subtrees.
As cool as this is, it is not available and will not be for a while in mature distributions such as CentOS 6 and 7.
Since the software components are located in separate directories under /opt/software, an application will not automatically find its dependencies, or be able to locate its own files. Therefore, each application has to be run by a special tool, which merges the directory trees of the main application and it’s dependencies together using OverlayFS.
Unlike AppImages, application packaged for Limba cannot just be downloaded and run by the end user. Rather, the user has to install a runtime (the "special tool") first.
http://listaller.tenstral.net/ (Matthias Klumpp)
According to this announcement from 2014 "This project has been superseded by Limba".
Listaller unifies the way you manage software on your Linux distribution, by providing an user-friendly application-centered software manager GUI.
So unlike AppImage, this is a package manager. Unlike AppImageKit, Listaller allows applications to have dependencies to other packages. That creates the need for package management. So with Listaller, you end up with 2 package managers: one in the base operating system and one provided by Listaller. In contrast, AppImages are designed to have no dependencies that are not part of the base operating system. So you do not need a package manager to download and run them.
We also provide a software setup package format (IPK-packages)
And unlike AppImages, regular packages are uses that must be installed.
which works on all Linux distributions and provide tools to make your application-binaries work on every distro.
ligcc by Hongli Lai (also found in Ubuntu in the limba-licompile package) is similar to AppImageKit's LibcWrapGenerator - more investigation is needed. Probably nothing prevents you from using ligcc for building your application and then packaging it as an AppImage.
Unlike LibcWrapGenerator, ligcc also can enforce static linking for some or all libraries. This sounds interesting and should be further investigated.
Listaller supports relocation. (...) However, most applications are not relocatable. The paths where in they search for data files are usually hardcoded at compile time.
Listaller uses BinReloc (a component that was originally developed for Autopackage), an API that uses dynamic linker and kernel magic to find out the full path of an application or library. This means that the upstream application author has to specifically change the source code. While this is a clean solution, it is also additional work and mandates patching and recompiling the source code, which might not be an option, e.g., for closed source applications. ApppImageKit uses binary patching instead to replace hardcoded references to
/usr in the binary with the bundled equivalent inside AppImage. Nothing prevents you from using BinReloc in your application and then packaging it as an AppImage.
The package format is based on AppStream metadata.
AppImageKit is not yet using AppStream metadata but considering to do so.
You can publish your (signed) package anywhere on the web and have users install it using Listaller. Later, you might want to set-up and update-source for your software, so all users stay up-to-date.
Like AppImages, upstream application authors can host their apps for download without a central instance. But unlike AppImages, Listaller packages cannot simply be downloaded and run by end users; instead, end users have to install the Listaller runtime first.
There are 2 sample applications available for download. The applications are not packaged by the upstream application authors.
Now claimed by Canonical to be cross-distro, but appears to be mainly a frontend to a central App Store with Canonical as the gatekeeper and ubuntu-core as a required runtime. (Detailed analysis to be written) https://www.happyassassin.net/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/
(Mike Hearn, Jan Niklas Hasse)
According to this announcement from 2010 "Listaller and the Autopackage project will merge. Autopackage will be integrated into Listaller and we work with distributors on improving the IPK package format."
Zero Install is a decentralised cross-distribution software installation system.
Applications must be installed when using 0install. Also you need to install 0install on the target system before you can run applications distributed with 0install (i.e., installing a runtime is required). In contrast, you can just download and run AppImages.
0install does not define a new packaging format; unmodified tarballs or zip archives can be used. Instead, it defines an XML metadata format (...) A single metadata file can be used on multiple platforms (e.g. Ubuntu, Debian, Fedora, openSUSE, Mac OS X and Windows), assuming binary or source archives are available that work on those systems.
Like AppImageKit, it does not magically solve backward binary compatibility of shared libraries.
The XML file describing the program's requirements can also be included in a source-code repository, allowing full dependency handling for unreleased developer versions.
Unlike AppImageKit, 0install allows applications to have dependencies to other 0install packages. That creates the need for package management. So with 0install, you end up with 2 package managers: one in the base operating system and one provided by 0install. In contrast, AppImages are designed to have no dependencies that are not part of the base operating system. So you do not need a package manager to download and run them.
As well as being able to download and manage 0install packages, 0install also allows programs to depend on native packages from the user's distribution.
This means that unlike with AppImages, 0install packages are installed very specific to a given host system, and hence cannot be easily copied from one machine to another running a slightly different host system.
0install is written in OCaml
This choice of programming language makes it hard for contributors, since not many people are skilled in OCaml. AppImage is written in C with some surrounding code in bash and python, languages many more people understand.
Roadmap: Sandboxing - Provide better integration with sandboxing systems such as Rainbow, Plash or LXC.
Like AppImageKit, Sandboxing is not the default in 0install yet but is on the roadmap.
OS X, Windows
Unlinke AppImageKit, 0install also targets the OS X and Windows platforms.
There is a software catalog of roughly 70 applications packaged using 0install. The applications are not packaged by the upstream application authors.
Nix is a purely functional package manager.
Call me clueless, but I actually have no clue what that means.
This means that it treats packages like values in purely functional programming languages such as Haskell
The description reads like it is made by computer scientists for computer scientists. I still can't figure it out. But unlike AppImage, it is a package manager.
It provides atomic upgrades and rollbacks, side-by-side installation of multiple versions of a package, multi-user package management and easy setup of build environments.
That sounds good. Seems like it is a package manager that deals with source code. Similar to a compile environment like Yocto?
Lists 11,000 packages that are supposed to be easy to build. Possibly this can be used on CentOS 6 or older machines to create builds that run everywhere? But hey, even this impressive repository doesn't list the Subsurface app. How likely is it that it will ever be added? Could upstream do that on their own? Doesn't seem so.
bash <(curl https://nixos.org/nix/install ) # 67.1 M nix-env -i atom # installing ‘atom-1.4.3’ # these paths will be fetched (168.07 MiB download, 882.90 MiB unpacked): (...) ls /nix/store/ | wc -l # 1322
So in order to install the Atom app I can either download one 76 MB AppImage file, or 1.322 individual packages totaling 883 MB plus a 67 MB runtime. This feels like a distribution on top of a distribution. So probably Nix is a great system to build a distribution, but doesn't seem like a suitable tool to run a 3rd-party app on top of a distribution with minimal fuss.
It's a package manager. Not one app = one file.
RadioTux Magazin November 2016
German podcast RadioTux Magazin November 2016 summarizes the differences around 22:00:
AppImage: Relativ einfach - anklicken, geht.
Snap: Man muss sich erst was installieren, man muss sich irgendwie bei Ubuntu One anmelden, aber dann kann man etwas installieren, geht.
Flatpak: Ich muss erst mal Flatpak besorgen, dann muss ich mir die Repositories da hinzufügen, dann muss ich mir die GPG Keys holen, dann muss ich mir Runtimes runterladen, und dann kann ich irgendwie die Flats da rausholen, installieren und die Programme starten.
Sozusagen aufsteigend nach der Schwierigkeit.
AppImage: Relatively simple - click, runs.
Snap: You have to install something, you have to login somehow to Ubuntu One, but then you can install something, runs.
Flatpak: I need to get Flatpak first, then I have to add the repositories there, then I have to get the GPG keys, then I have to download Runtimes, and then I can somehow get the Flats out of there, install and start the programs.
So to say, ordered according to difficulty.
- Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS
- On Snappy and Flatpak: business as usual in the Canonical propaganda department
- http://www.valdyas.org/fading/index.cgi/2016/06/17 and comments on https://www.reddit.com/r/linux/comments/4oihga/appimages_snaps_xdgappswflatpaks/
- Antithesis: http://kmkeen.com/maintainers-matter/
- https://github.com/probonopd/AppImageKit/files/327061/evolution.pdf Caution: Might be humorous. Or not.