La comparaison ne porte pas sur le nombre de ligne de code que pond le développeur, mais le nombre de ligne de code que pond l’administrateur.
Et bien ça n'est pas très clair que la comparaison ne concerne que les admins sys. Et dans le cadre de cette dépêche, un fork de Debian, un système qui se veut universel, il y a pas mal d'utilisateurs qui modifient leurs scripts d'init, ou en rajoutent d'autres sans même parfois tout bien comprendre. (c'est un des intérêts du shell que de pouvoir pratiquer rapidement en ne connaissant qu'un sous-ensemble du langage). Alors quand on a le code sous les yeux, la logique même du script, c'est un gros avantage. Il n'est bien sûr a ce niveau pas question de forker systemd. Alors dans ces cas là, on utilisera des programmes tout prêt, ou on ne fera pas (il y a apparemment moyen de faire fonctionner des script shell sous systemd ce qui amoindrit pas mal ce problème).
Ce que je voulais dire, c'est qu'il est normal et logique d'avoir plus de lignes lorsque l'on a le programme ET sa configuration réunis, que lorsque l'on a uniquement le fichier de configuration. Si maintenant il s'agit de montrer que la config est plus simple, alors ce n'est pas tout à fait honnête, car on peut faire la même chose en shell (sourcer un fichier de config, c'est en partie le cas, mais là on nous montre aussi les entrailles du script).
Je prend juste un exemple:
script shell:
if [ -f /etc/sysconfig/sendmail ] ; then
. /etc/sysconfig/sendmail
else
DAEMON=no
QUEUE=1h
fi
unit systemd:
[Service]
EnvironmentFile=-/etc/sysconfig/sendmail
Maintenant, rien n’empêche (et assez facilement) d'avoir :
script shell:
# Source global config "unit-like"
if [ -f ./etc/rc.d/init.d/conf/sendmail.unit ] ; then
. /etc/rc.d/init.d/conf/sendmail.unit
fi
...
et dans /etc/rc.d/init.d/conf/sendmail.unit, quelque chose de similaire au fichier de config de systemd, c'est à dire, une dizaine de variable. Et dans ce cas pour le sysadmin, ça ne changera pas grand chose.
Donc l'argument de la clarté, je le trouve un peu léger, et pas très fairplay. Tant qu'a montrer la logique, l’algorithmie, du script shell, autant montrer aussi celle équivalente dans systemd pour voir si elle est aussi compréhensible et facile à modifier (et oui, Debian n'est pas fait que pour les sysadmin allergiques aux scripts shell, et sans même être un gros bidouilleur, on peut vouloir modifier quelques trucs et comprendre).
[^] # Re: Forkons Fedora !
Posté par gnujsa . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 1.
Et bien ça n'est pas très clair que la comparaison ne concerne que les admins sys. Et dans le cadre de cette dépêche, un fork de Debian, un système qui se veut universel, il y a pas mal d'utilisateurs qui modifient leurs scripts d'init, ou en rajoutent d'autres sans même parfois tout bien comprendre. (c'est un des intérêts du shell que de pouvoir pratiquer rapidement en ne connaissant qu'un sous-ensemble du langage). Alors quand on a le code sous les yeux, la logique même du script, c'est un gros avantage. Il n'est bien sûr a ce niveau pas question de forker systemd. Alors dans ces cas là, on utilisera des programmes tout prêt, ou on ne fera pas (il y a apparemment moyen de faire fonctionner des script shell sous systemd ce qui amoindrit pas mal ce problème).
Ce que je voulais dire, c'est qu'il est normal et logique d'avoir plus de lignes lorsque l'on a le programme ET sa configuration réunis, que lorsque l'on a uniquement le fichier de configuration. Si maintenant il s'agit de montrer que la config est plus simple, alors ce n'est pas tout à fait honnête, car on peut faire la même chose en shell (sourcer un fichier de config, c'est en partie le cas, mais là on nous montre aussi les entrailles du script).
Je prend juste un exemple:
script shell:
if [ -f /etc/sysconfig/sendmail ] ; then
. /etc/sysconfig/sendmail
else
DAEMON=no
QUEUE=1h
fi
unit systemd:
[Service]
EnvironmentFile=-/etc/sysconfig/sendmail
Maintenant, rien n’empêche (et assez facilement) d'avoir :
script shell:
# Source global config "unit-like"
if [ -f ./etc/rc.d/init.d/conf/sendmail.unit ] ; then
. /etc/rc.d/init.d/conf/sendmail.unit
fi
...
et dans /etc/rc.d/init.d/conf/sendmail.unit, quelque chose de similaire au fichier de config de systemd, c'est à dire, une dizaine de variable. Et dans ce cas pour le sysadmin, ça ne changera pas grand chose.
Donc l'argument de la clarté, je le trouve un peu léger, et pas très fairplay. Tant qu'a montrer la logique, l’algorithmie, du script shell, autant montrer aussi celle équivalente dans systemd pour voir si elle est aussi compréhensible et facile à modifier (et oui, Debian n'est pas fait que pour les sysadmin allergiques aux scripts shell, et sans même être un gros bidouilleur, on peut vouloir modifier quelques trucs et comprendre).