Le carnet du grincheux

Il paraît que nous avons en France un furieux besoin de logements. J'avoue ne pas forcément être d'accord, ce qui pose problème en France n'est pas le logement, mais le fait que les emplois qui n'ont pas encore été détruits malgré l'acharnement des gouvernements successifs depuis bientôt quarante ans soient très mal répartis. Si les emplois étaient répartis sur l'ensemble du territoire, nul doute qu'il n'y aurait aucun problème de logement.

Nous avons donc un tel problème et, depuis de nombreuses années, s'accumulent des lois, des règlements et des textes divers défendant toujours plus le toujours gentil locataire contre l'affreux capitaliste exploitant et propriétaire (toujours aussi). Dans les faits, il est impossible pour un propriétaire de se débarrasser d'un locataire indélicat et, lorsque par extraordinaire il arrive à le faire, il récupère généralement un appartement dans un état lamentable. Il y a un peu plus de dix ans, j'ai aidé mes parents à nettoyer un appartement d'un centre ville de province après deux ans d'impayés de loyer, j'ai gazé pour éliminer la vermine, il y avait cinquante centimètres de merde sur plus de cinquante mètres-carrés. Ils ont récupéré cet appartement en juin dernier après le départ d'un autre locataire, il avait été repeint en… noir ! Tout le mobilier avait été détruit (armoire, lit, chaises de cuisine pliées…).

Dans les faits, donc, il est de plus en pus difficile de trouver un appartement à louer car les propriétaires ont été échaudés et préfèrent laisser un appartement vacant que de prendre le risque de récupérer un taudis. Les locations de courte durée ont encore aggravé la situation puisque les propriétaires préfèrent louer sur de courtes périodes, au moins, après le temps de la location, le propriétaire a l'assurance que le locataire, indélicat ou non, part.

Il y a donc des zones dites tendues et qui ne sont tendues que par la légisghorrée française. Comme cela n'est pas suffisant, l'écologisme débridé dans lequel nous vivons vient de proposer d'interdire à la location des biens immobiliers qui ne seraient pas vertueux du point de vue de l'isolation thermique. C'est un peu plus compliqué que cela, mais dans les faits, un juge pourra interdire une telle location et un appartement pourra être déclaré insalubre. D'après ce que je lis, un appartement de beaux quartiers parisiens, dans un immeuble hausmannien, sous prétexte que la façade sur rue est en pierres et la façade sur cour en briques, pourra être déclaré grâce à ces seuls critères insalubre par décision de justice, voire dans certains cas automatiquement, l'administration française ayant tous les droits.

Il faudra donc forcer les propriétaires à investir dans l'isolation intérieure (mais des études ont montré qu'il fallait plus d'un siècle pour que cela soit rentable dans de tels immeubles) ou dans une isolation extérieure qui pose au moins deux problèmes que sont la mutilation des façades souvent historiques et la condensation. Il y aura donc encore moins de biens mis en location.

Là où cela va piquer fortement, c'est dans le parc de HLM, que celui-ci soit privé ou public. Parce que s'il existe des passoires énergétiques, c'est bien là. Il sera assez amusant de voir les premiers effets de bord de cette loi dispensable sur les bailleurs sociaux.

Encore une fois, c'est un problème bien vu, bien réglé, pris par le mauvais bout et avec des effets faciles à imaginer. Il n'y a pas à dire, la moitié de l'humanité est plus bête que la médiane. Cette statistique est encore vérifiée parmi nos chers élus.

J'ai entendu ce matin d'une oreille tout d'abord distraite puis assez attentive une certaine Frédérique Vidal causant sur Radio Paris.

Oui, je parle de Radio Paris et non de France Inter puisque la pluralité n'étant absolument plus respectée sur cette radio d'état, ce poste sert plus d'organe de propagande que de radio de service public. Si vous ne me croyez pas, faites la liste des différents invités dans les tranches 6h/9h et 18h/20h sur un ou deux mois et regardez ce qu'il en sort. Mais revenons au sujet, ce matin, donc, parlait dans le poste une certaine Frédérique Vidal.

Et cette personne affirmait haut et fort que tous les doctorants de tous les laboratoires français auraient dès demain — ce qui signifie dès la promulgation d'une loi grassouillette et pleine d'effets de bord sans doute rigologènes — une rémunération pour vivre décemment de leurs travaux de recherche.

Ben tiens. Lorsque j'étais doctorant, on se débrouillait avec le financement du laboratoire — personnellement, j'avais de la chance, j'étais payé sur la grille des maîtres de conférence —, on faisait des piges à droite et à gauche (travaux pratiques, cours du soir que personne ne voulait donner, cours le samedi matin à l'autre bout du département dans une antenne éloignée du laboratoire et j'en passe). Cela nous permettait de vivre correctement tout en assurant ses quarante heures minimales de travail hebdomadaire sur son sujet de recherche.

J'entrevois déjà un effet de bord amusant. Dans un pays ruiné qui ne compte que sur les universités publiques et, à la marge, les grands établissements publics eux aussi pour effectuer des travaux de recherche, il existe un moyen assez simple de respecter une telle loi : refuser l'inscription en thèse de tous les doctorants potentiels qui n'ont aucun financement.

Le problème de la recherche en France n'est vraiment pas celui-là. Son problème est d'être une recherche étatique aux mains de grands machins comme le CNRS que tous les pays nous envient certainement et qui contraignent les entreprises, mêmes les grandes, à rester leurs simples supplétifs. Cela va même tellement loin que lorsqu'une entreprise embauche un doctorant sous contrat CIFR, elle se retrouve généralement le dindon de la farce. Elle se retrouve à payer en partie le doctorant, à se battre avec le laboratoire universitaire pour que le doctorant travaille dans les locaux de l'entreprise et qu'il fasse effectivement ce pour quoi il est payé, et se retrouve généralement avec des histoires de brevets dans les pattes déposés par le laboratoire universitaire, le doctorant étant contraint d'écouter son directeur de thèse bien plus que son employeur. Ne me dites surtout pas le contraire, j'ai déjà donné. Et j'ai déjà donné et à plusieurs reprises.

Le problème n'est pas en France la rémunération des doctorants. C'est un épiphénomène, même si pour ceux qui n'ont pas de financement, la vie du thésard n'est pas simple. Le problème est, en France, que l'on a sabordé la recherche privée avec la conscience d'un pays communiste en prenant les financeurs pour des imbéciles et on s'étonne, naïvement, que l'argent privé ne coule pas à flot vers les laboratoires universitaires. Une entreprise privée veut bien payer un laboratoire, mais cette même entreprise ne veut pas, alors qu'elle a payé une grande partie des opérations de recherche, que le fruit de son financement soit breveté, même conjointement, par un laboratoire universitaire. Une entreprise veut bien payer un doctorant sur un contrat CIFR, mais pour que le doctorant soit son employé et non celui d'un laboratoire universitaire. Le problème, en France, c'est qu'une fois la thèse de doctorat en poche, il faut encore trouver un poste de chercheur et que ces postes se comptent tous les ans sur les doigts de la main, la plupart du temps dans des laboratoires sclérosés avec des chercheurs dont certains n'ont rien publié depuis des années parce qu'ils sont attachés statutairement à des matières obsolètes. Pire encore, ces postes sont dans les faits donnés par un genre de cooptation dont le fonctionnement est totalement délétère. Une commission se réunit et permet ou non à un candidat de postuler sur un emploi de chercheur. Problème : cette commission étudie du papier et elle se retrouve à juger des candidats sur des publications dont rien ne lui permet d'affirmer que ces publications sont la production du candidat. J'ai eu connaissance de dossiers où les articles présentés avaient été écrit par d'autres chercheurs et simplement cosignés par le candidat. J'ai aussi vu certains candidats adoubés par cette commission parce que l'un des membres de la commission attendait un retour de la part du directeur de thèse du candidat en question. Tout cela n'est pas réellement sain.

Certains postes sont donc attribués à vie à des gens qui n'ont objectivement pas le niveau pour les occuper, les autres s'orientant vers des laboratoires étrangers où ils sont reconnus à leur juste valeur. Le problème de la rémunération des doctorants est donc un faux problème, il s'agit avant tout de réformer totalement la recherche en France pour que son fonctionnement soit sain. Une fois ce premier travail effectué, travail ingrat et difficile tant les oppositions seront nombreuses, il sera possible de s'attaquer à ce problème de rémunération. Ne pas le faire est une fois de plus se battre contre une conséquence alors qu'on en chérit les causes.

Par le plus grand des hasard, je viens de tomber sur l'interview donnée par notre charmant président de la république, loué soit son nom, pour le 14 juillet.

J'y entends cet élément de langage que je ne peux plus entendre. Il faudrait, selon lui, défendre notre modèle social. C'est bien, c'est dit. Mais le défendre contre qui ? Contre les gens comme moi qui sont ultraminoritaires ? Soyons sérieux, le français adore son modèle social, la légende qui vient avec lui et sont persuadés, les imbéciles, que sans ce sacro-saint modèle social, ils seraient tous en train de crever dans la rue.

Or, lorsqu'on réfléchit à peine plus loin que le bout de son nez, on s'aperçoit très vite que le chômage est la conséquence de ce fichu modèle social ; que les faibles salaires, les faibles retraites et la faiblesse de l'économie sont aussi sa conséquence directe ; que le système de santé agonisant n'est dû qu'à ce satané système que l'immense majorité des Français veut absolument conserver.

Mais il faut toujours défendre ce système. Je pose donc à nouveau la question : contre qui ou contre quoi ?

La seule réponse logique est ainsi qu'il faille le défendre contre lui-même parce qu'il porte en lui les gènes de sa propre destruction.

Je fus l'un des premiers à installer un système Linux sur un ordinateur en France, avec une pile de disquettes, Internet n'étant pas encore ce qu'on connaît aujourd'hui. Je me souviens même du premier serveur installé dans mon laboratoire qui tournait avec un noyau 1.0.9, ce qui ne nous rajeunit pas vraiment et j'ai même participé au développement du noyau pour des architectures exotiques comme les Sparc (à l'époque en 32 bits) et les Alpha. J'ai arrêté de participer à ce développement au cours de la vie du noyau 2.4 puisqu'il était impossible de suivre les modifications internes, surtout les changements de mémoire virtuelle, et tous les bidouillages introduits pas un développement effectué principalement sur architecture x86. Néanmoins, entre les noyaux 1.0 et 2.2 inclus, l'évolution de ce système d'exploitation en faisait quelque chose de prometteur. Vingt-cinq ans plus tard, que peut-on en dire ?

Durant toute une période, j'ai migré mes serveurs d'Unix propriétaires (Ultrix, OSF/1, Solaris, HP-UX) vers Linux parce le système était efficace, carré. Aujourd'hui, je constate que j'effectue la démarche inverse. Je ne réinstalle pas des Unix propriétaires, non, mais des NetBSD (sur serveur) ou des FreeBSD (principalement sur station de travail). Je n'installe plus des système Linux que sur des machines qui utilisent des outils bien particuliers ou pour des besoins spécifiques comme des ordinateurs portables dont les paramètres réseau, par exemple, doivent pouvoir être changés facilement par l'utilisateur sans attaquer avec vi des fichiers de configuration.

Comment en suis-je arrivé là?

Il est bizarre de voir que ce que les développeurs de Linux reprochaient à Windows au tournant des années 2000 se retrouve aujourd'hui presque intégralement dans Linux. Le développement se faisant quasiment exclusivement sur architecture amd64, le code n'est pas réellement propre et des tas d'hypothèses sont faites, hypothèses qui se vérifient sur amd64 mais pas forcément sur d'autres architectures (voir pour cela les problèmes sur Sparc64). Et même sur architecture amd64, il est devenu bien difficile de faire fonctionner de manière fiable des machines dans des configurations particulière — typiquement, une machine diskless peut aujourd'hui gravement dysfonctionner, soit par plantages totaux en cas de fichier de swap sur un disque NFS (problème officiellement corrigé, mais mon noyau ne semble pas être au courant), soit par destruction du serveur X par systemd pour des raisons incompréhensibles lorsque la machine se met à swapper. Mais il y a bien pire, une partie des principes Unix comme KISS (Keep It Simple, Stupid) est de plus en plus bafouée. Un exemple parmi tant d'autres, l'inénarrable systemd.

Pour démarrer un système Unix, il existe principalement deux techniques :

• BSD : un fichier de configuration (généralement /etc/rc.conf et les fichiers inclus) indique quels sont les daemons qui doivent être démarrés avec le système. Les scripts de démarrage de ces daemons contiennent des dépendances et le daemon init (de PID 1) s'arrange alors pour les démarrer dans l'ordre nécessaire. C'est simple, efficace, sans surprise. C'est même économe en mémoire et en ressources diverses ;
• SysV : c'est encore plus trivial. Un répertoire contient une collection de scripts exécutés dans l'ordre alphabétique. C'est à l'utilisateur de régler les dépendance en réglant le nom des différents scripts. C'est encore plus économe. Sans doute trop, cela demande à l'utilisateur de réfléchir un peu.

Ces deux techniques sont trop simples et on a vu arriver un daemon à tout faire dans Linux pour, soi disant, simplifier le problème. Il s'agit de systemd. Systemd, c'est un truc qui fait tout, qui sert à tout, qui a une syntaxe délirante et des fichiers de configuration planqués un peu partout (/lib/systemd/system, /lib/systemd/user, /etc/systemd/system, /etc/systemd/user et peut-être même ailleurs). C'est une usine à gaz avec des fuites qui empêche un démarrage rapide de toute machine ayant moins de 1 Go de mémoire puisque pour des raisons de rapidité (sic), tous les services devant démarrer sont lancés en même temps jusqu'à ce que toutes les dépendances soient satisfaites. Sur les machines un peu courtes en mémoire, ça fait chauffer le dérouleur de pages, et ça peut le faire chauffer longtemps. Mais il paraît que c'est un progrès indéniable.

Vous allez me dire que les machines classiques actuelles ont plusieurs gigaoctets de mémoire, que cela n'est pas un problème. C'est pourtant un problème puisque Linux est malheureusement de plus en plus utilisé dans l'électronique embarquée où on n'a pas forcément une telle quantité de mémoire à disposition. Un autre problème de systemd est qu'il est associé à un noyau en particulier. Lorsqu'un noyau pose problème, il peut être aujourd'hui impossible de démarrer sur un noyau plus ancien qui n'aura pas la bonne version de systemd, celle-ci étant unique pour l'ensemble des noyaux. Mais le pire est tout de même les effets de bords de systemd avec les autres daemons du système comme udev. Le noyau Linux a eu la bonne idée depuis des lustres de nommer les interfaces Ethernet en eth. Premier problème, d'une version à une autre, l'énumération ne se faisait pas forcément dans le même sens. Pour madame Michu qui n'a qu'une seule interface réseau, ce n'est pas grave. Pour quelqu'un qui utilise des serveurs avec plusieurs cartes Ethernet, cela peut rapidement devenir compliqué. Plutôt que de fiabiliser l'ordre d'énumération puisqu'il n'y a aucune raison que d'un noyau à un autre, l'ordre d'énumération sur une même machine ne change, un cataplasme sur une jambe de bois a été rajouté. Deux si je veux être précis. Historiquement, udev peut renommer les interfaces en fonction de leur adresse Ethernet. Plus récemment, les noms de périphériques ont été changés et ce qui était eth0 a pu devenir au gré d'une mise à jour de noyau enp0s31f6, ce qui était très pratique pour les gens qui utilisaient un firewall bloquant tout par défaut sur une machine à distance. Mais encore, en lisant la documentation et en acceptant d'ouvrir un peu tous les ports le temps de la migration, il était possible de s'en tirer.

Or arrive sur ces entrefaites l'inénarrable systemd qui, lui aussi, veut avoir son mot à dire sur le nommage des interfaces. À titre personnel, les interfaces réseau de l'un de mes serveurs sont les suivantes :

Root rayleigh:[~] > ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1335
inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::c48a:96ff:fede:8a07 prefixlen 64 scopeid 0x20<link>
inet6 2001:7a8:a8ed:1::1 prefixlen 64 scopeid 0x0<global>
ether c6:8a:96:de:8a:07 txqueuelen 1000 (Ethernet)
RX packets 10316123 bytes 4301990769 (4.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10982367 bytes 9779960261 (9.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.1 netmask 255.255.255.0 broadcast 192.168.254.255
inet6 fe80::208:2ff:feaf:da70 prefixlen 64 scopeid 0x20<link>
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)
RX packets 8698421 bytes 1258112154 (1.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7780169 bytes 2744108696 (2.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.81 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.82 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.83 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.84 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.85 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.86 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.253.1 netmask 255.255.255.0 broadcast 192.168.253.255
inet6 2001:7a8:a8ed:253::1 prefixlen 64 scopeid 0x0<global>
inet6 fe80::208:2ff:feaf:da71 prefixlen 64 scopeid 0x20<link>
ether 00:08:02:af:da:71 txqueuelen 1000 (Ethernet)
RX packets 20477825 bytes 11652375271 (10.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 21845494 bytes 13687329761 (12.7 GiB)
TX errors 7 dropped 0 overruns 0 carrier 7 collisions 0

lan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.128 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::5246:5dff:fe72:efa2 prefixlen 64 scopeid 0x20<link>
ether 50:46:5d:72:ef:a2 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9402 bytes 614631 (600.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xf7e00000-f7e20000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Boucle locale)
RX packets 17945139 bytes 6569208488 (6.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 17945139 bytes 6569208488 (6.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1336
inet 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::6cb8:b3ff:fed0:235f prefixlen 64 scopeid 0x20<link>
ether 6e:b8:b3:d0:23:5f txqueuelen 100 (Ethernet)
RX packets 51661 bytes 18867944 (17.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 66902 bytes 4769816 (4.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1335
inet6 2001:7a8:a8ed:1::1 prefixlen 64 scopeid 0x0<global>
inet6 fe80::30f3:6dff:fe94:8c9b prefixlen 64 scopeid 0x20<link>
ether 32:f3:6d:94:8c:9b txqueuelen 100 (Ethernet)
RX packets 1545324 bytes 1307060028 (1.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1371546 bytes 810892202 (773.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1335
inet6 fe80::7807:ceff:fefe:4c12 prefixlen 64 scopeid 0x20<link>
ether 7a:07:ce:fe:4c:12 txqueuelen 100 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 35056 bytes 1824754 (1.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Il y a du monde. Vous noterez qu'il n'y a plus de eth0 mais un lan0. Pourquoi ? Parce que cette saleté de systemd a décidé depuis sa dernière mouture d'entrer en conflit avec le renommage des interfaces par udev et eth0 était renommé en je ne sais plus quoi. Heureusement que l'interface en question était une interface du LAN, ce qui ne m'empêchait pas de prendre la main à distance pour corriger le problème. Tout cela ne fait pas bien sérieux et n'est pas vraiment très sec. Cela me donne même l'impression d'essuyer du plâtre avec des briques.

Hier, j'ai installé sur un ordinateur portable tout neuf une Debian testing. Lors de l'installation, je me suis aperçu de la présence de liens étranges dans /. Typiquement, /bin était un lien vers /usr/bin, /sbin un lien vers /usr/sbin et /lib vers /usr/lib. Je me suis dit qu'il s'agissait de liens lors de l'installation. Non, ces liens restent sur le système final.

J'ai donc cherché un peu dans la documentation et je suis tombé sur des justifications totalement oiseuses :

Amélioration de la compatibilité avec les autres Unix / Linux dans le comportement. Après la fusion avec /usr, tous les binaires deviennent disponibles respectivement dans :

• "/bin <–> /usr/bin"
• "/sbin <–> /usr/sbin"
• "/lib <–> /usr/lib"

simplement parce que /bin devient un lien symbolique vers /usr/bin, resp /sbin vers /usr/sbin… Cela signifie que les scripts/programmes écrits pour d’autres Unix ou d’autres Linux et portés à la distribution courante n’auront plus besoin de correction pour les chemins de système de fichiers des binaires appelés, ce qui est par ailleurs une source majeure de frustration. /usr/bin et /bin (resp. /usr/sbin et /sbin…) deviennent tout à fait équivalents.

J'ai rarement lu un truc aussi bête. /bin et /sbin contiennent les binaires nécessaires du démarrage du système, /usr/bin et /usr/sbin les autres. C'est simple, carré. Par ailleurs, les scripts doivent utiliser une variable PATH, donc ce problème n'existe pas.

Mais ce n'est pas la seule justification puisque je peux lire aussi:

Amélioration de la compatibilité avec les systèmes de compilation GNU : la majeure partie du logiciel Linux est construite avec GNU autoconf / automake (c’est-à-dire GNU autotools), qui ignorent la division /usr spécifique à Linux. Le maintien de la division /usr nécessite une gestion non triviale du projet dans le système de génération en amont et dans les packages de votre distribution. Avec la fusion /usr, ce travail devient inutile et le portage des paquets vers Linux devient plus simple.

J'utilise les autotools depuis vingt-cinq ans, je n'ai jamais constaté cela sauf si les scripts sont écrits par des pieds, mais dans ce cas, pourquoi mettre un cataplasme sur une jambe de bois ? On corrige en amont, on ne fait pas n'importe quoi en aval ! Les autotools sont justement faits pour gérer ce genre de problème. Quant à parler de la compatibilité Solaris, il y a un point que les gens oublient, c'est que Solaris est livré comme un tout et que, à l'instar des BSD, /usr concerne le seul système. La dernière fois que j'ai eu un Solaris entre les pattes (un 10, j'avoue), les programmes autres que ceux du système étaient dans /opt ou /usr/local. Chez Debian, ce n'est pas le cas, ils sont dans /usr/bin. J'attends donc avec une certaine impatience la conceté suivante, la fusion de /usr/bin avec /usr/sbin. Parce que les arguments que je lis pour la fusion de /bin avec /usr/bin et /sbin avec /usr/sbin s'appliquent de la même manière.

Un système Unix, un vrai, doit pouvoir démarrer avec une partition racine qui contient /etc, /bin, /sbin et /lib. Je sais qu'avec Linux, il est possible de bricoler avec initramfs, mais cela reste un bricolage qui ne devrait pas exister. /usr, /usr/local et /opt le cas échéant, doivent pouvoir être montés bien plus tard puisque ces partitions ne sont pas des partitions critiques. L'intérêt de la chose est de pouvoir démarrer sur une tout petite partition, même montée en utilisation normale en lecture seule. Cela permet de réparer un système endommagé, surtout lorsqu'on a les utilitaires de base compilés en statique.

Après avoir lancé cette argumentation, la réponse des développeurs de Debian fut laconique. Pour eux, dans une telle situation, il faut utiliser une image GRML appelée depuis le programme d'amorçage (grub2).

Là, j'avoue que les bras m'en tombent et je me demande pourquoi il faudrait faire simple quand on peut faire outrageusement compliqué. Comparons par exemple un NetBSD avec un système Debian/Linux. Je vais passer sous silence que le code du noyau NetBSD est un code qui est d'une qualité nettement supérieure au noyau Linux puisqu'une modification n'est poussée dans l'arborescence des sources que lorsqu'elle a été testée avec succès sur l'ensemble des architectures dites tier 1, ce qui n'est pas le cas avec Linux où elles sont poussées quand elles fonctionnent sous amd64 et advienne que pourra.

Il existe en particulier un répertoire /rescue dans NetBSD. Il contient tous les utilitaires nécessaires à la maintenance du système, compilés en statique et son contenu évolue avec le système. Ces utilitaires sont donc toujours à jour et il n'est pas nécessaire de maintenir à jour une image complète GRML.

La fusion de / avec /usr est une mauvaise idée parce que c'est une source de problèmes potentiels. Il faut que / (contenant /usr) soit en état d'être montée. Cette partition, dans un système Debian, fait plusieurs dizaines de gigaoctets puisque tous les paquets s'y trouvent. Si maintenant /usr est distincte de /, on se retrouve avec un initramfs qui doit monter / et /usr. Il faut donc que deux partitions soient en état d'être montées et que initramfs soit utilisable pour que le démarrage se passe correctement.
C'est bien pour cela que je trouve très bête (et je suis poli) le fait d'avoir ces liens de / vers /usr alors que le bon sens voudrait au contraire que l'on sépare bien ce qui est de l'ordre du mécanisme de démarrage de ce qui est de l'ordre de l'utilisation du système une fois celui-ci démarré. Certaines décisions me semblent prises sous l'effet de la mode — pour ne pas dire sous l'effet de la drogue — par des gens qui n'ont pas réfléchi plus que cela à ce qui se faisait par ailleurs. Si /bin, /sbin, /usr/bin et /usr/sbin ont été séparés depuis trente ans, il y a peut-être des raisons fondamentales, ceux qui ont fait ces choix n'étant pas plus bêtes que nous.

Dans un NetBSD, il n'y a typiquement pas besoin d'avoir une image GRML quelque part parce qu'il existe ce répertoire /rescue et que /bin, /lib et /sbin (et /etc) ne servent qu'au démarrage.

Exemple :

legendre:[~] > uname -a
NetBSD legendre.xxx.fr 9.0_STABLE NetBSD 9.0_STABLE (CUSTOM) #6:
Sat Jun  6 16:01:51 CEST 2020 root@grincheux.de-charybde-en-scylla.fr:/usr/src/netbsd-9/obj/sys/arch/amd64/compile/CUSTOM amd64
legendre:[~] > du -hs /bin
1.7M    .
legendre:[~] > du -hs /sbin
12M     /sbin
legendre:[~] > du -hs /lib
18M     /lib
legendre:[~] > du -hs /rescue
20M     /rescue
legendre:[~] > du -hs /stand/amd64/9.0
23M     /stand/amd64/9.0

Pour peu que / soit une partition séparée (en lecture seule), il est toujours redémarrer même en cas d'effacement d'une bibliothèque critique puisque /rescue est là pour cela. Ce répertoire permet de démarrer un NetBSD en single user tout en permettant de travailler sur le vrai système sans jouer du mount -o bind et autres joyeusetés qui sont assez rapidement plantogènes pour peu que le noyau de l'image ne soit pas celui en cours sur le système à dépanner. En mettant un lien de /sbin vers /usr/sbin, cette possibilité est interdite par construction puisque cela augmente les chances que cela se passe mal. En effet, lorsqu'on est contraint de travailler en single user, il y a souvent des partitions qui ne sont plus en état d'être montées, donc il y a beaucoup plus de chances que cela se passe mal.

Exemple sur un serveur Debian :

rayleigh:[~] > uname -a
Linux rayleigh 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64 GNU/Linux
rayleigh:[~] > du -hs /bin
12M     /bin
rayleigh:[~] > du -hs /lib
2,0G    /lib
rayleigh:[~] > du -hs /usr/lib
9,6G    /usr/lib
rayleigh:[~] > du -hs /usr/bin
1,1G    /usr/bin
rayleigh:[~] > du -hs /usr/sbin
64M     /usr/sbin
rayleigh:[~] > du -hs /sbin
17M     /sbin

Pour démarrer, le système doit accéder à une partition en forme (assez en forme pour être montée au moins en read only) de 13 Go, voire deux partitions en forme dans le cas où /usr est distinct et où on joue avec initramfs. Et si une bibliothèque cruciale est corrompue, on n'a que ses yeux pour pleurer, car il n'y a aucun utilitaire compilé en statique pour réparer. Quiconque a déjà essayé de recompiler un apt en statique verra de quoi je veux parler. Remarquez bien, pour démarrer correctement un Linux de nos jours, il faut aussi que l'initramfs soit correct. Encore un truc qui est une aberration sans nom puisque les scripts appelés ne sont pas forcément ceux de /etc, mais ceux qui ont été copiés dans l'initramfs. Je conçois qu'on embarque des modules dans un système de fichiers spécial pour contourner les problèmes d'initialisation liés au bios. Mais on peut faire largement mieux avec un système comme grub2 sans passer par cette horreur qu'est l'initramfs et qui est une source d'ennuis

Ce n'était pas forcément mieux avant. Mais certains choix qui ont été fait par les concepteurs des systèmes Unix l'ont été pour d'excellentes raisons. Abandonner ces concepts simples peut torpiller un système d'exploitation. Personnellement, je ne suis pas plus gêné que cela tant qu'il me restera des BSD restant dans la philosophie Unix.

Le fait que le nouveau garde des sceaux ait réussi, dès sa nomination, à mettre tous les syndicats de la magistrature vent debout contre lui me le rend éminemment sympathique. Je connais bien trop cette sale engeance pour lui accorder le moindre crédit et je ne suis pas loin de penser que l'état actuel de la France est en grande partie dû à l'incurie de la plupart des magistrats qui, tellement indépendants et incontrôlables, sont en roue libre depuis trop longtemps et s'érigent plus en redresseurs de torts supposés — quitte à faire passer des défendeurs pour des victimes de la société — qu'en juges destinés à appliquer et à faire appliquer le droit si pas à la lettre, au moins dans son esprit.

Il faut dire qu'il a encore quelques jours, il déclarait encore à qui voulait bien l'entendre qu'il était totalement inacceptable dans un état qui se voulait de droit que les magistrats non seulement n'aient aucun compte à rendre mais encore ne soient responsables d'aucune de leurs décisions.

Je ne sais pas s'il pourra faire quelque chose pour changer cet état de fait, mais le simple fait qu'il l'ait dit fait que je lui laisse le bénéfice du doute.