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

Posté par .
Tags :
54
29
nov.
2014

Sommaire

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 :

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.

  • # mici

    Posté par (page perso) . Évalué à 9.

    cool un texte vraiment libre sous licence BSD 2-clause !

    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

    ce n'est pas plutôt du même ordre d'opposition qu'entre ceux qui préfèrent le pain au chocolat et ceux qui adorent la chocolatine ?

    • [^] # Re: mici

      Posté par . Évalué à 3.

      Non, parce que ceux-là parlent a priori (j'avoue ne plus avoir en tête les tenants et aboutissants de ce terrible débat qu'il est risqué de ne serait-ce que mentionner – je frissonne) du même objet.

    • [^] # Re: mici

      Posté par . Évalué à 2.

      ce n'est pas plutôt du même ordre d'opposition qu'entre ceux qui préfèrent le pain au chocolat et ceux qui adorent la chocolatine ?

      Bien sûr que non puisque dans le cas de systemd, aucun des deux cas n'a complètement tord ni raison.

      -----------> [ ]

      • [^] # Re: mici

        Posté par (page perso) . Évalué à 2.

        On t'a déjà dit que le torttue et que tu es torddu ? bin, pour systemd, c'est différent, mais c'est un peu pareil ou pas.
        Un peu comme KDE ou GNOME, donc, mais de là à passer à XFCE ou LXDE, même awesome et i3 ou wmii ont plus de fonctionnalités ;-)

  • # Oops le lapsus?

    Posté par . Évalué à 10.

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

    J'imagine que tu voulais dire "de uselessd"?

    • [^] # Re: Oops le lapsus?

      Posté par . Évalué à 4.

      My godness! /o\

      Si dans son infinie miséricorde un modo pouvait corriger promptement, ça m'arrangerait grandement…

    • [^] # Re: Oops le lapsus?

      Posté par (page perso) . Évalué à 6.

      J'imagine que tu voulais dire "de uselessd"?

      systemd-freud s'est retourné dans sa tombe, tellement ce lapsus est révélateur !

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

  • # Trop facile résumé...

    Posté par (page perso) . Évalué à -10. Dernière modification le 29/11/14 à 15:28.

    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.

    Chez moi, je peux proposer des baguettes et des fourchettes, et personne ne "gagne", c'est un peu plus de travail (ajouter un receptacle de plus) mais acceptable.
    Reste donc à ceux qui veulent des baguettes de se bouger les fesses et de les fabriquer (car perso je veux bien proposer les deux, mais refuse de fabriquer autre chose que ce qui m'interesse, je trouve ça normal de ne pas me taper le boulot pour l'autre choix, et le fait que les fabriquants de baguettes ne souhaitent pas cohabiter à côté de fourchettes en dit long).
    Note: intervertir baguettes et fourchettes est faisable, j'ai pris un sens comme ça, c'est tout.

    Bref, ton résumé est triste car il n'y a pas de "NdT: je sais, la conclusion est débile car une cantine peux proposer les deux, comme KDE et Gnome cohabitent très bien dans une distro".

    • [^] # Re: Trop facile résumé...

      Posté par (page perso) . Évalué à 9.

      Reste donc à ceux qui veulent des baguettes de se bouger les fesses et de les fabriquer

      Parce que tu fabriques tes fourchettes toi-même ?

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

      • [^] # Re: Trop facile résumé...

        Posté par . Évalué à 1.

        De toute façon, le problème des baguettes et des couverts n’est pas dans leur fourniture ou fabrication (ou rangement « un réceptacle de plus »). Le problème est qu’un plat fait pour être mangé avec des couverts n’est pas forcément facilement mangeable avec des baguettes.
        En clair : les frites avec des baguettes, ça va, le steak non découpé, c’est plus dur.

        • [^] # Re: Trop facile résumé...

          Posté par (page perso) . Évalué à -10. Dernière modification le 29/11/14 à 17:05.

          Et une cantine peut propose riz et baguettes et steak et couteau, pas besoin de créer une autre cantine pour ça. "Devoir" créer une autre cantine sous cette excuse est juste pour faire croire aux autres qu'on oeuvre pour leur bien, ans le penser le moins du monde (on veut juste bien cloisonner, au cas où ça soit contagieux, on ne jamais, comme les homos peuvent être contagieux).

          Vous pouvez moinsser, mais au moins vous pourriez aussi m'expliquer en quoi il y a besoin de forker pour proposer un init alternatif (option qui a été proposée, d'ailleurs, comme quoi vous avez besoin de leur expliquer que ce n'est pas possible leur idée sans forker…), parce qu'en attendant ça ressemlbe uniquement à des gamineries de cours d'école.

          • [^] # Re: Trop facile résumé...

            Posté par (page perso) . Évalué à 9.

            Vous pouvez moinsser, mais au moins vous pourriez aussi m'expliquer

            Pour ma part, je moinsse parce que j’estime que critiquer un résumé de trois lignes sur un article de 40 ko (le résumé n’étant là que pour ceux qui ont la flemme de lire l’article en question), ben… ce n’est pas pertinent.

            Tout comme le fait de vouloir débattre dudit résumé et de la justesse de la métaphore au lieu de débattre, je ne sais pas moi, du contenu de l’article peut-être.

            • [^] # Re: Trop facile résumé...

              Posté par (page perso) . Évalué à -10. Dernière modification le 29/11/14 à 17:47.

              si je comprend bien, tu me demandes de parler quand je n'ai rien à dire. Bof, je ne suis pas fan (je n'ai vraiment rien à dire sur le reste, il s'agit juste de personne ayant une vue différente de ce qu'elle veut, et je n'ai aucune critique à y apporter tous les gouts sont dnas la nature et il y a 36 bonnes raisons de ne pas vouloir systemd, alors pourquoi devrais-je écrire dessus?)

              Bizarre comme moinssage.

              • [^] # Re: Trop facile résumé...

                Posté par (page perso) . Évalué à 10. Dernière modification le 29/11/14 à 18:00.

                si je comprend bien, tu me demandes de parler quand je n'ai rien à dire.

                Non, je te dis que quand tu n’as rien à dire sur l’article proprement dit, tu peux juste… ne rien dire, plutôt que de chercher à critiquer les trois lignes du résumé.

                L’ironie de l’histoire est que c’est ton intervention qui donne à ce résumé une importance qu’il n’était probablement pas censé avoir.

              • [^] # Re: Trop facile résumé...

                Posté par . Évalué à 8. Dernière modification le 30/11/14 à 12:45.

                si je comprend bien, tu me demandes de parler quand je n'ai rien à dire.

                Eh bien moi je suis partisan que tu te taises quand tu n'as rien à dire. Surtout que tu annonces ça après avoir commencé à l'ouvrir. Ton credo c'est Ce n'est pas parce qu'on a rien à dire qu'il faut fermer sa gueule. Beaucoup déplorent, après, Beaucoup de bruit pour rien. Souvent du bruit désagréable, en plus. Tu as repris le flambeau de spécialiste de la logorrhée [Edit : et du pinaillage] autrefois tenu par d'autres, pas forcément mieux perçus.

                Je lis avec intérêt tes remarques à chaque fois qu'elles sont pertinentes, même si tu donnes souvent l'impression de penser que ceux qui n'ont pas la même opinion que toi sont des cons. Mais en l'occurrence, en accusant autrui de te demander de parler quand tu n'as rien à dire, tu parles de corde dans la maison du pendu.

            • [^] # Re: Trop facile résumé...

              Posté par . Évalué à 4.

              D'autant qu'à proprement parler c'est plus un teaser qu'un résumé. Il faut lire le texte pour le comprendre (les gens n'essaient en fait pas de trancher ce qui est le mieux entre fourchettes et baguettes mais entre cuisine occidentale et cuisine extrême-orientale – et non, les spécialistes du steak-frites qui tiennent la cantine ne vont vraisemblablement pas s'emmerder à rouler des makis tous les vendredis pour faire plaisir à tout le monde ; voilà, je pense effectivement qu'on peut passer à autre chose).

          • [^] # Re: Trop facile résumé...

            Posté par (page perso) . Évalué à 3.

            vous pourriez aussi m'expliquer en quoi il y a besoin de forker pour proposer un init alternatif

            Je pense que le problème, c'est que quand tu as des paquets qui dépendent de systemd pour certaines fonctionnalités, et que ces fonctionnalités sont utiles pour certains, ça va être difficile (et c'est normal) de convaincre ces mainteneurs pour qu'ils changent les options de compilation et/ou patchent le logiciel afin d'éliminer la dépendance ou proposer les deux options (ce qui peut compliquer la tâche au niveau des dépendances). Du coup, même si quelqu'un envoyait un patch pour proposer deux versions du paquet, ça ferait du travail en plus pour le mainteneur, de la communication en plus, des bugs en plus potentiellement, et il n'aura pas forcément envie de le faire. Du coup, il semble difficile de garantir, sans une ligne de conduite, une cohérence à une approche systemd+autres inits.

            Bref, pour qu'une distribution marche, il faut une certaine harmonie, donc suivre certaines règles, et il convient de savoir pour un mainteneur s'il doit ou pas s'inquiéter de la dépendance ou non de ses paquets à un système d'init (mais la même question pourrait se poser pour d'autres choses, comme le noyau, la librairie C, compilateur utilisé pour compiler, etc.). Quand les règles ne conviennent pas à tout le monde, ça fait un fork qui survit s'il y a suffisamment de monde, ou juste meurt dans le cas contraire, mais en ayant au passage fait du bruit. En tous cas, il n'y a pas de solution qui juste marche et peut convenir à tout le monde, à certains moments il y a des choix compliqués, même (ou plutôt surtout) quand on veut être « universel » comme Debian.

            • [^] # Re: Trop facile résumé...

              Posté par (page perso) . Évalué à 1. Dernière modification le 29/11/14 à 19:03.

              Du coup, même si quelqu'un envoyait un patch pour proposer deux versions du paquet, ça ferait du travail en plus pour le mainteneur,

              Etant développeur avec des gens "chiants" au niveau possiblités, je fais le nécessaire pour que tout soit possible (chargement dynamique des libs optionnelles, par exemple). Je suis conscient que c'est rare (la plupart des gens "rigolent" quand j'explique pourquoi je fais comme ça, ils se foutent du besoin des autres et veulent leur besoin), mais je trouve dommage que la seule solution affichée soit de forker à l'arrache comme ça : de mon point de vue, le travail pour garder une distro qui va bien et évoluer aussi vite que les autres (pour pas rester une "distro de vieux") demande bien plus d'efforts que de faire le nécessaire pour que les logiciels soient modulaires (dans tous les cas, le travail le plus dur, qui va être de coder ce qui manque pour que le logiciel x ne soit pas dépendant de systemd, sera à faire…), et désolé je ne crois pas que systemd soit si tentatuculaire qu'il va impacter 10 000 paquets ou plus.

              Bref, c'est dommage que le grand classique arrive : à la moindre petite difficulté, on préfére couper les liens que de passer l'épreuve ensemble en transformant la petite difficulté en "truc irréconciliable qui nous oblige à partir, attend on va te trouve des raisons qu'on va inventer pour arguementer contre les centristes qui ne comprennent rien" (toute ressemblance avec une politique nationale serait purement fortuite; ou pas)

              Dommage… Quel gachi.

              • [^] # Re: Trop facile résumé...

                Posté par . Évalué à 7.

                je ne crois pas que systemd soit si tentatuculaire qu'il va impacter 10 000 paquets ou plus.

                Non juste les paquets qui utilisent les libs systèmes (et par ricochet tous les paquets qui reposent sur des paquets qui utilisent des libs systèmes).

                Donc potentiellement tous oui. On est pas encore tout à fait au point ou on peut considérer que Linux avec systemd et Linux sans systemd sont deux OS distincts (Comme GNU/Linux et Android) mais on s'en rapproche vite.

                • [^] # Re: Trop facile résumé...

                  Posté par (page perso) . Évalué à 5. Dernière modification le 30/11/14 à 13:52.

                  Faut se dire, quand même que, sur Gentoo, les deux systèmes d'init sont possibles, donc ça reste dans le domaine du faisable a priori. Après, Debian n'a pas les mêmes contraintes sur ce qu'on attend de l'utilisateur (il faut un peu plus de finition), mais j'attends toujours de voir le jour où sysvinit (ou autre altenative à systemd) n'est pas possible dans Debian. Pour le moment, à quelques égratignures près, les deux marchent que je sache, tout ceci sans besoin de fork, et il y a surtout eu des discussions peu productives, plus qu'autre chose. Ceci dit, je ne suis pas tellement pessimiste au sujet d'un fork non plus : au pire, le travail qui sera fait dessus (à supposer qu'il y en ait, j'ai des doutes quand même) pourra revenir sur Debian, et vice-versa si besoin.

                  Et puis je trouve quand même que les systèmes d'init reçoient trop d'attention ces temps-ci. Debian c'est un peu plus qu'un système d'init, même quand celui-ci s'appelle systemd ;) Si Debian fait aujourd'hui un choix, rien n'oblige à ce que dans quelques années un autre choix ne soit pas fait : s'il fallait changer de noyau et la moitié des paquets ça risquerait d'être dur, mais juste changer de système d'init, même un dur à cuire avec des ramifications, ça ne devrait pas faire si peur que ça, je trouve.

                  • [^] # Re: Trop facile résumé...

                    Posté par . Évalué à 8.

                    mais juste changer de système d'init

                    systemd va bien au delà du système d'init, il controle les cgroups, le système de log, la création des devices aussi bien au boot que dynamiquement, la création des consoles, les sessions utilisateurs etc.

                    Pour l'instant on a des alternatives possibles pour la plupart des éléments séparément, mais au fur et à mesure que systemd avance ces alternatives deviennent de plus en plus complexe, et certaines sont impossibles. Par exemple les cgroups sont hardlockés et le système de log doit passer par systemd si systemd est installé (et en plus il faut faire pas mal de modifications pour que systemd daigne renvoyer des infos ET les logs sont dans un format différents du format habituel cf http://www.freedesktop.org/wiki/Software/systemd/syslog/ )
                    Prochaine étape annoncée : pas moyen de dialoguer avec udev si kdbus n'est pas présent dans le noyau (http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html)
                    Ensuite kmscon obligatoire, plus de getty ? On ne sait pas.

                    Donc non, le problème de systemd est très loin d'être la partie init (qui est même plutôt bonne en fait - bien qu'insuffisante poru certains besoins spécifiques). Mais bon c'est juste un daemontools inittabisé donc pas de crainte à avoir de ce coté là .Le problème de systemd c'est tout le reste.

                    • [^] # Re: Trop facile résumé...

                      Posté par . Évalué à 4.

                      Ensuite kmscon obligatoire, plus de getty ? On ne sait pas.

                      Quel est le rapport entre l'éradication de CONFIG_VT du kernel et systemd oO ?

                    • [^] # Re: Trop facile résumé...

                      Posté par (page perso) . Évalué à 3.

                      pas moyen de dialoguer avec udev si kdbus n'est pas présent dans le noyau

                      J'imagine que le fork d'udev de Gentoo n'aura pas cette contrainte, non ? Enfin, j'imagine que ça peut devenir compliqué, sans doute.

                      Les autres choses que tu mentionnes, m'ont plutôt l'air de montrer que la transition sysvinit vers systemd peut être difficile sous certaines configurations, voire même être impossible, mais il faudrait regarder surtout l'autre sens (que sysvinit vers systemd soit éventuellement compliqué, c'est un problème aujourd'hui, mais l'essentiel c'est que systemd vers un autre système reste humainement possible un jour si besoin).

                      • [^] # Re: Trop facile résumé...

                        Posté par . Évalué à 8.

                        Je crois que la clé est dans le courriel de Lennart Poettering. Il ne cache pas que le but à terme est d'avoir une pile noyau/systemd/GNU comme socle du système Linux, ce qui va fatalement nécessiter, au fur et à mesure que les composants de base seront intégrés à systemd (syslog, la console, etc.), de coder/maintenir des alternatives, aboutissant lentement mais sûrement à élaborer deux piles de base distinctes (noyau/systemd/GNU et noyau/un tas d'outils indépendants/GNU).

                        Finalement, ce ne sera pas très différent de ce qui se fait sous BSD, où chaque projet, même s'il n'a pas beaucoup de ressources, maintient sa propre pile de base en reprenant/intégrant les fonctionnalités qui l'intéresse chez les autres. Je pense que, comme le suggère l'auteur original, le vrai problème des détracteurs de systemd est qu'actuellement ils savent qu'ils ne veulent pas de systemd sans savoir où ils veulent vraiment aller, (contrairement à ceux qui font systemd, qui ont de toute évidence les idées claires).

                        Il y a aussi le problème de la perméabilité des couches. Si on est quasi-sûr que Linus ne laissera jamais l'intégration noyau/systemd se faire, il se pourrait que dans les couches hautes les gros environnements de bureau cèdent à la tentation, auquel cas ce sera très compliqué pour la pile alternative (faire du bricolage pour avoir une pile qui fonctionne sans systemd quand une partie est prévue pour, ça risque de susciter beaucoup de frustration chez ceux qui tiennent à la propreté des implémentations).

                        • [^] # Re: Trop facile résumé...

                          Posté par (page perso) . Évalué à 5.

                          Finalement, ce ne sera pas très différent de ce qui se fait sous BSD, où chaque projet, même s'il n'a pas beaucoup de ressources, maintient sa propre pile de base en reprenant/intégrant les fonctionnalités qui l'intéresse chez les autres.

                          Ceci dit, une différence, c'est que les outils du système de base, hors noyau, peuvent probablement se porter pour la plupart relativement facilement à un autre BSD, voir à une distribution Linux ; en pratique ça ne se fait pas forcément souvent, juste parce que personne n'y voit l'intérêt, j'imagine, mais ça reste une possibilité. Je pense par exemple à syslog, cron, ou même un système d'init traditionnel : il n'y a pas de couplage entre ceux-ci normalement.

  • # C’est toi qui est pas consistant!

    Posté par (page perso) . Évalué à 7.

    qui fait une inconsistance incohérence logique […]
    […] Fédora Fedora […]

    D’autre part, je n’ai pas compris ce que l’auteur a voulu dire dans ce paragraphe:

    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.

    Ce journal mérite une promotion en dépêche.

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: C’est toi qui est pas consistant!

      Posté par . Évalué à 3.

      Si je comprends bien cette partie, cela voudrait dire:

      «Si on considère que la portabilité de l'init est hors de propos (note perso: puisque le mécanisme d'init lui-même est fortement dépendant du système), alors il est logique que des projets s'appuient sur l'API de systemd. Comme le choix de tel ou tel système d'init est conséquemment politique (note perso: en raison de ce qui a été expliqué précédemment), l'hypothèse du "monde plus juste" ne peut pas tenir puisque tout choix politique conduit nécessairement à un rejet direct des autres propositions, au fondement tout aussi politique, conduisant à davantage de frustration.»

      Voilà comment je comprends le paragraphe.

    • [^] # Re: C’est toi qui est pas consistant!

      Posté par . Évalué à 1.

      Messieurs Robert et Larousse sont pourtant d'accord, on peut parler de l'inconsistance d'un raisonnement. L'original dit « non sequitur », le problème n'est pas que c'est faux mais que ça pourrait aussi bien l'être (d'où idée de fragilité, d'où « inconsistance »). Maintenant, j'aurais peut-être dû opter pour le latin dûment wikipédié (traduire est un métier, loin de moi l'idée de le nier).

      D’autre part, je n’ai pas compris ce que l’auteur a voulu dire dans ce paragraphe:

      Si le monde est juste, il est impossible que systemd triomphe par autre chose que ses qualités, d'où ses zélateurs ne vont même pas discuter de ce qu'implique ou pourrait impliquer l'exposition de ses APIs.

      Ce journal mérite une promotion en dépêche.

      Je voulais minimiser les risques de « parasitage » avec la dépêche en court (même si elle a un pointeur vers l'original). ;)

  • # Je ne suis pas sûr à 100%...

    Posté par . Évalué à 5.

    Je ne suis pas certain à 100% de comprendre cette phrase:

    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 ».

    L'auteur veut-il dire que OpenRC eut été une [des] amélioration(s) viable(s) du système d'init actuel, pourvu qu'on la développât éventuellement davantage?

    • [^] # Re: Je ne suis pas sûr à 100%...

      Posté par . Évalué à 4.

      Je ne crois pas qu'il aille aussi loin ici. Il dit juste que finir avec une bouillie de scripts cradingues comme c'est trop souvent le cas n'est pas une fatalité (ie. pas un bon argument contre sysvinit).

      • [^] # Re: Je ne suis pas sûr à 100%...

        Posté par . Évalué à 4.

        Merci pour ton éclaircissement. La litanie des sophismes autour des zélateurs de systemd m'a aussi éclairé et je comprends encore un peu plus pourquoi c'est le bordel généralisé.

        Je pense qu'on peut parler d'hypocrisie et les deux camps sont concernés. Je reste persuadé qu'il naîtra un jour un système qui ne provoque plus ce genre de débat infructueux, qu'il dérive de systemd (ou pas) ou qu'il dérive de SystemV (ou pas).

  • # bientôt en dépêche

    Posté par (page perso) . Évalué à 2. Dernière modification le 29/11/14 à 19:40.

    @MrSpackman :
    On est en train de transformer ton journal en dépêche, j'ai réécris un paragrahe que je trouvais peu compréhensible, ça me semble correct par rapport à l'original mais qu'en penses-tu toi ?

    • Ta traduction : Beaucoup de monde travaillerait plus volontiers sur des projets personnels plutôt 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).
    • Révision : Beaucoup de gens coderaient plus volontiers des projets personnels plutôt que faire l'effort d'écrire de tels systèmes dont ils pensent qu'ils sont largement compensés par des outils séparés et discrets (sans doute en ont-ils écrit certains).

    NB : j'ai remplacé "monde" par "gens" à cause du "ils" qui suit.

    Il y aussi pas mal de retouches de détails faites dans le texte. Pas pour le plaisir mais pour la clarification.

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: bientôt en dépêche

      Posté par (page perso) . Évalué à 8. Dernière modification le 29/11/14 à 22:13.

      Il y aussi pas mal de retouches de détails faites dans le texte

      en profiter pour reprendre le commentaire de sinma< plus haut et j'ajouterai (en acceptant1 la licence retenue pour le texte, soit une BSD 2-clause, évitant d'imposer une CC-by-sa que le passage par l'espace de rédaction aurait apposée) :

      • s/émergeant/émergent/
      • enlever les virgules avant les et et les ou
      • s/supporters/zélateurs/ et s/opposants/détracteurs/ par cohérence avec le titre du §
      • s/quelque soit le côté/quel que soit le côté/
      • s/APIs/API/
      • s/Ce qu'ont cherche/Ce qu'on cherche/
      • j'ai un doute sur s/gère tant de choses, telles/gère tant de choses, tels/
      • s/propagés/propagées/ (les dépendances)
      • s/le débats/les débats/
      • s/nulle-part/nulle part/
      • s/temps de démarrages/temps de démarrage/
      • s/la plupart des distros Linux a accumulé/la plupart des distros Linux ont accumulé/
      • s/Unixes/Unix/g
      • s/Solaris, …/ Solaris…/
      • s/l'assomption/la supposition/ mais ça doit être mon côté catholique qui ressort
      • l'éternelle muleta : je suis le seul à penser qu'il y a une contrepèterie avec Nutella ?
      • s/plugin/greffon/
      • j'ai adoré l'expression très imagée « vous faire seppuku avec une roulette à pizza »
      • s/BSDs/BSD/
      • s/bons principes conception/bons principes de conception/
      • s/à ne déboucher sans cesse nulle part/à déboucher sans cesse nulle part/ mais mon compteur de négations s'est peut-être emballé ?
      • s/Le parties techniquement/Les parties techniquement/
      • s/hackeurs/_hackers_/ autant utiliser le terme anglais
      • s/Ils sont les personnes/Ce sont les personnes/ pour éviter de ramener les féministes dans la discussion (là c'est le neutre qui conserve sa place, moins visible ou parfois confondue :/)
      • s/voire même/voire/
      • s/certainement à un choc/certainement un choc/

      Le faible nombre de coquilles relevées icitte est à mettre au crédit du traducteur, surtout pour un texte aussi long et argumenté (resterait à vérifier d'éventuels contresens entre l'anglais et le français, ce que je n'ai point fait, même si j'ai aussi lu la version en anglais :D). Félicitations pour l'écriture parfaite de dilemme pour lequel j'ai toujours un doute ;-) Merci au modérateur qui prendra en compte mes suggestions pour les apposer aussi au journal , alors qu'il suffirait qu'un admin' me redonne des droits pour que ce soit moi qui m'y colle).

      J'aimerais bien une clarification de la boutade sur OpenRC (sans doute à demander à l'auteur), moi je l'ai comprise par rapport à la notion de rc.d/ : les services étant par nature hors de l'init (mais souvent appelés par l'init), mais je confonds peut-être un peu tout.

      Merci encore de cette traduction qui a dû te prendre de l'ordre de 7 heures réparties sur plusieurs jours, à moins que tu ne sois un prodige de la traduction et de l'écriture ; tu peux faire une passe sur les traductions classiques pour nous faire partager ton savoir ! ;-)


      1. même si de la correction typographique et orthographique et des suggestions éparses n'ouvrent que peu souvent de droit d'auteur, autant le préciser. 

      • [^] # Re: bientôt en dépêche

        Posté par (page perso) . Évalué à 2.

        c'est fait, merci

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: bientôt en dépêche

          Posté par (page perso) . Évalué à 3.

          ah bah, non, je suis encore visitor :/

          c'est fait, merci

          merci à toi, plutôt (c'est l'ami de Mickey<).

          belle abnégation d'une part et implication pour un texte déjà bien rédigé d'autre part, vivement qu'il soit publié ! Merci encore de la promotion méritée en dépêche.

          • [^] # Re: bientôt en dépêche

            Posté par (page perso) . Évalué à 3.

            Peut-être qu’une petite note sur le fait qu’une autre dépêche sur systemd est encours dans le même registre serait intéressante (afin de ramener un peu plus de monde et surtout aider à la finaliser). Qu’en pensez-vous?

            Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: bientôt en dépêche

        Posté par . Évalué à 3.

        j'ai adoré l'expression très imagée « vous faire seppuku avec une roulette à pizza »

        +1

        J'aimerais bien une clarification de la boutade sur OpenRC

        MrSpackMan répond à cette question, que j'ai posée un peu plus haut.

        • [^] # Re: bientôt en dépêche

          Posté par . Évalué à 2.

          j'ai adoré l'expression très imagée « vous faire seppuku avec une roulette à pizza »

          +1

          Perso, ça m'a aussi évoqué Hara-kiri, dans lequel ils obligent le gars à s'ouvrir le ventre avec son sabre en bois. Comme quoi, le seppuku on en fait tout un plat, mais c'est juste une question d'outillage.

      • [^] # Re: bientôt en dépêche

        Posté par . Évalué à 1.

        Mazette ! j'ai pourtant fait gaffe, mais il en restait pas mal…

        • Pour « émergeant » c'est le participe présent (avec l'adverbe « partout ») ;
        • supporters/opposants, c'est parce que ça diffère dans l'original, mais effectivement je ne crois pas qu'il y ait un sens particulier derrière ;
        • ce sont les choses qui sont telles quelles ;
        • assomption est plus fort que supposition, il y a affirmation implicite. On peut mettre « en partant du principe que » ;
        • pour muleta on peu mettre « chiffon rouge », si ça gêne.

        Pour RC, je crois que c'est simplement parce que sous BSD le premier script à être lancé est /etc/rc, qui va lancer à son tour tous les autres en fonction de ce qui est configuré dans /etc/rc.conf. J'imagine qu'OpenRC reprend ce schème.

        Merci pour cette relecture. :-)

      • [^] # Re: bientôt en dépêche

        Posté par . Évalué à 1.

        Encore une…

        s/ce sont les mainteneurs des distros qui porte/ce sont les mainteneurs des distros qui portent/

    • [^] # Re: bientôt en dépêche

      Posté par . Évalué à 1.

      J'ai pas mal souffert sur ce passage (la traduction de « solve », en particulier). Dans la révision, je mettrais juste « qu'ils pensent être » pour s'économiser le « dont ».

      Et puisqu'on en cause, j'ai eu un doute sur le sens de la parenthèse, je ne sais pas si ça veut dire « ils ont écrits certains de ces outils », ou bien « ces outils sont certains de ceux qu'ils ont écrits ». Dans le deuxième sens, ça pourrait sous-entendre qu'ils s'en sortent avec du gros hack perso mais pas une solution universellement déployable. Vraiment, je ne sais pas.

      • [^] # Re: bientôt en dépêche

        Posté par (page perso) . Évalué à 2.

        J'ai eu le même doute :-)
        Dans le doute j'ai repris ta version en forçant un peu l'ambiguité. Je la crois d'ailleurs volontairement présente dans la version anglaise.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.