Nos ordinateurs prennent chaque jour une place de plus en plus importante dans nos vies ; le moindre problème peut affecter notre humeur, voire notre bonne humeur ! Bien sûr, les utilisateurs de Windows sont plus sujets à la panique : virus ( vive Linux ! ), défragmentation du disque dur, recherche et installation de Clean Master pour PC ( même si, sous Linux, il faut aussi nettoyer le système ; BleachBit est une alternative appréciée ). Récemment, certains utilisateurs Linux ont rencontré un problème particulier : systemd.
Bref, pour en venir au fait, j'ai lu un article intéressant sur systemd , qui semble être très en vogue ces temps-ci.
Systemd , que certains considèrent ( pour reprendre les mots d'un ami ) comme « la solution miracle », laisse d'autres indifférents : du moment que l'ordinateur fonctionne correctement, peu leur importe que ce soit init qui fasse telle ou telle chose, ou que systemd soit utilisé. Quant à moi… disons simplement que je préfère init ; je le trouve plus simple.
Je laisse l'article ici:
Avant de commencer, je tiens à préciser que je désapprouve fortement la décision de modifier certaines choses dans Debian, mais je n'ai aucune intention d'abandonner ma chère distribution. Je souhaite simplement m'assurer que, si nous abordons un sujet, nous le fassions aussi bien préparés que possible, même si je ne me considère pas comme un partisan de systemd. Pour démystifier systemd, je m'appuierai sur un site web où les développeurs partagent leurs points de vue , que j'ai découvert grâce à un collègue qui semble, lui, être favorable à systemd, bien qu'il n'utilise pas Debian. Ceci étant dit, je pense pouvoir tenter d'éclaircir les points de vue exprimés sur systemd.
systemd est basé sur binaire
C'est peut-être l'un des aspects qui nous choquent le plus, si tout est basé sur le binaire, comment surveillons-nous les choses que nous faisons habituellement à travers les journaux? Je ne sais pas comment ce mythe est né, mais ce n'est pas absolument vrai.
systemd est configuré presque exclusivement via des fichiers de texte brut. Certains paramètres peuvent également être modifiés avec la ligne de commande du noyau et via des variables d'environnement. Il n'y a rien de binaire dans votre configuration (pas même XML). Juste un fichier texte simple, direct et facile à lire.
Cette chose est monolithique et contrôle tout
Avant d'accéder au site susmentionné, j'avoue avoir pensé ainsi moi-même, mais après avoir lu ce que disent ses développeurs, mon avis a changé quelque chose ...
Si vous compilez systemd avec toutes les options de configuration activées, vous obtiendrez 69 binaires distincts . Ces binaires remplissent différentes fonctions et sont soigneusement séparés pour plusieurs raisons. Par exemple, systemd a été conçu en mettant l'accent sur la sécurité ; par conséquent, la plupart des démons s'exécutent avec des privilèges minimaux (en utilisant les capacités du noyau, par exemple) et ne sont responsables que de tâches très spécifiques, minimisant ainsi leur surface d'attaque et leur impact. De plus, systemd parallélise le démarrage plus que toute solution précédente. Cette parallélisation est obtenue en exécutant plusieurs processus en parallèle. Ainsi, il est clair que systemd est très bien divisé en de nombreux binaires et, par conséquent, en processus. En fait, nombre de ces binaires sont si bien séparés qu'ils sont très utiles en dehors de systemd.
Un paquet contenant 69 fichiers binaires individuels ne saurait être qualifié de monolithique. Ce qui le distingue des solutions précédentes, c'est que nous distribuons davantage de composants dans une seule archive tar et les maintenons regroupés dans un dépôt unique, avec un cycle de publication unifié.
Cela ne ressemble pas à Unix
Il y a certainement du vrai à cela. Les fichiers source systemd ne contiennent pas une seule ligne de code à partir des lignes UNIX d'origine. Cependant, l'inspiration est dérivée d'UNIX, et donc il y a beaucoup d'UNIX dans systemd. Un exemple serait l'idée UNIX "tout est un fichier" qui se reflète dans le fait que dans systemd tous les services sont exposés à l'exécution dans un système de fichiers du noyau, le cgroupfs. L'une des fonctionnalités d'origine d'UNIX était donc la prise en charge multi-postes, basée sur la prise en charge intégrée des terminaux. Avec systemd, nous avons à nouveau apporté le support multi-siège de manière native, mais cette fois avec un support complet pour le matériel d'aujourd'hui, couvrant les graphiques, les souris, l'audio, les webcams, etc. En fait, la conception de systemd comme une suite d'outils intégrés qui ont chacun leurs propres objectifs, mais lorsqu'ils sont utilisés ensemble, sont plus que la somme des parties, ce qui est plus ou moins au cœur de la philosophie UNIX. Ainsi, la façon dont notre projet est géré (c'est-à-dire conserver la plupart du noyau du système d'exploitation dans un seul référentiel git) est beaucoup plus proche du modèle BSD (qui est un véritable UNIX, par opposition à Linux) pour faire avancer les choses (où la plupart des le système d'exploitation principal est conservé dans un référentiel CVS / SVN unique), ce qui n'a jamais été le cas sous Linux.
En fin de compte, la question de savoir si quelque chose est UNIX ou non importe très peu. Étant techniquement excellent, il n'est guère unique à UNIX. Pour nous, UNIX est une influence importante (en fait, la plus grande), mais nous avons aussi d'autres influences. Par conséquent, dans certains domaines, systemd sera très UNIX, et dans d'autres un peu moins.
C'est très complexe ...
Il y a certainement du vrai à cela. Les ordinateurs modernes sont des bêtes complexes et le système d'exploitation qui les utilise le sera évidemment aussi, ils doivent donc être complexes. Cependant, systemd n'est certainement pas plus complexe que les implémentations précédentes des mêmes composants. C'est plus simple et moins redondant. D'un autre côté, la construction d'un système d'exploitation basé sur systemd simple impliquera beaucoup moins de packages que les utilisations traditionnelles de Linux. Moins de packages facilite la construction de votre système, élimine les interdépendances et la plupart des comportements différents de tous les composants impliqués.
Cela ne me permettra pas d'utiliser des scripts shell
C'est totalement faux. Nous ne les utilisons tout simplement pas pour le processus de démarrage car nous estimons qu'ils ne sont pas les plus adaptés à cet usage précis, mais cela ne signifie pas que systemd leur est incompatible. Vous pouvez facilement exécuter des scripts shell en tant que services ou démons systemd ; vous pouvez exécuter des scripts écrits dans n'importe quel langage en tant que services systemd, car systemd se fiche complètement du contenu de votre exécutable. De plus, nous utilisons abondamment des scripts shell pour nos propres besoins : installation, compilation et test de systemd. Vous pouvez intégrer ces scripts au processus de démarrage initial, les utiliser pour des services classiques, les exécuter lors de l'arrêt final — les possibilités sont pratiquement illimitées.
À ce stade, je pense que certains points essentiels ont été clarifiés. Bien que je ne me considère pas comme un partisan du changement et que j'aie des réserves quant à l' idée d' un système unique pour gouverner tous les systèmes , je crois qu'en fin de compte, personne n'osera affirmer qu'il ne fonctionne pas du tout. Je connais même des utilisateurs qui constatent qu'avec systemd, « l'ordinateur est plus rapide », mais c'est un autre sujet. Pour l'instant, je vous invite simplement à débattre de vos points de vue ici sur le système d'initialisation adopté par de nombreuses distributions, même si les réactions les plus vives se manifestent actuellement au sein de la communauté Debian, qui a même créé une nouvelle branche à ce sujet. Que cela vous plaise ou non est une affaire personnelle ; pour ma part, je souhaite simplement contribuer à démystifier systemd, qui sera finalement présent dans Jessie, la prochaine version stable de Debian.
J'ai vu l'article sur GUTL (qui lui-même était tiré de DesdeAbreus ).
Courant Systemd?
Je fais partie de ceux qui ne lisent pas beaucoup d'actualités quand quelque chose suscite autant de polémiques, je préfère rester avec des détails plus techniques. Le truc, c'est…. Parfois, j'ai l'impression que certains sujets cessent d'être une discussion ou un débat purement technique et deviennent comme de ces potins du showbiz
Tout d'abord, un coup de gueule ouvert d'un utilisateur contre systemd intitulé systemd VS intelligence , puis Linus Torvalds affirmant que systemd n'est pas aussi mauvais qu'on le prétend ( et il n'a pas tort ), un fork appelé uselessd ... pas de commentaires... et pour faire court, enfin Devuan.
Je ne dirai pas si c'est aussi mauvais qu'on le prétend, moins mauvais ou pire. Le système me convient, mais personnellement, je préfère init, car j'aime sa façon d'organiser les choses (comme les journaux, par exemple). Mais bon, si systemd est appelé à devenir un cheval de trait et doit remplacer init ( deviendrait-il notre bête de somme, capable de tout faire, mais lentement ? ), eh bien… tant que le changement n'est pas trop radical, que les utilisateurs peuvent s'y adapter sans trop de difficultés et que le système fonctionne mieux (oui, mieux, mais ce ne sera peut-être pas suffisant pour moi !), alors bienvenue ! 😉