Pourquoi je m'en tiens à des distros Linux basés sur Systemd

Plus de 10 ans depuis son introduction, SystemD peut toujours faire en sorte que certains utilisateurs de Linux fassent un ÉNORME. Il se trouve que je n'en fais pas partie. Même si j'essaye des distributions sans systemd, j'utiliserai probablement régulièrement régulièrement les distros basés sur Systemd. Voici quelques-unes des raisons.

Sysvinit a dû y aller

Lorsque SystemD est apparu pour la première fois au début des années 2010, de nombreux utilisateurs de Linux se sont demandé pourquoi une telle refonte du système d'initial que Linux avait utilisé était nécessaire.

L'ancien système, système V init ou sysvinit, a eu ses racines dans les années 1980. De retour dans les années 80, les systèmes UNIX ont été utilisés d'une manière différente des machines modernes. Unix était principalement utilisé sur les grands mini-ordinateurs et les postes de travail puissants. Sysvinit lance les services séquentiellement, ce qui peut augmenter les temps de démarrage. Les ordinateurs portables étaient rares à cette époque. L'USB n'existait pas et les périphériques n'ont généralement pas été ajoutés et retirés entre les bottes. La configuration du système n'a généralement pas changé tout au long de son runtime. Une fois le système en place, il est généralement resté debout pendant longtemps, donc les temps de démarrage n'étaient pas un problème. Les changements matériels sur les systèmes partagés se sont rarement produits et étaient également davantage une expérience «unique».

Traditionnellement, si vous ajoutez un matériel, même quelque chose comme un lecteur de disque externe, vous devrez arrêter et redémarrer le système. Sysvinit a également été alambiqué, avec des scripts de coquille correspondant aux « couleurs ». Cette approche était inadéquate alors que Linux était de plus en plus répandu. Avec les machines modernes, vous pouvez brancher un lecteur USB ou vous déplacer entre les réseaux Wi-Fi et Wired avec un ordinateur portable. SystemD peut répondre instantanément à un tel matériel « hotplugged ».

Cela témoigne de la force de l'idée de systèmes d'exploitation de type Unix que les principaux composants peuvent être remplacés au besoin.

Systemd est là pour rester

Alors que Systemd émergeait pour la première fois, il y avait plus de débat et de concurrence quant à ce qui le remplacerait. Le débat a été tellement chauffé que certains développeurs de distribution Linux ont démissionné de la contrainte du flux constant d'invective des utilisateurs de Linux.

Pour le meilleur ou pour le pire, l'utilisation d'une distribution Linux traditionnelle signifie l'utilisation de SystemD. La documentation le mentionnera, et si vous optez pour votre soutien, si vous rencontrez un problème, il impliquera probablement d'utiliser l'utilitaire SystemCTL.

Parce que SystemD fait partie intégrante de la façon dont les distributions Linux modernes se déroulent, la plupart des distributions principales sont peu susceptibles de la remplacer à moins qu'elles aient une bonne raison.

Ce ne serait pas un scénario farfelue. Si vous utilisiez Linux dans les années 2000, vous avez peut-être pensé que le système sysvinit durerait éternellement. Si vous ne l'aimiez pas, vous pouvez utiliser l'un des BSDS.

Peut-être que quelqu'un créera un système d'initial différent, celui que les développeurs de Linux pensent mieux. Mon argent serait sur tout ce que les développeurs BSD préparent pour remplacer leur propre système d'initial vieillissant. J'imagine que cela finirait par quelque chose comme le lancement de MacOS, qui a également influencé Systemd.

Pour de nombreux développeurs de distribution Linux, SystemD semble être au moins une option « assez bonne ». Dans de nombreuses formes d'ingénierie, y compris l'ingénierie logicielle, vous devez faire des compromis lors de la conception de choses pour le monde réel au lieu d'essayer de créer la meilleure solution absolue.

Systemd fonctionne pour moi

L'une des raisons pour lesquelles j'ai tendance à rester avec les distros basés sur Systemd est que je n'ai jamais eu de problème avec SystemD. La réponse « Fonctionne pour moi » peut être irritante en réponse à des problèmes avec Linux, mais je n'ai aucune plainte dans ma propre utilisation.

Je préfère Systemd à l'ancienne méthode. Je n'ai jamais été entièrement à l'aise avec Sysvinit, avec son besoin de gérer les scripts et les niveaux coulants. J'ai grincé des dents chaque fois que je voyais de la documentation sur l'activation et la désactivation des services, même si c'était quelque chose que j'ai rarement fait sur les systèmes de bureau, car la plupart d'entre eux ont été mis en place avec ce dont ils avaient besoin pour exécuter immédiatement.

Lorsque j'ai besoin d'activer, de désactiver, de démarrer ou d'arrêter les services, je exécute simplement une commande rapide SystemCTL. C'est tout ce qu'il faut.

En tant qu'utilisateur qui démarre et arrête les services, malgré les services, malgré le ballonnement supposé de Systemd, je trouve que la commande SystemCTL est facile à comprendre.

J'ai récemment installé Arch dans une machine virtuelle. J'ai dû activer certains services, car Arch est plus pratique que d'autres distros Linux. Il suffit de quelques commandes SystemCTL.

Si Systemd est assez bon pour Arch Linux …

Une chose qui m'a finalement informé en faveur de Systemd, c'est qu'Arch Linux l'avait tourné. Arch a déjà la réputation d'être destiné aux utilisateurs sophistiqués de Linux en les mettant davantage au contrôle de la configuration de leur système. Vous pouvez choisir l'outil de partitionnement et le chargeur de démarrage, ainsi que l'environnement de bureau, ou même pour installer un environnement de bureau.

Lorsque j'ai trouvé un ancien article de forum de l'un des développeurs de 2012, lié à partir de l'arc Wiki, j'ai étudié le cas que le développeur a présenté. Le développeur a cité la possibilité de savoir tout ce qui se passait avec le système, la capacité de détecter les appareils hotpluggés, les fonctionnalités de modularité, de sécurité et de sable de Systemd, ainsi que le développement multiplateforme du projet Systemd.

Selon l'Arch Wiki, l'une des lumières directrices de la distribution est le « pragmatisme »:

L'arc est une distribution pragmatique plutôt que idéologique. Les principes ici ne sont que des directives utiles. En fin de compte, les décisions de conception sont prises au cas par cas par le biais d'un consensus du développeur. L'analyse technique et le débat fondés sur des preuves sont ce qui compte, pas la politique ou l'opinion populaire.

Arch Linux m'a toujours paru en tant que distribution Linux « Unixy » avec sa mise en scène sur la configuration basée sur le texte et la quantité de contrôle qu'il donne aux utilisateurs. Si les développeurs Arch pouvaient voir les mérites de Systemd malgré son supposé «ballonnement», je pensais que Systemd valait un look sérieux. Toute appréhension persistante envers Systemd a disparu. Cela peut sembler un argument de l'autorité, mais l'équipe de développement de l'Arch a gagné ma confiance grâce à ses résultats.

La gestion des processus est une petite partie de mon utilisation Linux

Le système Init peut être une partie importante de Linux, mais pour moi, c'est surtout dans les coulisses. J'interagis rarement avec lui directement à l'extérieur de la commande SystemCTL.

Bien qu'il puisse se faire du lancement de programmes tout au long de la journée et que leur fermeture puisse être considérée comme une gestion des processus, la plupart du temps, je pense que je peux compter le nombre de fois où j'ai interagi directement avec SystemD pour gérer les processus via SystemCTL d'une part. Sur une distribution de bureau, ce serait probablement une ou deux fois.

Je vérifie les journaux de temps en temps, comme tout utilisateur le devrait. Les journaux binaires de SystemD ont également été controversés, mais la commande JournalCTL est facile à utiliser. Beaucoup de journaux sur Ubuntu semblent être reflétés dans le répertoire / var / log, donc je peux les examiner avec un éditeur de texte régulier.

Les distros sans système ne m'impressionnent pas beaucoup

Le fait que Systemd soit en arrière-plan est l'une des raisons pour lesquelles les distros qui se favorisent comme étant sans système ne m'impressionnent pas beaucoup. J'en ai exploré quelques-uns récemment, comme EXE GNU / Linux et Obarun. Les distributeurs des distances sont libres de mettre ou de ne pas mettre dans leurs distrons quoi qu'ils veuillent.

Lorsque j'évalue les distros de HTG, j'essaie de prendre la position d'un utilisateur ordinaire, pas d'un hacker Linux qui a des opinions fortes pour ou contre Systemd. L'expérience utilisateur est plus importante que ce qui est sous le capot.

Une distribution devra se lever ou tomber en fonction de tout ce qu'il a. Certaines distros offrent une expérience unique, telle que les conceptions rétro de rétro de EXE GNU / Linux.

Parfois, le changement est bon

Bien que le système d'origine VI dans le système v init a bien fonctionné pendant de nombreuses années, les changements dans le monde de l'ordinateur l'ont finalement rendu obsolète dans un monde de plus en plus mobile et en ligne.

Il pourrait y avoir des préoccupations concernant la taille de Systemd ou la prétendue domination du développement Linux par Red Hat et sa société mère, IBM.

---

Le monde change, les changements de matériel informatique et les logiciels du système d'exploitation modifient avec lui. Les systèmes d'exploitation doivent servir les utilisateurs et gérer leurs programmes. Ils doivent évoluer avec ce que leurs utilisateurs font avec eux. Ils ne peuvent pas être des pièces de musée.