Je continue ma tentative d'écrire des
billets pas trop interminables avec une autre considération
informatique (qui mériterait pourtant un traitement beaucoup plus long
et approfondi, parce que c'est quelque chose d'important et de trop
peu souligné). Contrairement à la
précédente, ici je ne vais pas prétendre que c'était mieux
âââvant
: ce n'était pas mieux avant
(la preuve !), il y a même
peut-être eu une légère amélioration ; et c'est peut-être un problème
assez inévitable, mais ça ne veut pas dire qu'on ne puisse rien y
faire.
Beaucoup d'efforts sont consacrés au fait de rendre les systèmes Linux utilisables par des gens qui n'y connaissent rien : donc de leur fournir des interfaces graphiques faciles et conviviales pour faire des tâches courantes (et j'ai déjà souligné que ce n'était pas forcément une si bonne idée). Mais souvent, en informatique, on veut faire quelque chose qui n'est pas exactement dans les sentiers battus (après tout, c'est bien le principe d'un ordinateur que de pouvoir servir à essentiellement n'importe quoi : il n'est pas concevable de faire une interface simple et conviviale pour n'importe quelle tâche imaginable). Donc il faut aussi que le système soit utilisable par quelqu'un qui est prêt à fouiller un peu plus pour faire des choses plus compliquées : et ces deux impératifs entrent fréquemment en tension.
Le problème principal de l'écosystème Linux, de ce point de vue-là, est aussi ce qui fait sa force : le fait qu'il a émergé sans conception centrale. N'importe qui a le droit d'écrire un bout de logiciel, ou de lancer un projet pour faire telle ou telle tâche, il n'y a pas à demander d'autorisation. Du coup, plein de gens ont fait plein de bouts de logiciels qui font plein de choses différentes, sans bien se coordonner, et parfois avec des idées très différentes sur la Bonne Façon de faire ceci-ou-cela. Donc on se retrouve avec un puzzle gigantesque d'outils et de mécanismes, qu'il y a souvent plein de façons différentes d'assembler.
La tâche principale d'une distribution Linux, c'est d'assembler le puzzle pour vous. Ou du moins de préassembler plein de bouts du puzzle de manière un peu cohérente. Mais même comme ça, il reste des libertés d'assemblage et des choix non résolus.
(Bon, peut-être que ma métaphore du puzzle n'est pas terrible. Au début je pensais parler de labyrinthe, mais ce n'est pas idéal non plus. En tout cas, je n'ai pas vraiment trouvé mieux, alors tenons-nous en au puzzle, surtout que ça va me permettre de donner à ce billet une fin dont je suis très content.)
Je pense que beaucoup d'utilisateurs même parmi les plus débutants sont conscients du fait qu'il y a, par exemple, plusieurs navigateurs Web entre lesquels on peut choisir : presque tout le monde utilise Chrome, de nos jours, mais on peut aussi préférer Firefox (c'est mon cas) ou Opera. Ce qui n'est pas forcément clair pour les débutants, c'est qu'en fait, ce genre de choix existe pour énormément de composantes du système, et si ça représente une grande liberté, c'est aussi une source possible de confusion.
Pour à peu près n'importe quelle tâche, dans l'écosystème
Linux, il y a plusieurs outils différents, et la manière de régler des
problèmes dépend de celui que vous utilisez, parfois sans le
connaître. C'est la raison principale pour laquelle, quand
on cherche comment faire <machin> sous Linux ?
on trouve
souvent des conseils qui, quand on les applique, ne marchent pas du
tout (ou, pire, cassent des choses) : ils supposent que vous utilisez
un outil différent.
Et ce n'est pas juste qu'il y a souvent 7 outils différents pour faire la même chose et qui fonctionnent différemment : le lien entre ces outils peut être très varié, et ne se résume pas toujours simplement à un choix entre eux. Ils ne recouvrent pas forcément le même terrain, ils peuvent avoir des philosophies très différentes.
Parfois Bar est prévu pour être un remplacement de Foo (et on va
prétendre que Foo est maintenant obsolète
, ce qui ne veut pas
forcément dire que tout le monde est d'accord avec ce jugement :
certains vont parfois lutter pour garder Foo vivant parce qu'ils
trouvent que Bar ne le remplace pas correctement — c'est même une
situation très courante). Parfois Bar continue à utiliser des bouts
de Foo : parfois il émule son comportement pour que les programmes qui
prévoyaient de tourner avec Foo puissent quand même fonctionner avec
Bar ; mais parfois il y a des différences subtiles entre Foo et
Foo-émulé-par-Bar, et parfois il y a en fait le choix entre Foo,
Foo-émulé-par-Bar, et Bar-nouvelle-façon-de-faire.
Et bien sûr, parfois, alors que Bar prétendait remplacer Foo et que ça se passait mal, un troisième arrivé, Qux, prétend résoudre la confusion en apportant ses propres solutions d'harmonisation, et le résultat est encore plus de confusion. (Il y a un xkcd pour ça, évidemment.)
Ça peut vite devenir un véritable chaos.
Et si vous n'imaginez pas qu'un projet puisse être à la fois tout neuf et en même temps déjà considéré comme obsolète (voire, plus obsolète que le truc qu'il est censé remplacer), c'est que vous n'avez pas beaucoup utilisé Linux.
La situation classique, donc, c'est que Foo est obsolète, Bar est censé le remplacer, sauf qu'en fait Qux est en développement pour régler les problèmes causés à la fois par Foo et Bar, mais il y a aussi des gens qui préfèrent Corge, lequel est un fork de Bar fait par des gens qui ne veulent vraiment passer à Qux parce qu'ils lui reprochent de ne pas correctement faire tout ce que faisait Foo ; et il y a aussi Flarp qui est un petit projet développé dans son coin par un unique développeur qui a ses propres idées sur la façon de tout faire, et qui a son propre groupe de fans, sans parler de Grault, qui n'a pas bougé depuis 1999 (où il cherchait à reproduire un outil de Solaris) mais qui continue à plaire aux gens qui aiment la stabilité.
Bref, parfois les outils différents pour une même tâche sont des alternatives entre lesquels il faut choisir. Parfois ils sont strictement incompatibles (et si vous essayez de les utiliser en même temps, il vous arrivera toutes sortes de malheurs, ou au moins des messages d'erreur totalement incompréhensibles). Parfois ce sont des couches au-dessus les unes des autres (i.e., Bar ne remplace pas Foo, il se met au-dessus, et vous êtes censé utiliser l'interface fournir par Bar, pas directement celle de Foo, mais vous pouvez quand même et ça causera de la confusion). Parfois ils tentent de s'abstraire les uns les autres (c'est-à-dire qu'un certain outil vous tente de fournir la même interface que plusieurs autres au-dessus desquels il se place et entre lesquels il faut peut-être choisir). Parfois ils s'émulent partiellement. Parfois ils peuvent cohabiter harmonieusement. Parfois ils partagent une partie de leur état, parfois ils sont strictement séparés. Parfois ils ont différents modes de compatibilité permettant d'utiliser l'un sans l'autre ou les deux ensemble. Et souvent, très souvent, trop souvent, ils ne vous disent pas clairement dans lequel de ces cas de figure vous êtes.
Parfois votre distribution Linux fait un choix pour vous. Parfois elle vous fournit les mécanismes pour faire votre propre choix.
Parfois vous avez une couche graphique au-dessus de tout ça qui fait elle-même des choix, et vous avez le plus grand mal à savoir si l'outil graphique est un truc indépendant ou s'il fait en fait appel à Foo, Bar ou Qux : et trouver ce qu'il en est se transforme en un véritable jeu de piste.
Parfois le choix entre Foo, Bar et Qux est un choix global au niveau du système, parfois c'est un choix par utilisateur ou par session. Parfois c'est même juste au sein d'un programme donné (souvent le noyau Linux lui-même) qu'il y a trois mécanismes différents pour faire la même chose. Parce que chaque programme un peu important de l'écosystème Linux est son propre mini-écosystème, qui tire dans plusieurs directions à la fois et n'a souvent pas de chef clair, ou dont le chef aime le principe de la liberté de choix.
On comprend que les choses peuvent rapidement ressembler à un puzzle 10 000 pièces, qui, en plus de ça, a la possibilité d'être assemblé de plein de manières différentes.
Mais soyons bien clair : je ne me plains pas vraiment de cette situation (qui est une conséquence inévitable du principe même du logiciel libre) ; je me plains surtout de la difficulté à trouver des explications sur la situation dans tel ou tel sous-domaine.
Parce que le problème ce n'est pas tant qu'il existe Foo, Bar, Baz, Qux, Flarp, Corge et Grault qui font plus ou moins la même chose. Ça c'est plutôt bien, en fait : in varietate concordia et tout et tout. Le problème c'est surtout que la doc de Foo ne mentionne même pas Bar, la doc de Bar mentionne brièvement Foo mais n'explique pas clairement si Bar remplace Foo ou peut cohabiter avec lui, la doc de Qux ne dit pas qu'il est à moitié inachevé, la doc de Corge est écrite par des gens qui détestent Qux donc ils en disent délibérément du mal, la doc de Flarp ne parle que de Flarp donc vous n'arrivez pas à savoir comment il s'articule avec Foo, Bar et Qux, et la doc de Grault, évidemment, date de 1999 donc passe la moitié de son temps à vous expliquer comment l'installer sous Solaris.
Ah et bien sûr, vous avez une interface graphique qui utilise probablement un de ces outils, mais vous ne savez pas lequel, et vous ne savez pas comment chercher cette information. Ça c'est vraiment ce qui me met hors de moi.
Et pour couronner le tout, vous avez un million de pages Web qui prétendent vous expliquer comment faire <truc> sous Linux, sans vous expliquer lequel de ces outils elles prétendent utiliser. Sans commencer par un avertissement en gras pour dire que ce qui suit s'applique uniquement à ceux qui utilisent Qux. Et vous avez un million de débutants (pressés et qui n'ont pas envie d'apprendre, juste de régler leur problème) qui vont aléatoirement suivre les conseils de ces pages Web (ou, maintenant, demander à des IA sans leur donner les infos nécessaires, et suivre les hallucinations de ces IA), peut-être éditer les mauvais fichiers de config qui ne vont avoir aucun effet jusqu'au jour où leur système passe de Bar à Qux et là le fichier de config qu'ils avaient édité et oublié qu'ils ont édité des années avant se met à prendre effet et ils ne comprennent rien pourquoi tout est cassé.
Ce qui manque surtout, selon moi, ce sont des gens qui essaient d'expliquer la situation d'ensemble. Idéalement, la doc de chacun des projets Foo, Bar, Baz, Qux, Flarp, Corge et Grault devrait mentionner honnêtement chacun des autres, et surtout, comment ils s'articulent avec le projet dont cette doc parle, et comment savoir auquel on a affaire. Et plus généralement, dans toutes sortes de sous-domaines de l'écosystème, on a besoin de gens pour écrire des pages donnant the big picture : quelles sont les pièces du puzzle dans ce domaine, quels sont les choix possibles, et quelles sont les façons de les assembler.
⁂
Je devrais sans doute donner des exemples.
Le plus évident, c'est sans doute la manière dont le noyau Linux
n'arrête pas de changer d'avis sur le filtrage réseau. Depuis le
temps que j'utilise Linux, j'ai vu passer successivement : ipfwadm,
ipchains, iptables, nftables et bpfilter/ebpf (je ne suis pas bien sûr
si bpfilter
et ebpf
sont synonymes ou quoi). Cinq
mécanismes de filtrage réseau en à peine 30 ans, ça veut dire qu'il y
en a un nouveau tous les 6 ans en moyenne : c'est vraiment une blague
d'avoir autant la bougeotte. Mais à la limite, ce n'est pas tellement
l'enjeu. Le problème est surtout qu'il ne semble y avoir aucun
document clair qui explique ces cinq mécanismes, leur histoire
(pourquoi on a cru bon de devoir changer aussi souvent), leur rapport,
qu'est-ce qui est complètement obsolète, juste déprécié, qu'est-ce qui
peut cohabiter avec quoi, comment ça interagit si on essaye d'en
utiliser plusieurs à la fois, etc. Si je
fais une
recherche Google de ces termes, je devrais tomber
immédiatement sur une page dans le répertoire Documentation
du
noyau qui explique clairement comment les pièces s'articulent : au
lieu de ça, je tombe sur des forums de discussion où les gens sont
tout embrouillés. Voilà l'exemple parfait de ce qui ne va pas.
À un plus haut niveau de configuration réseau, on a aussi toutes
sortes de possibilités, notamment le tristement
célèbre Network Manager
qui, si vous le laissez
tourner, tient à refaire absolument toute la configuration réseau à sa
propre sauce, si bien qu'aucune des commandes habituelles ne marchera
comme on s'y attend, et vous serez complètement confusé quant au
pourquoi, parce que la doc que vous lisiez n'a pensé à vous
dire attention ! si vous utilisez Network
Manager, il faut tout faire autrement, ne lisez pas plus loin
cette doc
.
Ceci étant, l'exemple des paragraphes précédents n'est pas tellement typique parce qu'il résulte plus de décisions concertées de remplacer un outil par un outil jugé plus adapté que de tensions et conflits entre communautés dans l'écosystème. Un autre exemple serait la gestion du son : vous avez OSS, ALSA, PulseAudio, Jack et maintenant PipeWire. La version courte, c'est qu'OSS est obsolète (mais évidemment il y a toujours des pages Web qui en parlent), ALSA est le mécanisme audio principal du noyau Linux, qui a aussi une composante userland (i.e., hors noyau), mais des gens n'en sont pas satisfaits pour différentes raisons et ont imaginé des couches au-dessus d'ALSA pour le simplifier ou le faire fonctionner dans un contexte plus large, mais évidemment ils ne sont pas d'accord entre eux, donc il y a eu PulseAudio et Jack, qui sont concurrents (je crois… mais peut-être qu'ils peuvent quand même parler entre eux ?), et PipeWire dont on me dit qu'il résout justement le problème de cohabitation entre PulseAudio et Jack. Fort bien : encore une fois, je ne me plains pas tellement du bordel, je me plains de la difficulté à trouver des explications claires sur ce qui fait quoi.
Il y a, bien sûr, l'impression,
qui est un chaos complet depuis
belle lurette. Je continue à ne rien comprendre à la manière dont
interagissent CUPS, linux-printing, foomatic, les
fichiers PPD, GhostScript, et mon imprimante. (La
dernière évolution c'est que des gens ont eu l'idée d'imaginer
l'impression driverless
, et évidemment personne
n'explique par quelle magie une telle chose serait censée être
possible : les drivers, ils ne sont pas là pour décorer, ils
remplissent une fonction, donc ce serait sympa d'expliquer qui est
censé remplir cette fonction à leur place. En tout cas, comme je le
racontais dans ce billet, quand
j'ai voulu tester avec ma nouvelle imprimante
Brother HL-L5210DW toute neuve, quand j'ai essayé
d'imprimer une page de test, ben elle a simplement craché 50 pages de
symboles aléatoires avant que je réussisse à l'interrompre, parce
qu'évidemment s'il n'y a pas de driver pour transformer la page de
test en quelque chose que l'imprimante comprend, ben ça fait n'importe
quoi.) Toujours est-il que maintenant, quand je veux imprimer, j'ai
le choix entre trois queues d'impression différentes, selon que le
système parle à l'imprimante
en PPL, BRscript (qui est en fait du
PostScript), PDF via CUPS,
ou PDF directement envoyé à l'imprimante, et chacune de
ces solutions a des problèmes et limitations subtilement différents
(recto-verso qui ne marche pas bien dans certaines orientations,
transparence qui pose des problèmes parce que PostScript ne connaît
pas la transparence, polices qui disparaissent, etc.). Bon, une
partie du problème est sans doute que le format PDF est
lui-même un labyrinthe de bizarreries : mais ça n'aide pas que je
n'aie aucune idée de comment fonctionne l'impression dans son
ensemble, et il n'y a aucune doc claire.
Encore un exemple : je tape avec un clavier QWERTY américain, et
pour les accents français et toutes sortes d'autres caractères
j'utilise
une touche
Compose (par exemple, pour taper un ‘é’ je tape
Compose-apostrophe-e ou bien Compose-e-apostrophe). C'est assez
commode (j'ai même convaincu ma maman de s'en servir) et ça a
l'avantage de marcher pour plein de symboles de plein de langues (pas
besoin de passer à un clavier allemand pour taper des umlaute, ou
hongrois pour taper des doubles accents aigus). J'en suis très
content, mais le mécanisme sous-jacent est incroyablement
labyrinthique, et dès qu'on fouille on ne comprend plus rien.
Notamment, je remarque qu'il y a des différences subtiles mais réelles
dans le fonctionnement de la touche Compose selon que je l'utilise
dans un xterm ou dans un programme Gnome : par exemple,
dans un cas le fichier .XCompose a un effet, dans l'autre
cas il n'en a pas ; dans un xterm, je peux taper
Compose-p-o-o pour avoir l'emoji U+1F4A9
PILE OF POO, mais dans un gnome-terminal ça ne
marche pas ; mais symétriquement, dans un gnome-terminal
je peux taper Control-shift-u et saisir un numéro Unicode pour entrer
ce caractère directement, et dans un xterm je ne peux
pas. Tout ça est quand même sacrément la merde, ça veut dire qu'il y
a au moins deux listes différentes de séquences Compose possibles, et
je sais que l'une d'elle (celle gérée, je suppose, par la libX11) est
dans /usr/share/X11/locale/en_US.UTF-8/Compose mais je
n'ai jamais réussi à trouver où était l'autre (celle gérée, je
suppose, par Gtk), et, surtout, comment je peux y ajouter
des choses que je veux pouvoir taper facilement. Et ce n'est pas
tout, parce qu'entre mes machines Debian et mes machines Ubuntu (ou
peut-être à cause du fait que sur ces dernières je suis sous Gnome et
pas sur les autres), la touche Compose a un comportement différent
aussi : sur mes machines Ubuntu, taper Compose fait apparaître un
petit cercle en pointillés pour montrer qu'il attend quelque chose.
Je subodore que c'est parce que Gtk lui-même a plusieurs
gestions différentes possibles de la touche Compose, selon qu'il la
traite lui-même ou qu'il la subdélègue à un mécanisme général de
méthodes d'entrées (qui lui-même doit exister en plusieurs variantes).
Toujours est-il que c'est un puzzle, et que ce dont je me plains n'est
pas tant l'existence du puzzle mais le fait que personne n'ait écrit
une page claire expliquant quelles sont toutes les pièces du puzzle
(j'ai entendu parler de trucs appelés ibus
, scim
et xim
, mais je ne sais pas comment ils interagissent[]) et
comment elles s'articulent.
(Cette
question montre que je ne suis pas le seul à ne pas comprendre ;
et même s'il y a des bouts d'explications, que j'ai postés en
commentaires, ici
et là,
l'ensemble du puzzle est loin d'être clair.)
[] Sous-exemple : de ce que je comprends
de cette
page, lancer GTK_IM_MODULE="xim" gnome-terminal
devrait me fournir un gnome-terminal qui utilise la
méthode historique d'entrée de X, donc la touche Compose devrait se
comporter exactement comme dans un xterm. Mais non,
Compose-p-o-o n'y marche pas, alors que dans xterm ça
marche. Si je passais des heures à enquêter, je finirais sans doute
par comprendre ce qui se passe, mais je n'ai pas ce temps, et je ne
comprends pas pourquoi ce serait à moi de faire ce travail
d'investigation au lieu qu'une doc me donne simplement la réponse.
Pour finir avec un exemple plus anecdotique, mais qui montre que
les puzzles peuvent se cacher même au sein d'une application qu'on
pouvait imaginer unifiée : je me suis rendu compte (en voulant changer
la couleur des sous-titres d'une vidéo pour gagner en contraste) qu'il
existe au moins deux mécanismes différents d'affichage de sous-titres
dans le programme MPlayer (en plus de ça, il existe je ne sais combien
de formats de sous-titres, et probablement des interactions
compliquées entre le format de sous-titres et le mécanisme
d'affichage). La doc, évidemment, semble supposer que ce fait est
évident pour tout le monde, au lieu de contenir un gros
avertissement attention ! cette option ne marchera que pour le
mécanisme Foo d'affichage des sous-titres, et si vous cherchez à
l'utiliser avec le mécanisme Bar, ça n'aura aucun effet et vous vous
demanderez pourquoi c'est le cas : voyez telle option pour plus
d'explications
.
Ah oui, et récemment j'ai aussi voulu comprendre comment faire pour
demander à pdfLaTeX d'utiliser une police
vectorielle TTF (en l'occurrence FreeSerif dont je
voulais utiliser le symbole ‘🕉︎’/‘ॐ’). En
fait, ce
n'était pas si compliqué, mais j'ai perdu énormément de
temps parce que diverses pages m'ont mis sur la voie des
fichiers VPL et VF, qui sont probablement
une façon différente mais obsolète de faire la même chose, mais
évidemment aucune page ne disait attention, il y a plusieurs façons
d'arriver à ce genre de choses, et voici comment elles
s'articulent
.
⁂
Bon. Je pense que la meilleure façon de terminer ce billet et ma métaphore du puzzle est de citer telle quelle la fin de mon roman préféré, La Vie mode d'emploi de Georges Perec (désolé si c'est une sorte de divulgâchis), qui, pour peu qu'on imagine que le ‘W’ fait référence à Wayland et le ‘X’ à X11 (qu'il prétend remplacer), pourrait s'appeler Linux le manuel d'utilisation tant il décrit parfaitement la frustration de ne pas comprendre comment les morceaux du puzzle s'imbriquent et comment je pourrais utiliser l'un à la place de l'autre :
Sur le drap de la table, quelque part dans le ciel crépusculaire du quatre cent trente-neuvième puzzle, le trou noir de la seule pièce non encore posée dessine la silhouette presque parfaite d'un X. Mais la pièce que [Bartlebooth] tient entre ses doigts a la forme, depuis longtemps prévisible dans son ironie même, d'un W.
Voilà, donc le puzzle, pourquoi pas, mais donnez-nous un mode d'emploi correct !