_ openRC conserve la complexité d'écriture de scripts de sysVinit ( j'entends par la que la syntaxe utilisée est celle de sh, ce qui est complexe du point de vue utilisateur, pas de celui du système )
#!/sbin/runscript# Copyright 1999-2011 Gentoo Foundation# Distributed under the terms of the GNU General Public License v2# $Header: /var/cvsroot/gentoo-x86/app-admin/metalog/files/metalog.initd,v 1.5 2011年09月23日 03:15:23 vapier Exp $extra_started_commands="buffer unbuffer"PIDFILE=/var/run/metalog.pid
depend(){
need localmount
use clock hostname
after bootmisc
provide logger
}
ssd(){ start-stop-daemon --exec /usr/sbin/metalog --pidfile "${PIDFILE}""$@";}
start(){
ebegin "Starting metalog"
ssd --start -- \
--daemonize --pidfile="${PIDFILE}"${METALOG_OPTS}
eend $?}
stop(){
ebegin "Stopping metalog"
ssd --stop
eend $?}
buffer(){
ebegin "Enabling log buffering"
ssd --signal USR2
eend $?}
unbuffer(){
ebegin "Disabling log buffering"
ssd --signal USR1
eend $?}
C'est pas démesuré comme difficulté.
_ mais openRC permets de paralléliser les tâches ( comme pour systemd ) . Chose qui d'ailleurs m'intrigue vu que j'ai lu diverses allégations laissant supposer que sysVinit en serait aussi capable ( on parle de script shell dans les 2 cas si je ne m'abuse, donc ça ne m'a pas semblé irréaliste )
La parallélisation est indépendante de la façon de décrire le lancement d'un service. On pourrait très bien réécrire tous les scripts d'init en ruby ça n'empêcherait pas sysvinit (svi) de faire du parallélisme. Il lance les scripts (ou binaires d'ailleurs) en parallèle il se fout de savoir ce qu'il y a derrière (ça c'est pour OpenRC et svi).
Ensuite ce qui démarque systemd de ces deux là c'est que le modèle de parallélisme n'est pas le même.
Dans OpenRC et svi tu construit un arbre de dépendances de manière statique. Tu indique pour chaque service de quel services il dépend et l'init va se débrouiller pour lancer le services dont toutes les dépendances sont satisfaites en même temps. svi parle d'un make style pour décrire la manière dont il fait l'exécution.
Dans systemd, tu peut décrire ce genre de dépendance, mais ce n'est pas forcément nécessaire, il est capable de détecter tout seul les dépendances. Par exemple si un service A dépend d'un autre (B) et en a besoin parce qu'il communique avec lui par une socket. systemd va lancer A puis lorsque A va avoir besoin de B, il va lancer B (c'est le socket activation). L'avantage de cette méthode c'est qu'elle est dynamique (si A n'avait pas eu besoin de B avant 10 minutes, alors B n'aurait pas était lancé trop tôt).
C'est bien une différence de paradigme, ils n'ont pas le même modèle d'exécution.
[^] # Re: OpenRC
Posté par barmic . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 4.
Une unité systemd c'est ça :
Un service OpenRC c'est ça :
C'est pas démesuré comme difficulté.
La parallélisation est indépendante de la façon de décrire le lancement d'un service. On pourrait très bien réécrire tous les scripts d'init en ruby ça n'empêcherait pas sysvinit (svi) de faire du parallélisme. Il lance les scripts (ou binaires d'ailleurs) en parallèle il se fout de savoir ce qu'il y a derrière (ça c'est pour OpenRC et svi).
Ensuite ce qui démarque systemd de ces deux là c'est que le modèle de parallélisme n'est pas le même.
Dans OpenRC et svi tu construit un arbre de dépendances de manière statique. Tu indique pour chaque service de quel services il dépend et l'init va se débrouiller pour lancer le services dont toutes les dépendances sont satisfaites en même temps. svi parle d'un
make stylepour décrire la manière dont il fait l'exécution.Dans systemd, tu peut décrire ce genre de dépendance, mais ce n'est pas forcément nécessaire, il est capable de détecter tout seul les dépendances. Par exemple si un service A dépend d'un autre (B) et en a besoin parce qu'il communique avec lui par une socket. systemd va lancer A puis lorsque A va avoir besoin de B, il va lancer B (c'est le socket activation). L'avantage de cette méthode c'est qu'elle est dynamique (si A n'avait pas eu besoin de B avant 10 minutes, alors B n'aurait pas était lancé trop tôt).
C'est bien une différence de paradigme, ils n'ont pas le même modèle d'exécution.
Si tu veux plus t'informer, je te conseil les dépêches Petit état de l'art des systèmes d'initialisation et Évolutions techniques de systemd.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)