bizarre cet article,

apparemment les sysadmins aiment systemd, ce qui en partant est très discutable, une coalition de sysadmins ayant été jusqu'à forker debian en devuan tellement systemd leur rendait la vie impossible mais passons, et ce pour des raisons qui semblent se résumer à systemd propose des fonctionnalités qu'on pouvait déjà avoir avant mais là il faut réapprendre une nouvelle syntaxe au lieu d'utiliser les outils du quotidien.

1. Boot management, Booting a Linux computer can be a surprisingly rare event, if you want it to be.
   sauf que mettre à jour systemd implique de devoir rebooter la bécane, et rebooter après une mise à jour de systemd et ben parfois ça ne marche juste pas parce que systemd.
   par exemple: https://www.svennd.be/systemd-doesnt-want-to-reboot/ ou https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776171 ou https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808151

Et des fois au reboot le système passe en mode panique parce que la mise à jour de systemd a changé un truc fondamental et basique et refuse maintenant de booter tant que le disque externe déclaré dans le fstab n'est pas branché, heureusement il y a un shell de secours qui permets de faire ça, mais bon pas de chance c'est systemd qui le gère et il y a un bug qui empèche ce shell de secours de démarrer, et vous voila obligé de faire 400km pour aller au datacenter pour pouvoir redémarrer votre serveur. Ce jour, ce sysadmin là était loin de proférer son amour pour lennart poettering et systemd

1. Log reviews

grace à journald (ce n'est déjà plus systemd mais un des multiples composants optionnels obligatoires qui vont avec) on peut enfin faire exactement ce qu'on faisait avant mais maintenant avec une nouvelle syntaxe, des informations pertinentes qui ne sont plus dans les logs, un format de logs binaire compatible avec rien qui aime se corrompu pile quand c'est le plus inopportun et qui introduit de nouvelles limitations qui forcent le sysadmin à faire tourner un second moteur de log en parallèle pour retrouver la possibilité de logger par le réseau.

par exemple: https://news.ycombinator.com/item?id=26645749 ou https://centosfaq.org/centos/systemd-journald-corruption/ ou https://bugzilla.redhat.com/show_bug.cgi?id=1508984 ou https://texts.xexyl.net/docs/purge-systemd-journald.html ou https://bbs.archlinux.org/viewtopic.php?pid=1235392#p1235392

1. Service management

Si il y a du vrai que systemd apporte une gestion des services qui simplifie la vie du sysadmin, ça vient aussi avec des bugs qui sont des fonctionnalités non documentés qui sont triviales à corriger mais au bout de 5 ans sont toujours ignorées et amènent le bug report a être verrouillé parce que les mécontents parlent trop fort, comme avec ce bug ou systemd va silencieusement annuler une commande mount qui a réussi juste parce que systemd et laisser le sysadmin sans aucun retour ni trace dans les logs passer des heures avant de trouver une solution, voir : https://github.com/systemd/systemd/issues/1741

1. Timers

Là rien à ajouter, l'article précise bien que systemd ne fait que réimplémenter cron sans que ce ne soit nécéssaire. Il ne donne aucune explication à pourquoi les syadmins aimeraient systemd à cause de ça.

1. Targets

Avant on avait les init level, maintenant on a les systemd targets. même chose mais réimplémentées par systemd, voir point 4.

Conclusion, article qui fait plus penser à du publi-marketing. Et on pouvait voir venir l'arnaque quand dès l intro, l'auteur réécrit l'histoire pour faire oublier que systemd devait à la base etre un system d'init pour permettre à redhat de s'omposer dans le domaine des systèmes embarqués et qu'il est devenu un monstre qui a tout absorbé, remplacé, couplé, réimplémenté en introduisant moults bugs, failles de sécurité, problème de vie privée et bien plus. Au point de pousser certains sysadmin a migrer vers BSD: https://orville.thebennettproject.com/articles/how-i-learned-to-stop-worrying-about-systemd/

voir aussi: https://blog.darknedgy.net/technology/2020/05/02/0/
— Permalink