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.
C'est peut être plus simple avec systemd qui écoute les évènement udev, plutôt que d'écrire son propre script pour 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 ?
Je crois que l'idée c'est d'avoir une vision globale du système. Savoir pour un service donné s'il est lancé ou pas est simple, mais le faire de manière globale avec des services lancés à la demande (par socket activation, dbus activation ou udev) c'est plus compliqué.
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.
Je ne comprends pas ce que tu veux dire dans ta seconde phrase ? Je pense que l'idée c'est de ne pas mettre une dépendance sur un service appelé par gnome via dbus occasionnellement par exemple.
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 pense qu'il compare rc.sysinit et systemd. Il ne parle pas de l'ensemble des alternatives et de leur intérêt à chacune.
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 ?
J'ai traduit modestement ce qu'il disait, mais c'est peut être une subtilité que j'ai introduit malencontreusement. La vo :
logind will finally deliver on what consolekit was supposed to do: we can now track user sessions and seats, assign permissions to resources on-the-fly etc. This should be the topic of a separate message, as it is too much to get into. Suffice it to say that I'm very happy that we are finally getting these features working as they should.
C'est le « consolekit was supposed to do » qui m'a fait penser qu'il ne faisait pas ce qu'il était censé faire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi passer à systemd ?
Posté par barmic . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 2.
C'est peut être plus simple avec systemd qui écoute les évènement udev, plutôt que d'écrire son propre script pour udev ?
Je crois que l'idée c'est d'avoir une vision globale du système. Savoir pour un service donné s'il est lancé ou pas est simple, mais le faire de manière globale avec des services lancés à la demande (par socket activation, dbus activation ou udev) c'est plus compliqué.
Je ne comprends pas ce que tu veux dire dans ta seconde phrase ? Je pense que l'idée c'est de ne pas mettre une dépendance sur un service appelé par gnome via dbus occasionnellement par exemple.
Je pense qu'il compare rc.sysinit et systemd. Il ne parle pas de l'ensemble des alternatives et de leur intérêt à chacune.
J'ai traduit modestement ce qu'il disait, mais c'est peut être une subtilité que j'ai introduit malencontreusement. La vo :
C'est le « consolekit was supposed to do » qui m'a fait penser qu'il ne faisait pas ce qu'il était censé faire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)