Hello la liste, Je n'écris pas souvent alors je me permet de réagir....
> Je suis aussi utilisateur, mais tardif. Très tardif, mais je suis en train de ne plus être utilisateur (voir plus bas). > Les scripts sysinit m'ont toujours rebuté, entre la répétition entre scripts, > l'incompatibilité entre distribs, le boilerplate dans chaque daemon, la > gestion des dépendances ... > Il y quelques années j'avais essayé initng initng me paraissais bien en tous cas pour les linux qui le supportaient. > choix avant de passer a systemd Idem. Passé dessus parce qu'on m'as pas demandé mon choix (enfin, techniquement je pourrais, mais l'install de base du linux m'obligeant sur les devices linux only que j'ai... j'ai dû m'adapter) (...) > Je n'ai pas l'envie de le lancer un débat, mais il y a quand même un certain > découpage des programmes et fonctions dans le projet/paquet systemd. Il y a le > /sbin/init et les fonctions annexes (networkd par exemple) sont dans des > binaires séparés. Est-ce qu'il n'y a pas trop de choses dans le pid 1, pour ca > les opinions divergent ... Heu là je suis un dino, et la phylosophie des unix c'est KISS : keep it simple and stupid. Sans compter le repects des RFC qui sont totalement ignorées par les dev. Exemple : le DNS, le client DHCP, les RA etc... Systemd avec tout le merdier dans pid 1 est tout SAUF KISS. Et ses dépendances ne le sont pas, ainsi que les besoins de plein de lib, a un tel point qu'on arrive a faire des choses "fat" pour un OS qui as la réputation d'être simple (voir encore plus bas). (...) > Le problème de la doc est que vu qu'il faut créer (pour chaque interface) 3 > types de fichier, il faut regarder dans 3 pages de man : systemd.link > systemd.netdev systemd.network . > Et aussi, ca multiplie très vite le nombre de fichiers, par exemple sur une > passerelle un peu complexe j'en suis a plus de 30 ... Suis désolé mais 3 fichiers pour chacune des interfaces, c'est tout sauf KISS. Quand par exemple je fait du NAT compliqué avec un os libre, j'ai besoin d'avoir tout sur un fichier pour comprendre les choses. En terme de maintenabilité, c'est tout sauf maintenable. Un moment de trop découper on deviens une usine a gaz et on espère que les dépendances sont correctement gérées. Pourquoi je râle ? Simple: quand on reprends une infra d'un tier et qu'il faut passer plusieurs jours a comprendre les systemdiseries qui bien évidement changent parce qu'il n'y a pas de stabilité dans les implementation, on croise les doigts pour ce machin n'explose pas en vol. Si pour le poste de travail, je n'ai rien contre systemd (oui on peux l'encadrer), dans le cadre d'infra serveur, je n'ai absolument pas besoin de ce truc. On a plein de méthode pour éviter ce délire, et les containers (docker, jails, etc...) permettent d'arbitrer correctement le lancement des dépendance si on est pas idiot, et aussi permettre de faire une archi scalable. Systemd en env serveur n'as rien a faire dedans. D'ailleurs les idées de fichiers découpés en plusieurs fichiers ont tjrs rendu les choses compliquées que simple, mais l'habitude des debian a fait que ça a dérapé. De mon coté, je pousse du FreeBSD, des jails et un vrai stack réseau qui marche. Un /etc/rc.conf qui contient tout la configuration système est bcp plus pratique qu'une centaine de fichiers mis un peu partout... Après connaissant bien le monde de linux, je suis avec mon générateur de popcorn, et comme debian permet de nouveau de ne pas dépendre de systemd, c'est que quand même il y a de l'espoir... Xavier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
