J'ai rien contre systemd ou Lennart (je suis sous FreeBSD) mais l'article que tu donnes en référence a quelques traits franchement ridicules. Par exemple il y est écrit:
As the tables above hopefully show in all clarity systemd has left behind both sysvinit and Upstart in almost every aspect. With the exception of the project's age/maturity systemd wins in every category.
Sympa la victoire à plate couture auto-proclamée ... Mais jetons donc un œil à ces catégories. Vers le début:
Première information: shell-free bootup est un aspect positif. Deuxième information: c'est tellement positif que je le compte deux fois: vu que les deux autres utilisent le shell pour la procédure d'amorçage, c'est clair qu'on ne peut pas y coller des modules en C.
De plus en y regardant de plus près, le deuxième point est plutôt mauvais pour systemd, puisque les fonctions sont rendues par des modules, qui peuvent être écrits dans n'importe quel langage puisque le SHELL est utilisé pour coordonner l'éxécution de ces programmes.
Et maintenant
Qu-est-ce que c'est que ces no? À la fin de la procédure d'amorçage à la systemv les systèmes de fichiers ne sont pas montés peut-être? À moins qu'il veuille dire que le démon puisse s'occuper de monter et démonter les disques à la demande de l'utilisateur? C'est bien mais il y a déjà les commade mount et umount pour ça, non?
Il y a beacuoup de features saugrenues et son as the tables above hopefully show in all clarity est loin de me convaincre: elle ressemble plutôt à une tentative piteuse de rationnaliser une préférence personnelle.
Pourtant son initial announcement de systemd est plus persuasif mais son systemd a quand-même un gros côté fourre-tout: en gros tout ce qui est susceptible de démarrer un programme se retrouve dans systemd: ainsi les dæmons classiques inetd se retrouve dupliqué par le module socket, etc. L'intérêt de ces modules n'est pas motivé, vu que systemd est présenté comme un outil d'amorce qui permet de booter la machine plus rapidement, il me semble qu'il fallait plutôt modifier un peu inetd' pour qu'il signale les services qu'il lance àsystemd` (d'ailleurs cela ferait moins de roues réinventées).
Si j'ai bien compris sa présentation les deux aspects intéressants de systemd sont:
Comme de plus en plus de démons utilisent dbus pour se synchroniser au démarrage et bien on a intérêt à démarrer dbus le plus rapidement possible: OK, ce n'était certainement pas la peine de réecrire toute la séquence d'amorçage pour faire ça.
Every executed process gets its own cgroup
Cela devrait permettre d'améliorer la gestion des services sur la machine. C'est bien.
Et le reste des features c'est franchement du remplissage et de la duplication de fonctions existant déjà.
[^] # Re: Même si le liens est dispo en fin de l'article pointé...
Posté par jean . En réponse au journal systemd est un "bloat". Évalué à 8.
J'ai rien contre systemd ou Lennart (je suis sous FreeBSD) mais l'article que tu donnes en référence a quelques traits franchement ridicules. Par exemple il y est écrit:
Sympa la victoire à plate couture auto-proclamée ... Mais jetons donc un œil à ces catégories. Vers le début:
Première information: shell-free bootup est un aspect positif. Deuxième information: c'est tellement positif que je le compte deux fois: vu que les deux autres utilisent le shell pour la procédure d'amorçage, c'est clair qu'on ne peut pas y coller des modules en C.
De plus en y regardant de plus près, le deuxième point est plutôt mauvais pour systemd, puisque les fonctions sont rendues par des modules, qui peuvent être écrits dans n'importe quel langage puisque le SHELL est utilisé pour coordonner l'éxécution de ces programmes.
Et maintenant
Qu-est-ce que c'est que ces
no? À la fin de la procédure d'amorçage à la systemv les systèmes de fichiers ne sont pas montés peut-être? À moins qu'il veuille dire que le démon puisse s'occuper de monter et démonter les disques à la demande de l'utilisateur? C'est bien mais il y a déjà les commademountetumountpour ça, non?Il y a beacuoup de features saugrenues et son as the tables above hopefully show in all clarity est loin de me convaincre: elle ressemble plutôt à une tentative piteuse de rationnaliser une préférence personnelle.
Pourtant son initial announcement de systemd est plus persuasif mais son
systemda quand-même un gros côté fourre-tout: en gros tout ce qui est susceptible de démarrer un programme se retrouve danssystemd: ainsi les dæmons classiquesinetdse retrouve dupliqué par le modulesocket, etc. L'intérêt de ces modules n'est pas motivé, vu quesystemdest présenté comme un outil d'amorce qui permet de booter la machine plus rapidement, il me semble qu'il fallait plutôt modifier un peuinetd' pour qu'il signale les services qu'il lance àsystemd` (d'ailleurs cela ferait moins de roues réinventées).Si j'ai bien compris sa présentation les deux aspects intéressants de
systemdsont:Comme de plus en plus de démons utilisent dbus pour se synchroniser au démarrage et bien on a intérêt à démarrer dbus le plus rapidement possible: OK, ce n'était certainement pas la peine de réecrire toute la séquence d'amorçage pour faire ça.
Every executed process gets its own cgroup
Cela devrait permettre d'améliorer la gestion des services sur la machine. C'est bien.
Et le reste des features c'est franchement du remplissage et de la duplication de fonctions existant déjà.