Si. A l'heure actuelle, wikipedia me dit que ça marche sous windows, mac os x et android. Pour android je reconnaît que c'est une découverte pour moi, hein, mais pour l'OS d'apple ça fait perpette je crois.
Les autres systèmes d'init ne sont pas "moins bons" mais "moins efficaces dans mon utilisation". M'emmerder à gérer des dizaines de lignes de bash par script alors qu'un unit systemd c'est 3 lignes, c'est tout vu pour moi. Le vitesse au boot étant un bonus appréciable.
La, rien à redire. Dans telle ou telle utilisation, je suis persuadé que systemd est le meilleur. Je dirais, à vue de nez, avec un gros DE type KDE ou Gnome qui utilisent un certain nombre d'outils pour détecter les sessions, par exemple.
Alors que pour un utilisateur de logiciels léger qui bricole son propre environnement graphique en sélectionnant lui-même les composants, je pense que systemd n'est plus pertinent.
Pour ce qui est des 10aines de lignes de shell pour un script, tu as raison. Je viens de regarder, le script d'init d'apache utilisé par void pèse bel et bien plusieurs dizaines de lignes:
#!/bin/sh
set -e
[ -s conf ] && . ./conf
mkdir -p /run/httpd
chmod 0710 /run/httpd
chown root:_apache /run/httpd
: ${ROOTDIR:=/srv/www/apache}
: ${LOGDIR:=/var/log/httpd}
if [ ! -d $ROOTDIR ]; then
mkdir -p $ROOTDIR
chown _apache:_apache $ROOTDIR
fi
if [ ! -d $LOGDIR ]; then
mkdir -p $LOGDIR
chown _apache:_apache $LOGDIR
fi
exec httpd -DNO_DETACH
Le vrai problème des scripts d'init shell, c'est sysV et sa tendance à avoir des dépendances dans tous les coins. Avec l'ancêtre, on ne parle pas de dizaines, mais de centaines voire de milliers.
Je remercie systemd moi. Grâce à ce truc, que je n'apprécie ni n'utilise, les inits vont être plus maintenables. Que ce soit via l'utilisation de systemd ou d'un autre n'est pas important. Chacun son truc, y'a bien des gens qui utilisent emacs après tout.
avec les inits alternatifs, ça "ne juste marche pas" parce qu'il faut mettre les mains dans le cambouis.
Seulement parce que personne n'a fait le travail pour ta distribution, chose qui a été faite pour systemd. Tu peux me dire que le travail avec systemd peut être mutualisé, et c'est sûrement vrai, mais je pense que ça l'est aussi avec les autres.
Dans l'exemple ci-dessus (pas pris apache au hasard, j'espérait qu'il soit gros. Sinon, j'aurai pris dhclient dont le script pèse... 3 lignes, shebang inclut.) peu de choses sont utiles à modifier d'une distro à l'autre. Peut-être les dossiers: var, run et srv?
On est très loin de la complexité de sysV: j'ai 424 lignes pour le fichier /etc/init.d/apache2 et c'est autrement plus complexe. Ca doit faire plein de choses en plus, j'en suis sûr, comme... supporter la commande service, chose inutile pour runit (il suffit de supprimer un lien symbolique pour stopper un daemon, pas besoin de passer par une usine à gaz en shell).
Après, si ton argument, c'est que le boulot à été fait pour systemd et pas pour les autres, ok.
Mais il a bien fallu que quelqu'un le fasse, et la complexité de sysV n'est pas liée au fait que ce soit du shell.
je pense qu'il est nécessaire d'avoir certaines briques élémentaires "références"
Le problème, c'est quand la brique de référence entraîne des modifications qui font qu'il devient difficile de s'en passer. Un peu comme si l'utilisation de grub2 entraînait des changement dans le bureau, rendant difficile l'usage de lilo ou syslinux. Ou comme si vi et ses héritiers avaient un impact sur les émulateurs de terminal. Et c'est bien la l'un des reproches qui sont faits à systemd.
Evidemment, Devuan n'est pas à destination des utilisateurs débutants sous Linux.
Logique.
Debian ne l'est pas, après tout, et c'est un fork qui aspire à retrouver "l'esprit d'origine". Enfin, c'est l'impression que j'ai eue quand ils ont forké.
[^] # Re: 3 ans ?
Posté par freem . En réponse au journal Devuan Jessie 1.0. Évalué à 1.
Si. A l'heure actuelle, wikipedia me dit que ça marche sous windows, mac os x et android. Pour android je reconnaît que c'est une découverte pour moi, hein, mais pour l'OS d'apple ça fait perpette je crois.
La, rien à redire. Dans telle ou telle utilisation, je suis persuadé que systemd est le meilleur. Je dirais, à vue de nez, avec un gros DE type KDE ou Gnome qui utilisent un certain nombre d'outils pour détecter les sessions, par exemple.
Alors que pour un utilisateur de logiciels léger qui bricole son propre environnement graphique en sélectionnant lui-même les composants, je pense que systemd n'est plus pertinent.
Pour ce qui est des 10aines de lignes de shell pour un script, tu as raison. Je viens de regarder, le script d'init d'apache utilisé par void pèse bel et bien plusieurs dizaines de lignes:
Le vrai problème des scripts d'init shell, c'est sysV et sa tendance à avoir des dépendances dans tous les coins. Avec l'ancêtre, on ne parle pas de dizaines, mais de centaines voire de milliers.
Je remercie systemd moi. Grâce à ce truc, que je n'apprécie ni n'utilise, les inits vont être plus maintenables. Que ce soit via l'utilisation de systemd ou d'un autre n'est pas important. Chacun son truc, y'a bien des gens qui utilisent emacs après tout.
Seulement parce que personne n'a fait le travail pour ta distribution, chose qui a été faite pour systemd. Tu peux me dire que le travail avec systemd peut être mutualisé, et c'est sûrement vrai, mais je pense que ça l'est aussi avec les autres.
Dans l'exemple ci-dessus (pas pris apache au hasard, j'espérait qu'il soit gros. Sinon, j'aurai pris dhclient dont le script pèse... 3 lignes, shebang inclut.) peu de choses sont utiles à modifier d'une distro à l'autre. Peut-être les dossiers: var, run et srv?
On est très loin de la complexité de sysV: j'ai 424 lignes pour le fichier /etc/init.d/apache2 et c'est autrement plus complexe. Ca doit faire plein de choses en plus, j'en suis sûr, comme... supporter la commande
service, chose inutile pour runit (il suffit de supprimer un lien symbolique pour stopper un daemon, pas besoin de passer par une usine à gaz en shell).Après, si ton argument, c'est que le boulot à été fait pour systemd et pas pour les autres, ok.
Mais il a bien fallu que quelqu'un le fasse, et la complexité de sysV n'est pas liée au fait que ce soit du shell.
Le problème, c'est quand la brique de référence entraîne des modifications qui font qu'il devient difficile de s'en passer. Un peu comme si l'utilisation de grub2 entraînait des changement dans le bureau, rendant difficile l'usage de lilo ou syslinux. Ou comme si vi et ses héritiers avaient un impact sur les émulateurs de terminal. Et c'est bien la l'un des reproches qui sont faits à systemd.
Logique.
Debian ne l'est pas, après tout, et c'est un fork qui aspire à retrouver "l'esprit d'origine". Enfin, c'est l'impression que j'ai eue quand ils ont forké.