PROJET AUTOBLOG


FredericBezies

source: FredericBezies

⇐ retour index

Le « build once, run everywhere », un fantasme dans le monde du logiciel libre ?

lundi 4 juillet 2016 à 17:54

Dans ce billet coup de gueule – oui, j’ai sorti l’orangina rouge à l’orange sanguine, je voudrai vous parler d’un truc qui me lasse au dernier point : les paquets universels ou cruci-distributions.

Comme Java qui promettait au début du « write once, run everywhere » – écrire une seule fois, lançable partout – le monde du logiciel libre voit arriver deux technologies concurrentes, Snappy poussée par Canonical et FlatPak poussé par RedHat.

Technologies incompatibles entre elles, elles entrent en concurrence avec une troisième technologie, AppImage qui veut elle aussi accomplir le fantasme de l’informatique : compiler une seule fois le code source d’un logiciel, et le lancer tel quel sur toutes les distributions existantes. En gros, reprendre le principe des fichiers images DMG d’Apple. En rajoutant la marotte actuelle en terme de sécurité, le bac à sable.

Dans un article du mois de juin 2016, Canonical faisait entendre que son projet Snappy fonctionnerait indépendamment des distributions cibles.

Un annonce a été récemment faite sur l’arrivée du daemon snapd qui permet d’avoir le support des « paquets » Snaps sur Archlinux. Il y a même une page de wiki pour le logiciel en question.

Dans sa gazette du 4 juillet 2016, Distrowatch a tiré un bilan préliminaire du couple infernal Snappy / Flatpak en mettant en perspective que ce sont des technologies encore jeunes. Voici les morceaux de choix, pour Snappy :

[…]What made my experience more bitter this week was that not only were Flatpak and Snap not universal across distributions, the packages I tried did not even work on the distributions which claim to support them. Snap, on Ubuntu, looked promising. The snap command line utility feels a lot like apt-get and automatically handles dependencies. It might not work yet, but the concept seems viable once the edges get polished. Unfortunately, it looks as though Snap’s backend (the server side of things) is proprietary and unlikely to be accepted in the larger Linux community.[…]

Ce qui donne traduit :

[…]Ce qui a rendu mon expérience plus amère cette semaine, c’était que non seulement Flatpak et Snap ne sont pas universel entre les distributions, mais que les paquets que j’ai essayé n’ont même pas fonctionner sur les distributions qui prétendent les soutenir. Snap, sur Ubuntu, semblait prometteur. L’utilitaire snap ligne de commande ressemble un peu à apt-get et automatiquement gère les dépendances. Il pourrait ne pas fonctionner encore, mais le concept semble viable une fois que les angles seront arrondis. Malheureusement, il semble que le backend Snap (le côté serveur des choses) soit propriétaire et il y a peu de chances qu’il soit accepté par la communauté Linux au sens large.[…]

Pour Flatpak ?

Flatpak though is broken by design. Like Snap, Flatpak has a rough command line interface, but it also requires far too many steps to get it working. These steps involve installing Flatpak, then typing out long, complex commands which will immediately turn away most users. To even try to run a Flatpak application the user must import signing keys, manually install dependencies and then hope that is enough to get the application working. Further, Flatpak relies on systemd and only works in desktop sessions, preventing the package format from working on servers and in embedded environments. This makes Flatpak a non-starter in the race for universal packages.

Ce qui donne traduit :

[…]Flatpak bien est défectueux par la conception. Comme Snap, Flatpak dispose d’une interface de ligne de commande rugueuse, mais il faut aussi beaucoup trop d’étapes pour le faire fonctionner. Ces étapes impliquent l’installation de Flatpak, puis en tapant sur de longues commandes complexes qui feront s’éloigner automatiquement la plupart des utilisateurs. Pour même essayer d’exécuter une application de Flatpak l’utilisateur doit importer les clés de signature, installer manuellement les dépendances et avec l’espoir que ce soit suffisant pour obtenir le fonctionnement de l’application. En outre, Flatpak repose sur systemd et ne fonctionne que dans les sessions de bureau, ce qui empêche le format de paquet de travailler sur des serveurs et dans des environnements embarqués. Cela donne à Flatpak un faux départ dans la course au les paquets universels.[…]

La conclusion est une « balle en pleine tête » des deux projets.

[…]The most frustrating thing in this situation is we already have a cross-platform package format which works. AppImage has been around for years, automatically handles dependencies, truly works across multiple distributions and does not require root/sudo access to install. AppImage requires no additional framework or libraries to be installed, there is no new package manager to learn and AppImage programs can be launched through any distribution’s file manager.[…]

Ce qui donne traduit :

Le plus frustrant dans cette situation est que nous avons déjà un format de paquets multi-plateforme qui fonctionne. AppImage est présent depuis des années, gère automatiquement les dépendances, fonctionne vraiment sur de multiples distributions et ne nécessite pas l’accès root / sudo à installer. AppImage nécessite pas de cadriciels ou de bibliothèques supplémentaires à installer, il n’y a aucun nouveau gestionnaire de paquets pour apprendre et programmes AppImage peut être lancée via le gestionnaire de fichiers de toute distribution.

Snappy et Flatpak vont tuer un truc à peu près fonctionnel, AppImage. Cependant, j’ai voulu faire ma propre expérience, et j’ai pris deux logiciels supportés par les trois formats : LibreOffice et Gimp. Ce sont deux logiciels suffisamment complexe pour tester la solidité du principe et surtout son côté cruci-plateforme. Pour des raisons de légèreté, j’ai pris une Archlinux Mate installée dans VirtualBox que j’ai cloné autant de fois que nécessaire.

Première surprise : aucun Gimp en paquet snap… Ni de LibreOffice. Mal cherché ? Paquets indisponibles ? Heureusement que j’ai pu me retourner vers VLC 🙂

Deuxième surprise : outre que Flatpak est laxatif à installer, le port pour Archlinux semble être encore un peu vert. Au point que j’ai fini par jeter l’éponge.

Pour être franc, je ne crois pas le moins du monde dans un format de paquet universel… Sans que le nombre de distributions existantes ne se réduisent qu’à une grosse dizaine. Vu qu’on en est à environ 270 distributions indexées et vivantes sur Distrowatch…

Je laisse 18 mois à 2 ans avant qu’on enterre aussi bien snappy que flatpak. Le « compiler une fois, installer partout », cela restera du domaine du rêve à moins de vouloir décider de transformer le monde du libre en une copie de ce qui se fait sous Apple ou Microsoft.

Si je me trompe, et bien, je le reconnaitrai et je ferai amende honorable. Dans le cas contraire, je constaterai que mon intuition était correcte.

Slackware Linux 14.2… Le retour de la vénérable distribution ancestrale.

dimanche 3 juillet 2016 à 20:51

Ah, la Slackware Linux. Elle a pour moi un goût particulier, celui de la madeleine de Proust. C’est la première distribution GNU/Linux sur laquelle j’ai mis la souris en 1996.

En mars 2016, je faisais un peu mumuse avec la Slackware 14.2rc1. Comme la Slackware 14.2 est enfin sortie, j’ai voulu la tester. Cette fois, et contrairement à l’article précédent, je vais utiliser Xfce. J’aurais très bien utiliser Mate Desktop (en me basant sur le port officiel de l’environnement pour la Slackware Linux), mais j’ai voulu rester aussi proche de l’original que possible.

Après avoir récupéré l’ISO de la version 14.2 en 64 bits, j’ai lancé mon ami VirtualBox avec les réglages habituels : 2 go de mémoire dédiée, 128G de disque, et 2 CPU virtuels.

Je suis donc parti sur une installation de la Slackware Linux tout ce qu’il y a de plus classique. Pour le partionnement, le trio habituel : / de 20 Go, 4 Go de swap et le reste en /home.

Pour alléger l’installation, j’ai décoché les groupes E, F, K, KDE, KDEI, T (n’ayant pas besoin de TeX) et Y. Autant dire que l’installation a été assez allégée.

J’ai aussi activé l’utilisation de NetworkManager au niveau de la connexion réseau. Côté service au démarrage, j’ai rajouté ntpd et cups.

Au niveau de l’environnement à lancer, j’ai pris Xfce.

Une fois l’installation terminée et en me connectant en root le temps nécessaire, j’ai redémarré et puis j’ai modifié le fichier /etc/profile.d/lang.sh pour faire prendre en compte le français.

J’aurai pu modifier le noyau utilisé, mais comme je n’avais pas envie de me prendre la tête… Sinon, c’est fortement conseillé par la documentation de la distribution🙂

L’étape suivante a été de configurer un miroir pour slackpkg. J’ai pris celui de lip6 en http.

J’ai ensuite effectué le quatuor habituel, même si c’était un brin inutile, étant donné la jeunesse de l’ISO !

slackpkg update gpg
slackpkg update
slackpkg install-new
slackpkg upgrade-all

J’ai créé un compte utilisateur classique avec l’outil adduser.

En me connectant en tant qu’utilisateur standard et avec startx, j’ai pu accéder à Xfce que j’ai configuré comme je l’aime… Ou presque 🙂

J’ai ensuite modifié le fichier /etc/inittab pour que le démarrage se fasse en mode graphique directement.

Tout cela étant fait, Kazam a chauffé à son tour pour capturer la post-configuration de la Slackware fraichement installée. La vidéo a été un peu longue pour des raisons expliquées ci-après.

Vous avez pu voir qu’il était relativement simple de compléter l’installation via le duo slackpkg+ et le dépot d’AlienBob. Il est dommage que le temps pris pour finaliser la version 14.2 de la Slackware Linux ait mis de côté Plasma 5. Mais ce n’est que reculer pour mieux sauter au final.

Dommage que gFtp soit proposé par défaut, et qu’un outil comme mousepad ou encore xarchiver ne soit pas disponible dès l’installation. J’aurai bien fait recompiler Filezilla, mais wxGTK3 qui est une des dépendances est un veau à faire construire.

J’ai vraiment énormément de plaisir à faire fonctionner l’une des plus vieilles distributions GNU/Linux encore en vie (23 ans cette année). Même si elle montre son âge, cette vénérable dame a encore des atours qui peuvent attirer les vieux geeks qui n’aiment pas la direction prise par la plupart des distributions classiques.

Chacun voit midi à sa porte, après tout, non ? 🙂

Les projets un peu fous du logiciel libre, épisode 8 : GNU/Hurd.

samedi 2 juillet 2016 à 17:37

Je sais, j’ai mis énormément de temps à sortir ce nouvel épisode de la série « Les projets un peu fous du logiciel libre », mais l’attente en valait la peine. Le huitième épisode est donc consacré à GNU/Hurd, qui est sûrement le projet le plus fou et le plus moqué du logiciel libre.

Noyau du projet GNU, il est plus vieux que Linux lui même… Dans la célèbre « dispute » entre Linus Torvalds et Andrew Tannenbaum, concernant le choix d’un noyau monolithique au lieu d’un micro-noyau (comme celui prévu pour GNU) en janvier 1992, Linus Torvalds déclara :

« […]If the GNU kernel had been ready last spring, I’d not have bothered to even start my project: the fact is that it wasn’t and still isn’t. Linux wins heavily on points of being available now.[…] »

Ce qui donne traduit ?

« […]Si le noyau de GNU avait été prêt au printemps dernier, je n’aurais pas pris la peine de même commencer mon projet: le fait est qu’il n’a pas été et est toujours pas. Linux gagne en grande partie sur le fait d’être disponible dès maintenant.[…] »

Le printemps dernier étant bien entendu celui de l’année 1991. Bref, 25 ans sont passés, et si on va sur le site officiel de GNU/Hurd, on s’aperçoit que les options sont limités. La seule distribution fonctionnelle ? Une image disque avec une Debian GNU/Hurd.

J’ai donc récupéré l’image ISO de la dernière version (mars 2016), et j’ai donc suivi les instructions disponibles aussi sur la page du projet chez Debian pour tester l’ensemble. Le noyau GNU/Hurd ne semblant être fonctionnel qu’en 32 bits pour le moment.

gnuhurd001

Une fois l’ensemble lancé, j’ai reconfiguré le clavier, comme conseillé, puis j’ai lancé le duo apt-get update et apt-get upgrade. Oui, je suis un peu malade. Histoire d’avoir un noyau et un ensemble relativement à jour 😀

La Debian GNU/Hurd mise à jour, j’ai fait redémarré le tout et j’ai installé un compte utilisateur classique. Puis, j’ai fait chauffer mon ami Kazam pour capturer la distribution en action.

Malgré les aléas du direct, je dois dire que voir fonctionner GNU/Hurd est un plaisir de fin gourmet. Le morceau de choix ? Voir fonctionner Mozilla Firefox 45.0.2 sous GNU/Hurd. Non, je ne plaisante pas 🙂

Allez, on va dire que dans 10 ans, le noyau sera soit suffisamment stable pour être utilisable… Soit il aura fini sa vie dans un musée consacré à l’informatique libre 🙂

En vrac’ de fin de semaine.

samedi 2 juillet 2016 à 15:24

Comme chaque fin de semaine, l’obligatoire billet en vrac’. Il sera uniquement consacré cette semaine à l’informatique. Je n’ai eu aucun coup de coeur littéraire ou musical… Quoique j’écris le billet en écoutant un album de 1972… « Fragile » d’un petit groupe peu connu… Yes 😀

C’est tout pour aujourd’hui !

Bon week-end !

Mémoires télévisuelles d’un enfant des années 1970, épisode 23 : La dernière séance…

vendredi 1 juillet 2016 à 14:21

S’il y a une émission qui a bercé mon enfance et mon adolescence, c’est bien « La Dernière Séance » diffusée entre janvier 1982 et décembre 1998 sur FR3 puis France 3.

Émission mensuelle, elle se basait sur un principe simple : faire (re)découvrir des films américains classiques des années 1930 aux années 1960, tous genres confondus : aventure, western, fantastique, comédie, drame, etc.

Présentée par Eddy Mitchell, on se retrouvait dans une salle de cinéma qui proposait avant le premier film des actualités filmées.

Voici un extrait de l’émission de novembre 1997 :

Diffusée au début le mardi soir, c’était pour moi l’occasion de pouvoir me coucher un peu tard, surtout pour les dessins animés entre les deux films.

C’est vraiment une émission qui me manque. En bonus, le clip vidéo officiel du titre « La dernière séance », tiré de l’albume éponyme sorti par Eddy Mitchell en 1977.

Je sais pas vous, mais ce titre me fout un brin le bourdon…