Je pense que les anti-systemd sont ceux qui hackent (ou ont hacké) le système de boot. C'est lumineusement simple, basé sur du shell, et le fait de passer par un truc binaire carré fait penser à la base de registre de microsoft: bien intégré, rapide mais obscur. Et comme systemd vient de partout, bah il faut le manger quand même, envie ou pas.
Les zamoureux de systemd ont du regarder vaguement un jour l'init, voient systemd avec des fichiers .unit tout basiques et > disent que "ça marche, c'est rapide, et ça fait le job". Pourquoi pas.
Je trouve que tu as bien saisi la nuance de jugement selon le public : les sysadmins/utilisateurs qui trouvent ça bien foutu et facile à utiliser (je suis aussi de cet avis), et les bidouilleurs et autres intégrateurs/packageurs qui ont vu l'envers du décor, pas forcément joli-joli.
Pour avoir intégré systemd il fut un temps à la distribution que je maintiens (http://0linux.org), c'est ce côté-là qui m'a rebuté : systemd ne sait pas se tenir tranquille. À chaque release ce sont des binaires supplémentaires qui apparaissent et s'accaparent un rôle supplémentaire, de nouvelles règles Udev qui modifient le comportement, des déplacements de binaires, un paquet qui devient finalement obèse tout comme sa documentation (que ce soit un bien ou un mal, il faut se la coltiner)...
Nous avons donc utilisé systemd pendant 6-8 mois avec quasi-bonheur (bien qu'on ait dû se taper quelques unités à écrire et bien faire attention au mécanisme de dépendances ainsi qu'à un vocabulaire qui évolue vite où de nouveaux mots-clés font leur entrée régulièrement) côté utilisateur, mais côté intégration/empaquetage on n'a jamais été vraiment à l'aise et confronté à des limitations et à un manque de souplesse qui a fini par avoir raison de sa présence dans 0Linux, car demandant trop de hacking, justement, de notre part sur un logiciel qu'on connaît quand même plutôt mal.
En vrac : la restriction du démarrage des sessions du bureau sur le tty1, la création de fichiers spécifiques plus ou moins obscurs pour démarrer un initramfs (pour un Live par exemple) nous forçant peu à peu à passer à dracut qui lui intègre tout ce qu'il faut, le journal binaire qui a occasionné de beaux plantages de la machine, les consoles qui sautent après un certain temps si on ne s'y connecte pas, le service d'optimisation du temps de démarrage « readahead » qui a fini par être encore plus lent que mes initscripts à la BSD/Slackware et sûrement d'autres aspects que j'oublie.
Mais de là à dire que systemd n'est pas du tout hackable, il y a un fossé. Mis à part le journal en binaire, tout est au contraire très modulaire et le vocabulaire des unités et des options des binaires couvre très largement les usages et besoins (même si ça doit passer par la réécriture de nombreuses unités mais c'est un autre problème, systemd fournit le maximum de fichiers pour que tout marche tout de suite, on ne va pas s'en plaindre).
Plus le temps passe et plus je me dis que Lennart aurait bien mieux fait de concevoir une sorte de protocole ou une norme/RFC bien définie et stable (car les idées sont toutes très bonnes à la base) mais surtout pas d'implémenter tout ça dans un gros machin comme systemd, qui veut tout savoir faire tout en continuant d'avancer très vite (il va peut-être même un jour gérer nos paquets !). Ici on va conserver notre init BSD-like en attendant que les choses se tassent.
Donc, pour répondre à ta question : les deux. Intégration pour l'utilisateur, hackabilité pour le mainteneur/bidouilleur. Et justement systemd est peut-être trop intégré pour être hackable, bien qu'il le soit suffisamment (hackable).
# Du point de vue utilisateur ou mainteneur ?
Posté par appzer0 (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 10.
Je trouve que tu as bien saisi la nuance de jugement selon le public : les sysadmins/utilisateurs qui trouvent ça bien foutu et facile à utiliser (je suis aussi de cet avis), et les bidouilleurs et autres intégrateurs/packageurs qui ont vu l'envers du décor, pas forcément joli-joli.
Pour avoir intégré systemd il fut un temps à la distribution que je maintiens (http://0linux.org), c'est ce côté-là qui m'a rebuté : systemd ne sait pas se tenir tranquille. À chaque release ce sont des binaires supplémentaires qui apparaissent et s'accaparent un rôle supplémentaire, de nouvelles règles Udev qui modifient le comportement, des déplacements de binaires, un paquet qui devient finalement obèse tout comme sa documentation (que ce soit un bien ou un mal, il faut se la coltiner)...
Nous avons donc utilisé systemd pendant 6-8 mois avec quasi-bonheur (bien qu'on ait dû se taper quelques unités à écrire et bien faire attention au mécanisme de dépendances ainsi qu'à un vocabulaire qui évolue vite où de nouveaux mots-clés font leur entrée régulièrement) côté utilisateur, mais côté intégration/empaquetage on n'a jamais été vraiment à l'aise et confronté à des limitations et à un manque de souplesse qui a fini par avoir raison de sa présence dans 0Linux, car demandant trop de hacking, justement, de notre part sur un logiciel qu'on connaît quand même plutôt mal.
En vrac : la restriction du démarrage des sessions du bureau sur le tty1, la création de fichiers spécifiques plus ou moins obscurs pour démarrer un initramfs (pour un Live par exemple) nous forçant peu à peu à passer à dracut qui lui intègre tout ce qu'il faut, le journal binaire qui a occasionné de beaux plantages de la machine, les consoles qui sautent après un certain temps si on ne s'y connecte pas, le service d'optimisation du temps de démarrage « readahead » qui a fini par être encore plus lent que mes initscripts à la BSD/Slackware et sûrement d'autres aspects que j'oublie.
Mais de là à dire que systemd n'est pas du tout hackable, il y a un fossé. Mis à part le journal en binaire, tout est au contraire très modulaire et le vocabulaire des unités et des options des binaires couvre très largement les usages et besoins (même si ça doit passer par la réécriture de nombreuses unités mais c'est un autre problème, systemd fournit le maximum de fichiers pour que tout marche tout de suite, on ne va pas s'en plaindre).
Plus le temps passe et plus je me dis que Lennart aurait bien mieux fait de concevoir une sorte de protocole ou une norme/RFC bien définie et stable (car les idées sont toutes très bonnes à la base) mais surtout pas d'implémenter tout ça dans un gros machin comme systemd, qui veut tout savoir faire tout en continuant d'avancer très vite (il va peut-être même un jour gérer nos paquets !). Ici on va conserver notre init BSD-like en attendant que les choses se tassent.
Donc, pour répondre à ta question : les deux. Intégration pour l'utilisateur, hackabilité pour le mainteneur/bidouilleur. Et justement systemd est peut-être trop intégré pour être hackable, bien qu'il le soit suffisamment (hackable).