David Madore's WebLog: 2026-01

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.

⁂

[Lire la suite…]

Je vais de nouveau tenter d'écrire un ou plusieurs billets pas trop interminables. On va voir comment ça va marcher.

Ce que je veux dire ici va recouvrir en partie ce que je disais déjà dans ce billet récent mais concerne un aspect un peu différent : la difficulté à compiler des programmes sous Linux. Et ce n'est pas juste que ça devient difficile, c'est aussi que plus grand-monde ne le fait, et les deux aspects forment un cercle vicieux.

👉︎ Quelques explications terminologiques pour les personnes pas trop familières de l'informatique : Quand on [= des humains] écrit un programme, la forme textuelle du programme (ou package) sur laquelle on travaille est appelée le code source, ou de façon un peu abusée, le source (notez le genre masculin). La forme que l'ordinateur est capable d'exécuter est appelée l'exécutable binaire, ou de façon un peu abusée, le binaire. Comme le binaire est illisible et non éditable en pratique par un humain, et qu'il dépend des détails de l'ordinateur sur lequel on va le faire tourner (type de processeur, système d'exploitation, etc.), on préfère souvent distribuer le source et refabriquer le binaire au besoin. L'opération par laquelle on passe du source au binaire est appelée la compilation (bon, c'est simplifié parce qu'il peut y avoir d'autres opérations qui vont avec, par exemple de préparer des fichiers de données annexes, mais c'est l'idée). Conceptuellement, ce n'est pas compliqué, on applique un programme appelé compilateur sur le source et il fabrique le binaire (adapté au processeur et à l'OS souhaités). En pratique, le diable est dans les détails, il y a énormément de bouts de source à compiler dans un ordre bien précis, souvent avec des dépendances compliquées, il faut donner des options très précises au compilateur, et il existe toutes sortes de mécanismes différents servant à lancer la compilation comme il faut.

À titre d'exemple, je compile mes propres Firefox[#] à partir du source. Je ne connais absolument personne d'autre qui fasse ça. Pourtant, je fréquente pas mal de geeks, mais je n'ai jamais rencontré qui que ce soit d'autre que moi qui compile Firefox (régulièrement, ou même de temps en temps pour essayer) et qui ne soit pas dans — ou facilement assimilable à — l'une des deux catégories évidentes : ⓐ développeur pour Mozilla, ou bien ⓑ mainteneur d'une distribution Linux. Absolument personne. Je sais parce que j'ai souvent fait des appels à l'aide suite à des problèmes de compilation de Firefox, et personne ne répond jamais. Tout le monde télécharge simplement son Firefox sous forme de binaire sur le site de Mozilla, ou utilise celui de sa distribution.

[#] La principale raison pour laquelle je le fais est qu'il y a un bug insupportable dans Firefox depuis plus de 20 ans(!) qui fait qu'il transforme des espaces insécables (U+00A0 NO-BREAK SPACE) en espaces normales (U+0020 SPACE) lors du copier-coller dans de nombreuses circonstances. Comme je ne veux pas que ce billet devienne interminable, je ne donne pas plus de détails, mais voyez ce fil Bluesky si vous voulez en savoir un peu plus sur le fait que ce bug a été partiellement mais non complètement corrigé, et pourquoi ils ne veulent pas le corriger complètement. Bref, j'ai un patch très facile qui le corrige en grande partie (mais pas complètement non plus) et je tiens à l'appliquer.

Je ne veux pas trop jouer au vieux con sur l'air de c'était mieux âââvant, mais j'ai connu une époque où c'était assez normal de compiler beaucoup de programmes qu'on utilisait. Les raisons pouvaient varier (programme pas packagé par la distribution, souhait d'appliquer un patch ou de changer les options de compilation ou de configuration ou les d'utiliser des bibliothèques différentes, ou d'avoir une version différente, ou simple question de principe), en tout cas, c'était courant.

Et ce n'est pas juste que c'était courant : c'est le principe d'utiliser des logiciels libres, ou open source, que ce soit possible. C'est la liberté la plus basique derrière le terme de logiciel libre, c'est la base de la notion d'open source, et le problème fondamental avec les libertés qu'on n'utilise pas, c'est qu'elles finissent toujours par s'éroder.

Je ne dis pas que c'était terriblement facile. Quand j'ai commencé à utiliser des Unix, c'était vraiment assez chaotique, généralement il fallait éditer des fichiers d'options de compilation pour dire à quoi ressemblait le système pour lequel on voulait compiler (et parfois on n'avait aucune idée de la réponse à des questions du style les gestionnaires de signaux se comportent-ils façon BSD ou façon System V ?). Puis est venu un jeu d'outils appelé les GNU autotools qui fabriquent un script appelé configure qui détecte tout seul plein de choses sur le système au lieu de demander à l'opérateur humain de répondre à toutes ces questions : très commode quand ça marchait, mais souvent ça ne marchait pas et on ne savait pas comment réparer le problème[#2]. Néanmoins, ils avaient l'avantage d'être assez standards, donc on savait à quoi s'attendre et comment s'en servir.

[#2] Ceci est un phénomène récurrent et courant en informatique : plus quelque chose est automatisé, plus c'est commode quand ça marche, mais compliqué de réparer les choses quand quelque chose ne va pas. Il y a certainement des moyens de réduire la tension entre les deux (par exemple fournir des outils capables de décomposer les étapes, montrer ce qu'ils font à chaque étape, proposer des moyens de modifier le comportement à chaque niveau, etc.), mais ils ne sont pas assez mis en œuvre.

A contrario, distribuer des programmes sous forme binaire était terriblement difficile, quasi impossible, il y a 25–30 ans : Linux était quasiment incompatible avec Linux, chaque distribution avait ses propres idiosyncrasies, rendant la compilation quasiment obligatoire. Soit votre distribution se chargeait de vous donner exactement le bon binaire pour vous, soit il fallait le produire par vos propres moyens à partir du source.

Il me semble qu'il y a eu plusieurs évolutions. Distribuer les binaires est devenu plus facile : les distributions Linux ont fait des efforts pour se rendre au moins minimalement compatibles entre elles, les Unix autres que Linux (et éventuellement les *BSD) ont quasi disparu, l'espace disque et le temps de compilation sont plus abondants ce qui permet plus facilement aux auteurs d'un projet de fournir plein de binaires précompilés ; et aussi, divers systèmes sont apparus (Snap, Flatpak, Docker, etc.), que je trouve absolument abominables mais c'est un autre débat, pour permettre de distribuer un programme en même temps que toutes ses dépendances sous une forme qui est censée « juste marcher ». Peut-être aussi que plus de programmes sont fournis par les distributions.

Toujours est-il que ces évolutions ont diminué le besoin de recompiler à partir du source. Et je crois que les gens qui ne sont ni ⓐ développeurs du projet Machintruc ni ⓑ mainteneurs de celui-ci pour le compte d'une distribution, compilent de plus en plus rarement.

Le principal projet qui me semble faire encore exception, c'est le noyau Linux lui-même. Parce qu'il est particulièrement facile à compiler vu qu'il n'a essentiellement pas de dépendances, et parce que le gain est important vu la myriade d'options qu'on peut régler en le compilant, ou de patchs qu'on peut vouloir sélectionner, si bien qu'il est difficile pour les distributions de fournir une version compilée qui convienne à tout le monde. Mais même le noyau, je pense que beaucoup moins de gens le compilent maintenant qu'il y a 25–30 ans ; et l'apparition de code Rust dedans ne va certainement pas simplifier les choses.

Évidemment, il y a des nuances selon les distributions Linux : Gentoo, par exemple, part du principe qu'on compile (quasiment) tout localement. Mais ce n'est pas la compilation au sens dont je parle ici : je parle de recompiler la version upstream, celle qui est publiée par les auteurs du programme, pas un package source créé par les mainteneurs de la distribution (et qui est garanti fonctionner parce que tout a été fait pour, mais qui n'est pas fondamentalement différent d'un binaire quand il s'agit de bidouiller dans les options). Idem pour Nix[#3], qui utilise l'approche consistant à tout figer au bit près. Tout ça ne règle pas le problème fondamental sous-jacent : pour qu'un logiciel soit véritablement open source, il faut qu'on puisse lire, éditer et recompiler son source (celui distribué par les auteurs du projet, pas une version spéciale adaptée pour la distribution), sans que ce soit impossiblement compliqué ; et ce, même si on n'est pas développeur du projet ou mainteneur d'une distribution, et sans que la distribution ait mâché le travail pour nous.

[#3] Les fans de Nix sont insupportables à venir toujours faire la pub de leur truc : Nix n'est pas une solution au problème que les sources sont difficiles à compiler parce que les dépendances sont devenues impossiblement touffues et parfois contradictoires — Nix est un constat d'échec et une façon de contourner le problème en actant ce constat d'échec, mais qui ne règle rien au problème lui-même.

Et il me semble que plus le temps passe, plus la compilation devient difficile. Ça peut être lié à la multiplicité des dépendances, ou au fait qu'elles soient extrêmement pointilleuses (je veux utiliser la version 1.729.42b(8)-deadbeef de la libfoobar et pas une autre). Ça peut être lié aux langages utilisés. Ça peut être simplement le fait que comme de moins en moins de non-développeurs compilent, les auteurs font de moins en moins d'efforts[#4] (les mainteneurs pour les distributions vont de toute façon tout refaire à leur sauce). Ou peut-être que c'est simplement lié à la démocratisation de Linux et du fait que les utilisateurs n'aient pas envie de compiler des choses (mais ceci ne peut pas vraiment expliquer la diminution absolue du nombre de gens qui le font, seulement une diminution relative).

[#4] À l'inverse, on vous pousse à récupérer un binaire, et tout est fait pour rendre ça facile : on vous dit souvent carrément de faire curl someinstallscript | sh pour, en gros, aller chercher un script en ligne et l'exécuter directement (ce qui est d'ailleurs un cauchemar absolu question sécurité). En tout cas, autrefois, le lien download d'un projet Linux typique pointait vers le source, maintenant il pointe vers le binaire (et pour le source on vous renvoie typiquement juste à une page GitHub sans explications).

La difficulté peut prendre diverses formes. Parfois c'est simplement une absence d'explications sur comment compiler le projet : il est difficile d'y voir là autre chose qu'une attitude du style les développeurs savent comment faire, les mainteneurs des distributions feront leur propre sauce, et les autres n'ont qu'à récupérer un binaire. (Ou si ce n'est pas un manque d'explications sur comment compiler, ça peut être sur la façon d'installer le(s) binaire(s) une fois compilé(s), ou même sur l'endroit où ils se trouvent à la fin de la compilation.) Parfois c'est une absence d'explications sur l'outil utilisé[#5]. Le bon vieux système du ./configure --prefix=/some/where && make && make install avait toutes sortes de problèmes, mais au moins on savait quoi faire parce qu'il était standard au point d'être quasi universel.

[#5] Par exemple, les projets Rust utilisent cargo : fort bien, mais il faut se rappeler que la personne qui cherche à compiler le projet ne connaît peut-être rien de Rust (ou peut-être juste assez pour changer, disons, un message d'erreur ou un comportement trivial), et n'a peut-être aucune idée de comment utiliser cargo ni ne veut apprendre. Pour un outil comme make qui peut servir à n'importe quel langage, il est raisonnable de demander que celui qui veut compiler apprenne à s'en servir, mais si l'outil est spécifique à un langage, ce n'est pas raisonnable vu le nombre de langages de programmation différents qui existent. (Et on ne peut pas simplement renvoyer à la doc, qui est généralement beaucoup trop longue, trop générale, et trop orientée pour les gens connaissant déjà le langage et ses conventions, pour pouvoir servir aux gens qui veulent juste compiler une fois un projet utilisant cet outil. Ou alors l'outil doit prévoir une doc spécifique pour ce cas.)

Parfois c'est une difficulté cachée sous une façade en trompe l'œil on a fourni un script qui permet de tout compiler automagiquement (pour la compilation de Firefox, ce script s'appelle mach), ce qui semble effectivement facile mais se transforme en cauchemar dès que quelque chose ne va pas exactement comme prévu (cf. ma note #2 ci-dessus) ou dès qu'on sort du périmètre exact du script magique qui fait tout.

Certains sont d'ailleurs tellement pinailleurs qu'ils commencent par télécharger la version exacte du compilateur qui va faire marcher la compilation (Firefox est de ce genre : il veut une version tellement précise de CLang et Rust et compagnie que le script magique qui le compile commence par télécharger les binaires de tout ça). On se demande un peu quel est l'intérêt de compiler si en fait la compilation consiste à aller chercher d'abord les binaires pour le compilateur qui est le seul à pouvoir servir ! Le source est ce qui est censé pouvoir permettre de reproduire l'outil qu'on compile ab ovo à partir d'outils standards, pas à partir d'une version unique du compilateur que vous ne pouvez pas reproduire elle-même.

Un problème supplémentaire est que ces outils compliqués ont tendance à devenir de moins en moins reproductibles : ils vont stocker des choses dans votre répertoire personnel ($HOME)[#6], soit des bouts de code téléchargés ou déjà compilés ou carrément installés localement, soit un état global (options de configuration ou de compilation, variables diverses), et comme on ne sait pas où et comment ces choses sont stockées ni ce qui peut l'être, on perd l'aspect reproductible d'une compilation. Là aussi, la documentation peut être particulièrement opaque pour qui n'a pas envie d'apprendre à se servir en détail de l'outil, juste de compiler un projet bien précis.

[#6] La pollution du $HOME est une des choses qui m'énervent particulièrement : autrefois, ça ne se faisait jamais, mais maintenant tout le monde semble trouver normal de faire ses besoins malodorants dans un sous-répertoire de $HOME sans qu'il y ait un avertissement préalable. Comme le mien est distribué entre plusieurs machines et fait l'objet de sauvegardes abondantes, l'espace dedans est particulièrement cher : je n'ai pas envie que la moindre compilation le remplisse de giga-octets de données partiellement compilées. Si je lance la compilation dans /usr/local/src/somepackage-0.42 j'entends bien qu'il se serve de ce répertoire et de ce répertoire seulement pour toute écriture. Quand j'ai un doute, je compile sous le nom d'un utilisateur qui n'a pas le droit d'écrire dans son $HOME, ce qui provoque une erreur s'il cherche à le faire : mais si ça arrive, ça ne me dit quand même pas comment remédier au problème.

Toujours est-il que Linux évolue de plus en plus dans la direction d'Android[#7]. Il y a bien quelques logiciels open source dans les applications Android, mais essayer de fabriquer un .apk binaire à partir du source est une tâche incroyablement difficile, et je ne parle pas de recompiler le système Android lui-même (en gros il vous faudra une machine dédiée à ça, avec exactement la bonne version de tous les outils). Et de toute façon, même si vous y arrivez, vous ne pouvez même pas vraiment vous en servir, parce que vous ne pouvez pas signer l'application avec la clé des distributeurs, donc le système Android, sous le prétexte de sécurité (bidon), ne vous laissera pas installer la version que vous aurez compilée à moins d'effacer totalement la version antérieure (et donc de perdre toutes vos données). Bref, tout est fait pour que vous n'ayez aucune liberté dans l'affaire (cf. cet autre billet).

[#7] Oui, Android est un Linux en interne, mais il n'y ressemble pas du tout, et il n'est pas du tout fait pour vous laisser bidouiller avec, cf. ce que j'écrivais il y a déjà 11 ans.

Je propose d'utiliser le terme clopen source (clopen est un mot-valise entre closed et open, souvent utilisé en topologie) pour parler de ces projets qui sont théoriquement open source, mais en pratique faire quelque chose du source est tellement difficile (soit parce qu'il est difficile à compiler ou à comprendre comment compiler, soit parce qu'il y a d'autres barrières comme les signatures Android dont je viens de parler) que c'est presque complètement théorique.

Sur le papier, l'open source a gagné, beaucoup de projets importants ont maintenant un code source public, mais en pratique, c'est surtout le clopen source qui a gagné : vous avez accès à du code, mais c'est tellement difficile d'en faire quoi que ce soit que personne n'en fait rien, et en plus tout le monde s'en fout. Est-ce que ça valait la peine de se battre pour la liberté des logiciels si c'était pour en arriver là ?

Après avoir écrit un ou deux billets sur l'« intelligence » artificielle, ça fait longtemps que je me dis qu'il faut que j'en écrive un sur l'intelligence « naturelle », humaine, et sur les tentatives pour la mesurer. J'y suis poussé par une conversation sur Twitter (où, sans surprise, il n'a pas fallu longtemps pour que je croise un raciste pas du tout subtil dans sa tentative de me convaincre que si les pays africains sont moins « développés » c'est qu'il y a une différence d'intelligence d'origine génétique entre les populations — ben voyons).

J'aime bien dire de façon courte mais sèche que les mesures de QI sont une bonne façon de tester l'intelligence parce que les gens qui y croient sont des idiots complets. Mais essayons de développer un peu.

☞ Qu'est-ce que l'intelligence ?

Le principal problème avec l'intelligence, déjà, c'est que personne ne sait ce que c'est. Si vous ouvrez N dictionnaires, vous trouverez N définitions différentes, chacune énumérant d'ailleurs souvent plusieurs traits ou caractéristiques, le rapport entre lesquelles est laissé en exercice au lecteur. Wikipédia en français, par exemple, écrit :

L'intelligence est l'ensemble des processus trouvés dans des systèmes, plus ou moins complexes, vivants ou non, qui permettent d'apprendre, de comprendre ou de s'adapter à des situations nouvelles. La définition de l'intelligence ainsi que la question d'une faculté d'intelligence générale ont fait l'objet de nombreuses discussions philosophiques et scientifiques. L'intelligence a été décrite comme une faculté d'adaptation (apprentissage pour s'adapter à l'environnement) ou au contraire, faculté de modifier l'environnement pour l'adapter à ses propres besoins.

— tandis que pour Wikipédia en anglais :

Intelligence has been defined in many ways: the capacity for abstraction, logic, understanding, self-awareness, learning, emotional knowledge, reasoning, planning, creativity, critical thinking, and problem-solving. It can be described as the ability to perceive or infer information and to retain it as knowledge to be applied to adaptive behaviors within an environment or context.

On sent bien là une tension entre différentes définitions et entre différents domaines : biologie de l'évolution, sciences cognitives, philosophie, neurologie, psychiatrie, psychologie, cybernétique, que sais-je encore, chacune peut avoir sa propre définition de l'intelligence avec un rapport pas forcément très clair.

Mais bon, le fait qu'on ne sache pas définir quelque chose n'est pas forcément un signe que cette chose n'existe pas : c'est probablement encore plus difficile de définir ce qu'est la beauté que l'intelligence, ce qui ne veut pas dire que le mot soit dénué de sens (nonobstant le fait qu'il est éminemment subjectif et variable selon la personne qui juge).

☞ L'idée des tests objectifs

La différence, c'est qu'il est largement admis que la beauté est une caractéristique essentiellement subjective et culturelle (ce qui n'est pas pour autant dire que tout le monde est également beau), et que ça n'a pas de sens d'essayer de la quantifier, il y a beaucoup de gens, y compris avec une certaine formation scientifique[#], qui voudraient nous faire croire que l'intelligence est quelque chose de précisément et objectivement mesurable, voire, qu'ils ont effectivement des tests permettant de faire ça.

[#] Dans une direction un peu différente, il y a aussi (notamment autour d'un gourou appelé Eliezer Yudkowsky, dont je n'ai jamais bien compris pourquoi plein de gens l'écoutent ni quelles compétences il est censé avoir sur le sujet) des gens qui vouent carrément une sorte de culte à l'intelligence et/ou à la « rationalité », humaine ou artificielle. Ils ont même développé une sorte de catéchisme ou de mythologie, avec des notions qu'on peut difficilement qualifier d'autre chose que religieuses — ici une sorte de resucée du pari de Pascal. Je n'en parle pas plus ici parce que ce n'est pas vraiment mon sujet, mais c'est difficile de ne pas mentionner ces gens dont le rapport à la notion d'intelligence semble assez proche de celle de beauty influencers à la beauté ou de fitness influencers à la forme physique.

Évidemment, on peut toujours postuler que l'intelligence est justement et par définition ce que mesure tel ou tel test d'intelligence existant, auquel cas, oui, l'intelligence a un sens, mais la question est maintenant si ce sens a le moindre intérêt ou le moindre rapport avec ce qu'on entend informellement par le mot.

Pour commencer, les premiers tests d'intelligence étaient plutôt faits pour identifier les enfants présentant des retards de développement mental (soit dans l'idée de les aider spécifiquement, soit dans l'idée de les écarter, tout ça n'est pas forcément très clair ni très cohérent mais peu importe ici). L'idée de prendre une méthodologie développée (et peut-être pas de façon très soigneuse) pour diagnostiquer des problèmes et essayer de s'en servir pour définir une caractéristique positivement valorisée, c'est peu comme si des gens se mettaient à se vanter d'avoir un test de diabète très bas et en faisaient un signe qu'ils ont une constitution particulièrement vigoureuse.

☞ Remarques sur mon cas personnel

À ce point il faut sans doute que je fasse un avertissement concernant une possible partialité liée à mon cas personnel. Plein de gens ont essayé, notamment quand j'étais gosse (notamment parce que j'avais une certaine précocité dans ma propension à faire des maths, je l'ai déjà raconté), mais encore maintenant, de me persuader que j'étais très intelligent, et ce genre de jugement a pu me causer toutes sortes de problèmes émotionnels ou de complexes (je ne prétends pas que ce soit la seule cause, mais ça a certainement joué en partie), notamment des difficultés à sociabiliser avec mes pairs. Je soupçonne que les enfants qu'on soumet à des concours de beauté doivent avoir peu le même genre de problèmes. En tout cas, si vous voulez transformer un gamin en petit con prétentieux et pontifiant comme je le suis, répétez-lui qu'il est très intelligent.

Certes, je n'ai jamais fait de test de QI officiel. J'ai vu passer toutes sortes de questions, de tests se voulant plus ou moins sérieux, et je les trouve suffisamment idiotes (notamment dans le style ah oui là je vois très bien que la personne qui a conçu la question veut que je réponde ceci-cela pour avoir juste, et je pense que son raisonnement est assez bidon) pour être raisonnablement convaincu que j'aurais une bonne note à ces trucs et aussi sur le fait que ça ne dit rien de pertinent sur moi à part ma capacité à reconnaître ce qu'on veut me faire dire sur des questions complètement connes.

Mais si vous pensez que le petit con prétentieux que je suis est effectivement « intelligent », alors il faudra au moins donner un minimum de créance à ce que je vais dire sur le fait que je vois bien, de l'intérieur, que cette capacité qu'on prétend mesurer n'a pas grande signification. (Et à l'inverse si vous trouvez que je ne suis pas « intelligent », alors c'est que ce genre de questions que je trouve faciles, et les jugements à ce sujet, n'ont pas beaucoup de sens.)

Pour être bien clair, je ne vais pas prétendre être stupide (en désignant par « stupidité » l'opposé supposé de l'« intelligence », qui est possiblement un peu mieux défini que l'intelligence). Je prétends surtout qu'il y a un gazillion de façons d'être « intelligent », que je suis certaines d'entre elles, et pas du tout d'autres (voire complètement idiot pour certaines), et que toute mesure de mon intelligence ou tout jugement à ce sujet en dit beaucoup plus sur la personne qui prétend mesurer[#2] qu'elle n'en dit sur moi.

[#2] De façon encore plus concise et provocatrice : si vous trouvez que je suis intelligent, c'est probablement juste que vous êtes souvent d'accord avec mes rants.

☞ Un million de dimensions d'intelligence

Car voilà mon problème numéro 1 avec la notion d'intelligence et toute tentative pour la mesurer, surtout avec un seul chiffre :

Je ne prétends certainement pas que tout le monde pense de la même manière. Ce que je prétends, c'est que les capacités intellectuelles sont si extraordinairement variées que tenter de les résumer en un seul test, pire, en un seul nombre, sans même être capable de définir le sens de la quantité qu'on cherche à mesurer, est une pure imposture scientifique.

Donc, la mesure du QI dit tout sur la personne qui mesure le QI (disons, celle qui conçoit le test, et peut-être aussi celle qui y croit) et essentiellement rien sur la personne à qui on fait subir le test.

(Ou pour parler comme un matheux : on a affaire à un espace de très grande dimension, si vous prenez une forme linéaire dessus, vous ne dites rien sur votre espace et tout sur la forme linéaire que vous avez prise.)

Pour prendre une comparaison, c'est comme si on essayait de mettre au point un « test de caractère » unique. Je ne prétends pas que tout le monde a la même personnalité : je veux bien qu'on essaie d'identifier et de reconnaître quelques traits de personnalité importants (la plupart des tests dans ce sens sont aussi sérieux qu'un horoscope, mais certains sont peut-être un peu moins du bullshit que les autres), mais essayer ensuite de donner un « score de caractère » qui serait un seul nombre, comme s'il y avait une seule dimension de personnalité, et parler de quelqu'un qui a un très bon score de caractère… ça ne dira pas grand-chose sur cette personne et beaucoup sur ce qui intéresse les concepteurs du test.

Il y a plein de façons de penser[#3] ou de faire usage de son cerveau : on peut être plus ou moins logique, plus ou moins intuitif, plus ou moins empathique, plus ou moins pratique, plus ou moins systématique, plus ou moins capable de se concentrer, plus ou moins capable de passer rapidement d'un problème à un autre, plus ou moins capable d'esprit de synthèse, plus ou moins doué pour s'exprimer avec des mots, plus ou moins précis et méticuleux, plus ou moins capable de mémoriser les détails d'une situation ou de les organiser en un motif cohérent, plus ou moins capable de convaincre les autres, plus ou moins observateur, plus ou moins instinctif, plus ou moins capable de retrouver des informations de sa mémoire, plus ou moins capable de concevoir des typologies, plus ou moins capable de généraliser ou au contraire de spécialiser, plus ou moins à l'aise devant les idées abstraites ou au contraire concrètes, etc. Toutes sortes de choses qu'on peut plus ou moins arbitrairement classer comme des formes d'intelligence ou pas. Essayer de mesurer un score dans chacune de ces caractéristiques a peut-être un sens (mais même pour ça, je vais formuler d'autres objections plus bas) : essayer de faire un score unique et appeler ça un quotient intellectuel est d'une connerie sans nom.

[#3] Bonne occasion de replacer une des citations de Heinlein (dans Time Enough for Love) que j'aime bien : A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. Chacune de ces activités requiert une faculté mentale différente (et je suis très bon pour certaines et très mauvais pour d'autres).

Les IA textuelles nous ont montré qu'il était, au moins en principe, possible d'être très doué sur certains domaines (par exemple, savoir très bien parler) et d'être totalement et complètement stupide sur d'autres : l'idée d'une intelligence « générale » est quelque chose de purement et simplement dénué de sens. Mais certains s'obstinent à croire à ce mirage.

☞ Le mirage de l'intelligence « générale »

Mon père m'avait raconté que, quand il était à l'université de Toronto, quelqu'un lui avait posé la question suivante : quelle est la raison derrière la répartition suivante des lettres de l'alphabet en deux lignes ?

A

E

F

H

I

K

L

M

N

T

V

W

X

Y

Z

B

C

D

G

J

O

P

Q

R

S

U

[Lire la suite…]