Similar projects
Note: Please feel free to contribute to this page if you discover inaccuracies.
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 page compares various similar systems to AppImage. Of course, each system was built toward its own specific objectives. This page is intended to illustrate the points that were important in the AppImage design, and similarities as well as differences to other systems.
The AppImage format is popular with users due to its simplicity (download one file, run it, done) and with developers (one Linux file that runs on all distributions).
The purpose of this table is not to show that AppImage is "better" than the other solutions. The point is to show that while similar in some aspects, there are still fundamental differences in objectives, scope, and features that justify the co-existence of AppImage with the other solutions.
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Package desktop GUI apps | ✅ Yes | ✅ Yes | ✅ Yes |
| Package terminal CLI tools | ✅ Yes | ✅ Yes | ✅ Yes (with App ID aliases if you edit PATH)[1] |
| Package server processes | ✅ Yes | ✅ Yes | |
| Package system services | ❌ No | ✅ Yes [1] | ❌ No |
| Package kernels | ❌ No | ✅ Yes [1] | ❌ No |
| Correct Application Theming | ✅ Yes (if done correctly) | ✅ Yes (if the current system theme has been Snapped) [1] | ✅ Yes (if current system theme has been Flatpak'ed) [1] [2] [3] |
| Using libraries and dependencies | From base system or bundled with appimage | From base system, base snap, platform snap (KDE, GNOME, Wine, ..) or bundled with Snap | From Freedesktop, GNOME, KDE main runtimes or bundled with Flatpak |
| Corporate backing | ❌ No (Community project) | ✅ Yes (Canonical) | ✅ Yes (Endless, Red Hat) |
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Number of applications in main store | +1300 (2021-10-06 [1] history) | +6600 (20212-01-16 [1]) | +1400 (2022-01-16[1]) |
| Brand-name commercial application vendors using the format | Adobe, IBM, KDAB, Microsoft, Prusa, Ultimaker, ... | Microsoft, Spotify, Slack, JetBrains, Skype, nodesource, ... | Xamarin, Codethink, Igalia, ... |
| Built into third-party application development tools | electron-builder | electron-builder, GNOME Builder | GNOME Builder |
AppImage Download from site, then drag-and-drop a single file in the file manager to desired installation location.
Snap
Install via distribution app store (supported out of the box on Ubuntu, Zorin OS, KDE Neon, ..) or via CLI:
$ snap install gimp
Flatpak
Install via distribution app store (supported out of the box on Fedora, EndlessOS, ..) or via CLI:
$ flatpak install --user flathub org.gimp.GIMP
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Can run without sandboxing | ✅ Yes (Not required. Optional to the packager.) | ✅ Yes (if snap was built and approved to use 'classic' confinement) [1] [2] | ❌ No (Limiting application access's by design) |
| Can be used with different sandboxes | ✅ Yes (e.g. Firejail [1], AppArmor [2], Bubblewrap) | ❌ No (is tightly coupled to AppArmor) | ❌ No (is tightly coupled to Bubblewrap) |
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Can run without installation | ✅ Yes (after setting the executable bit) | ❌ No (needs to be installed by snapd) | ❌ No (needs to be installed by Flatpak client-side tools) |
| Can run without root access | ✅ Yes | ||
| Run from compressed source and not unpacked | ✅ Yes | ✅ Yes | ❌ No |
| Application authors can place downloadable file next to .exe (Windows) and .dmg (macOS) which users can install on offline systems | ✅ Yes (.appimage - contains all that is needed to run the application on an offline system) | ❌ No (.snap - requires snapd to be installed and the system must be online if additional snaps are required) | ❌ No (.flatpakref files require Internet, .flatpak bundles require a runtime to be installed) |
| Allows application authors to self-host application with no functionality loss | ✅ Yes | ❌ No | ✅ Yes [1] |
| Suitable/optimized for air-gapped (offline) machines (the kind Ed Snowden uses) | ✅ Yes | ✅ Yes (You can side-load apps and updates offline) | ✅ Yes (P2P support allows offline installs and updates) |
| Can store and run applications from non-standard locations such as network shares, CD-ROM, etc. | ✅ Yes | tbd | ✅ Yes (requires configuration) [1] |
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Central Repo / Directory | AppImageHub | Snap Store | FlatHub |
| Fully decentralized without central gatekeepers | ✅ Yes | ❌ No (one dominant app store) [1] | ✅ Yes |
| Individual App Repositories | ❌ No (not stored in repositories) | ❌ No (you can only have one repo per device) | ✅ Yes |
| Can have multiple versions in parallel (including historical ones) | ✅ Yes (unlimited number of arbitrary versions) | ✅ Yes (one per channel) | ✅ Yes (any version available in OSTree can be installed in parallel) |
| Once the application is installed, it still can be easily copied to another machine (e.g., share with a friend locally) | ✅ Yes (one app=one file; there is no “installation” so the app is in the same form at all times) | ✅ Yes (but also need to copy snaps it depends on) | ✅ Yes (you can use flatpak create-usb to copy to USB drive) |
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Update mechanism | AppImageUpdate | From Repo | From Repo |
| Binary delta updates | ✅ Yes (using zsync with no need to generate deltas in advance) | ✅ Yes (Only if using a private server-side service that needs to generate the deltas) | ✅ Yes (using OSTree to provide atomic updates) |
| Applications can be self-updating | ✅ Yes (using embedded information) | ✅ Yes | ✅ Yes |
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Earliest Ubuntu Supported | Ubuntu 10.04 | Ubuntu 14.04 | Ubuntu 16.04 |
| Earliest OpenSUSE Supported | OpenSUSE 11.3 | Leap 42.2 | Leap 42.1 |
| Earliest Fedora Supported | Fedora 12 | Fedora 24 | Fedora 23 |
| Earliest Debian Supported | Debian 6 | Debian 9 | Debian 9 |
| Earliest CentOS Supported | CentOS 6 | CentOS 7.6 | CentOS 7 |
| Runs on Ubuntu out-of-the-box | ✅ Yes | ✅ Yes | ❌ No |
| Runs on OpenSUSE out-of-the-box | ✅ Yes | ❌ No | tbc |
| Runs on Fedora out-of-the-box | ✅ Yes | ❌ No | ✅ Yes |
| Runs on Debian out-of-the-box | ✅ Yes | ❌ No | tbc |
| Runs on CentOS out-of-the-box | ✅ Yes | ❌ No | ✅ Yes |
| Live systems (e.g., Live ISO, Live USB, Live CD, Live network boot) | ✅ Full | ||
| Can run on Chrome OS (Crostini) | ✅ Yes (Chrome OS 73) | ✅ Yes (Chrome OS 73) | ✅ Yes |
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Independent from any particular distribution maker | ✅ Yes (a community project) | ❌ No (a Canonical initiative) | ✅ Yes (a community project) |
| Not linked to any dominant company’s business case | ✅ Yes | ❌ No (central to Canonical’s business) | ❌ No |
| Made to decrease distributions’ influence on the desktop Linux ecosystem as central gatekeepers | ✅ Yes | ❌ No | ✅ Yes (Everyone can host his / her own repo) |
| Made to empower application developers and end users | ✅ Yes | ✅ Yes [1] | ✅ Yes [1] |
| Working to unify the Desktop Linux Platform rather than continuing to split the user base into different distribution ecosystems | ✅ Yes (by pointing out the core issues that need to be solved together) | ❌ No (effectively placing another distribution's base snap over the underlying distribution) | ❌ No (effectively placing a Yocto distribution over whatever underlying distribution) |
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Application storage on disk remains compressed at all times | ✅ yes | ✅ yes | ❌ No (server-side is compressed, client-side is not) [1] |
| Applications use much less disk space than "traditionally installed" ones | ✅ yes | ✅ yes | tbd |
| Example: LibreOffice download size (source) | ~248 MByte | 463 MByte [July 2020 update] | 543 MByte |
| Before downloading, know exactly the size to be downloaded and stored on disk | ✅ Yes (One app = one file) | ❌ No [Does not take platform snaps into account [1]] | ❌ Can only estimate worst case due to de-duplication |
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| LibreOffice start time (source) | 3 seconds | 13 seconds | 7 seconds |
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| File format is standardized through an official standards body | ❌ No (but interested in it once the format is stabilized) | ✅ Yes (Created by the Snap format TOB[1]) | ❌ No (although experimental OCI support exists) |
| Conceptually inspired by | macOS .app inside .dmg (tracing back to NeXT); Rox AppDir | Click (Ubuntu Touch packages) | klik (former name of AppImage) |
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Contributors do not need to sign a CLA | ✅ Yes | ❌ No | ✅ Yes |
| Developed since | 2004 (then called klik) | 2010 (predecessor called Click Packages) | 2013 (predecessors called Glick Glick2, and xdg-app) |
The closer equivalent to NeXTStep's application bundle format would be an application directory, which according to Wikipedia dates back to RISC OS from 1987; so at the point of this writing more like 30 years ago. Which shows that the concept here is far from "new" and apparently something people have been thinking about for a very long time already.
Conceptually, an AppImage is more like a ".app inside a self-mounting and self-executing .dmg", that is an application directory (following the ROX AppDir specification) inside a self-mounting filesystem image.
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.
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.
ostree
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.
Sandbox
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.
As of February 2018, Flatpak is not installed by default on Ubuntu. It has to be installed manually by the user with sudo apt install flatpak before it can be utilized.
This is the user experience on a freshly booted ubuntu-17.10-desktop-amd64.iso.
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 older distribution releases such as CentOS 6.
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. AppImageKit 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.
(Canonical)
Snap is a cross-distro packaging format created by Canonical. Packages are hosted on Canonical's Snap Store.
Snaps run in a sandbox with access to a base snap for core libraries like glibc and access to optional "Platform snaps" for frameworks like KDE, GTK and Wine. "Classic" confined applications also have access to the host system this is commonly used for development tools such as IDE's so they can use compilers from the host system.
Snap is designed so each device only connects to a single store, although anyone can run such a store.
The main Snap Store is not curated: anyone can publish any application in the Snap Store. Applications only get limited access to the host system by default, however. Publishers can ask users for additional permissions or go through a formal process to get more permissions by default. Regardless of the sandbox, Canonical advises to only install snaps from publishers you trust.
In contrast to Snap, AppImage is designed as a de-central system which gives all the power to application authors and end users, with no central intermediaries in between.
(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."
0install homepage | GitHub (Thomas Leonhard, Bastian Eicher et al.)
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, and subsurface is listed here. Installing Atom:
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.
Turns out it can be a great way to generate AppImages that bundle everything, starting with ld-linux.so and abovem, thus making AppImages that truly run on every Linux machine.
http://www.ocsmag.com/2016/07/05/guix-the-non-aligned-universal-package-manager/
It's a package manager. Not one app = one file.
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.
English translation:
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.
NOTE: Logging into Ubuntu One is no longer required as of Q4/2017 (and has not been for a while); apparently this was a bug at the time of the review.
- https://www.reddit.com/r/linux/comments/4ohvur/nix_vs_snap_vs_flatpak_what_are_the_differences/
- 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/
- https://plus.google.com/+DirkHohndel/posts/cFZLu9bEGx2
- Antithesis: http://kmkeen.com/maintainers-matter/
- c't Linux 2017: Praxis und Root-Know-How für den Linux-Alltag (German) https://books.google.de/books?id=mOmNDQAAQBAJ&pg=PA20&dq=appimage#v=onepage&q=appimage&f=false
- https://github.com/probonopd/AppImageKit/files/327061/evolution.pdf Caution: Might be humorous. Or not.