Moi, j'ai rien contre systemd. Mais je comprends complètement celles et ceux qui n'en veulent pas. Et puis la monoculture, c'est pas top.
Donc quand je vois :
So what should distros without systemd do?
First, consider using GNOME with systemd.
Je me dis que bon… c'est pas très sympa. C'est pragmatique, c'est sûr. Et il reste plein d'autres environnements très chouettes, comme Xfce ou KDE, bien que je ne sache pas si ce dernier dépende de systemd.
Dans la vraie vie, beaucoup de distributions utilise systemd par défaut cependant.
Posté par da_kal .
Évalué à 3 (+2/-0).
Dernière modification le 12 juin 2025 à 13:40.
Si cette aventure suit le chemin habituel, les deux mondes vont probablement un peu plus vite qu'avant de séparer coté compatibilité. GNOME c'est une sacré brique logicielle. Ça va faire mal et reproduire une nouvelle génération d'anti-systemd, super.
Pas sur qu'elogind soit aussi la solution la plus pérenne pour BSD. Sur le long terme. La question se pose aujourd'hui pour GNOME mais demain quid des autres qui ont des dépendances trop fortes ?
C'est cyclique, on va retourner aux sources comme au bon vieux temps ou nos systèmes communautaires demandaient un peu de sueur pour être utiliser. youpi!
C'est ce que l'on reproche à SystemD. Le problème n'est pas vraiment Gnome mais SystemD qui pousse à utiliser ses services plutôt que ceux standard… Évidemment incompatibles entre eux.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Donc Gnome choisit de réutiliser un truc (ce qui élimine du code redondant, donc possiblement des bugs), et tu déduis que le problème n'est pas Gnome mais le truc qu'ils ont choisi. Ils pouvaient juste… ne pas le choisir ? Donc ils ont sûrement fait la balance bénéfice risque et tranché en fonction. Le post en lien l'explique assez bien, ça marchait avec des hacks pas très propres : "GDM relies on legacy behaviors and straight-up hacks to get this working."
Bah ok, c'est plus simple. Mais ça te gêne pas que du coup ce soit beaucoup plus compliqué d'installer Gnome s'il n'y a pas SystemD…
Tant qu'à faire, installe Windows, ce sera plus simple.
Ce n'est pas un argument valable.
Je n'ai pas étudié le problème mais Une solution serait peut-être de faire un package (projet indépendante), interface qui gère cette complexité que ce soit SystemD ou autres.
PS : il existe un projet qui donne les fonctionnalités (autres qu'init) de SystemD sans SystemD.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Les logiciels ont des dépendances. Les développeurs choisissent leurs dépendances. Ce que je dis c'est qu'on ne peut pas reprocher à systemd d'avoir été choisi par Gnome. Le choix a été fait par Gnome. Donc quand tu dis
Le problème n'est pas vraiment Gnome mais SystemD
ça n'a pas de sens. C'est comme reprocher à dbus le fait que Firefox dépende de lui. Et non ça ne me gêne pas, je fais juste confiance aux devs pour choisir les briques qui conviennent. Et quand une brique ne me convient pas (Wayland par exemple) je ne prends pas le logiciel qui en dépend (Sway par exemple).
on ne peut pas reprocher à systemd d'avoir été choisi par Gnome
C'est exactement, ce que je fais, je ne reproche pas a Gnome son choix de SystemD, mais à SystemD, son monolithisme (non UNIX, non KISS). Je ne reproche même pas a SystemD ses choix techniques, mais ses choix d'architecture en terme de projets. Je veux que le système de boot qui remplace InitV, ne remplace pas tout mais qu'il dépendent de sous projets. De cette manière, ou pourra avoir un autre système de boot qui dépendent de ces même sous-projets (ou non). Une séparation et indépendance des sous-projets (Avec une interface commune et standard).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Posté par Psychofox (Mastodon) .
Évalué à 5 (+2/-0).
Dernière modification le 13 juin 2025 à 13:46.
Il me semble que systemd n'est pas si monolithique que ça puisque les distros choisissent les parties qu'elles utilisent. Sur ma machine j'ai genre 8 démons différents qui tournent. Ce n'est pas vraiment ce que j'appelle monolithique. Tu peux utiliser systemd sans systemd-resolved par exemple.
Le seule problème c'est que si tu veux maintenir un port de Gnome pour un système qui n'a pas, par exemple logind, ben tu dois utiliser ou développer et maintenir un remplaçant. Après systemd est libre donc même sans utiliser systemd on a les clés pour maintenir des API compatibles.
C'est essentiellement un problème de main d'oeuvre pour les systèmes linux qui ne veulent pas utiliser systemd ou les systèmes BSD. Après Gnome n'est pas non plus obligatoire, il y a plein d'autres bureaux disponibles.
Posté par raphj .
Évalué à 10 (+11/-2).
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.
En fait pour couper court à la critique, il suffirait de faire des paquets séparés pour les différentes thématiques du projet systemd: boot, init, session, container… Ici, Gnome utilise plus de modules liés à la gestion d'une session, ce qu'on peut comprendre. Ce qui est déjà plus frustrant, c'est que ça implique d'utiliser tout le reste de systemd.
A 100% d'accord. Je sais qu'il y a une initiative en ce sens… Le problème c'est qu'elle manque de soutiens. SystemD devrait en être le premier soutiens.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
PS: Moi aussi j'utilise SystemD, et je le trouve très bien. Là n'est pas le problème. Il fallait refondre le system de boot. On est d'accord. Le problème est ailleurs. Dans son architecture en terme de paquets.
C'est comme Windows VS Linux. Windows fonctionne très bien mais pas sans interface graphique. Linux est meilleur car on peut ne pas mettre d'interface graphique. Et c'est tellement mieux pour tous les environnement ou on a pas besoin de cette consommation de ressources.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Pourquoi pas, mais un peu forcé
Posté par Glandos . Évalué à 6 (+4/-0).
Moi, j'ai rien contre systemd. Mais je comprends complètement celles et ceux qui n'en veulent pas. Et puis la monoculture, c'est pas top.
Donc quand je vois :
Je me dis que bon… c'est pas très sympa. C'est pragmatique, c'est sûr. Et il reste plein d'autres environnements très chouettes, comme Xfce ou KDE, bien que je ne sache pas si ce dernier dépende de systemd.
Dans la vraie vie, beaucoup de distributions utilise systemd par défaut cependant.
[^] # Re: Pourquoi pas, mais un peu forcé
Posté par Voltairine . Évalué à 5 (+3/-0). Dernière modification le 11 juin 2025 à 17:32.
KDE est dépendant de systemd logind depuis un bon moment (cf. le commentaire #2 sur ce signalement de bogue de 2016.
Et probablement XFCE aussi. Si l'on veut s'en passer il faut utiliser elogind.
[^] # Re: Pourquoi pas, mais un peu forcé
Posté par da_kal . Évalué à 2 (+1/-0).
Ou seatd + consolekit
Toutefois, Steam ne fonctionne pas correctement sans elogind.
[^] # Re: Pourquoi pas, mais un peu forcé
Posté par Lutin . Évalué à 4 (+2/-0).
Pas sympa d'oublier tous les *BSD.
[^] # Re: Pourquoi pas, mais un peu forcé
Posté par da_kal . Évalué à 3 (+2/-0). Dernière modification le 12 juin 2025 à 13:40.
Si cette aventure suit le chemin habituel, les deux mondes vont probablement un peu plus vite qu'avant de séparer coté compatibilité. GNOME c'est une sacré brique logicielle. Ça va faire mal et reproduire une nouvelle génération d'anti-systemd, super.
Pas sur qu'elogind soit aussi la solution la plus pérenne pour BSD. Sur le long terme. La question se pose aujourd'hui pour GNOME mais demain quid des autres qui ont des dépendances trop fortes ?
C'est cyclique, on va retourner aux sources comme au bon vieux temps ou nos systèmes communautaires demandaient un peu de sueur pour être utiliser. youpi!
# rah
Posté par abriotde (site web personnel, Mastodon) . Évalué à -8 (+3/-12).
C'est ce que l'on reproche à SystemD. Le problème n'est pas vraiment Gnome mais SystemD qui pousse à utiliser ses services plutôt que ceux standard… Évidemment incompatibles entre eux.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: rah
Posté par Faya . Évalué à 5 (+5/-2).
Donc Gnome choisit de réutiliser un truc (ce qui élimine du code redondant, donc possiblement des bugs), et tu déduis que le problème n'est pas Gnome mais le truc qu'ils ont choisi. Ils pouvaient juste… ne pas le choisir ? Donc ils ont sûrement fait la balance bénéfice risque et tranché en fonction. Le post en lien l'explique assez bien, ça marchait avec des hacks pas très propres : "GDM relies on legacy behaviors and straight-up hacks to get this working."
Tant qu'on y est, et sur le même sujet, tu as oublié de donner un vrai exemple de "systemd intègre tout, on peut pas debugger"
[^] # Re: rah
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+2/-2).
Bah ok, c'est plus simple. Mais ça te gêne pas que du coup ce soit beaucoup plus compliqué d'installer Gnome s'il n'y a pas SystemD…
Tant qu'à faire, installe Windows, ce sera plus simple.
Ce n'est pas un argument valable.
Je n'ai pas étudié le problème mais Une solution serait peut-être de faire un package (projet indépendante), interface qui gère cette complexité que ce soit SystemD ou autres.
PS : il existe un projet qui donne les fonctionnalités (autres qu'init) de SystemD sans SystemD.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: rah
Posté par Faya . Évalué à 3 (+1/-0).
Les logiciels ont des dépendances. Les développeurs choisissent leurs dépendances. Ce que je dis c'est qu'on ne peut pas reprocher à systemd d'avoir été choisi par Gnome. Le choix a été fait par Gnome. Donc quand tu dis
ça n'a pas de sens. C'est comme reprocher à dbus le fait que Firefox dépende de lui. Et non ça ne me gêne pas, je fais juste confiance aux devs pour choisir les briques qui conviennent. Et quand une brique ne me convient pas (Wayland par exemple) je ne prends pas le logiciel qui en dépend (Sway par exemple).
[^] # Re: rah
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+2/-3).
C'est exactement, ce que je fais, je ne reproche pas a Gnome son choix de SystemD, mais à SystemD, son monolithisme (non UNIX, non KISS). Je ne reproche même pas a SystemD ses choix techniques, mais ses choix d'architecture en terme de projets. Je veux que le système de boot qui remplace InitV, ne remplace pas tout mais qu'il dépendent de sous projets. De cette manière, ou pourra avoir un autre système de boot qui dépendent de ces même sous-projets (ou non). Une séparation et indépendance des sous-projets (Avec une interface commune et standard).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: rah
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 13 juin 2025 à 13:46.
Il me semble que systemd n'est pas si monolithique que ça puisque les distros choisissent les parties qu'elles utilisent. Sur ma machine j'ai genre 8 démons différents qui tournent. Ce n'est pas vraiment ce que j'appelle monolithique. Tu peux utiliser systemd sans systemd-resolved par exemple.
/usr/lib/systemd/systemd-journald
/usr/lib/systemd/systemd-userdbd
/usr/lib/systemd/systemd-udevd
/usr/lib/systemd/systemd-oomd
/usr/lib/systemd/systemd-resolved
/usr/lib/systemd/systemd-homed
/usr/lib/systemd/systemd-logind
/usr/lib/systemd/systemd-machined
Le seule problème c'est que si tu veux maintenir un port de Gnome pour un système qui n'a pas, par exemple logind, ben tu dois utiliser ou développer et maintenir un remplaçant. Après systemd est libre donc même sans utiliser systemd on a les clés pour maintenir des API compatibles.
C'est essentiellement un problème de main d'oeuvre pour les systèmes linux qui ne veulent pas utiliser systemd ou les systèmes BSD. Après Gnome n'est pas non plus obligatoire, il y a plein d'autres bureaux disponibles.
[^] # Re: rah
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Un autre exemple d'une autre config (pas userdbd & homed mais timesync et gnome, qui utilise déjà systemd):
[^] # Re: rah
Posté par Pol' uX (site web personnel) . Évalué à 3 (+1/-0).
On sait que tu es habitué à affirmer des choses fausses, mais je t'invite à lire le premier item de cette liste : http://0pointer.de/blog/projects/the-biggest-myths.html
Adhérer à l'April, ça vous tente ?
# Raisonnable
Posté par raphj . Évalué à 10 (+11/-2). 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.
[^] # Re: Raisonnable
Posté par Christophe . Évalué à 5 (+3/-0).
En fait pour couper court à la critique, il suffirait de faire des paquets séparés pour les différentes thématiques du projet systemd: boot, init, session, container… Ici, Gnome utilise plus de modules liés à la gestion d'une session, ce qu'on peut comprendre. Ce qui est déjà plus frustrant, c'est que ça implique d'utiliser tout le reste de systemd.
[^] # Re: Raisonnable
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3 (+2/-0).
A 100% d'accord. Je sais qu'il y a une initiative en ce sens… Le problème c'est qu'elle manque de soutiens. SystemD devrait en être le premier soutiens.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Raisonnable
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3 (+2/-0).
PS: Moi aussi j'utilise SystemD, et je le trouve très bien. Là n'est pas le problème. Il fallait refondre le system de boot. On est d'accord. Le problème est ailleurs. Dans son architecture en terme de paquets.
C'est comme Windows VS Linux. Windows fonctionne très bien mais pas sans interface graphique. Linux est meilleur car on peut ne pas mettre d'interface graphique. Et c'est tellement mieux pour tous les environnement ou on a pas besoin de cette consommation de ressources.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.