Re: Description de systemd ?

Et si Linux incluait un module remplaçant mail ? un client ftp ? (minimaliste, bien sûr, enfin, au début...)

On est quand même loin là, le noyau n’est pas censé fournir d’application. systemd fournit des démons indépendants, qui peuvent être désactivés et remplacés.

On parle bien ici d'un projet systemd, qui faute de limite claire dans son rôle (démarrer un système et le gérer, c'est quand même très flou), est en train de tout refaire à sa sauce. Ce projet est-il donc incapable d'interagir avec une brique de l'espace utilisateur sans créer un module dédié ? Le daemon DHCP, au départ tout simple, ambitionne déjà de gérer un cache DNS et DNSSEC...

S’ils font un truc bien, pourquoi pas. Bizarrement quand le projet systemd fait des trucs on parle de NIH, mais sinon les trouze milles distributions c’est de la diversité, hein? J’ai envie de dire: nous verrons bien ce que ça va donner.

Alors, bien sûr, on peut ne pas activer ces modules. Mais il n'empêche que ces modules seront intégrés de plus en plus fortement au démarrage du système, et la possibilité qu'ils deviennent irremplaçables est bien là.

Je ne vois pas en quoi les modules précédents pourraient devenir obligatoires.

Le problème, tel que je le vois, est double: 1. on a un projet qui se disperse, ne trouve pas son rôle, et 2. on a un risque de rigidifier fortement le système GNU/Linux en faisant tout passer par un composant central.
Récemment il m'est arrivé d'avoir cassé mon DBus à la suite d'une bidouille malheureuse: j'ai dû corriger le problème à l'intuition, car journalctl et systemctl ne fonctionnaient plus... Très pratique.

Je me trompe peut-être, mais:

• si le shell est H.S., point de SystemV. dbus serait-il plus susceptible de ne pas fonctionner qu’un shell?
• avec dbus dans le noyau, ça risque d’être plus dur de foutre en l’air dbus, non?

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