Et en effet, je suis d'accord avec Flanker, ayant déjà écrit à la fois des scripts d'init sysvinit /etc/init.d et des services systemd à titre professionnel, c'est beaucoup plus simple d'écrire des services systemd. Même s'il faut se plonger un peu dans la documentation, qui ne m'avait pas semblé mal faite, et pourquoi pas regarder d'autres services du système comme exemple, avec systemd, il y a beaucoup moins de boilerplate à copier à droite à gauche en espérant ne pas en oublier, et bien sûr, l'élimination de diverses non-portabilités intrinsèques dans les scripts sysvinit eux-mêmes (par exemple, que je sache, start-stop-daemon est une spécificité des Debian et dérivées), qui était du reste un des buts de systemd. Un service systemd simple pour déclarer un daemon tout bête, ou un cronjob simple, fait facilement moins de 10 lignes; des choses un peu plus complexes (commandes spéciales pour l'arrêt ou le redémarrage) font quelques lignes de plus. Bonne chance pour faire des scripts sysvinit "portables" (hors utilisation de chemins de conf différents selon les distros, mais systemd a également gommé des différences de ce type) équivalents en quelques lignes.
L'homogénéisation entre distros, ou des features plus avancées comme les profils seccomp (comme dans les conteneurs, à juste titre pour des raisons de sécurité) ou les capabilities, en mode déclaratif plutôt que programmatique, sont de gros plus.
Ca ne veut pas dire que tout est parfait avec systemd. Il y a des désagréments comme l'indiquent Folco et robinHood, même s'ils se contournent. Le log du journal systemd a une taille limitée, souvent réglée bas par défaut. La plupart des daemons gèrent une sortie logs autre que le journal, ce qui peut limiter les problèmes.
Aussi, plusieurs vulnérabilités historiques des composants de systemd sont embarrassantes. A l'époque où l'écriture de systemd a commencé, Rust n'était pas un choix possible; maintenant, ces composants critiques du système devraient être écrits dans un langage beaucoup plus sûr que C...
Quelles infrastructures utilises-tu pour gérer le réseau, Zeph ? NetworkManager et firewalld sont des usines à gaz exposant des services DBus et plein d'autres choses, je ne les utilise donc que si elles s'avèrent plus simples à mettre en service que la façon classique de gérer le réseau. /etc/resolv.conf et /etc/network/interfaces(.d) sur Debian/Ubuntu ou /etc/sysconfig/... sur CentOS, et règles iptables même s'il faut rentrer dedans au début, font ce que je veux pour des dizaines de machines headless ou installées sur des réseaux à assignation statique. Sur les desktops/laptops avec Desktop Environment que je n'administre pas finement, en général, je laisse NetworkManager et ses GUIs; sur ceux que j'administre finement, dont mes machines perso et pro directes, il est très rare que j'utilise NetworkManager. Le Wifi est clairement beaucoup plus facile à utiliser avec les GUIs qui commandent NetworkManager que les CLI iwconfig, iw et autres, mais en moyenne, je n'utilise même pas une fois par an du Wifi. Ce n'est, j'en conviens, pas le cas de la plupart des utilisateurs
Si je bascule un des laptops où le réseau est géré à la main entre un réseau avec assignation statique et un réseau DHCP, un coup de dhclient et c'est réglé.
Au fait: dans la GR sur les init systems, les DDs viennent de voter pour "B: Systemd but we support exploring alternatives", qui a légèrement devancé "F: Focus on systemd", et plus nettement tous les autres choix. https://lwn.net/Articles/808217/ . C'est une bonne chose pour l'avancement du projet.