Il est pourtant bien écrit là qu'un init qui monte rapidement un système est un bon init, et pas que c'est un objectif de systemd.
Il est ensuite indiqué ce qu'il faut selon l'auteur pour obtenir un bon init (en 2010+).
Il est précisé ensuite la pensée de l'auteur par ce qu'il entend par "fast", et c'est répété partout : tout est lancé en parallèle en fonction des événements, et surtout pas de manière sérialisée.
On ne parle pas de booter en quelques secondes de moins là, on parle de maximiser le CPU et les IO disponibles, comme précisé ensuite, et pas seulement au boot, mais pendant toute la durée où l'espace utilisateur et monté.
L'auteur parle également de la gestion de l'aspect dynamique du noyau, qui doit être géré par l'init. Il y a beaucoup de choses dans ce blog en fait.
Ceci afin de ne pas se retrouver avec des boucles d'attente sur des montages de disques ou carrément des boots crashés comme j'ai vu si souvent avec sysvinit.
Les arguments dans ce post décrivent la réflexion qui a conduit à systemd, pas les objectifs de systemd. Et la rapidité intrinsèque aux choix effectués montrent selon l'auteur que c'est un bon init s'il suit sa définition d'un bon init.
Il me semble qu'il y a un autre blog de l'auteur qui explique les objectifs de systemd (l'ensemble de logiciels, pas juste l'init).
[^] # Re: Merci
Posté par ookaze . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à -4.
Il est pourtant bien écrit là qu'un init qui monte rapidement un système est un bon init, et pas que c'est un objectif de systemd.
Il est ensuite indiqué ce qu'il faut selon l'auteur pour obtenir un bon init (en 2010+).
Il est précisé ensuite la pensée de l'auteur par ce qu'il entend par "fast", et c'est répété partout : tout est lancé en parallèle en fonction des événements, et surtout pas de manière sérialisée.
On ne parle pas de booter en quelques secondes de moins là, on parle de maximiser le CPU et les IO disponibles, comme précisé ensuite, et pas seulement au boot, mais pendant toute la durée où l'espace utilisateur et monté.
L'auteur parle également de la gestion de l'aspect dynamique du noyau, qui doit être géré par l'init. Il y a beaucoup de choses dans ce blog en fait.
Ceci afin de ne pas se retrouver avec des boucles d'attente sur des montages de disques ou carrément des boots crashés comme j'ai vu si souvent avec sysvinit.
Les arguments dans ce post décrivent la réflexion qui a conduit à systemd, pas les objectifs de systemd. Et la rapidité intrinsèque aux choix effectués montrent selon l'auteur que c'est un bon init s'il suit sa définition d'un bon init.
Il me semble qu'il y a un autre blog de l'auteur qui explique les objectifs de systemd (l'ensemble de logiciels, pas juste l'init).