• [^] # Re: C’est du propre

    Posté par . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 7.

    systemd est encore jeune. Peut-être atteint-il maintenant un stade assez mature, mais pas depuis très longtemps.

    Bah écoute, à part une unité que j’ai dû modifier pour que la session ssh se coupe avant l’arrêt du réseau sur un serveur (voir le wiki d’Arch Linux), je n’ai jamais rien modifié et ça fonctionne au poil. Et vu son adoption en masse j’ai l’impression qu’il est déjà bien mature.

    Ben c’est-à-dire que quand un script d’init de quelques dizaines de lignes était pourri, je pouvais le déboguer moi-même.

    C’est le plus mauvais argument tout catégories confondues que j’ai entendu à propos de systemd. Si tu dois modifier le code du système d’initialisation c’est qu’il est mal foutu. Est-ce qu’on gueule parce que Linux n’est pas en Bash et qu’on peut pas le modifier facilement?

    Par contre, si tu dois modifier un fichier de configuration ou une unité c’est tout à fait acceptable vu que c’est fait pour ça.

    Sur mon portable sous Arch, avant systemd, je démarrais les quelques services dont dépendent vraiment les autres séquentiellement, puis quasiment tout en parallèle. Au début (quand systemd n’était que dans les contributions), systemd démarrait aussi rapidement, mais avec la multiplication des micro-unités et des fichiers de configuration, ça demande plus d’accès disques et c’est finalement plus lent.

    Chez moi et chez la plupart des gens c’est plus rapide. En plus je vois pas ce que ça fait qu’il y ai plusieurs fichiers, comme si l’init à la BSD ou SystemV c’était pas plusieurs fichiers. Donc je ne pense pas que ça soit ça; essaie de faire systemd-analyze blame ou systemd-analyze plot > graphe.svg, ça te donnera une idée de ce qui ralentit le démarrage.

    Avec le bémol que la distribution la plus populaire n’a pas adopté systemd.

    Ils n’adoptent pas Wayland alors qu’il fait consensus partout ailleurs.

    Il arrive que des points de montage NFS restent après l’arrêt du réseau (léger souci dans l’enchaînement quand même... et ça, c’est sous Fedora 19 avec un systemd récent, sur les versions plus anciennes, ce genre de problème était plus fréquent et bien plus long) et alors systemd patine pendant un certain temps dessus...

    J’ai eu le même genre de problème avec SSH (voir plus haut), mais c’est tout. Ce genre de cas devient de plus en plus rares.

    Écrit en Bépo selon l’orthographe de 1990