systemd répond à des problématiques qui sont apparus avec l'informatique moderne tels que la mobilité, le caractère asynchrone de pas mal de services et périphériques, etc. Des choses dont les anciens outils y répondaient parfois partiellement ou mal car nécessitant des contorsions énormes pour parvenir au résultat souhaité.
Je reprend la question que j’ai posé à Zenitram (parce que mon petit doigt me dit que j’ai plus de chance d’avoir une vraie réponse avec toi...) : uselessd est significativement plus simple que systemd ; quels besoins sont loupés par lui, et sont-ils suffisamment répandus pour justifier de ne pas faire une solution spécifique pour des besoins très spécifiques ?
Tu viens de poser la problématique à laquelle doit répondre un gestionnaire de services moderne. Et je suis assez d’accord avec ça. Bon, mais pourquoi systemd-logind, dbus activation dans le PID 1 ? Pourquoi udev intégré fortement à l’init, alors qu’on avait déjà des gestionnaires d’événements qui pouvaient gérer les événements « périphériques » sans ça ? (d’ailleurs systemd avant l’intégration d’udev le pouvait dans une certaine mesure).
J’entends bien qu’il y ait dans les Linux moderne une certaine complexité qui n’était pas là avant (je pense aux cgroups, namespaces et capabilities principalement), mais c’est loin d’être insurmontable. De fait, ce n’est généralement pas la gestion des cgroups de systemd qui est critiqué quand on critique sa complexité.
De plus tu fais une grosse erreur en pensant « à problème complexe solution complexe ». La notion d’abstraction est très puissante. Un gestionnaire d’événements répond à une problématique fonctionnelle bien plus complexe qu’un gestionnaire de services, mais n’est pas conceptuellement plus complexe (au contraire, c’est plus simple : dans le premier cas on a une définition implicite et extensive de la notion d’événement, pas dans le second cas), et n’a pas à être énormément plus complexe dans l’implémentation.
Je veux bien croire que parfois on ne puisse pas faire autrement que complexifier les choses. Simplement, étant donné les besoins auxquels sont capables de répondre les concurrents de systemd et leur complexité bien inférieure, j’ai un a priori très négatif sur la « nécessité » de cette complexité.
[^] # Re: Du bon et du mauvais
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 5. Dernière modification le 18 février 2015 à 13:12.
Je reprend la question que j’ai posé à Zenitram (parce que mon petit doigt me dit que j’ai plus de chance d’avoir une vraie réponse avec toi...) : uselessd est significativement plus simple que systemd ; quels besoins sont loupés par lui, et sont-ils suffisamment répandus pour justifier de ne pas faire une solution spécifique pour des besoins très spécifiques ?
Tu viens de poser la problématique à laquelle doit répondre un gestionnaire de services moderne. Et je suis assez d’accord avec ça. Bon, mais pourquoi systemd-logind, dbus activation dans le PID 1 ? Pourquoi udev intégré fortement à l’init, alors qu’on avait déjà des gestionnaires d’événements qui pouvaient gérer les événements « périphériques » sans ça ? (d’ailleurs systemd avant l’intégration d’udev le pouvait dans une certaine mesure).
J’entends bien qu’il y ait dans les Linux moderne une certaine complexité qui n’était pas là avant (je pense aux cgroups, namespaces et capabilities principalement), mais c’est loin d’être insurmontable. De fait, ce n’est généralement pas la gestion des cgroups de systemd qui est critiqué quand on critique sa complexité.
De plus tu fais une grosse erreur en pensant « à problème complexe solution complexe ». La notion d’abstraction est très puissante. Un gestionnaire d’événements répond à une problématique fonctionnelle bien plus complexe qu’un gestionnaire de services, mais n’est pas conceptuellement plus complexe (au contraire, c’est plus simple : dans le premier cas on a une définition implicite et extensive de la notion d’événement, pas dans le second cas), et n’a pas à être énormément plus complexe dans l’implémentation.
Je veux bien croire que parfois on ne puisse pas faire autrement que complexifier les choses. Simplement, étant donné les besoins auxquels sont capables de répondre les concurrents de systemd et leur complexité bien inférieure, j’ai un a priori très négatif sur la « nécessité » de cette complexité.