Hé bien tous ces trucs viennent avec systemd mais ne font pas partie du binaire systemd, tout comme Linux est livré avec tout en tas de pilotes qui ne sont que des modules.
Et si Linux incluait un module remplaçant mail ? un client ftp ? (minimaliste, bien sûr, enfin, au début...)
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...
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à.
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.
[^] # Re: Description de systemd ?
Posté par Christophe . En réponse à la dépêche systemd versions 212 à 215. Évalué à 5.
Et si Linux incluait un module remplaçant mail ? un client ftp ? (minimaliste, bien sûr, enfin, au début...)
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...
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à.
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.
(et merde, on est seulement lundi...)