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 Kdenlive. Ce qui m'intriguait n'était pas l'application elle-même - qui fonctionne très bien, malgré quelques aspérités 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 pour distribuer des applications aux utilisateurs finaux. Un programme au format AppImage devrait : • 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 s'est passé avec 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 le 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 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 intéresser les gens qui sont à un stade précoce du développement d'une application, ou dans des situations où plusieurs versions concurrentes d'une application 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 d'une 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
Dans un sens, le format de fichier AppImage et son mécanisme de distribution miment ce que font déjà Mac OS d'Apple et les fichiers .DMG. Un des points forts de ce système est précisément sa facilité d'usage.
Pour créer une application AppImage, d'après ce que je peux en voir, à peu près n'importe quel langage de programmation disponible dans un système GNU/Linux peut être utilisé convenablement, qu'il soit compilé ou interprété. Même une application existante en format binaire - dont le code pourrait être difficile à trouver ou à modifier - pourrait être re-packagée en fichier AppImage. On a juste besoin du logiciel approprié pour convertir l'application dans le format de fichier nécessaire. L'obtention de ce logiciel est vraiment facile. Il suffit de suivre les instructions du fichier README sur la page GitHub du projet à : https://github.com/AppImage/AppImageKit/blob/appimagetool/master/README.md . Il est tout à fait approprié que le logiciel AppImage soit distribué sous forme de fichier AppImage. Ça va sans le dire ! Au moment où j'écris, les étapes sont les suivantes. Commencez par télécharger le logiciel :
$ wget “https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage”
Maintenant, rendez ce fichier exécutable :
$ chmod 755 appimagetool-x86_64.AppImage
Et il peut être exécuté directement :
$ ./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
Pour créer un exemple d'application, j'ai commencé par créer une arborescence de répertoires et je l'ai peuplée avec mes fichiers. Cette structure de dossiers semble fortement inspirée par le fichier ROX et les gestionnaires de bureau.
$ mkdir HelloWorld.AppDir
$ cp terminal.png HelloWorld.AppDir/helloworld.png
$ editor HelloWorld.AppDir/AppRun
$ editor HelloWorld.AppDir/helloworld.desktop
Au moins trois de ces fichiers sont obligatoires. Le fichier image PNG sera l'icône de l'application. Ici, j'ai simplement réutilisé un fichier image bidon qui traînait dans mon ordinateur. Le fichier Desktop nécessite plus d'attention, car il donne les métadonnées système de l'application. Pour cet exemple, j'ai inclus le code suivant :
[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
Enfin, le fichier AppRun doit être rendu exécutable. C'est un script de lancement qui sera utilisé chaque fois que l'utilisateur exécute le fichier AppImage, pour lancer la vraie application. Pour cet exemple, j'ai écrit un script shell très simple :
#!/bin/bash
echo “Hello, world!”
Ensuite, Je pouvais créer les fichiers AppImage, soit, par défaut, pour mon architecture 64-bit, soit pour un 32-bit. Malheureusement, la version actuelle de appimagetool manque un peu de fonctionnalités et la compilation croisée n'est pas supportée, c'est-à-dire celle en 32-bit sur une architecture 64-bit. Vous aurez besoin de préparer le fichier AppImage de chaque architecture sur une plateforme de cette architecture. Ainsi, soit :
$ export ARCH=x86_64 ; ./appimagetool-x86_64.AppImage HelloWorld.AppDir
soit :
$ 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!
Pour ce qui est de la compatibilité avec le système, comme d'habitude, les applications AppImage compilées pour l'architecture 32-bit tourneront aussi bien sur des systèmes 32-bit compilées pour un i386 (ou plutôt de nos jours un i686), et sur un architecture 64-bit compilées pour une architecture 64-bit :
$ ./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).
Un exemple plus complexe pourrait comprendre, par exemple, une application graphique écrite en Python. Une façon aisée de lancer une application serait de remplacer simplement le fichier script AppRun par une appli en Python, commençant par une invocation correcte en entête. Par exemple, en utilisant Python 3 et les bibliothèques Gtk, ceci deviendrait :
#!/usr/bin/python3
import gi gi.require_version('Gtk', '3.0') from gi.repository import Gtk
class MyWindow(Gtk.Window): …
J'ai construit une application très simple, l'ai packagée comme fichier AppImage 64-bit et lancée ensuite sous Linux Mint 18.3 (ci-dessus).
Je l'ai ensuite re-packagée à l'identique pour un système 32-bit, téléchargée et exécutée à partir d'un Live CD de Fedora 26. La conversion en AppImage a été faite à l'intérieur d'une instance VirtualBox de Fedora elle-même (ci-dessous).
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.
Cette AppImage même a fonctionné directement sur une version plutôt ancienne de elementary OS (Freya, construite sur Ubuntu Trusty et présentée à droite).
Naturellement, l'utilisation d'une telle solution technique impose que Python 3 et Gtk soient installés ensemble sur le système de l'utilisateur. Ce n'est pas vraiment un problème, car c'est le cas pour la plupart, sinon tous, des systèmes GNU/Linux actuels. Si ce n'est pas le cas, ils doivent être groupés dans le fichier AppImage lui-même. Ceci le rendra largement plus gros que s'il ne contenait que le seul script en Python, mais c'est faisable quand la disponibilité du logiciel sur le système cible est inconnue.
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.
Il convient de noter que les deux exemples ci-dessus s'appuient sur des scripts interprétés et peuvent donc tourner sur l'importe quelle plateforme matérielle pour autant que les interpréteurs correspondants soint présents. Les applications écrites dans des langages compilés sont aussi possibles, bien qu'elles dépendent plus de la plateforme matérielle. Les applications compilées pour des plateformes 64-bit sont limitées à cette architecture. Ça ne devrait pas poser un problème de nos jours où la plupart des ordinateurs sont des machines 64-bit, mais vous devez le garder à l'esprit si vous faites tourner diverses machines. Naturellement, cette remarque est encore plus pertinente pour un fonctionnement sur des ordinateurs basés sur ARM (tels que le Raspberry Pi) et des tablettes, un domaine dans lequel les plateformes 32-bit sont très classiques.
Quant aux distributions GNU/Linux, elles ne sont pas toutes également compatibles. J'ai eu d'excellents résultats avec des versions assez actuelles de la constellation Debian / Ubuntu / Linux Mint / Neon. Ceci est aussi vrai pour les versions récentes de Fedora. Le résultat peut varier sur d'autres 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.
Après cette courte incursion dans l'utilisation des applications AppImage et la création de quelques petits tests, on voit quelques avantages très clairs par rapport aux options classiques pour la distribution des logiciels, basées sur les dépôts et les gestionnaires de paquets. Il est très facile pour l'utilisateur final de se débrouiller avec le processus d'installation d'une application, au moins dans son propre espace de travail. Plusieurs versions différentes du programme peuvent ainsi être installées en même temps, ce qui aide pour les tests et les procédures de montée de version. Ces avantages du point de vue de l'utilisateur peuvent aussi être vus comme positifs du point de vue de l'administrateur du système : les utilisateurs peuvent être plus indépendants pour beaucoup de tâches simples. En revanche, il faut aussi souligner qu'un des avantages d'un mécanisme de distribution basé sur des dépôts plus centralisés, avec le besoin d'un accès au système en tant que root, est la sécurité. Les applications qui sont distribuées sous la forme d'une AppImage nécessitent que l'utilisateur soit pro-actif, en s'assurant de l'origine de ces programmes et en se demandant si cette origine mérite sa confiance. Je pense qu'il est juste de dire qu'une partie de la pagaille dans les mondes de Windows et d'Android est due, précisément, à la facilité avec laquelle les utilisateurs finaux peuvent installer à peu près n'importe quelle application sans même penser à l'authenticité du logiciel. Même si les AppImages ne peuvent pas être installées directement en dehors du dossier personnel (/home) de l'utilisateur du système GNU/linux sans avoir des privilèges d'administrateur, le simple fait de faire tourner des logiciels non vérifiés sur son ordinateur constitue déjà un risque pour la sécurité, comme démontré récemment avec les fiascos de Spectre et Meltdown.
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.
Comme d'habitude, chaque fois qu'une nouvelle technologie est publiée, nous aurons maintenant besoin d'un peu de temps pour réfléchir aux usages des AppImages qui peuvent être pertinents ou non pour notre propre façon d'utiliser le système d'exploitation dans ses différents formats et distributions. Mon idée personnelle est qu'il est toujours bienvenu d'avoir une autre option pour exercer sa liberté de choix avec nos ordinateurs, mais que cette liberté vient toujours avec le prix d'être responsable de nos choix. J'utiliserai les AppImages et téléchargerai des applications d'autres développeurs, mais, toujours, avec un œil ouvert sur leur origine et leur authenticité.