Journal Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais

Sommaire

• Préface express du traducteur
• Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais
  • Les erreurs habituelles faites par les zélateurs et les détracteurs
  • Architecture monolithique
  • Ce sale diable de Lennart
  • L'hypothèse d'un monde juste
  • Portabilité
  • C'est une question de choix
  • Du cyanure dans la sémantique, ou la manipulation du langage
  • Les temps de démarrage en toute justice
  • La philosophie Unix
  • Écrire une alternative
  • sysvinit : l'éternelle muleta
  • Les milieux culturels et techniques des zélateurs/détracteurs
  • Conclusion

Préface express du traducteur

Ceci est la traduction d'un texte écrit par l'auteur de uselessd que j'ai trouvé particulièrement intéressant en ce qu'il ne cherche pas tant à déterminer qui des zélateurs ou des détracteurs de systemd a raison qu'à exposer pourquoi une telle question ne sera jamais tranchée.

On a encore vu récemment qu'il suffisait de mentionner systemd (sans même risquer un avis dessus) pour relancer un petit Verdun. Ceci n'aura donc pas la naïve prétention de faire asseoir le lion à côté de l'agneau, mais juste de donner à méditer à ceux qui sont las de tous ces pseudo-débats, éternellement reconduits à l'identique (dont, si on se pose la question, le traducteur lui-même se fout bien, étant depuis une décennie sous Slackware – comprendra qui lira).

Résumé quand même pour le lecteur pressé ou saturé : nous assistons-là à une guerre culturelle, dans laquelle certains soutiennent que les baguettes c'est beaucoup mieux tandis que d'autres ne jurent que par couteaux et fourchettes, mais où personne ne parle en fait de la même cuisine. À la fin, ce sont ceux qui contrôlent la cantine qui vont gagner.

Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais

L'écriture de ceci m'a été inspirée par les annonces récentes réclamant publiquement un fork de Debian, une idée que je trouve idiote et qui ne débouchera probablement pas sur énormément de travail technique.

Néanmoins, j'ai vu se dérouler le même débat sur systemd une fois encore. Je l'ai déjà vu un nombre incalculable de fois, et il n'y a eu virtuellement aucune variation par rapport à la formule type. Vous avez deux côtés ardents et bruyants, disposés grossièrement selon une dichotomie zélateurs/détracteurs, dont aucun n'a à dire quoi que ce soit d'éclairant avec cependant pour chacun son propre ensemble unique d'incompréhensions, qui ont mémétiquement muté en idées indépendantes empoisonnant virtuellement tout débat de cette nature.

J'évite largement les « débats » autour de systemd à présent. Ils me dépriment à cause de tous les raisonnements erronés et des détournements émergeant partout, mais j'ai senti que peut-être ce petit texte pourrait essayer d'expliquer le contexte et les causes amenant juste systemd à susciter autant de vitriol et de guerres de clochers.

Les erreurs habituelles faites par les zélateurs et les détracteurs

Les sophismes que font les détracteurs de systemd ont été mis en évidence tellement de fois qu'il n'est pas la peine d'en faire une revue exhaustive. Pour ce qui est de l'objet de cet exposé, nous relaterons en y répondant les arguments habituels pour et contre systemd, tels qu'ils se rencontrent dans presque toutes les « discussions policées et nuancées » à son sujet. Le but ici est de montrer que, contrairement à la croyance populaire, ce ne sont pas seulement les détracteurs, avec leurs agaçantes tirades sur la « philosophie Unix » et leur incrédulité technique, qui ont tort, mais qu'à peu près tous ceux impliqués dans cette dispute sont ignorants d'une manière ou d'une autre.

Les arguments idiots donnés par les supporters de systemd ont été largement laissés sans correction et libres de se propager de manière égale aux arguments idiots de leurs opposants, même si moins de monde le reconnaîtra. Cela a été le cas jusqu'à ce que, le 26 septembre 2014, Judec Nelson écrive un billet de blog exhaustif appelé « Systemd : les plus gros sophismes », qui est devenu énorme sur /r/linux et n'a reçu en comparaison que peu de réponses sur HN (NdT : Hacker News).

Jetons un œil à sa réception sur /r/linux.

Les commentaires les mieux évalués comprennent quelqu'un hurlant en retour « sophisme, sophisme », une réfutation partielle des arguments qui comporte des erreurs clés dans son raisonnement (comme échouer à distinguer le system d'init de ses scripts rc), et qui répond largement aux accroches des paragraphes mais pas aux élucidations plus profondes cachées à l'interieur, une personne qui fait une inconsistance logique en répondant à une seule remarque d'une manière sans rapport avec son sens réel, un argument bidon sur la façon dont les gens devraient arrêter de crier au sujet des logiciels qu'ils préfèrent, et un peu de discussion positive ou nuancée mélangée partout dans tout ça. Très discutable est le vitriol rance jeté par un utilisateur qui qualifie l'auteur de « sale putain de troll manipulateur ».

Pour l'essentiel, nous voyons que presque tout le monde fait du mieux qu'il peut pour éviter de corriger quoi que ce soit, se mettant immédiatement sur la défensive.

Cela ne cherche pas à mettre en accusation les zélateurs de systemd, mais plutôt à montrer une chose : le débat autour de systemd est rarement une dispute technique quelque soit le côté, au lieu de cela, c'est une guerre idéologique et culturelle engagée entre deux populations opposées qui habitent la même sphère générale de Linux et du Libre. Ça n'est pas une question de qualités techniques, c'est une question de politique. Peu l'admettront, mais les gens qui se disputent ne sont pas réellement soucieux d'améliorer l'état des systèmes de gestion de processus. Ils sont impliqués dans un schisme philosophique sans précédent dans le logiciel libre, qui aura probablement quelques implications notables dans le futur. Les identités et les egos sont à l'œuvre ici.

En avant.

Architecture monolithique

« systemd est monolithique ! Il implémente tout dans PID 1 ! », dit le détracteur de systemd, en ayant tout faux.

« systemd n'est pas monolithique ! Songez aux 69 binaires ! », répond le zélateur de systemd, en ayant également tout faux.

Les disputes autour de l'architecture de systemd ont tendance à être des bouillies de jargon avec différentes interprétations, souvent avec des gens considérant que le caractère modulaire d'une chose la rend automatiquement non-monolithique. Le problème est que cela est en réalité correct selon certaines définitions. De l'autre côté, quelque chose étant et modulaire (à un degré au moins) et monolithique simultanément est également absolument possible et considéré comme une interprétation correcte pour divers logiciels tels X.Org, Busybox et le noyau Linux.

Cette espèce de guerre linguistique est typiquement ce qui détourne les esprits de certaines des décisions techniques les plus profondes prises par systemd, et conduit à des manques de compréhension mutuels auto-imposés. Les détracteurs refuseront souvent de lâcher le mensonge d'un énorme blob collé dans PID 1, mais les zélateurs refuseront pareillement d'admettre que la modularité de systemd n'est pas aussi étendue qu'elle pourrait l'être et que son PID 1 demeure quoi qu'il en soit plus gros que dans la plupart des autres systèmes.

Ce sale diable de Lennart

Souvent à l'initiative des détracteurs, qui vont se lamenter des horreurs de PulseAudio et mettre en évidence leur mépris pour Lennart Poettering. Cela est après coup devenu un faux prétexte habituel à l'usage des zélateurs pour balayer les critiques comme relevant d'attaques personnelles contre Lennart. Il est futile de même en discuter, mais c'est un élément important.

La personnalité de Lennart est en réalité, de temps en temps, un sujet pertinent. Essayer d'avoir une grande discussion autour de systemd sans l'invoquer est comme discuter du détail de la glibc sans jamais mentionner Ulrich Drepper. La plupart des gens prennent ça trop passionnément, de toute façon.

L'hypothèse d'un monde juste

Beaucoup des détracteurs de systemd vont s'exprimer au sujet d'une supposée prise de contrôle sur l'écosystème de Linux de la part de systemd, dans la mesure où ses auxiliaires (nécessitant tous d'être pilotés par l'init de systemd) exposent des APIs qui sont ensuite utilisées par d'autres logiciels de la pile bureautique, créant ainsi des liens de dépendance entre ceux-ci et systemd que les détracteurs jugent injustifiés. Ils vont aussi pointer du doigt la débâcle d'udev et citeront Lennart à l'occasion. Les détracteurs voient ça comme un comportement anti-compétitif et le compare à une pratique de type « adopter, étendre, étouffer ». Ils exagèrent souvent cependant et se laissent complètement emporter par leur vitriol à mesure qu'ils commencent sérieusement à envisager d'obscures conspirations chez Red Hat (il faut admettre que c'est plutôt drôle de prétendre que quiconque défend un logiciel est un homme de paille travaillant secrètement pour lui, mais je digresse), laissant beaucoup de leurs sujets de préoccupation être ignorés et jugés ridicules par la même.

La modération est rarement de mise. La plupart des zélateurs essaient de convaincre en niant carrément toute interférence politique et en insistant sur le fait que systemd est adopté sur la seule base de ses qualités techniques et qu'un aussi large consensus parmi les distributions étant impossible à fabriquer, il doit y avoir derrière des raisons techniques valables qui montrent clairement la supériorité de systemd.

Aucun de ces points de vue n'est la stricte vérité. Il est très probable qu'il n'y a pas de conspiration de la part de Red Hat s'enracinant dans les bureaucraties de toutes les distributions (aussi amusant que cela sonne), mais dire que l'adoption de systemd est purement technique et pas du tout politique est également faux. Cela est particulièrement évident du fait qu'à peu près toutes les distributions (surtout Debian, cependant) ont une structure de gouvernement élaborée. Les décisions techniques et politiques s'entrecroisent très fréquemment (demandez juste à Microsoft ou à Oracle), et les logiciels libres ne sont pas nécessairement immunisés contre cela.

De plus, la communauté Linux est connue pour réinventer la roue carrée encore et plus encore. Le chaos est en même temps la plus grande force et la plus grande faiblesse de Linux. Vous vous souvenez de HAL ? L'adoption par les distros n'est pas tant l'indice que quelque chose est bon que du fait qu'il a suffisamment de publicité.

Cela dit, ce qui se passe n'est pas que les gens nient que des interférences politiques se produisent en matière de logiciel, mais plutôt qu'ils nient que cela arrive dans leur camp. Les détracteurs s'en rendent également coupables (comme lorsque Ian Jackson réouvre la résolution Debian sur systemd, ce qui était par nature brûlant, quelles qu'aient été ses intentions), même s'ils ne sont pas aussi influents.

S'attendre à ce que les débats autour de systemd n'impliquent rien de politique, en tant que tel, est plutôt auto-contradictoire. systemd est déjà le sujet le plus chargé politiquement dans l'histoire du logiciel libre, et ce n'est pas si arbitraire. Néanmoins, les deux côtés sont regrettablement obtus et nous analyserons plus tard leurs milieux types, pour comprendre pourquoi.

Portabilité

La portabilité des systèmes d'init est rare, principalement parce que les phases 1 (immédiatement après le lancement d'init(8) par le noyau) et 3 (extinction) sont intrinsèquement spécifiques au système. Ceci est également la cause pour laquelle il y a une forte prégnance philosophique dans la conception des inits, même si ce n'est que rarement exposé aussi explicitement.

Les zélateurs soutiennent avec raison que la non-portabilité de systemd est quelque chose de courant et que ce n'est pas un bon argument contre lui, mais les détracteurs mettent généralement en évidence les décisions politiques et la ramification des dépendances, en soutenant que systemd n'a pas besoin d'être un init et devrait juste être un superviseur de processus tournant au-dessus d'un init existant. Il y a des arguments à donner en faveur des deux options, même si l'architecture de systemd tend en général à en faire un init. Il fournit une plus grande sécurité contre les erreurs critiques au prix d'une surface plus large, contrairement à l'approche des daemontools où vous avez une séparation stricte entre la gestion du système et la gestion des services.

Pour autant que l'argument de la portabilité soit normalement un sophisme, l'exposition des APIs de systemd à l'usage d'autres paquets lui donne une pertinence. Bien sûr, « l'hypothèse d'un monde juste » joue un grand rôle ici, car du fait que cet argument est intrinsèquement politique, il est en conséquence souvent directement rejeté, générant encore un surplus de situations à se cogner la tête contre le mur (« Ce que nous avons ici est… une incapacité, à communiquer. Certains hommes, vous ne pouvez simplement pas les atteindre. » ) durant les débats.

C'est une question de choix

Généralement, un fier utilisateur de Gentoo, qui saisit l'importance de dérouler toutes les boucles lors de la compilation d'un paquet, va se lever et proclamer « Linux est une question de choix ! systemd s'immisce dans tous mes logiciels et confisque ma liberté de choix ! »

Il sera la plupart du temps immédiatement réfuté par quelqu'un l'envoyant sur islinuxaboutchoice.com, et allant même parfois jusqu'à lui expliquer pourquoi, en fait, le choix est une mauvaise chose et conduit au malheur. Si seulement nous avions tous voté pour le même parti politique, le monde serait meilleur.

Excusez les caricatures, mais le fond de tout cela est que ces deux approches sont fausses et ne conduisent nulle-part. Les zélateurs ont bon en ce que Linux n'est pas intrinsèquement une question de choix, mais ils ne parviennent également souvent pas à réaliser que la tradition Linux consistant à construire des systèmes en mélangeant et en ajustant des composants ouverts (du fait que Linux est seulement un noyau) a en fait joué un grand rôle dans la formation de sa culture, et est sans doute une raison pour laquelle beaucoup d'entreprises basent leurs infrastructures sur Linux, quand bien même il est couvert par une licence plus restrictive comparé aux BSDs.

Dans les faits, rien de cela n'a à voir avec le choix. Ce qu'ont cherche réellement à dire est « ça casse les procédures de travail ».

Du cyanure dans la sémantique, ou la manipulation du langage

Il apparaît que beaucoup de gens ne savent même pas ce qu'est systemd. Je développe uselessd, et je ne sais pas non plus – sérieusement. Tout du moins, je ne peux penser à aucune explication concise qui décrirait proprement le champ d'application de systemd.

Lorsqu'ils se lamentent à propos de toutes les critiques (entendre : la haine sans limite) à propos de systemd, les zélateurs vont souvent demander « Pourquoi tant de gens se soucient-ils de l'init de leur système ? Je m'en moque, du moment que ça marche ! »

Les détracteurs feront alors entendre leurs préoccupations en disant quelque chose dans la veine de « Je n'aime pas la manière dont systemd gère tant de choses, telles la connexion, les conteneurs, la locale, les comptes, les points de montage et d'auto-montage… »

Arrivé à ce point, une autre personne va crier « Mais systemd n'est pas qu'un système d'init, c'est un ensemble de démons et de services pour un système d'exploitation basé sur Linux ! »

En fait, nous verrons systemd compris tour à tour comme étant :

• un démon init ;
• un système d'init ;
• un gestionnaire de processus ;
• un gestionnaire de services ;
• une brique de base de l'espace utilisateur avec laquelle bâtir un système d'exploitation ;
• un réseau de dépendances entre objets pouvant être propagés, combiné à un puissant moteur d'exécution ;
• etc.

Habituellement, quand ses zélateurs essaieront de défendre systemd, ils vont insister sur le fait que c'est « juste un système d'init », mais quand ils seront contredits ils mentionneront à la place une des définitions plus larges.

Toutes les définitions ci-dessus sont techniquement correctes. Aucune d'entre elles n'est complète.

C'est ainsi que le débats sont condamnés à ne mener nulle-part, dans la mesure où personne ne peut s'entendre sur une unique définition de systemd, et les développeurs n'ont aidé vraiment en rien en la matière. Être vague peut être une force, en ce que cela permet aux gens de diviser pour régner, mais c'est également improductif et conduit à des carnages inutiles. En sus, être vague donne carte blanche pour balayer les réserves et consolider les fonctionnalités, tout en entraînant aussi beaucoup d'ignorance chez les détracteurs comme chez les zélateurs.

Les temps de démarrage en toute justice

Les détracteurs de systemd partent fréquemment du principe que la seule raison pour laquelle les gens l'aiment tient dans ses temps de démarrage plus courts. C'est faux, même si le fait que ses fans vantent beaucoup cet aspect n'aide certainement pas, et ce bien que les développeurs de systemd eux-mêmes découragent l'utilisation de cet argument, insistant à la place sur la « bonne conception » à laquelle cela est dû (et ainsi le cycle des guerres ouvertes se poursuit).

Les développeurs reconnaissent que les temps de démarrages ne sont par défaut pas aussi fulgurants qu'ils pourraient l'être, et avec les années la plupart des distros Linux a accumulé beaucoup d'expédients comme insserv et startpar, qui ont amélioré les performances de SysV en accélérant son exécution sérielle par des expédients de parallèlisation passant par le démarrage des services en tâches de fond.

La philosophie Unix

La philosophie Unix est elle-même un gigantesque champ de bataille. Elle est remarquablement chargée d'un point de vue politique. Beaucoup de gens seront d'accord avec une grande partie de ses principes si vous les présentez individuellement, et de fait une partie d'entre eux est devenu synonyme de « bonne conception », mais si vous les mentionnez derrière le paravent « philosophie Unix », les ennuis vont commencer.

La plupart des détracteurs de systemd essaient de convaincre en hurlant aveuglément « Phylozofie Hunixe » comme si cela signifiait quoi que ce soit sans élaborer un peu le sujet, mais beaucoup de zélateurs sont par ailleurs inhabituellement hostiles à son égard et la mécomprennent eux aussi. Une réfutation habituelle comme « Linux n'est pas Unix » est correcte uniquement du point de vue de la licence en ce que, en effet, Linux n'est pas une licence d'Unix. Cela n'invalide pas le fait que son architecture a intrinsèquement à voir avec celle d'un Unix.

Un courriel de réponse de la part de Lennart Poettering, que nous avons reçu à la suite d'une enquête de l'un des membres de notre forum, disait ce qui suit :

« Tout cela étant dit, je suis presque sûr que systemd amène Linux beaucoup plus près d'Unix que Linux ne l'a jamais été. Tous les vrais Unixes actuels (comme FreeBSD, Solaris, … ) sont maintenus dans un lieu centralisé, en partageant l'infrastructure des dépôts de code, les cycles de vie et les schèmes de publication pour tous leurs composants, peu importe que ce soit le noyau, la libc, ou le reste de l'espace utilisateur. Sur les vrais Unixes, il est beaucoup plus facile de patcher le long de la pile entière depuis le noyau à jusqu'à l'espace utilisateur, parce que tout provient de la même source, et suit les mêmes cycles. Les vrais UNIXes ont tendance à paraître plus uniformes car les mêmes gens travaillent sur toute la pile, les choses sont faites d'une même main. Linux a toujours été différent, nos composants sont maintenus indépendamment, dans des dépôts différents, avec des styles de code différents, par des gens différents, suivant des cycles de publication différents. Ils sont maintenus plus ou moins bien, une bonne partie de notre pile est en réalité traditionnellement très mal maintenue, voire pas du tout.

Avec systemd nous essayons de trouver une sorte d'entre-deux, aller vers un schème plus proche d'UNIX sans tout coller dans le même dépôt comme le fait UNIX, mais seulement les éléments essentiels de l'espace utilisateur. Mais même au-delà des éléments de procédure, il y a beaucoup de domaines où systemd est plus proche des UNIX traditionnels que Linux ne l'a été. Par exemple, un des mantras d'Unix est « tout est fichier » (ce qui, au passage, est plutôt faux, car mon imprimante n'est pas un fichier, pas du tout), et on pourrait dire que systemd donne à voir l'un des concepts les plus fondamentaux d'un système Unix, à savoir les services/démons en tant que fichiers via la logique des cgroups. Donc ouais, si vous prétendez que nous ne somme pas UNIX, je vous dirais que nous sommes en réalité sous bien des aspects beaucoup plus proches d'Unix que nous ne l'avons jamais été.

Je suis presque sûr que la plupart des gens qui répètent constamment comme des perroquets que systemd n'est pas proche d'Unix n'ont en réalité aucune idée de ce qu'est vraiment UNIX… »

Apparemment, ce que Lennart a retenu d'Unix est qu'il est « développé au sein d'un unique dépôt » (bien que cela n'ait jamais été un pré-requis strict, c'est juste que les noyaux individuels des systèmes d'exploitation n'ont auparavant jamais vraiment décollé à la manière de Linux) et que systemd est plus unixifié que n'importe quoi avant lui parce qu'il utilise les cgroups… même si on doit la conception de cgroupsfs aux développeurs du noyau et pas à systemd (à eux et au système de fichiers à contrats de Solaris, qui a probablement été une source d'inspiration majeure pour les cgroups). De plus, il nous éclaire sur le fait que son imprimante n'est pas un fichier. À l'évidence, Lennart n'a jamais entendu parler de 9P (NdT : Plan 9 Filesystem Protocol), qui est un exemple de protocole simple ayant été mis en application avec succès pour exposer à peu près tous les ressources et services du système en tant que systèmes de fichiers virtuels, les rendant pilotables avec les appels système les plus basiques manipulant les descripteurs de fichiers.

Écrire une alternative

Après beaucoup d'arguties quelqu'un va tout simplement finir par lâcher que si les détracteurs n'aiment pas systemd, ils devraient lui écrire une alternative.

Bien entendu, au minimum plus au moins une douzaine de celles-ci existent déjà. Que signifie en réalité « Écrire une alternative » ?

systemd est vraiment au sein de l'espace utilisateur la couche intermédiaire qui prend place entre GNU et Linux. J'ai aussi entendu systemd comparé aux serveurs d'un micro-noyau, d'une manière très proche du Hurd. Cela a en fait plus de sens qu'il n'y paraît au premier regard, et avec les anciens composants du noyau comme la console Linux qui sont en train d'être déportés vers l'espace utilisateur (d'abord en tant que kmscon, puis en tant que systemd-consoled – ce qui n'implique pas que ce soit mauvais, au passage), cela donne quelque crédit à l'idée. Les composants de systemd implémentent souvent d'anciens outils indépendants en tant que démons auxiliaires, programmables.

En tant que tel, pour que quelqu'un écrive une alternative à systemd, un second systemd doit pour l'essentiel être écrit.

Ceci est déjà un dilemme insoluble, car c'est précisément ce que les détracteurs ne veulent pas. Beaucoup des anti-systemd techniquement compétents souscrivent à des philosophies entièrement différentes, comme l'approche des daemontools ou autre chose.

Plus encore, beaucoup ignorent qu'écrire un second systemd serait un risque énorme. Faire de la programmation système de bas niveau et de la plomberie en espace utilisateur n'est pas comme programmer des applications pour l'utilisateur final. Un superviseur de processus et un traitement de texte sont complètement différents. Le dernier peut-être remplacé très facilement s'il ne convient pas, le premier requiert une intégration et a des ramifications fondamentales dans la manière dont on interagit avec un système d'exploitation donné. La tâche n'est pas aisée et risque fort d'être entièrement vaine. Beaucoup de monde travaillerait plus volontiers sur des projets personnels que de consacrer des efforts à écrire des systèmes qu'ils pensent déjà avoir été largement compensés par des outils séparés et discrets (sans doute certains desquels ils ont eux-mêmes écrits).

De ce ce point de vue, l'argument « implémenter une alternative » conduit seulement à empoisonner les débats avec l'assomption implicite que la philosophie de systemd est bonne, rendant ainsi les choses encore largement plus politiques.

sysvinit : l'éternelle muleta

Il semble que par une sorte de destinée divine, tout débat autour de systemd se mue en dispute stérile autour des avantages de systemd sur sysvinit. Les zélateurs vont joyeusement parler des fonctionnalités géniales de systemd qui ont remplacé la base des affreux scripts shell, alors que les détracteurs vont proclamer la supériorité de sysvinit dûe à son minimalisme et à sa flexibilité infinie du fait qu'il délègue les services à un langage de commande interprété et Turing-complet.

Tous ont faux et manquent totalement l'essentiel.

Le constat que sysvinit est idiot et défectueux avec ses abstractions vieillotes comme son inittab et ses niveaux d'exécution n'est absolument pas nouveau. Richard Gooch a écrit un article dès 2002 intitulé « Les scripts de démarrage Linux, qui critiquait les approches de SysV et de BSD, en se basant sur son précédent travail sur simpleinit(8). Cela dit, sa solution restait fermement ancrée dans les philosophies de SysV et de BSD, mais il rendait ça plus élégant en fournissant des bases de modularité et en exprimant les dépendances.

Même avant cela, DJB (NdT : Daniel J. Bernstein) a écrit la fameuse suite des daemontools, qui a eu beaucoup de successeurs influencés par son approche, notamment s6, perp, runit et daemontools-encore. Les deux premiers sont des implémentations complètement indépendantes mais basées sur des principes similaires, avec il est vrai des améliorations significatives. Un article daté de 2007 intitulé « Les scripts d'init considérés comme néfastes » encourage cette approche et critique les scripts d'init.

Aux alentours de 2002, Richard Lightman a écrit depinit(8), qui a introduit le démarrage parallèle des services, un système de dépendances baptisé « groupes de services » au lieu de « niveaux d'exécution » (similaires aux « cibles » de systemd), sa propre logique de démontage des périphériques à l'extinction, des redirections arbitraires entre démons à des fins de journalisation, et plus encore. Il n'a pas réussi à se populariser et c'est maintenant une relique historique.

D'autres systèmes comme initng et eINIT sont venus après cela, lesquels étaient basés sur des architectures hautement modulaires à base de plugins, et implémentaient une grosse partie de leur logique en tant que plugins, pour une large palette d'actions que des logiciels comme systemd implémentent comme parties inamovibles de leurs socles. Quelqu'un pour parler d'Initmacs ?

Même Fefe, activiste anti-bloat phénoménal a écrit auparavant son propre système appelé minit, qui pouvait gérer les dépendances et le démarrage automatique. Comme d'habitude avec les logiciels de Fefe, c'est très douloureux à lire, vous donnant envie de vous faire seppuku avec une roulette à pizza.

Et tout ça juste pour Linux. Une liste partielle, évidemment.

En tout et pour tout, la comparaison avec sysvinit ne fait que montrer que vous avez vécu dans une grotte pendant des années. Qui plus est, il n'est un secret pour personne que la manière dont les distros ont pendant des années rédigé les scripts d'init a été une hérésie vis à vis des pratiques de base du développement, comme la modularisation et la réutilisation des fonctions communes. Cela parmi d'autres problèmes tels l'usage inadéquat d'abstractions déjà trouées comme start-stop-daemon(8). Même si sysvinit encourage jusqu'à un certain point un mauvais travail comme celui-là, ce sont les mainteneurs des distros qui porte le gros de la faute pour le désordre. Regardez les BSDs pour un bon exemple d'écriture de scripts d'init. OpenRC a été directement inspiré de l'exemple des BSDs. Astuce : c'est dans le nom – « RC ».

Le champ d'application plutôt énorme de systemd et son caractère intransigeant conduisent des gens à regretter l'époque de sysvinit. Une bonne part de cela tient à leur ignorance des bons principes conception, mais pour beaucoup c'est aussi motivé par l'inaptitude à communiquer leur désir pour des systèmes simples et transparents. De la sorte, zélateurs et détracteurs sont pris dans des boucles de rétroaction consistant à ne déboucher sans cesse nulle part en partant en guerre ouverte autour d'une implémentation d'initd (qui s'est trouvée dominante) tout en ignorant complètement toutes les recherches précédentes sur l'amélioration des inits, dans la mesure où celles-ci ont toutes été au final abandonnées au sol. Plus encore, la plupart des gens n'arrivent pas à distinguer l'init des scripts rc et tiennent en quelque sorte sysvinit pour un équivalent des pauvres scripts que les distros ont écrits, et de tous les trucs qu'elles ont bricolés par dessus comme les en-têtes LSB ou startpar(2). C'est une mécompréhension majeure qui entraîne la perte de beaucoup d'énergie.

Ne discutez pas de sysvinit. Discutez de systemd à partir de ses propres qualités et des avantages ou désavantages de sa manière de résoudre les problèmes, ce en le mettant potentiellement en contraste avec d'autres systèmes d'init. Mais ne commencez pas immédiatement avec « les scripts d'init de SysV étaient un approche meilleure et bien plus configurable, je ne vois pas ce que systemd contribue à résoudre au-delà de temps de démarrage plus courts », ou de l'autre côté « systemd est une meilleure approche que sysvinit, regardez comme les unités sont propres comparées à ce script épouvantablement écrit que j'ai glané ! Pourquoi ne changeriez-vous pas ? »

Les milieux culturels et techniques des zélateurs/détracteurs

Maintenant que nous avons mis en évidence comment les débats autour de systemd se déroulaient en pratique et pourquoi y prendre part est habituellement une colossale perte de temps, faisons un grossier survol des personnalités qui rendent ce bordel possible.

Le parties techniquement compétentes tendent largement à tomber dans ces deux larges catégories :

a) les zélateurs sont généralement montés dans le train du Bureau Linux moderne. Ils tournent avec les distributions dominantes contemporaines et les derniers logiciels, utilisant en y contribuant les initiatives des gros environnements de bureau et de leurs standards associés comme les *kits. Ils ne sont pas nécessairement focalisés sur le bureau Linux. Ils travaillent souvent sur des fonctionnalités destinées à la gestion des serveurs d'entreprise, à l'informatique dans les nuages, aux systèmes embarqués, et à d'autres besoins, mais la rhétorique selon laquelle on a besoin d'un meilleur bureau et qu'il faut suivre les exemples de Windows et d'OSX est largement répandue dans leurs rangs. Ils vont dénoncer ce qu'ils considèrent comme des « échecs d'intégration », de la « fragmentation », et sont généralement hostiles à l'égard des projets de recherche et de tout ce qu'ils perçoivent comme des « projets gadgets ». Ce sont des hackeurs, mais leur tournure d'esprit est largement orientée vers la réduction de la complexité des interfaces au lieu de celle des implémentations, et ils argumenteront souvent contre les prétendus dangers de trop de configurabilité, tout en regardant les ordinateurs comme des applications plutôt que des outils.

b) les détracteurs sortent de milieux un peu plus variés, mais viennent typiquement de distributions plus de niche comme Slackware, Gentoo, CRUX, et autres. Ils sont largement peu intéressés par les « avancées » du bureau Linux, apprécient la configuration, le minimalisme, et se soucient plus de la malléabilité que de la convivialité. Ils sont souvent familiarisés avec beaucoup d'autres environnements apparentés à Unix en plus de Linux, bien que ce dernier garde leur faveur. Ils ont leurs propres projets fétiches et sont enclins à utiliser, à contribuer, ou au moins à suivre plein de petits projets dans le domaine de la plomberie système de bas niveau. Ils peuvent aller jusqu'à nommer au moins une douzaine d'alternatives aux GNU coreutils (je peux en nommer à peu près 7, je pense), approuvent généralement les principes Unix traditionnels et regardent les ordinateurs comme des outils. Ils sont les personnes les plus enclines à avoir de la sympathie pour des choses comme la philosophie suckless.

Il ne devrait être une surprise pour personne que le premier groupe est dominant. Ce sont eux qui façonnent largement l'expérience de l'utilisateur final. Par contraste, le second groupe est plutôt insensible à cet égard, voire même critique. Qui plus est, le premier groupe a beaucoup plus de ressources humaines placées aux bons endroits. Les employés de Red Hat à eux seuls dominent le gros du noyau Linux, le système de base GNU, GNOME, NetworkManager, beaucoup de projets affiliés aux standards Freedesktop.org (Polkit, notamment) et plus encore. Il n'y a aucun moyen de concurrencer un vaste groupe d'individus rémunérés comme celui-ci.

Conclusion

L'« année du bureau Linux » est devenu un mème à présent, utilisé le plus souvent sarcastiquement. Cependant il demeure des gens qui y tiennent profondément et pensent que si seulement Linux avait un bon moteur d'abstraction pour les soubassements des gestionnaires de paquets, tous ces utilisateurs Windows tourneraient sous Fédora en un rien de temps.

Ce à quoi nous assistons est certainement à un choc culturel entre deux pôles opposés qui coexistent dans la communauté Linux. Nous pouvons le voir en œuvre à travers le vitriol jeté sur les développeurs de Red Hat, et inversement dans la dérision envers les utilisateurs de Gentoo de la part de Lennart Poettering, Greg K-H. et autres. Même s'il apparaît dans ce cas que « utilisateurs de Gentoo » est utilisé comme une métonymie pour les utilisateurs de Linux dont les besoins sortent de la palette des applications dominantes. Theo de Raadt a autrefois fielleusement ironisé sur le fait que Linux était pour « les gens qui détestent Microsoft », mais cette citation commence à présent à dater.

Beaucoup des gens les plus techniquement compétents avec des opinions critiques sur systemd sont restés plutôt silencieux en public, pour quelque raison. Probablement qu'ils réalisent que la direction prise par le Bureau Linux est inévitable et qu'en conséquence la critiquer est une entreprise futile. Il y a des gens qui pensent toujours que l'abandon de Sawfish par GNOME a été une erreur, donc oui.

Les gens qui ne se sentent pas concernés par le bureau ont encore leur propre espace, mais se sentent menacés par systemd à un degré ou à un autre. Reste que, personnellement, je ne vois pas leur nombre décroître. Ce que je crois qu'il va se passer, c'est qu'ils vont devenir encore plus ségrégués qu'il ne le sont déjà par le Linux dominant et qu'utiliser leurs logiciels va avoir l'air de plus en plus décalé à mesure que le temps passera.

Beaucoup prédisent une grande renaissance de BSD dans le sillage de systemd, mais je suis sceptique à ce sujet. Il y aura sans doute un gain d'intérêt, mais au total il semble que la majorité de la population anti-systemd s'investit encore profondément à rester sous Linux.

En tout dernier lieu, la cruelle ironie est que systemd, dans sa tentative de supposément unifier les distributions, a créé comme aucun autre un immense fossé et a exacerbé à des degrés absolument anormaux les hostilités latentes entre le camp du bureau Linux et celui du Linux minimaliste. Ce qui va advenir de systemd demeure inconnu. Étant donné l'inclination de Linux au chaos, il pourrait devenir le nouveau HAL, avec cependant des conséquences significativement plus pénibles, ou il pourrait poursuivre son gai bonhomme de chemin et devenir un standard Linux gravé dans la pierre, auquel cas la communauté Linux connaîtra une division idéologique intense. Ou peut-être pas. Peut-être que les choses vont continuer comme d'habitude suivant une spirale infinie de réinventions sans climax. Peut-être serons-nous condamnés à nous déchirer sur systemd pour toute l'éternité. Peut-être finalement nous en dégoûterons-nous et poursuivrons-nous nos propres chemins dans des directions différentes.

En tous les cas, je deviens de moins en moins adepte de politique concernant uselessd et je vois les débats autour de systemd comme étant métaphoriquement comme les accidents de voiture. Je n'y apporte probablement rien mais j'y participe de temps en temps, bien que je destine uselessd à tracer son propre chemin avec le temps.

---

Copyright © 2014 MrSpackMan (pour la présente traduction)

Copyright © 2014 the author/developer of uselessd (pour le texte original)

Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code (SGML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified.

2. Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.