Posté par Kaane .
En réponse au journal udev forké.
Évalué à 10.
Et pourquoi pas? C'est si horrible que ça?
Oui.
Déjà il y a des dépendances dans tous les sens, ça ne peut être piloté correctement que via DBus (donc pour le debug il va falloir créer un client DBus avec des droits démentiels et des cgroups transversaux), c'est fortement incompatible avec pas mal de méthodes de chiffrement de la partition de boot (grosso-modo tous sauf luks), ca monopolise des ressources mémoires (les cgroups c'est loin d'être gratuit, surtout en embarqué) etc.
Mais surtout :
- C'est fait par Red Hat, les experts en "on laisse tomber la fonctionnalité phare de la version précédente". Si vous avez investi dans les technos de virtualisation à la sauce Red Hat, vous savez de quoi je parle.
Il faut réécrire profondément les scripts d'init pour en tirer partie. Certes on peut créer assez rapidement des scripts qui fonctionnent du moment que l'on force une exécution séquentielle (c'est d'ailleurs ce que font pas mal de distribs en ce moment) mais pour que systemd apporte quelque chose il faut repenser l'init. Quand on voit qu'en près de 14 ans de déprécation les scripts utilisant ifconfig n'ont pas tous été réécrit et que iwconfig n'est toujours pas complètement intégré à au set d'outils iproute2 …
Vu la gueule de la stabilité API des linuxeries du passé (HAL, DBus, SELinux etc.) je n'investirais pas de temps à apprendre systemd. Et quand je n'aurais pas le choix (tous les linux avec systemd) je créerai un script bien gruik dans un cgroup absolu (tous les pouvoirs) qui lancera un bon vieux script shell en mode séquentiel. Bref il y aura un script init2 sur ma machine sur lequel je pourrais intervenir en mode texte avec pour toute arme une console et un vi.
Mais bon le truc c'est que ce qu'il y a de plus chiant dans Linux (bien plus que de gérer les dépendances et de faire un système de packages cohérent) c'est de faire des scripts d'init. C'est probablement la seule raison pour laquelle j'utilise une distrib toute faite et pas un LFS ultra customisé. Donc la perspective de devoir tous les réécrire et les maintenir pendant les deux ou trois ans que va mettre systemd à crever ne m'enchante pas.
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 10.
Et pourquoi pas? C'est si horrible que ça?
Oui.
Déjà il y a des dépendances dans tous les sens, ça ne peut être piloté correctement que via DBus (donc pour le debug il va falloir créer un client DBus avec des droits démentiels et des cgroups transversaux), c'est fortement incompatible avec pas mal de méthodes de chiffrement de la partition de boot (grosso-modo tous sauf luks), ca monopolise des ressources mémoires (les cgroups c'est loin d'être gratuit, surtout en embarqué) etc.
Mais surtout :
- C'est fait par Red Hat, les experts en "on laisse tomber la fonctionnalité phare de la version précédente". Si vous avez investi dans les technos de virtualisation à la sauce Red Hat, vous savez de quoi je parle.
Il faut réécrire profondément les scripts d'init pour en tirer partie. Certes on peut créer assez rapidement des scripts qui fonctionnent du moment que l'on force une exécution séquentielle (c'est d'ailleurs ce que font pas mal de distribs en ce moment) mais pour que systemd apporte quelque chose il faut repenser l'init. Quand on voit qu'en près de 14 ans de déprécation les scripts utilisant ifconfig n'ont pas tous été réécrit et que iwconfig n'est toujours pas complètement intégré à au set d'outils iproute2 …
Vu la gueule de la stabilité API des linuxeries du passé (HAL, DBus, SELinux etc.) je n'investirais pas de temps à apprendre systemd. Et quand je n'aurais pas le choix (tous les linux avec systemd) je créerai un script bien gruik dans un cgroup absolu (tous les pouvoirs) qui lancera un bon vieux script shell en mode séquentiel. Bref il y aura un script init2 sur ma machine sur lequel je pourrais intervenir en mode texte avec pour toute arme une console et un vi.
Mais bon le truc c'est que ce qu'il y a de plus chiant dans Linux (bien plus que de gérer les dépendances et de faire un système de packages cohérent) c'est de faire des scripts d'init. C'est probablement la seule raison pour laquelle j'utilise une distrib toute faite et pas un LFS ultra customisé. Donc la perspective de devoir tous les réécrire et les maintenir pendant les deux ou trois ans que va mettre systemd à crever ne m'enchante pas.