J'aime beaucoup systemd.
C'est encore de l'excellent (et paradoxalement détesté par beaucoup) Lennard.
Systemd se rapproche beaucoup de launchd (l'init d'Apple sous licence Apache), pour définir un service, on n'écrit plus un script shell mais un simple fichier de configuration (un format .ini like), donc on se débarasse de l'overhead lié au lancement d'un shell pour exécuter le job (upstart)/unit (systemd).
Ça c'est pour les performances, je dois dire que ça me touche peu (booter en 20 ou 30 secondes je m'en fous).
Par contre, ça va forcer la standardisation des services au-lieu que chaqu'un fasse comme bon lui semble. D'autres optimisations seront alors possibles.
De plus, systemd est beaucoup plus aggressif qu'upstart pour la parallélisation des tâches
systemd s'en fout de la parallélisation des tâches :-)
C'est plus con et plus subtile que ça.
systemd s'arrange pour que D-Bus place les requêtes de A dans une file d'attente le temps que B ait fini de se lancer.
Pas vraiment. Systemd crée les "ports" d'écoute pour A et B et lance A et B.
A "parle" à B et si B ne peut répondre (car il n'est pas encore initialisé), A attend (probablement bloqué dans l'appel système d'écriture à B).
Il y a aussi un mode à la "inetd". systemd crée un port d'écoute pour B, tant que personne ne cause à B, systemd ne le lance pas.
L'exemple typique est sshd. Pourquoi lancer au démarrage sshd ? Il faut le lancer quand on en a besoin, c'est ce que fait systemd.
Systemd est assez bien fourni en outils d'administration (ligne de commande ou graphique) qui permettent de suivre l'état des processus (grâce à l'api cgroups du noyau linux entre autre).
Avec cgroups, c'est surtout enfin fiable.
systemd est vraiment la bonne réponse au problème. J'adore.
Sûr il va y avoir des problèmes au début, mais c'est la voie à suivre.
[^] # Re: systemd / upstart
Posté par IsNotGood . En réponse à la dépêche Sortie de la bêta de Fedora 14 Laughlin. Évalué à 5.
C'est encore de l'excellent (et paradoxalement détesté par beaucoup) Lennard.
Systemd se rapproche beaucoup de launchd (l'init d'Apple sous licence Apache), pour définir un service, on n'écrit plus un script shell mais un simple fichier de configuration (un format .ini like), donc on se débarasse de l'overhead lié au lancement d'un shell pour exécuter le job (upstart)/unit (systemd).
Ça c'est pour les performances, je dois dire que ça me touche peu (booter en 20 ou 30 secondes je m'en fous).
Par contre, ça va forcer la standardisation des services au-lieu que chaqu'un fasse comme bon lui semble. D'autres optimisations seront alors possibles.
De plus, systemd est beaucoup plus aggressif qu'upstart pour la parallélisation des tâches
systemd s'en fout de la parallélisation des tâches :-)
C'est plus con et plus subtile que ça.
systemd s'arrange pour que D-Bus place les requêtes de A dans une file d'attente le temps que B ait fini de se lancer.
Pas vraiment. Systemd crée les "ports" d'écoute pour A et B et lance A et B.
A "parle" à B et si B ne peut répondre (car il n'est pas encore initialisé), A attend (probablement bloqué dans l'appel système d'écriture à B).
Il y a aussi un mode à la "inetd". systemd crée un port d'écoute pour B, tant que personne ne cause à B, systemd ne le lance pas.
L'exemple typique est sshd. Pourquoi lancer au démarrage sshd ? Il faut le lancer quand on en a besoin, c'est ce que fait systemd.
Systemd est assez bien fourni en outils d'administration (ligne de commande ou graphique) qui permettent de suivre l'état des processus (grâce à l'api cgroups du noyau linux entre autre).
Avec cgroups, c'est surtout enfin fiable.
systemd est vraiment la bonne réponse au problème. J'adore.
Sûr il va y avoir des problèmes au début, mais c'est la voie à suivre.