URL: https://linuxfr.org/news/mise-aux-poings-sur-systemd Title: Mise aux poings sur systemd Authors: ariasuni esdeem, rogo, BAud, Misc, ZeroHeure, antistress, olivierweb, claudex, Benoît Sibaud, Atem18, lcld, palm123, Valentin, oinkoink_daotter, Denis Dordoigne, Melkor73, Nils Ratusznik, Fabrice Devaux, Kaane, JPEC, rootix, ZeDuke, Laurent Pointecouteau, _PhiX_, Vincent, or zax, Pierre Jarillon et Anthony Jaguenaud Date: 2014年03月29日T20:16:18+01:00 License: CC By-SA Tags: systemd, dbus, troll, selinux, bsd, démarrage et mauvaise_foi Score: 96 `systemd` est un gestionnaire du système et de services (aussi appelé « PID 1 », car c’est le premier processus à être lancé) pour Linux, compatible avec SysV et les scripts d’init [LSB](http://fr.wikipedia.org/wiki/Linux_Standard_Base). `systemd` a des capacités de parallélisation énergiques. Il utilise les sockets et l’activation par D-Bus pour démarrer les services, permettant le démarrage à la demande des démons. Il surveille et commande les processus avec les groupes de contrôle (_cgroups_) Linux. Il prend en charge la construction d’instantanés et la restauration de l’état du système. Il maintient les points de montage et d’auto-montage, et implémente une logique de contrôle transactionnelle élaborée fondée sur les dépendances entre services. [systemd](http://freedesktop.org/wiki/Software/systemd/) ne fait pas partie du projet [freedesktop.org](http://www.freedesktop.org/wiki/), bien qu’hébergé sur le site. Il est codé en langage C et publié sous licence GNU GPL 2.1+. Il a été lancé par Lennart Poettering, auteur de PulseAudio et d'Avahi entre autres, et est maintenant activement développé par plusieurs dizaines de développeurs. La dernière dépêche concernant systemd a suscité de nombreuses réactions et certaines d'entre elles montraient une méconnaissance de ce logiciel : la dépêche se contentait, pour la majeure partie il est vrai, de traduire les notes de versions. Je vais donc faire un point sur systemd, histoire d’en finir une bonne fois pour toutes avec les discussions sans fin sur systemd (l’espoir fait vivre). ---- [Site officiel de systemd](http://freedesktop.org/wiki/Software/systemd/) [Dépêche: « Évolutions techniques de systemd »](https://linuxfr.org/news/%C3%A9volutions-techniques-de-systemd) [Les 30 plus grands mythes à propos de systemd](http://0pointer.de/blog/projects/the-biggest-myths.html) ---- Ce qui suit est en grande partie une traduction d’un article [_Les 30 plus grands mythes à propos de systemd_](http://0pointer.de/blog/projects/the-biggest-myths.html) paru en janvier 2013 sur le site de Lennart Poettering. Donc à partir de maintenant et jusqu’à la fin, c’est Lennart Poettering qui (indirectement) parle ! --- Depuis la première proposition d’inclusion de systemd au sein des distributions, on en a fréquemment parlé sur de nombreux forums, listes de diffusion et conférences. Dans ces discussions, on peut souvent entendre certains mythes à propos de systemd, qui sont répétés encore et encore, sans que cette répétition ne les rende vrais pour autant. Prenons le temps d’en briser quelques-uns : # systemd est monolithique systemd est constitué de plus de 70 binaires (NdT : 72 sur ma machine !) clairement séparés. D’une part, systemd a été conçu pour être sécurisé : chaque binaire effectue une tâche très spécifique avec des privilèges minimaux — en utilisant les capacités (_capabilities_) du noyau par exemple — pour réduire la surface d’attaque et l’impact de failles de sécurité. Cela rend également systemd plus robuste et plus facile à faire évoluer et à déboguer. D’autre part, cette séparation est essentielle pour que systemd puisse lancer ces binaires en parallèle. Beaucoup d'entre eux sont même si bien séparés qu’ils peuvent aussi être utiles en dehors de systemd (systemd-detect-virt, systemd-tmpfiles ou systemd-udevd, par exemple). Un ensemble de plusieurs dizaines de binaires peut difficilement être qualifié de monolithique. À la différence de ce qui se pratiquait auparavant, les composants sont dans une seule archive, et ils sont tous maintenus en amont dans un seul dépôt avec un cycle de publication unifié — ce qui est sans doute bénéfique au bon fonctionnement de l’ensemble. # systemd a été conçu pour la vitesse Oui, systemd est rapide (on peut obtenir un espace utilisateur presque complet en à peu près 900 ms !), mais c’est principalement un effet secondaire d’avoir fait les choses correctement. En fait, nous n’avons jamais essayé d’optimiser chaque parcelle de systemd ; au contraire, nous avons fréquemment choisi en toute connaissance de cause un code légèrement plus lent en faveur de la lisibilité du code. Cela ne veut pas dire que la vitesse ne nous intéresse pas, mais réduire systemd à sa vitesse est une idée fausse, car ce n’est pas du tout dans nos priorités. # La vitesse de systemd ne sert à rien pour les serveurs ! C’est complètement faux. Beaucoup d’administrateurs désirent réduire les temps d’arrêt des fenêtres de maintenance. Pour les configurations à haute disponibilité, c’est sympathique d’avoir une machine indisponible qui redevient très vite disponible (le besoin utilisateur étant « toujours disponible », même s’ils oublient les interventions techniques (montée de version de logiciel, d’OS...), vu qu’ils ont une approche « nos utilisateurs » pour lesquels une nouvelle version ne correspond qu’à des ajouts, pas des régressions...). Pour les configurations dans les nuages avec un nombre important de machines virtuelles ou de conteneurs, le cout d’un démarrage lent est multiplié par le nombre d’instances. Passer plusieurs minutes de temps CPU et d’entrées/sorties sur des démarrages très lents de milliers de machines virtuelles ou de conteneurs réduit la densité de votre système de façon importante, cela vous coute même plus d’énergie. Un démarrage lent peut vous couter beaucoup d’argent, alors qu’un démarrage rapide permet d’implémenter une logique d’activation de conteneurs par socket pour augmenter la densité de votre système dans les nuages. Bien entendu, pour la plupart des configurations de serveur, le temps de démarrage n’est pas intéressant, mais systemd est censé couvrir le plus de cas possibles. Et oui, je suis au courant que c’est souvent le micrologiciel du serveur qui prend le plus de temps au démarrage, et que le système d’exploitation démarre vite en comparaison, mais tous les serveurs n’ont pas un aussi mauvais micrologiciel, et certainement pas les machines virtuelles ni les conteneurs, qui sont un type de machine virtuelle également. Note : nous essayons de faire notre petite part pour rendre les micrologiciels meilleurs. En mettant les performances de démarrage du micrologiciel en évidence dans la sortie de systemd, nous espérons que la honte poussera les auteurs de micrologiciels à nettoyer leur travail. # systemd est incompatible avec les scripts shell C’est complètement bidon. Nous ne les utilisons pas pour le processus de démarrage parce que nous pensons qu’ils ne sont pas le meilleur outil pour cette tâche spécifique, mais cela ne signifie pas que systemd n’est pas compatible avec eux. Vous pouvez facilement lancer des scripts shell en tant que service systemd, systemd n’a strictement rien à faire de ce qui est à l’intérieur de votre exécutable. De plus, nous utilisons énormément les scripts shell pour installer, construire et tester systemd. Et vous pouvez continuer à utiliser vos propres scripts très tôt dans le démarrage, les utiliser comme des services normaux, les lancer à l’extinction de la machine, il n’y a quasiment aucune limite. # systemd est compliqué C’est aussi un non-sens total. Une plateforme systemd est en réalité beaucoup plus simple que les Linux traditionnels, car elle unifie le système d’objets et leurs dépendances en unités systemd. Le langage des fichiers de configuration est très simple et on se débarrasse des fichiers de configuration redondants. Nous fournissons des outils uniformes pour la plupart des tâches de configuration du système. Le système est beaucoup moins aggloméré que les Linux traditionnels. Nous avons également une documentation plutôt complète ([tout est présent sur la page d’accueil](http://www.freedesktop.org/wiki/Software/systemd)) sur à peu près tous les détails de systemd, et cela ne couvre pas seulement les interfaces pour utilisateur et administrateur, mais également les API pour les développeurs. systemd nécessite bien sûr un apprentissage. Comme toute chose. Cependant, nous aimons croire que c’est vraiment plus simple de comprendre systemd qu’un démarrage fondé sur des scripts shell pour la plupart des gens. Surpris de ces paroles ? Eh bien, il s’avère que le shell n’est pas un langage sympathique à apprendre, sa syntaxe est obscure et complexe. Les fichiers unités de systemd sont beaucoup plus simples à comprendre, ils ne nous exposent pas à un langage de programmation, mais sont simples et déclaratifs par nature. Cela dit, si vous avez de l’expérience en shell, en effet, adopter systemd vous demandera un petit peu d’apprentissage. Afin de rendre l’apprentissage facile, nous avons fait notre maximum pour fournir une compatibilité avec les solutions précédentes. De plus, sur de nombreuses distributions, vous remarquerez que certains des outils traditionnels vous diront — en faisant ce que vous leur aviez demandé — comment vous pourriez le faire avec les nouveaux outils à la place, possiblement d’une façon plus agréable. Bref, systemd ne peut probablement pas être plus simple qu’il ne l’est déjà pour la tâche qu’il remplit, et nous avons travaillé dur pour qu’il soit simple à apprendre. Alors oui, si vous connaissez sysvinit alors adopter systemd va vous demander un peu d’apprentissage ; mais franchement, si vous maitrisez sysvinit, alors systemd devrait être facile pour vous. # systemd n’est pas modulaire Tout faux. À la compilation, il y a beaucoup d’options de configuration pour choisir ce que vous voulez compiler ou non. Et nous documentons comment sélectionner encore plus en détail ce dont vous avez besoin, en allant plus loin que les options de configuration. Cette modularité n’est pas totalement différente de celle du noyau Linux, où vous pouvez sélectionner beaucoup de fonctionnalités individuellement à la compilation. Si le noyau est assez modulaire pour vous, alors systemd l’est probablement. # systemd est seulement pour les ordinateurs de bureau Ce n’est certainement pas vrai. Avec systemd, nous essayons à peu près de couvrir la même portée que Linux. Alors, que nous tenons compte des usages bureautiques, nous tenons aussi compte des usages serveur, ainsi que des usages embarqués. Vous pouvez parier que Red Hat ne voudrait pas en faire une pièce centrale de RHEL 7 si ce n’était pas la meilleure option pour gérer les services des serveurs. Des personnes de différentes entreprises travaillent sur systemd. Les fabricants de voitures l’intègrent dans leurs voitures, Red Hat l’utilise pour ses systèmes d’exploitation pour serveurs, et GNOME utilise nombre de ses interfaces afin d’améliorer le bureau. Vous le trouvez dans les jouets, les télescopes et dans les éoliennes. La plupart des fonctionnalités sur lesquelles j’ai travaillé récemment, relèvent du domaine des serveurs, comme le support des conteneurs, le management des ressources ou des fonctionnalités de sécurité. Nous couvrons plutôt bien les systèmes bureautiques pour le moment, et il y a de nombreuses entreprises faisant du développement sur systemd pour l’embarqué, certaines offrent même des services de consultance pour lui. # systemd est un résultat du syndrome NIH (NdT : _Not Invented Here_, « Pas inventé ici ») Ce n’est pas vrai. Avant que nous commencions à travailler sur systemd, nous poussions l’adoption à grande échelle d’Upstart (et Fedora/RHEL l’utilisent également depuis un moment). Cependant, nous sommes finalement arrivés à la conclusion que le cœur de sa conception présentait des défauts (au moins à nos yeux : plus fondamentalement, il laisse la gestion des dépendances à l’administrateur/au développeur, au lieu de résoudre ce problème difficile dans le code) et, si quelque chose ne va pas dans le cœur, il vaut mieux le remplacer que de le corriger. Ça n’est pas la seule raison cependant, d’autres choses ont joué, comme le bordel autour du _[CLA](http://en.wikipedia.org/wiki/Contributor_License_Agreement#Canonical)_. NIH n’était cependant pas une des raisons... Note : et puis, devinez quel projet inclut une bibliothèque « libnih » — Upstart ou systemd ? (indice : ça n’est pas systemd !) # systemd est un projet freedesktop.org Ma foi, c’est vrai que systemd est hébergé sur fdo, mais freedesktop.org n’offre pas grand-chose de plus qu’un dépôt pour le code et la documentation. À peu près tous les développeurs peuvent demander de l’espace et déposer leurs affaires ici (à condition d’avoir un vague rapport avec l’infrastructure des systèmes libres). Il n’y a pas de cabale, pas de processus de standardisation, pas de vérification de projet, rien. C’est juste un hébergement sympa, gratuit et solide pour mettre un dépôt. De ce point de vue, c’est un peu comme sourceforge, github, kernel.org, mais de nature non commerciale et sans demandes excessives et donc, un bon endroit où mettre notre projet. Donc oui, nous avons choisi fdo pour l’hébergement, mais l’hypothèse implicite de ce mythe, qu’il existe un groupe de gens qui se rencontrent et qui décident du futur des systèmes libres, est entièrement fausse. # systemd n’est pas UNIX Il y a certainement du vrai en cela. Les sources de systemd ne contiennent pas une seule ligne de code héritée de l’UNIX originel. En revanche, notre inspiration nous vient d’UNIX et c’est pourquoi il y a beaucoup d’UNIX en systemd. Par exemple, l’idée d’UNIX du « tout est fichier » trouve son jumeau dans systemd où tous les services sont exposés au lancement dans un système de fichiers du noyau, le cgroupfs. Ensuite, une des fonctionnalités originelles d’UNIX était celle des multi-terminaux (*multi-seat*), basée sur la prise en charge des consoles (terminaux d'ordinateurs). Les consoles en mode texte ne sont pas vraiment la manière dont vous interagissez avec votre ordinateur de nos jours. Avec systemd, nous avons apporté le retour de la gestion des multi-terminaux, mais cette fois avec la gestion complète des composants modernes, des cartes graphiques aux souris, systèmes audio, webcams et bien plus, et tout cela complètement automatique, branchements à chaud et sans configuration. En effet, le design de systemd en tant que suite d’outils intégrés dont chacun a ses buts propres, voilà la philosophie du cœur d’UNIX. Ensuite, la façon dont notre projet est géré (c'est-à-dire maintenir la majeure partie du cœur de l’OS dans un unique dépôt git) est plus proche du modèle BSD (qui est un vrai UNIX, pas comme Linux) dans la façon de faire (où la plus grande partie du cœur de l’OS est conservé dans un seul répertoire CVS/SVN) que de la façon de faire de Linux. Enfin, UNIX est quelque chose de différent pour chacun. Pour nous, les mainteneurs de systemd, c’est quelque chose dont nous nous inspirons. Pour d’autres, c’est une religion, et tout comme les autres religions du monde, il y a différentes façons de lire ou d’interpréter. Certains définissent UNIX comme un héritage de certains bouts de codes spécifiques, d’autres le voient juste comme un ensemble d’idées, d’autres comme un ensemble de commandes, et d’autres encore comme une définition de comportements. Bien sûr, il est impossible de faire en sorte que toutes ces personnes soient heureuses. Finalement, la question de savoir si quelque chose est UNIX ou non importe vraiment peu. Être techniquement excellent n’est pas exclusif à UNIX. Pour nous, UNIX est une influence majeure (zut, la plus grosse), mais nous avons aussi d’autres influences. Ainsi, dans certains domaines systemd sera vraiment UNIX et dans d’autres un peu moins. # systemd est complexe Il y a un fond de vérité à cela. Les ordinateurs modernes sont des choses complexes et le système qui tourne dessus doit donc être complexe aussi. Toutefois, systemd n’est pas plus complexe que les implémentations précédentes des mêmes composants. Au contraire, il est plus simple et réduit les redondances (voir plus haut). De plus, construire un système simple basé sur systemd impliquera moins de paquets qu’un système Linux traditionnel. Avoir moins de paquets facilite la construction du système et permet de se débarrasser des interdépendances et des comportements divergents de chaque composant impliqué. # systemd est une usine à gaz Hé bien, il y a probablement plusieurs définitions de « usine à gaz ». Mais dans la plupart des définitions, systemd est probablement l’opposé d’une usine à gaz. Vu que les composants systemd partagent une base de code commune, ils ont tendance à partager plus de code pour les fonctions générales. Voici un exemple : dans une configuration Linux traditionnelle, sysvinit, start-stop-daemon, inetd, cron, dbus implémentent tous une façon de lancer des processus avec des options de configuration variées dans un environnement que l’on espère propre. Dans systemd, les fonctions pour tout ceci, que ce soit le _parsing_ (NdT : analyse syntaxique si vous y tenez vraiment) de la configuration ou le lancement lui-même, sont partagées. Cela se traduit par moins de code, moins de place pour faire des erreurs, moins de mémoire occupée et moins de pression sur le cache, et donc c’est une très bonne chose. Et en plus, vous gagnez une tonne de nouvelles fonctionnalités grâce à ça. Comme mentionné plus haut, systemd est aussi plutôt modulaire. Vous pouvez choisir à la compilation les composants dont vous avez besoin et ceux dont vous pouvez vous passer. De sorte que les gens peuvent choisir à quel point systemd est une « usine à gaz ». Quand vous compilez systemd, il ne demande que 3 dépendances : glibc, libcap et dbus. C’est tout. Il peut utiliser beaucoup plus de dépendances, mais elles sont toutes entièrement optionnelles. Donc oui, sous tous les angles, ce n’est vraiment pas une usine à gaz. # systemd seulement pour Linux, pas sympa pour les BSD Complètement faux. Les gens de chez BSD ne sont pas vraiment intéressés par systemd. Si systemd était portable, cela n’aurait rien changé, ils ne voudraient pas l’adopter quand même. Et la même chose est vraie pour les autres Unix dans le monde. Solaris a SMF, BSD a son propre système _rc_, et ils l’ont toujours maintenu séparément de Linux. Le système d’initialisation est très proche du cœur du système d’exploitation. Et ces autres systèmes d’exploitation se définissent eux-mêmes, entre autres choses, par le cœur de leur espace utilisateur. L’hypothèse qu’ils aient adopté notre cœur d’espace utilisateur si nous l’avions juste rendu portable est sans aucun fondement. # systemd seulement pour Linux empêche son adoption comme système d’initialisation par défaut sur Debian NdT : [Debian est déjà passée à systemd](https://linuxfr.org/users/elessar/journaux/debian-adopte-systemd-comme-init-par-defaut), mais on traduit aussi cette partie pour le plaisir. :p Debian prend en charge des noyaux non-Linux dans leur distribution. systemd ne fonctionnera pas sur ceux-ci. Est-ce que c’est cependant un problème, et cela doit-il gêner l’adoption de systemd par défaut ? Pas vraiment. Les gens qui ont porté Debian sur ces noyaux sont prêts à investir du temps dans un portage qui demande beaucoup de travail, ils ont mis en place des systèmes de tests et de compilation, patché et compilé de nombreux paquets pour atteindre ce but. La maintenance à la fois d’une unité systemd et d’un script d’initialisation classique pour les services empaquetés est une charge de travail négligeable comparé à cela, en particulier parce que le plus souvent ces scripts existent déjà. # systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient C’est tout simplement faux. Faire un portage de systemd sur d’autres noyaux n’est pas faisable. Nous utilisons trop d’interfaces spécifiques à Linux. Pour certaines, on peut trouver des remplacements sur les autres noyaux, pour d’autres nous pourrions les désactiver, mais pour la plupart, ce n’est vraiment pas possible. Voici une petite liste non exhaustive: cgroups, fanotify, `umount2()`, `/proc/self/mountinfo` (incluant les notifications), `/dev/swaps` (de même), udev, netlink, la structure de `/sys`, `/proc/$PID/comm`, `/proc/$PID/cmdline`, `/proc/$PID/loginuid`, `/proc/$PID/stat`, `/proc/$PID/session`, `/proc/$PID/exe`, `/proc/$PID/fd`, tmpfs, devtmpfs, capacités, espaces de nommages en tout genre, divers `prctl()`s, de nombreux `ioctl`s, l’appel système `mount()` et sa sémantique, SELinux, audit, inotify, statfs, `O_DIRECTORY`, `O_NOATIME`, `/proc/$PID/root`, `waitid()`, `SCM_CREDENTIALS`, `SCM_RIGHTS`, `mkostemp()`, `/dev/input`, et ainsi de suite. Si vous regardez cette liste et prenez les quelques éléments auxquels vous pouvez trouver un équivalent évident dans d’autres noyaux, alors réfléchissez à nouveau, et regardez ceux que vous n’avez pas considérés et la complexité nécessaire pour les remplacer. # systemd n’a pas de raison de ne pas être portable Ça n’a aucun sens ! Nous utilisons des fonctions spécifiques à Linux parce que nous en avons besoin pour implémenter ce que nous voulons. Linux a beaucoup de fonctionnalités qu’UNIX/POSIX n’a pas, et nous voulons que les utilisateurs puissent en tirer parti. Ces fonctions sont incroyablement utiles, mais seulement si elles sont offertes de manière conviviale à l’utilisateur et c’est ce que nous voulons faire avec systemd. # systemd utilise des fichiers de configuration binaire Je n’ai aucune idée d’où est sorti ce mythe fou, mais ça n’est absolument pas vrai. systemd est configuré quasi exclusivement par de simples fichiers textes. Vous pouvez également modifier quelques options avec la ligne de commande du noyau ou par des variables d’environnement. Il n’y a rien de binaire dans sa configuration (même pas de XML). Seulement des fichiers en texte brut, simples, et faciles à lire. # systemd est un cauchemar de fonctionnalités Eh bien, systemd couvre certainement plus de terrain que par le passé. Ce n’est plus uniquement un système d’initialisation, mais le bloc de base de l’espace utilisateur à partir duquel construire un système d’exploitation ; mais nous faisons attention de garder optionnelles la plupart des fonctionnalités. Vous pouvez en désactiver beaucoup lors de la compilation, et encore plus lors de l’exécution. Ainsi pouvez-vous choisir librement combien de fonctionnalités injecter. # systemd vous force à faire quelque chose systemd n’est pas la mafia. C’est un logiciel libre, vous pouvez en faire ce que vous voulez, ce qui inclut ne pas l’utiliser. C’est plutôt l’opposé de « forcer ». # systemd rend impossible l’utilisation de syslog C’est faux, nous avons fait attention lors de l’introduction du journal à ce que les informations soient transmises au serveur syslog. En fait, s’il y a bien une chose qui a changé, c’est surtout le fait que syslog reçoit maintenant plus d’informations, car nous nous occupons du début du démarrage système ainsi que des flux STDOUT/STDERR de tous les services du système. # systemd est incompatible Nous faisons de notre mieux pour garantir la meilleure compatibilité possible avec sysvinit. En fait, la grande majorité des scripts d’initialisation fonctionne telle quelle sous systemd, sans modifications. Toutefois, il y a effectivement quelques incompatibilités, mais nous essayons de les documenter et d’expliquer comment y réagir. En fin de compte, tout système qui n’est pas systemd aura une certaine dose d’incompatibilité avec lui vu qu’il n’aura pas exactement la même structure d’exécution. Notre but est que les différences entre les multiples distributions restent à un niveau minimum. Cela implique que les fichiers unité fonctionnent généralement bien sur une distribution différente de celle où ils ont été conçus, ce qui est un énorme progrès sur les scripts classiques d’initialisation qui sont très difficiles à écrire d’une façon portable à d’autres distributions Linux, compte tenu des nombreuses incompatibilités entre elles. # systemd n’est pas scriptable, à cause de son utilisation de D-Bus Ce n’est pas vrai. Presque chaque interface D-BUS que fournit systemd est aussi accessible via un outil en ligne de commande, par exemple dans `systemctl`, `loginctl`, `timedatectl`, `hostnamectl`, `localectl` et autres. Vous pouvez aisément appeler ces outils depuis des scripts shell, ils donnent accès à pratiquement toute l’API depuis la ligne de commande avec des commandes faciles d’emploi. Cela dit, D-Bus a aussi une interface (NdT : *bindings*) pour presque tous les langages de script de ce monde. Même depuis le shell on peut invoquer des méthodes D-Bus quelconques avec `dbus-send` ou `gdbus`. Finalement, cela facilite son utilisation dans des scripts grâce à la bonne gestion de D-Bus par les différents langages de script. # systemd requiert l’utilisation d’obscurs outils de configuration au lieu d’éditer des fichiers textes directement Ce n’est pas vrai du tout. Nous proposons des outils de configuration, et leur utilisation vous fournit quelques fonctionnalités complémentaires (par exemple, la complétion en ligne de commande de tous les paramètres !), mais ils ne sont en rien nécessaires. On peut toujours modifier les fichiers en question directement si on le souhaite, et c’est totalement accepté. Bien sûr que quelquefois on a besoin de recharger explicitement la configuration d’un démon après l’avoir modifiée, mais ceci est vrai de la plupart des services UNIX. # systemd est instable et bogué Selon nos données, certainement pas. Nous analysons minutieusement le système de suivi de bogues (NdT : *bugtracker*) de Fedora (et d’autres) depuis longtemps. Le nombre de bogues est très faible pour un tel composant central du système d’exploitation, surtout si on en retranche les nombreuses propositions d’améliorations (NdT : *RFE*) que nous enregistrons dans ce projet. Nous sommes plutôt bons pour maintenir systemd hors de la liste des bugs bloquant la distribution. Notre cycle de développement est plutôt rapide avec principalement des modifications incrémentales pour conserver un haut niveau de qualité et de stabilité. # systemd n’est pas déboguable Faux. Certains sous-entendent que le shell était un bon débogueur. Hé bien pas vraiment. Dans systemd nous vous fournissons de véritables capacités de débogage. Par exemple, le débogage interactif, une traçabilité détaillée, la possibilité de masquer n’importe quel composant pendant le démarrage et plus encore. Nous fournissons aussi la [documentation associée](http://freedesktop.org/wiki/Software/systemd/Debugging/). Il est sans aucun doute parfaitement débogable, nous en avons nous-mêmes besoin pour notre propre développement. Cependant nous reconnaissons une chose : il utilise des outils de débogage différents, dont nous pensons qu'ils sont plus appropriés à l’objectif. # systemd fait des changements pour le plaisir de changer Largement mensonger. Nous avons à peu près uniquement des raisons techniques aux différents changements apportés, et nous les expliquons dans les multiples documentations, pages de wiki, articles de blogues et annonces dans les listes de diffusion. Nous faisons un réel effort pour éviter les changements incompatibles, et si nous y sommes contraints, nous essayons d’en documenter en détail la cause et la modalité. Et s’il vous reste des questions, n’hésitez pas à nous les poser ! # systemd est un projet uniquement dirigé par Red Hat, une propriété privée de quelques développeurs je-sais-tout, qui l’utilisent pour servir leur vision du monde C’est faux. Actuellement (NdT : 2013年01月16日), il y a 16 développeurs avec le droit de commit sur le dépôt git. Dans ces 16 développeurs, seulement 6 sont employés par Red Hat (NdT : le compte a changé depuis). Les 10 autres sont des gens d’ArchLinux, de Debian, de Mageia, d’Intel, de Pantheon et même de Canonical, ainsi qu’un certain nombre de gens de la communauté. Et ils font souvent de grosses modifications et des changements majeurs. Ensuite, il y a aussi les 374 particuliers avec des patchs dans notre dépôt. Ils viennent aussi d’horizons et d’entreprises variés et plusieurs ont bien plus qu’un seul patch dans le dépôt. Les discussions sur le futur de systemd sont faites de façon ouverte sur notre canal IRC (#systemd sur freenode, vous êtes les bienvenus), sur notre liste de discussion et lors de nos hackfests publiques (comme la prochaine qui aura lieu à Brno, où vous êtes cordialement invité). Nous assistons régulièrement à diverses conférences pour avoir des retours, pour expliquer ce que nous faisons et pour quelle raison, à un degré que peu de projets font. Nous gardons à jour les blogs, nous engageons la discussion sur les réseaux sociaux (nous avons du contenu assez intéressant sur Google+, et notre communauté Google+ est relativement vivante aussi), et nous tentons ardemment d’expliquer pourquoi et comment on fait les choses et on écoute les retours, afin de trouver où sont les soucis (par exemple, avec ces retours, nous avons écrit cette liste de mythes courants sur systemd...). La plupart des contributeurs à systemd partagent probablement une idée grossière de ce à quoi un bon système d’exploitation devrait ressembler, ainsi que le désir de la voir se concrétiser. Cependant, par la nature *Open Source* même du projet et son implantation dans la communauté, systemd est simplement ce que les gens veulent qu’il soit et si ça n’est pas ce qu’ils veulent, ils peuvent influencer la direction du projet avec des patchs et du code, et si ça n’est pas possible, il y a alors de nombreuses autres options à épuiser. systemd n’est jamais fermé. Un but de systemd est d’unifier un peu le paysage dispersé de Linux. Nous essayons de nous débarrasser de beaucoup des différences inutiles entre distributions dans différents domaines du cœur de l’OS. Dans ce cadre, nous adoptons parfois une méthode spécifique à une distribution et l’utilisons par défaut pour systemd dans le but de pousser gentiment tout le monde vers le même ensemble de configurations de base. Ce n’est cependant pas une obligation, les distributions peuvent continuer de le faire à leur manière. Cependant, si elles finissent par adopter le standard, leur travail devient plus simple et elles peuvent gagner une fonctionnalité ou deux. Actuellement, la plupart des standards que nous avons adoptés venaient de Debian plutôt que de Fedora/RHEL. Par exemple, les systèmes qui utilisent systemd stockent généralement leur nom d’hôte dans `/etc/hostname`, ce qui était auparavant spécifique à Debian et maintenant utilisé sur plusieurs distributions. Une chose que je vous accorde cependant est que nous pouvons certaines fois avoir l’air de monsieur-je-sais-tout. Nous essayons d’être préparés à chaque fois que nous ouvrons notre bouche, dans le but de soutenir nos affirmations. Cela peut nous faire passer pour des monsieur-je-sais-tout. De façon générale, effectivement, quelques-uns des plus influents contributeurs de systemd travaillent pour Red Hat. Cependant ils sont une minorité et systemd est une communauté saine et ouverte avec différents intérêts, différentes expériences, simplement unifiée par quelques idées grossières de la direction à prendre, une communauté où le code et sa conception comptent, mais certainement pas l’affiliation à une entreprise. # systemd ne gère pas l’utilisation d’un `/usr` séparé du répertoire racine Absurde. Depuis ses débuts systemd gère l’option `--with-rootprefix=` pour son script `configure`, ce qui vous permet de dire à systemd de bien séparer les choses nécessaires au début du démarrage de celles nécessaires plus tard. Toute cette logique est complètement présente et nous la gardons à jour dans le système de compilation de systemd. Bien sûr, nous ne pensons toujours pas qu’amorcer sans `/usr` disponible est une bonne idée, mais nous le prenons parfaitement en charge dans notre système de compilation. Cela ne corrigera pas les problèmes inhérents du procédé que vous rencontrerez partout, mais vous ne pouvez pas accuser de cela systemd, car dans systemd nous le gérons très bien. # systemd ne permet pas de remplacer ses composants Faux, vous pouvez désactiver et remplacer à peu près n’importe quel bout de systemd, à de très rares exceptions près. Et ces exceptions (comme journald) en général vous permettent d’utiliser une alternative côte à côte tout en coopérant avec elle. # L’utilisation de D-Bus dans systemd au lieu de sockets le rend opaque Cette affirmation est déjà contradictoire en elle-même : D-Bus utilise les sockets comme transport. Donc, chaque fois que D-Bus est utilisé pour envoyer quelque chose, une socket est utilisée. D-Bus est pour majeure partie une sérialisation standardisée de message à envoyer à travers ces sockets. Cela le rend plus transparent, car ce format de sérialisation est bien documenté, compris, et il y a de nombreux outils de traçage et des liaisons de langage (*language bindings*). C’est complètement à l’opposé des habituels protocoles maison que les divers démons Unix classiques utilisent pour communiquer localement. --- Hum, ai-je écrit que je voulais briser juste « quelques » mythes ? Peut-être qu’il y en avait plus que quelques-uns... Quoi qu’il en soit, j’espère que j’ai réussi à éliminer certaines idées fausses. Merci de votre temps.

AltStyle によって変換されたページ (->オリジナル) /