Diverses remarques

Pour la racine (« / »), cela ne présente pas d’intérêt ; mais pour les grosses volumétries qui peuvent être montées sur « /home », ou pour des partitions de données qui ne sont pas nécessaires au démarrage du système, cela présente un gain important.

Comment ça se traduit concrètement ?

Supposons que le /home (souvent la plus grosse partition pour un particulier) soit en train de faire un fsck. Ça n'empêche pas de continuer à booter et de proposer à l'utilisateur de s’authentifier (/etc/shadow et /ect/password sont dispo).

Qu'est ce qui se passe si le fsck est encore en cours et que l'utilisateur tente d'ouvrir une session ?

Est ce que ça reste gelé le temps que le fsck se finisse ?

Si c'est le cas, le remède est pire que le mal. Au bout d'une minute ou deux, l'utilisateur appuie sur reset.

D’après Lennart cette approche est condamnée à être lente. Sur son système, les scripts dans « /etc/init.d/ » appellent grep au moins 77 fois, awk l’est 92 fois, cut, 23 fois, et sed, 74 fois. À chaque appel, un processus doit être démarré, les bibliothèques résolues, la localisation initialisée, etc.. Après une manipulation de quelques octets, les données doivent être retournées à l’appelant via un descripteur de fichier et le processus est détruit. En outre, les scripts sont très sensibles à l’environnement et peu adaptés à la gestion des erreurs et des exceptions.

Dis donc Lennart, tu ne serais pas en train de militer pour une réécriture de tous ces scripts en scripts Perls auto-suffisants ? Hein ? Avoue :)

Le grand absent est Ubuntu, qui a beaucoup investi dans Upstart et n’a pas manifesté, pour l’instant, de volonté de passer à systemd (bien qu’un début d’intégration existe).

De toutes façons une fois intégré à Debian, l'effort à fournir pour l'intégrer à Ubuntu est minimal.