La mite et le maître

Le chat passe toute la journée à se prélasser au soleil. Les yeux fermés, mais sans dormir. Plongé dans ses pensées. Il essaie, entre autres, d'imaginer ce que c'est qu'attendre un maître. Jouer au maître, ça, il sait ce que c'est. Être le maître de la situation aussi. La seconde précise où il attrape une souris, celle où il flanque d'un coup de patte une mouche à terre. Quand il est le maître, l'essentiel est bien d'attendre. D'attendre le bon moment.

À la tombée du jour, une mite se pointe dans les parages. Pas trop près de lui, mais le chat a vite fait de la remarquer.

La mite est grasse, elle ne sent pas bon et fait du bruit quand elle respire, si bien qu'on a l'impression que l'air n'est pas sain. Le chat secoue la tête, il s'efforce de penser au chien, à la corde, à ce que c'est qu'attendre un maître qui n'arrive pas. Il s'efforce de ne pas entendre le bruit que fait la mite.

La mite bourdonne un petit peu, à moins qu'on puisse appeler ça chanter. Comme elle fait vibrer ses ailes, sa voix tremble elle aussi. Elle dit qu'elle attend le maître, mais elle est tellement agitée que c'est à peine si elle arrive à prononcer les mots.

— Le maître ? demande le chat en ouvrant un œil.

— Le maître, dit la mite. Le maître de tout.

— Le maître du chien ? demande le chat.

— De tout, y compris du chien, dit la mite. Le maître de tout et de tous.

Le chat se lève et grossit sa queue. Il dit que la mite ne fait que débiter des âneries. Le maître de tout et de tous, ça n'existe pas, dit-il, car il connaît des animaux qui n'ont pas de maître. Il pense à lui-même, à la chouette et au renard, puis, durant une brève seconde, au chien. La mite ferait mieux de déguerpir si elle ne veut pas que le chat lui apprenne la différence entre la gauche et la droite, entre devant et derrière, et lui fasse comprendre sur-le-champ qui c'est, le maître de tout et de tous. Le chat montre ses griffes, à gauche et à droite, devant derrière. Alors qu'il s'apprête à lever la patte pour frapper, une lumière s'allume dans la maison juste à côté.

La mite s'envole en disant :

— Le voilà ! Le voilà !

— Où ça ? Où ça ? demande le chat.

Ébloui par la lumière, il essaie de voir ce qui se passe dans la maison, mais sans distinguer le maître de tout et de tous.

La documentation piégeuse sur archlinux.fr

Si je m'en tiens à certaines interventions d'archers sur mon article précédent, l'installation de mon Arch m'aurait transfiguré : Arch est sur ma machine et je suis maintenant le maître de tout.

Maître mais un maître qui peste.

Arch est là, sur mon poste de travail depuis quelques jours, et je n'ai de cesse à pester. Je peste. Je peste contre tout. Presque tout. Enfin, surtout contre la documentation sur le wiki d'Archlinux.fr. Certes, cette documentation a au moins le mérite d'exister et l'on peut en remercier, comme c'est l'usage, la communauté des archers francophones. Mais, cela fait, qu'a-t-on fait ? Sinon des salamalecs. Autant dire, pas grand chose et, peut-être même, que l'on aurait mieux fait de s'en abstenir. Alors, allons un peu au-delà.

J'ai donné, dans mon article précédent, un exemple des difficultés ou des pièges que j'ai rencontrés ces derniers jours. Au vrai, je pourrai sans mal multiplier les exemples tant ils sont nombreux. Je regrette seulement de ne les avoir pas tous notés un à un, méthodiquement, pour les catégoriser.

Défaut de référence

Le premier type de pièges peut être qualifié de "défaut de référence". L'utilisateur nouvellement débarqué ne peut que difficilement l'éviter. Il ne connaît pas la distribution, ses commandes, ses particularités. Les utilisateurs chevronnés que sont les archers, eux, connaissent, savent, et d'ailleurs s'en félicitent à l'envi, toutes les recettes, toutes les subtilités, les moindres recoins de leur distribution, et ne peuvent, si l'on se fie au niveau de compétences affiché ou affirmé, qu'ignorer ces références. Ils n'en ont pas besoin. Eux savent comment passer d'une installation tout en CLI au mode graphique. Trois commandes. Tout au plus. À quoi bon les donner dans le petit guide d'installation… n'est-ce pas ?

Pourtant, si l'on en croit ce que d'aucun affirme, çà et là, l'installation d'une Arch c'est fait pour durer : on ne réinstalle pas son Arch tous les quatre matins, comme c'est le cas pour les distributions en sucre, marron et vert. De fait, je suis quelque peu sceptique sur la nécessité voire même la maîtrise réelle de ces procédures d'installation, dans le détail, par ceux mêmes qui s'en piquent. — On peut s'étonner en effet que seul Fred Bezies esquisse une réponse à la question : Comment fait-on, dans le "chroot", pour installer un logiciel ? J'aurais préféré ne pas revenir à zéro quand je me suis trouvé bloqué à la configuration du chargeur de démarrage (bootloader) : FAILED to set attribute Legacy BIOS Bootable on /dev/sd…. Problème et solution connus. Mais bon, à quoi bon, en effet, si l'on réinstalle son Arch tous les trois ans, préciser toutes les subtilités de ces procédures. Se rafraîchir la mémoire sans doute. Un divertissement, tout au plus.

Dès lors, il semble accessoire ou secondaire, peut-être, de proposer un "guide d'installation de base" au terme duquel la distribution de base serait parfaitement utilisable autrement qu'en CLI : connexion internet, dépôts importants activés, distribution mise à jour, environnement graphique, logiciels pour usage courant à savoir bureautique, audio/vidéo, navigateur Internet… Pourtant, n'est-ce pas là ce qu'on peut appeler une installation minimale ou de base pour un poste de travail en version "Desktop". Mais peut-être que le guide d'installation proposé sur le wiki d'archlinux n'est pas destiné à pareille utilisation. Qu'il n'est pas dans l'ordre des préoccupations des archers de satisfaire pareil usage. Défaut de référence, donc.

N.B. : Je regrette de n'avoir pas eu connaissance plus tôt des guides de Julien et de Fred. Simples, efficaces. Je m'en suis servi, a posteriori, pour peaufiner mon installation. Pendant que j'y pense, petite précision Fred : pour renseigner l'identité complète de l'utilisateur (full name), la commande est chfn -f "Christophe Gallaire".

Je sais donc je suis

L'installation d'une Archlinux de base, telle qu'on l'entend dans le guide disponible sur archlinux.fr, n'est nullement suffisante pour satisfaire à mon utilisation quotidienne. Je me suis heurté un certain nombre de fois à une documentation étonnamment imprécise ou confuse, une documentation tellement spécialisée parfois que les usages les plus "simples" ou les plus "évidents" sont tout bonnement écartés ou ignorés. Enfin, quand je dis "simple" ou "évident", "confus" ou "imprécis", il va s'en dire que c'est pour moi que cela est… Ce tour rhétorique n'efface pas pour autant l'enjeu majeur, me semble-t-il, d'une telle documentation — à moins de ne lui reconnaître qu'une seule fonction décorative — où la question de sa lisibilité ou de son accessibilité doit ou devrait primer sur la démonstration : Qui écrit ? Pour qui ? Pourquoi ? Problématique récurrente sur "Cyrille Borne et associés" ces derniers temps.

Je pourrais multiplier les exemples de ce type mais je vais me limiter à un seul, celui du dépôt communautaire "AUR" parce qu'il est à lui seul, je crois, assez éloquent.

Dans le guide disponible sur archlinux.fr, lorsque l'on procède à l'installation de base, une note précise que l'on peut en profiter pour installer le groupe "base-devel", lequel serait « nécessaire à l'utilisation de AUR » ; un lien renvoie, en complément d'information, vers une page de la documentation dédiée audit dépôt. On apprend alors que le groupe "base-devel" est une « dépendance implicite pour la plupart des paquets » disponibles sur le dépôt AUR.

Fred Bezies, dans son guide, fait des groupes "base" et "base-devel" le minimum vital et propose, par ailleurs, d'installer en plus un certain nombre outils qu'il juge « pratique » d'avoir dès le départ (zip unzip p7zip vim mc alsa-utils syslog-ng). "Vim" pour "vi", plutôt deux fois qu'une. Pour ce qui est des utilitaires de dé/compression, je crois que ça peut attendre. M'enfin, chacun voit midi à sa porte. À moins que… quelque chose ne m'échappe.

Julien, quant à lui, dans son guide, voit dans l'installation des groupes "base" et "base-devel" le moyen d'avoir un « système ArchLinux à jour » avec les « dernières versions de paquets » ainsi que les « outils nécessaires à une utilisation bureautique quotidienne ». Il propose lui aussi d'installer dans la foulée quelques outils supplémentaires (sudo vim zip unzip p7zip bzip2 tar) pour « pour avoir un système utilisable rapidement après l’installation complète ». Il prévient par ailleurs qu'il ne donne cette liste de logiciels qu'à titre indicatif parce qu'ils seraient « utiles dans de nombreux cas ». Si pour "vim", encore une fois, je comprends ce choix, "sudo", en revanche, je ne saisis pas. Tant qu'un utilisateur n'existe pas et que rien n'est créé, installé ou modifié depuis l'espace personnel qui exige ce transfert de pouvoir de l'administrateur, je ne comprends pas. Par ailleurs, il me semble bien que "sudo" a été installé sans que j'en passe commande explicitement. En dépendance. De quoi ? Je n'ai pas vérifié.

"Base" ou "base base-devel" ? Mais pour quoi au juste ? Minimum vital, système à jour, bureautique, dépôt AUR ? Et quid des logiciels complémentaires ou optionnellement proposés ? Pratiques ou nécessaires pour une installation de "base" ? — J'en perds mon latin.

Pourtant, comme le dit Fred Bezies, en commentaire sur mon article précédent, il serait dommage de ne pas utiliser la richesse logicielle du dépôt communautaire AUR. Mais comment ? C'est là que les choses se corsent.

Dans son petit guide, Fred utilise les ressources du dépôt AUR et de manière transparente, si j'ose dire, avec l'utilitaire "yaourt", parce que m'a-t-il dit en commentaire pour m'aider à installer "AfterShotPro" dont j'ai besoin pour travailler quotidiennement, un logiciel comme "yaourt" est le moyen le plus rapide d'y accéder. Ainsi, lorsque Fred, dans son petit guide, propose de récupérer certaines polices de caractères disponibles dans le dépôt communautaire, il envoie la commande suivante :

yaourt -S ttf-bitstream-vera ttf-liberation ttf-freefont ttf-dejavu ttf-ms-fonts

Sur les conseils que Fred m'a prodigués en commentaire, j'ai installé "yaourt" puis procédé, comme il me l'a indiqué, pour installer "AfterShotPro" :

yaourt -G aftershotpro
cd aftershotpro
makepkg -s
yaourt -U nom-du-paquet

Julien, qui s'est inspiré du guide de Fred, ne doit, vraisemblablement, pas procéder autrement que Fred pour « accéder aux dépôts 'AUR' ».

Fred et Julien ne disent rien, dans leurs guides respectifs, du dépôt communautaire "AUR". Pourtant, ils l'utilisent tous les deux mais… configuré différemment. Julien ajoute, à la fin du fichier /etc/pacman.conf :

[archlinuxfr]
Server = http://repo.archlinux.fr/$arch

Quant à Fred, il donne la configuration suivante :

[archlinuxfr]
Siglevel = Optional TrustAll
Server = http://repo.archlinux.fr/$arch

Quelle différence entre les deux ? Le niveau de vérification des signatures. L'option, dans la configuration de Julien n'est pas renseignée pour le dépôt concerné. Cette directive, à ce que j'ai lu, peut se configurer soit globalement, dans la section [options], soit dépôt à dépôt, comme le propose Fred, en l'affectant directement au dépôt concerné.

Pour autant, la configuration de Fred me renvoie une erreur :

avertissement : fichier de configuration /etc/pacman.conf, ligne 102 : l’instruction « Siglevel » dans la section « archlinuxfr » n’est pas valide.

Une malheureuse erreur de syntaxe, de casse, "Siglevel" pour "SigLevel", qui m'aura égaré pendant quelques heures…

Mais pourquoi cette différence de configuration du "SigLevel" pour "AUR" entre les guides de Fred et de Julien ? — L'option de vérification retenue par Fred, "TrustAll" n'existe qu'à des fins de debug et donne pleine confiance à des clés non vérifiées. On peut comprendre aisément ce choix si l'on sait que le dépôt "AUR" n'est pas signé. L'option "SigLevel" qui convient, pour le dépôt communautaire "AUR" [archlinuxfr], est donc : "Never".

Dernière question à ce sujet : pourquoi la configuration de Julien ne propose-t-elle aucune directive de vérification de signatures pour le dépôt "AUR" ? L'absence de directive correspond-elle à la directive "Never" ?

Gagnant gagnant

Je crois que nous serons tous à peu près d’accord sur l'un des fondements du Libre : l'expérience "utilisateur", à savoir, explorer, expérimenter, sans blocage, sans consensus obligé, au risque de s’écarter les uns les autres, pour trouver ce qui fonctionne réellement, et, bien entendu, participer, partager, dire ce que l’on pense être le plus efficace, le meilleur… même si l'on prend toujours un risque à l'exprimer parce qu'il est difficile de ne pas exprimer d’opinions ou de visions particulières sans entrer en conflit avec d’autres.

J’ai bien conscience que la teneur d’un tel article peut aviver quelque querelle intestine ou division mais ce n’était nullement mon intention en l'écrivant. Non. Mon objectif est ailleurs : faire tourner Linux, Arch ou quelque autre distribution, correctement (i.e. au mieux) sur une machine en production.

Et je crois, pour conclure, que le partage de l’expérience "utilisateur" est un puissant vecteur d’évolution.

N.B. : Au moment de la rédaction de cet article, il n'y avait pas 48 heures que j'avais installé Arch. Je confonds allègrement le dépôt communautaire "AUR" et le dépôt communautaire [archnilixfr]. Ce que Fred Bezies me précise dans le commentaire #9. Vous excuserez, certainement cette confusion mais… j'ai un peu de mal à en porter la responsabilité. À aucun endroit, ni dans le guide de Fred, ni dans celui de Julien, cette distinction n'est faite clairement. Voyez par exemple ce que dit Julien :

Toutefois, il existe aussi « Yaourt« , une sorte de Pacman avancé. Cet utilitaire (Yaourt), est plus puissant puisqu’il sait accéder aux dépôts « AUR », les dépôts des utilisateurs ArchLinux.

Il faut donc ajouter, à la fin du fichier « /etc/pacman.conf » :

Ajout dépôt téléchargement Yaourt

[archlinuxfr]
Server = http://repo.archlinux.fr/$arch

Original post of Cyrille BORNE.Votez pour ce billet sur Planet Libre.