il supporte des configurations mouvante (hot plug) : on branche un disque, il lance fsck et le monte proprement
Ça peut déjà être fait avec udev.
on peut connaître l'état du système : systemd connaît l'état de tout les deamons
On peut également savoir quels sont les services actifs sur les init standard. Que le PID1 le sache apporte quoi au juste ? Une manière différente d’interroger ?
c'est modulaire : on peut remplacer des parties par nos propres scripts (et ces parties sont bien documentées), il dit que c'est plus compliqué avec rc.sysinit car les dépendances sont moins claires
Ok. C’est un problème spécifique à Arch.
on peut plus facilement lancer un service à la demande notamment avec udev
On peut le faire aussi, il suffit d’avoir udev.
les sockets activation et dbus activation permettent de simplifier les dépendances
Ok. Je suis d’accord avec ça. Même s’il faut faire confiance à l’outil plutôt que de connaître parfaitement son produit.
on gagne en sécurité via les cgroup
Mouai, c’est déjà possible aussi.
on peut capitaliser les fichiers de descriptions de services (fini les scripts spécifiques à chaque distribution)
C’est vrai, l’uniformisation du system permet d’uniformiser les configs… mais si c’était un argument, il n’y aurait pas 300 distribution GNU/Linux. Quitte à uniformiser, je préfère openrc. En même temps, je suis gentooiste.
c'est plus simple pour eux d'être plus proche de l'upstream
Je ne vois pas en quoi tu es plus proche de l’upstream. Cela veut dire que c’est les développeurs qui vont faire les fichiers de config de systemd ? Ça rejoint l’argument de l’uniformisation.
logind fait le boulot que consolekit devrait faire (suivre les sessions utilisateurs, donner des droits, etc)
À bon. Consolekit ne répond pas aux exigences. Quand je lis devrait je comprends que consolekit ne répond pas au besoin de cette personne d’Arch, mais en quoi c’est-il ce que consolekit _devrait faire_ ? Les dév de consolekit doivent le savoir également, et donc faire la correction, non ?
il est rapide ou pas, mais il s'en fout
La rapidité n’est pas un argument, on est d’accord.
J’avoue que je n’avais lu que les 3 premières raisons. La seule bonne raison, à mes yeux, c’est l’uniformisation. Hélas, j’aurais préféré un truc du genre freedesktop, qui définisse une norme, plutôt que systemd.
Bientôt, ce sera Lennart/Linux qu’il faudra écrire ;-). Je ne suis toujours pas convaincu par les arguments, même si je comprends que beaucoup le soit. La suite sera intéressante.
[^] # Re: Pourquoi passer à systemd ?
Posté par Anthony Jaguenaud . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 5.
Oui, c’est intéressant :
Ça peut déjà être fait avec udev.
On peut également savoir quels sont les services actifs sur les init standard. Que le PID1 le sache apporte quoi au juste ? Une manière différente d’interroger ?
Ok. C’est un problème spécifique à Arch.
On peut le faire aussi, il suffit d’avoir udev.
Ok. Je suis d’accord avec ça. Même s’il faut faire confiance à l’outil plutôt que de connaître parfaitement son produit.
Mouai, c’est déjà possible aussi.
C’est vrai, l’uniformisation du system permet d’uniformiser les configs… mais si c’était un argument, il n’y aurait pas 300 distribution GNU/Linux. Quitte à uniformiser, je préfère openrc. En même temps, je suis gentooiste.
Je ne vois pas en quoi tu es plus proche de l’upstream. Cela veut dire que c’est les développeurs qui vont faire les fichiers de config de systemd ? Ça rejoint l’argument de l’uniformisation.
À bon. Consolekit ne répond pas aux exigences. Quand je lis devrait je comprends que consolekit ne répond pas au besoin de cette personne d’Arch, mais en quoi c’est-il ce que consolekit _devrait faire_ ? Les dév de consolekit doivent le savoir également, et donc faire la correction, non ?
La rapidité n’est pas un argument, on est d’accord.
J’avoue que je n’avais lu que les 3 premières raisons. La seule bonne raison, à mes yeux, c’est l’uniformisation. Hélas, j’aurais préféré un truc du genre freedesktop, qui définisse une norme, plutôt que systemd.
Bientôt, ce sera Lennart/Linux qu’il faudra écrire ;-). Je ne suis toujours pas convaincu par les arguments, même si je comprends que beaucoup le soit. La suite sera intéressante.