Ceci est une ancienne révision du document !
Recently, an article on the OMGUbuntu! website (https://www.omgubuntu.co.uk/2018/02/next-gen-kdenlive-beta-available-testing) lead me to test the newest version of the Kdenlive video editor. What intrigued me was not the application itself - which does work quite well, though with some rough edges as can be expected in a beta version - but the mode of delivery and installation: an AppImage file. This portable format for GNU/Linux applications is promoted as a simpler way of distributing applications to end-users. A program in the AppImage format should: • Run as-is on any GNU/Linux platform, as long as the distribution supports it. Most major modern distributions do so. • Be installable by an end-user, without any need to invoke administrative privileges. • Be downloadable directly from any web server, without needing to configure repositories or a PPA systemwide.
Un récent article sur le site Web d'OMGUbuntu! (https://www.omgubuntu.co.uk/2018/02/next-gen-kdenlive-beta-available-testing) m'a conduit à tester la toute nouvelle version de l'éditeur vidéo Hdenlive. Ce qui m'intrguait n'était pas l'application elle-même - qui fonctionne plutôt bien, malgré quelques points durs comme on peut s'y attendre avec une version bêta - mais le mode de livraison et d'installation : un fichier AppImage.
Ce format portable pour les applications GNU/Linux est présenté comme la solution la plus simple de distribuer des applications aux utilisateurs finaux. Un programme au format AppImage pourrait : • Tourner tel quel sur n'importe quelle plateforme GNU/Linux, pour autant que la distribution le supporte. La plupart des principales distributions modernes le font. • Être installable par l'utilisateur final, sans aucun besoin d'invoquer des privilèges administratifs. • Être téléchargeable directement de n'importe quel serveur Web, sans avoir besoin de configurer des dépôts ou un PPA à l'échelle de tout le système.
This is, precisely, what happened with the Kdenlive application. Installing it was simply a question of downloading the file to my desktop. It came in the form of a compressed file system with all necessary dependencies included. I then needed to change access permissions to make the file executable, and could then run it directly without dealing with any complex installation procedures. This got me to thinking about application creation. Many developers need to distribute applications to a reduced subset of users, for instance when a business program is written in-house and not shared outside of the company or organization. It may also be of interest to people who are yet in an early stage of application development, or in situations where several concurrent versions of an application need to coexist. This was precisely my personal use-case for Kdenlive: I wished to try out the newer version, but without uninstalling or affecting in any way, my existing version (that came from the Ubuntu repositories). Other projects are expressing interest in this technique, such as LibreOffice which has released an AppImage version of LibreOffice 6 that can easily be installed and run alongside an existing 5 series.
C'est précisément ce qui arrive à l'application Kdenlive. L'installer est une simple question de téléchargement du fichier sur mon ordinateur. Elle arrive sous la forme d'un système de fichiers compressés comprenant toutes les dépendances nécessaires. Ensuite, j'ai eu besoin de changer les permissions d'accès pour rendre le fichier exécutable ; puis, j'ai pu la lancer directement sans aucune procédure complexe d'installation.
Ceci m'a fait réfléchir à la création d'une application. Beaucoup de développeurs ont besoin de distribuer leurs applications à un ensemble réduit d'utilisateurs, par exemple, quand quand un programme professionnel est écrit en interne et n'est pas distribué à l'extérieur de l'entreprise ou de l'organisation. Ça peut aussi avoir de l'intérêt pour pour les gens qui sont à un stage précoce du développement d'une application, ou dans des situations où plusieurs versions concurrentes d'une applications doivent coexister. Ceci est précisément mon cas pour Kdenlive : je souhaitais essayer une version plus récente, mais sans désinstaller ou affecter d'une quelconque manière ma version existante ( qui venait des dépôts d'Ubuntu). D'autres projets expriment leur intérêt pour cette technique, comme LibreOffice qui a publié une version AppImage de LibreOffice 6 qui peut facilement être installée et tourner en parallèle de toute version 5 existante.
In a sense, the AppImage file format and distribution mechanism mimic that of Apple’s Mac OS and the .DMG files often used therein. One of that system’s strong points is, precisely, ease of use. To create an AppImage application, as far as I could see, just about any programming language available on a GNU/Linux system could conceivably be used, whether compiled or interpreted. Even an existing application in binary form – of which the source code may not be easily found or modified – could be repackaged as an AppImage file. One just needs the appropriate software to convert the application into the necessary file format. Obtaining this software is really easy. One just needs to follow the instructions in the README file in the project’s GitHub page, at: https://github.com/AppImage/AppImageKit/blob/appimagetool/master/README.md . It is quite apt that the AppImage software is distributed as an AppImage file. Of course it is! At the time of writing, the steps are as follows. Start by downloading the software: $ wget “https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage” Now make this file executable: $ chmod 755 appimagetool-x86_64.AppImage And it can be executed directly: $ ./appimagetool-x86_64.AppImage –version appimagetool, continuous build (commit continuous-2-g09dfd37), build 1460 built on 2018-02-17 22:55:22 UTC
To create a sample application, I started out by creating a directory tree, and populating it with my files. This directory structure seems to have been heavily inspired by the ROX file and desktop managers. $ mkdir HelloWorld.AppDir $ cp terminal.png HelloWorld.AppDir/helloworld.png $ editor HelloWorld.AppDir/AppRun $ editor HelloWorld.AppDir/helloworld.desktop At least three of these files are required. The PNG image file will be the application icon. In this case, I simply repurposed a spurious image file that was lying around on my computer. The Desktop file needs some care, since it gives the system metadata about the application. For this example, I included the following code: [Desktop Entry] Version=1.0 Type=Application Name=HelloWorld TryExec=helloworld Exec=helloworld %F Icon=helloworld
Finally, the AppRun file should be made executable. This is a boot script that will be used whenever the user executes the AppImage file, to launch the actual application. For this example, I wrote a very simple shell script: #!/bin/bash echo “Hello, world!” I could then create the AppImage files for either my default 64-bit architecture, or for 32-bit. Unfortunately, the current version of appimagetool is still a bit lacking in features, and cross-compiling is not supported, e.g. of a 32-bit application on a 64-bit computer. You will need to prepare the AppImage file for each architecture on a platform with that architecture. So, either: $ export ARCH=x86_64 ; ./appimagetool-x86_64.AppImage HelloWorld.AppDir or: $ export ARCH=i386 ; ./appimagetool-x86_64.AppImage HelloWorld.AppDir
Regarding system compatibility, as-is natural AppImage applications compiled for 32-bit architectures will run both on 32-bit systems compiled for an i386 (or today, rather, an i686), and on 64-bit systems compiled for the amd64 architecture: $ ./HelloWorld-i386.AppImage Hello, world! $ ./HelloWorld-x86_64.AppImage Hello, world!
A more complex example could involve, for instance, a graphical application written in Python. One easy way of launching the application would be to simply replace the AppRun script file with our Python app, beginning with the correct invocation header. For instance, if using Python version 3 and the Gtk libraries, this could become: #!/usr/bin/python3 import gi gi.require_version('Gtk', '3.0') from gi.repository import Gtk class MyWindow(Gtk.Window): … I built a very simple application, packaged it as a 64-bit AppImage file, and then ran it under Linux Mint 18.3 (above). I then repackaged the very same AppImage for a 32-bit system, downloaded and executed it from a Fedora 26 Live CD. The conversion to AppImage was actually done from within the Fedora VirtualBox instance itself (below).
This very same AppImage also worked straight away on a rather old version of Elementary OS (Freya, built upon Ubuntu Trusty and shown right). Naturally, using such a technical solution requires that both Python 3 and Gtk are installed on the user’s system. This is not much of a problem since this would be the case on most if not all current GNU/Linux systems. If it is not so, they must be bundled within the AppImage file itself. This would naturally become rather larger than if containing a simple python script, but it is doable when the software available on the target system is an unknown quantity. It can be noted that the two examples presented above both rely on interpreted scripts, and can thus be run on any hardware platform as long as the corresponding interpreters are present. Applications written in compiled languages are also possible, though they do rely more on the hardware platform. Applications compiled for 64-bit platforms are restricted to just that architecture. This should not be a problem in this day and age when most computers are 64-bit machines, but do bear this in mind if running a mix of platforms. Naturally, this remark is even more pertinent when working with ARM-based computers (such as the Raspberry Pi) and tablets, a domain in which 32-bit platforms are the most common. As for GNU/Linux distributions, not all are equally compatible. I have had excellent results with fairly current versions of the Debian / Ubuntu / Linux Mint / Neon constellation. The same has also been true for recent versions of Fedora. Your mileage may vary on other distributions.
After this short foray into using AppImage applications and creating a few small tests, there are a few very clear advantages over the more usual repository-based options for distributing software, and package managers. It is very easy for the end user to deal with the process of installing an application, at least into his or her own file space. Several different versions of the program can be installed at the same time, which helps for testing and upgrade procedures. These advantages from the user’s point of view can also be seen as positive from the system administrator’s standpoint: users can be more independent for many simple tasks. On the other hand, it should also be stressed that one advantage of a more centralized repository based distribution mechanism, and one that requires root access to the system, is security. Applications that are distributed in AppImage form require the user to be proactive as to making sure of the origin of these programs, as in asking him, or herself, if that origin is actually trustworthy. I think it is fair to say that some of the mess in the Windows and Android worlds is due, precisely, to the ease with which end users can install just about any application without even thinking in terms of software authenticity. Even though AppImages cannot be installed outside a GNU/Linux system user’s home directly without having administrator privileges, just running unverified software on one’s computer already constitutes something of a security risk - as demonstrated recently with the Spectre and Meltdown fiasco. As usual, whenever some new technology is released, we will now perhaps need some time to think about how the use of AppImages may or may not be pertinent to our own ways of using the operating system in its various forms and distributions. My personal thought is that having another option is always welcome to exercise our own freedom of choice with our computers, but that this freedom always comes at the price of being responsible for our choices. I will be using AppImages and downloading other developers’ applications, but always with an open eye as to their origin and authenticity.