C'est ma lecture : systemd apporte des fonctionnalités dont Gnome a besoin. Alors, au lieu de les réimplémenter en mal, le projet réutilise direct ce qui existe et est maintenu. De plus, sur les OS utilisant systemd, ça évite d'avoir plusieurs implémentations d'un même truc qui ont des comportements différents / incohérents.
À charge des OS n'utilisant pas systemd d'importer juste les briques systemd nécessaires quand c'est possible / modulaire, ou de réimplémenter les fonctionnalités pour les fournir à Gnome.
Ce qui est embêtant c'est que du point de vue de quelqu'un qui maintient un OS sans systemd, des choses fournies par GNOME ne le sont plus, et c'est donc des choses que l'OS doit maintenant fournir.
Mais je ne crois pas qu'il y ait de reproche à faire au projet systemd : il fournit des fonctionnalités liées au cœur du système, que les projets en espace utilisateur choisissent d'utiliser. systemd est un standard de facto, et aussi de plus en plus gros. C'est clair que c'est frustrant pour les gens qui développent des systèmes alternatifs, mais en même temps faut bien que ces fonctionnalités vivent quelque part aussi.
Il y a des fonctionnalités qui doivent vivre quelque part entre le noyau / le système de base et l'environnement de bureau, parce que ces fonctionnalités sont indépendantes de l'environnement de bureau mais trop haut niveau pour être dans le noyau ou dans le système de base. Et cet endroit, aujourd'hui, c'est systemd.
Je ne vois pas trop d'alternative à ça. On pourrait imaginer des briques indépendantes, mais fatalement on voudra certainement faire un paquet plus ou moins standard de ces briques indépendantes, et pourquoi pas unifier un peu les pratiques, mais ça, c'est tout comme systemd.
En réalité, derrière "Gnome dépend de plus en plus de systemd", faudrait lire "Gnome dépend des modules X, Y et Z de systemd, et ces modules sont de plus en plus nombreux". Les alternatives n'ont pas besoin d'être systemd, elles ont besoin de fournir X, Y et Z. Après c'est sûr qu'à force, on se retrouve à réimplémenter systemd au complet et à être piégé dans sa conception, mais j'ai du mal à voir une alternative à ça. Faut bien que les trucs dont dépendent les environnements de bureau vivent quelque part. Ou sinon, chaque environnement doit réimplémenter ces trucs, ça ne me semble pas très malin non plus.
Évidemment ma vision est biaisée, j'utilise (et j'aime bien) systemd, bon je n'utilise pas Gnome par contre. J'utilise KDE et je ne sais pas à quel point KDE dépend de systemd.
Je serais intéressé par lire quelqu'un qui aurait des idées pour éviter les problèmes que tout ça soulève.
# Raisonnable
Posté par raphj (site web personnel) . En réponse au lien GNOME va dépendre de plus en plus de systemd. Évalué à 10. Dernière modification le 11 juin 2025 à 17:08.
C'est ma lecture : systemd apporte des fonctionnalités dont Gnome a besoin. Alors, au lieu de les réimplémenter en mal, le projet réutilise direct ce qui existe et est maintenu. De plus, sur les OS utilisant systemd, ça évite d'avoir plusieurs implémentations d'un même truc qui ont des comportements différents / incohérents.
À charge des OS n'utilisant pas systemd d'importer juste les briques systemd nécessaires quand c'est possible / modulaire, ou de réimplémenter les fonctionnalités pour les fournir à Gnome.
Ce qui est embêtant c'est que du point de vue de quelqu'un qui maintient un OS sans systemd, des choses fournies par GNOME ne le sont plus, et c'est donc des choses que l'OS doit maintenant fournir.
Mais je ne crois pas qu'il y ait de reproche à faire au projet systemd : il fournit des fonctionnalités liées au cœur du système, que les projets en espace utilisateur choisissent d'utiliser. systemd est un standard de facto, et aussi de plus en plus gros. C'est clair que c'est frustrant pour les gens qui développent des systèmes alternatifs, mais en même temps faut bien que ces fonctionnalités vivent quelque part aussi.
Il y a des fonctionnalités qui doivent vivre quelque part entre le noyau / le système de base et l'environnement de bureau, parce que ces fonctionnalités sont indépendantes de l'environnement de bureau mais trop haut niveau pour être dans le noyau ou dans le système de base. Et cet endroit, aujourd'hui, c'est systemd.
Je ne vois pas trop d'alternative à ça. On pourrait imaginer des briques indépendantes, mais fatalement on voudra certainement faire un paquet plus ou moins standard de ces briques indépendantes, et pourquoi pas unifier un peu les pratiques, mais ça, c'est tout comme systemd.
En réalité, derrière "Gnome dépend de plus en plus de systemd", faudrait lire "Gnome dépend des modules X, Y et Z de systemd, et ces modules sont de plus en plus nombreux". Les alternatives n'ont pas besoin d'être systemd, elles ont besoin de fournir X, Y et Z. Après c'est sûr qu'à force, on se retrouve à réimplémenter systemd au complet et à être piégé dans sa conception, mais j'ai du mal à voir une alternative à ça. Faut bien que les trucs dont dépendent les environnements de bureau vivent quelque part. Ou sinon, chaque environnement doit réimplémenter ces trucs, ça ne me semble pas très malin non plus.
Évidemment ma vision est biaisée, j'utilise (et j'aime bien) systemd, bon je n'utilise pas Gnome par contre. J'utilise KDE et je ne sais pas à quel point KDE dépend de systemd.
Je serais intéressé par lire quelqu'un qui aurait des idées pour éviter les problèmes que tout ça soulève.