Re: 3 ans ?

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.

Oui donc pas Linux, nous sommes bien d'accord. C'est en ça que je trouve une utilité à OpenOffice/LibreOffice (outre les questions de licences, d'éthique, toussa...).

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.

Je suis concrètement ce type d'utilisateur, j'ai 106 units chargés actuellement, pour une utilisation desktop agréable c'est le minimum (on peut à la limite retirer le bluetooth, l'encryption des volumes et le multi-user, ça fait toujours 103 units sachant que systemd en lance lui-même 30). J'utilise OpenBox standalone avec une config maison.

J'ai essayé de maintenir mon OpenBox avec OpenRC mais c'était un calvaire. Je passais plus de temps à débugguer/compiler/réécrire mes scripts qu'utiliser mon système. Au bout d'un moment j'ai pris le même train que tout le monde et depuis je me laisse porter.

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.

Même avant l'avènement de systemd, je passais pas mal de temps à modifier mes scripts SysV parce qu'ils n'étaient pas forcément adaptés, pourtant il y avait aussi des gens qui me mâchaient le travail en amont. Oui c'est sûr que le fait que ma distro supporte systemd rend de fait plus facile la maintenance de systemd mais si tant de distros majeures ont fait le choix de le supporter par défaut, c'est sans doute qu'il a des avantages par rapport aux autres (soit dans ses fonctionnalités, soit dans sa facilité de maintenance pour les packagers).

Maintenant supprimer un lien symbolique ne me semble pas plus compliqué que de lancer un systemctl stop [daemon en question], ça me semble même plus "logique" mais là c'est purement subjectif et tout le monde trouvera à y redire.

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.

Et je suis parfaitement conscient de ce problème et ne le nie pas. C'est vrai, il est difficile de se passer de systemd et c'est même cette complexité qui fait que je n'ai pas pu supporter le travail de maintenance à faire pour l'utilisation d'un autre système d'init en plus de constater que le support pour les autres systèmes était plus difficile à trouver. C'est ce principal défaut qui m'a fait revenir à lui. Ce serait un vrai problème s'il était instable ou incomplet, ce n'est pas le cas. Il fait parfaitement son travail, je commence à le dompter doucement bien que je sois loin de le maîtriser parfaitement. Oui ça demande de réapprendre pas mal de choses mais ça compense largement le temps perdu à maintenir un autre système d'init. Cela dit oui, en terme de choix pour l'utilisateur, c'est assez limité. Concrètement c'est "systemd ou alors demmerde-toi". J'aime bien me démerder mais pour quelque chose d'aussi futile qu'un système d'init, je ne veux pas non plus m'emmerder.

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é.

C'est aussi la sensation que j'avais eu à l'époque. Cela dit attention avec la nostalgie, inclure des softs qui ne sont plus supportés par leurs devs (typiquement Slim en tant que login manager) n'est sans doute pas la meilleur des réminiscences nostalgiques qu'on peut avoir ;). Je ne sais pas si c'est le cas sur la v1 mais c'était le cas sur les bétas.

La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.