J'ai reçu une nouvelle machine au bureau ; jusqu'à présent j'utilisais mon portable personnel, mais à peine âgé de 2½ ans c'est déjà un vieillard : le voilà donc remplacé par un Core 2 Quad (enfin, un Core 2 Duo pour l'instant parce que Dell a fait une erreur en livrant le mauvais processeur) avec 8Go de RAM qui m'offre un environnement de travail un peu plus confortable (par exemple j'ai pu y compiler Sage — mais je digresse). Bref, j'ai décidé d'y installer une Ubuntu (mais peu importe, ce que je vais dire s'appliquerait à n'importe quelle distribution Linux), et j'ai gagné le droit de batailler contre la configuration : comme d'habitude, obtenir un système qui est à 99% comme on voudrait prend cinq minutes, passer à 99.9% prend cinq jours, et passer à 100% prendrait l'éternité.
Une des doctrines (je cherche ici à traduire le mot
anglais tenet
) de l'open source, et aussi d'une
certaine manière d'Unix, et spécifiquement des distributions Linux,
c'est qu'on doit avoir plein de petits programmes qui sont comme les
morceaux d'un puzzle et que ces morceaux s'assemblent pour former un
système utile. Malheureusement, il y a plusieurs problèmes avec
ça :
Premièrement, il arrive que le même morceau soit écrit de plusieurs façons différentes par plusieurs personnes indépendantes ; il arrive aussi qu'un morceau soit écrit, puis abandonné (rendu obsolète) à la faveur d'un autre mieux écrit ; ou encore, que deux morceaux fassent des choses semblables mais en fait différentes (et pas forcément incompatible) ; tout cela est très bien. Le problème, c'est qu'on manque complètent de carte pour expliquer comment les morceaux s'arrangent, du coup on est perdu dans un labyrinthe de petits programmes tous semblables dont les rapports entre eux ne sont expliqués nulle part.
Voici un exemple : il y a (au moins !) deux systèmes complètement différents d'économie d'écran dans une distribution Linux standard : le X screensaver et le Gnome screensaver (et peut-être aussi un analogue du côté de KDE) ; chacun de ces deux systèmes d'économie d'écran vient avec plusieurs dizaines d'économiseurs d'écrans (c'est-à-dire d'animations qu'on peut, concrètement, avoir sur l'écran), certains étant d'ailleurs communs aux deux, et par ailleurs les deux font appel à une même capacité sous-jacente du serveur X à éteindre l'écran. Bien sûr, les auteurs du Gnome screensaver prétendent que le X screensaver est obsolète et ceux du X screensaver prétendent que le Gnome screensaver est mauvais pour d'autres raisons. Les réglages du X screensaver et ceux du Gnome screensaver sont semblables mais subtilement différents. Il est tout à fait possible de ne pas savoir lequel on utilise, voire d'utiliser malencontreusement les deux à la fois (qui vont plus ou moins se marcher sur les pieds). Du coup, quand un utilisateur novice demandera de l'aide à un utilisateur un peu moins novice mais néanmoins ignorant de l'existence de deux systèmes différents d'économie d'écran, cela peut donner des jolis dialogues de sourds. Personnellement, j'ai compris l'existence des deux trucs quand j'ai essayé de régler mon X screensaver en utilisant les réglages du Gnome screensaver ce qui, évidemment, ne marchait pas, sans afficher le moindre message d'erreur compréhensible ; de même, je ne comprenais pas pourquoi mon poussinet avait une liste assez différent d'économiseurs d'écran que la mienne. Tout ceci réjouit immensément le Club Contexte mais pas forcément les utilisateurs. Personnellement, je n'ai rien contre l'existence de deux systèmes différents, à condition que chacun signale l'existence de l'autre et explique qu'il est différent sur tel ou tel point et dans quelle mesure ils sont compatibles, comment savoir lequel on utilise, etc.
Un autre exemple : pour placer l'ordinateur en sommeil
(suspend-to-RAM) ou en
hibernation (suspend-to-disk), il existe tout
un tas de mécanismes : le noyau a des capacités dans ce sens
(écrire mem ou disk
dans /sys/power/state), mais il existe aussi des choses
telles
que uswsusp, hibernate, pm-utils, gnome-power-manager
et j'en oublie certainement. Comment savoir ce qui dépend de quoi, ce
qui remplace quoi, ce qui sert à quoi, ce qui obsolète quoi, et ce qui
peut servir en supplément à quoi ? Les documentations vous diront
toutes qu'il s'agit d'un truc pour placer l'ordinateur en sommeil ou
en hibernation, pas comment le truc en question se relie aux autres
trucs qui prétendent servir à la même chose. En fait, il s'avère
que uswsusp est une sorte de béquille au code du noyau
qui lui permet de faire marcher plus de configurations en
reconnaissant des besoins spécifiques à certains périphériques,
que hibernate (Linux-spécifique et peut-être obsolète)
et pm-utils (plus général) sont des collections de
scripts censés travailler à plus haut niveau et font appels soit au
noyau soit à uswsusp s'il existe, et
que gnome-power-manager est sans doute une interface
graphique à pm-utils (comme il en existe forcément aussi
dans KDE) ; mais cela, on ne peut l'apprendre qu'en
passant des heures à essayer de démêler les fils — car chercher
un des noms dans Google ne vous aidera pas à trouver le rapport avec
les autres. Résultat, si vous avez un problème dans le suspend, vous
ne savez pas qui incriminer, vous ne savez pas contre quel package
envoyer un rapport de bug, vous ne savez pas où chercher des logs,
vous ne savez pas si vous pouvez essayer un autre programme ou si le
composant en question est le seul qui remplisse sa fonction. C'est un
cauchemar.
Mais le pire de tout, c'est probablement les mécanismes d'impression. Là vous devez à la fois choisir le spooler (ou front end) d'impression (par exemple CUPS, qui est d'ailleurs une horreur) qui sert à dispatcher les jobs d'impression et le driver (ou back end) qui sert à convertir les jobs au format compris par l'imprimante. Du côté du spooler, il y a plein de morceaux qui s'emboîtent de façon très compliquée et nulle part expliquée (CUPS, par exemple, est un serveur, donc il y a des clients qui vont avec, mais aussi des clients CUPS qui font semblant d'être des clients LPR ce qui fait que vous ne comprendrez pas si vous aurez besoin de ça si vous utilisez CUPS et pas LPR). Du côté du driver, c'est encore pire, parce qu'il y a toujours Ghostscript qui intervient d'une façon ou d'une autre, mais il en existe des versions patchées, il en existe de nombreux drivers proprement dits, et évidemment il y a un nuage de scripts autour de tout ça et des fichiers PPD dont on ne sait jamais s'ils décrivent l'imprimante ou le driver ou autre chose. Pour compliquer le tout, il existe des sortes de méta-drivers comme Gutenprint ou GIMP-print (peut-être certains sont-ils obsolètes mais, justement, c'est impossible à savoir). Et il existe un métasblurgh qui englobe tout ça à la fois et qui s'appelle Foomatic. Si votre imprimante ne marche pas, vous n'aurez aucune chance de savoir si la faute en est à Foomatic, Gutenprint, GIMP-print, Ghostscript, un des drivers de celui-ci, ou CUPS ou autre chose ; et si vous interagissez avec des machines Windows, ajoutes Samba à l'affaire (pour Mac OS, par contre, c'est aussi du CUPS). Je ne reproche pas l'existence de cette multiplicité de systèmes, je reproche que les auteurs des différentes parties (ou personne, en fait) ne prennent pas le soin d'expliquer comment elles se connectent aux autres. Il y a un embryon d'explication sur linuxprinting.org, mais ce n'est qu'un embryon.
Évidemment, parfois les choses marchent toutes seules (et les distributions Linux font tout pour que ce soit le cas). Parfois ça ne marche pas. Ce n'est pas mon reproche. Mon reproche est que quand les choses ne marchent pas, c'est quasiment impossible de savoir à qui on a affaire.
Là je parlais avant tout des soucis liés à la multiplicité des éléments qui font la même chose, même si dans le cas de l'impression ça tire aussi sur le problème de la multiplicité des éléments qui s'emboîtent de façon incompréhensible. Un problème différent mais apparenté est celui de la multiplicité des éléments non documentés qui parlent entre eux de façon trop automagique.
Un exemple archétypique serait Gnome (ou KDE, mais je
connais mieux Gnome, pas forcément que j'aime beaucoup plus). Gnome
est un environnement graphique pensé pour être aussi convivial pour le
débutant que les environnements proposés par Microsoft Windows ou
Mac OS. Du coup, il faut qu'il y ait toutes sortes de de
programmes et de démons qui fassent des choses magiques
qui ne
sont pas trop prévues par l'esprit ancestral d'Unix. Par exemple,
quand on insère une clé USB, le noyau Linux va le dire
(via le système de fichiers /sys et/ou via une socket
netlink) à un démon appelé udev qui va lui-même le dire à
un démon appelé hal et ensuite, en passant le message par
l'intermédiaire d'un autre démon appelé dbus, toutes
sortes de choses magiques vont se passer par les différentes couches
de Gnome. L'ennui, c'est que si on ne veut pas que toute
cette magie se passe (par exemple, si pour une raison quelconque je ne
veux pas que mon ordinateur monte automatiquement les
clés USB qu'on insère dedans), c'est très difficile : il
faut comprendre par où elle passe pour pouvoir l'arrêter. Les rois
mages udev, hal et dbus ont
tellement envahi tout le fonctionnement de Linux qu'on ne peut plus se
passer de les comprendre, et ils sont très complexes, mais au moins il
faut admettre qu'il en existe des documentations au moins de certains
aspects (et assez rébarbatives, il faut le dire), par
exemple là
pour ce qui est de hal. La magie qui se déroule dans les
entrailles de Gnome, en revanche, elle n'est expliquée nulle part, pas
plus qu'une partie importante de son terrifiant mécanisme de
configuration (qu'on peut naviguer
avec gconf-editor).
Un autre exemple est toute la sauce des GNU
autotools, dans les compilations : quand la compilation marche bien,
on est content, mais si jamais quelque chose échoue, allez fouiller
dans un Makefile généré à partir
d'un Makefile.in lui-même généré à partir
d'un Makefile.am pour comprendre d'où sortait la ligne de
commande erronée et comment lui faire comprendre de passer telle
option en plus au compilateur !
C'est très décevant pour les gens comme moi qui connaissent bien Unix de constater à quel point ces mécanismes pour faire de la magie deviennent sans arrêt plus complexes et moins bien documentés. Certes ils font des choses utiles, quand ils marchent ; mais quand on veut faire quelque chose qui les dépasse ou simplement quand ils cassent, on se rend compte qu'il n'y a aucune documentation, aucun log d'erreur, et que le source est labyrinthique (il n'est souvent même pas évident de savoir de quoi il faut chercher le source, d'ailleurs).
En plus, si on gagne en complexité, on ne gagne pas toujours en flexibilité : souvent, au prétexte qu'il faut que tel ou tel aspect du programme soit configurable par les utilisateurs novices, donc par une interface graphique simple, on se retrouve avec des outils extrêmement peu configurables. (Je pense notamment au gestionnaire de fenêtres de Gnome, Metacity, qui a remplacé le plus flexible Sawfish : j'ai l'impression qu'on ne peut même pas avoir deux racourcis clavier qui fassent le même effet, chose qui peut être souhaitable dans certains cas, sous prétexte qu'il faut que les utilisateurs novices puissent éditer leurs racourcis clavier avec une interface très simple où chaque action est associée à un racourci et un seul. Ainsi, si on veut avoir le eye candy moderne de Metacity ou Compiz, on est obligé de se passer de la puissance et de la flexibilité d'un Sawfish ou même Fvwm : c'est vraiment triste.)
Il y a cependant un programme auquel je tire mon chapeau, parce qu'il a réussi à combiner le meilleur de tout : à la fois très simple pour le novice et très puissant pour l'expert, constitué de milliers de composantes, extensible, et pourtant remarquablement bien documenté (ce ne fut pas toujours le cas, mais maintenant il est vraiment bon de ce côté-là), c'est Firefox.