systemd a résolu de nombreux problèmes lié à l’init historique, mais était-ce vraiment souhaitable qu’il acquière autant de fonctionnalités supplémentaires ?
Il est vrai que vu le nom choisi pour ce truc, « systemd », le périmètre était explicitement annoncé comme tentaculaire dès le départ.
Était-ce souhaitable dans l’absolu ?
Il ne reste plus au projet systemd qu’à accoucher d’une libc et d’une compilateur et on pourra alors parler de distribution Systemd/Linux. _o_
Sur cette question là, en effet, l'article botte en touche avec un "chez moi ça marche, donc c'est super".
C'est quand même fou que le packaging de systemd soit aussi monolithique, alors que pour des projets comme vlc ou qemu—du moins sur Archlinux—on trouve des dizainesde paquets…
Bon je suis d’accord avec toi sur l’aspect gros truc monolithique de systemd. Même si effectivement ça fait le taff (mais je suis loin de tout connaître tellement c’est gros)
Par contre pour ce qui est des paquets et de l’aspect gros truc monolithique tes exemples avec vlc ou qemu sont en fait du même acabit.
Posté par Christophe .
Évalué à 7 (+5/-0).
Dernière modification le 11 juillet 2025 à 19:18.
bah quand même, on n'est pas sur le même niveau de séparation…
systemd:
- les libs de base
- resolvconf (pourquoi en faire un cas particulier ? je l'ignore)
- quasi tout le reste de systemd
- les tests
- ukify, dont j'ignorais l'existence même dans systemd jusqu'à aujourd'hui
vlc:
- les libs de base
- la partie CLI
- les GUIs, une par paquet
- chaque plugin a sont petit paquet
- des groupes de plugins sont aussi proposés pour simplifier
Il n'y a pas photo: dans un cas on installe quasiment tout chez tout le monde, dans l'autre on peut piocher selon les besoins.
NB: je viens de découvrir que Debian fait une séparation assez sympa des paquets systemd:
- une base commune pour la gestion des services,timers,sockets,etc
- gestion du boot (UEFI)
- gestion des containers
- gestion des HOME "portables" (systemd-homed)
- repartitionnement (systemd-repart)
- DNS resolver
- userdb
- NTP
- gestion du chiffrement
Voilà, là on a un effort de séparation, on pioche dans ce qu'on a besoin. J'aimerais que Archlinux s'en inspire !
Oui en effet. C’est donc bien l’OS (ici Arch ou Debian) qui décide comment découper un projet monolithique en paquets.
Arch découpe peu Systemd, Debian le découpe plus. Mais les sources sont bien monolithiques. Idem pour vlc, tu ne compiles par un plugin vlc après la compilation de base. C’est juste le packageur de l’OS qui décide de découper les fichiers produits.
Tu ne peux pas partir sur le nombre de paquets pour définir la modularité d'un logiciel.
Par exemple le noyau Linux est monolithique d'un point de vue architecture du noyau, mais tu peux avoir des milliers de modules et techniquement on peut les fournir individuellement dans un paquet à part même si personne ne le fait car le ratio effort / utilité est faible.
Pour systemd c'est pareil, quand tu fais ton firmware avec tu as le moyen de compiler ce dont tu as besoin et tu as des paquets plus fins que ce que ArchLinux propose. Sans doute parce que pour ArchLinux c'est plus simple de faire ainsi.
Chaque distro et mainteneur a ses spécificités à cet égard.
Je dirais que vu le but d’un systemd la comparaison avec vlc ou qemu me semble pas hyper pertinente.
En fait ce que tu veux dire c’est qu’il devrait être possible d’utiliser des bouts de systemd, à commencer par l’init, sans avoir à se résoudre obligatoirement à utiliser tout le reste du bousin ?
J’avais jamais vu ça comme ça mais en effet, peut-être qu’un packaging plus fin aurait/pourrait rendre le tout moins invasif.
Il aurait été préférable de mettre l'article original en lien plutôt qu'OSNews…
Je pense que le ressenti de l'auteur est commun à de très nombreux adminsys : systemd a amélioré la gestion des services et grandement simplifié la configuration.
Sur les autres aspects : journald, timerd, etc. c'est plus discutable. Je ne sais toujours pas par exemple, comment avoir des rotations différenciées des logs par service. Ni comment envoyer simplement* un courriel à l'administrateur lors de l'exécution d'une tâche planifiée.
Très honnêtement ce qui à changé ma vie d'admin c'est pas systemd. C'est kubernetes. Et pas genre à la marge. Totalement. Jamais on pourrait gérer des centaines de postgresql, des milliers d'applications web sans ça. Et on est juste 5. On gère plus d'équipements à 5 tech et deux chef de projet/service manager que à 40 dans mon ancien taf. Par contre c'est vrai qu'on a moins de clients mais des clients qui ont bien plus de prod. Là où darty.fr et bien c'est une prod. On a des clients qui en ont des centaines.
Dans ma vie de dev de système embarqué Linux, systemd a clairement changé les choses.
ça répond à des tas de besoins qui m'auraient pris des années soit à développer moi-même, soit à intégrer des briques existantes qui ne sont pas faites pour aller ensemble.
Alors oui, il a ses limites. On n'utilise pas son client NTP parce qu'on a besoin de se synchroniser avec un récepteur GPS et de faire d'autres trucs tordus. On a eu un peu de mal à mettre en place certaines dépendances compliquées.
Mais dans l'ensemble, ça relance les services quand ils plantent, on récupère les logs dans un format facile à exploiter sans avoir à mettre en place un service rsyslog séparé, la gestion des dépendances marche toute seule, et surtout, la documentation est très complète et répond à énormément de questions.
Et puis, comme c'est un système embarqué, on compile tout nous-mêmes. On peut donc désactiver les parties qui ne nous intéressent pas si vraiment ça pose problème (spoiler alert: on a jamais eu besoin de le faire). La modularité apporte de la complexité dont on se passe bien dans ce cas ci.
Un problème de systemd dans l'embarqué, c'est que sur du très vieux matos où on n'a qu'un très vieux Linux, on ne peut pas utiliser de systemd récent, ou du moins ça peut devenir assez compliqué.
Posté par da_kal .
Évalué à 2 (+1/-0).
Dernière modification le 11 juillet 2025 à 13:46.
Ça signifie que s6 serait également en mesure de changer ta vie une nouvelle fois, quel bonheur! La gestion des logs, des dépendances, le redémarrage auto du service (à toi de le spécifier). En revanche, la doc .. c'est une aventure.
K8s me change la vie (en mieux) sur la gestion de l'infra de ma boîte, mais je reste hésitant pour les SGBD, qui tournent encore sur des VPS classiques.
Posté par Psychofox (Mastodon) .
Évalué à 5 (+2/-0).
Dernière modification le 12 juillet 2025 à 14:52.
Bon tout ça est à pondérer avec la qualité de la solution utilisée une fois les tests de pannes réellement effectué. J'ai utilisé par exemple kubedb il y a quelques année (je crois qu'il n'y avait pas de charts helm dispos) et il n'était clairement pas près à ce moment là. Oui ton cluster était créé mais parfois la réplication n'avait pas lieu et en cas de network split, d'arrêt de noeud et de changement de node primaire…tu te retrouvais avec une base soudainement vide et il fallait la réinitialiser depuis le dernier bon snapshot.
Kubernetes ? Tu veux dire system-containerd et systemd-podctl ?
Je raconte n’imp’ à cette heure tardive…
M’enfin depuis que par inadvertance je me suis retrouvé avec un system-bootd à la place de GRUB je m’attends à tout en terme de system-serviced et systemd-toolctl.
Je suis entièrement d’accord avec toi. Et je pense qu’en effet, et c’est un des intérêt fondamental du libre : si techniquement c’est voué à disparaître/être remplacé, alors rien n’interdit/n’empêchera que ce le soit.
Tout comme jadis, s’il n’y avait pas eu d’intérêt technique à systemd, il n’aurait pas vu le jour.
Je ne sais pas ce qu'est souhaitable mais dans mon cas de serveur personnel, j'essaye de limiter au maximum la douleur de la maintenance qu'est de revenir 6 mois après et de devoir réapprendre la configuration de tel ou tel outil, et il faut bien le dire, les fichiers de configuration ini sont plutôt plaisant que ce soit systemd, networkd ou même quadlet (extérieur au projet).
# C’est bien, mais !
Posté par Marotte ⛧ . Évalué à 9 (+13/-7).
systemd a résolu de nombreux problèmes lié à l’init historique, mais était-ce vraiment souhaitable qu’il acquière autant de fonctionnalités supplémentaires ?
Il est vrai que vu le nom choisi pour ce truc, « systemd », le périmètre était explicitement annoncé comme tentaculaire dès le départ.
Était-ce souhaitable dans l’absolu ?
Il ne reste plus au projet systemd qu’à accoucher d’une libc et d’une compilateur et on pourra alors parler de distribution Systemd/Linux. _o_
[^] # Re: C’est bien, mais !
Posté par Christophe . Évalué à 9 (+8/-1).
Sur cette question là, en effet, l'article botte en touche avec un "chez moi ça marche, donc c'est super".
C'est quand même fou que le packaging de systemd soit aussi monolithique, alors que pour des projets comme vlc ou qemu—du moins sur Archlinux—on trouve des dizaines de paquets…
[^] # Re: C’est bien, mais !
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Bon je suis d’accord avec toi sur l’aspect gros truc monolithique de systemd. Même si effectivement ça fait le taff (mais je suis loin de tout connaître tellement c’est gros)
Par contre pour ce qui est des paquets et de l’aspect gros truc monolithique tes exemples avec
vlcouqemusont en fait du même acabit.Voici le lien vers le
PKGBUILDsource desystemd: https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/main/PKGBUILDOn voit que ça build une fois et ensuite ça fait plein de paquets en plaçant les fichiers au bon endroit.
Pour les néophytes d’un
PKGBUILDc’est les partiespackage_qqch.À comparer avec :
- celui de
vlc: https://gitlab.archlinux.org/archlinux/packaging/packages/vlc/-/blob/main/PKGBUILD- celui de
qemu: https://gitlab.archlinux.org/archlinux/packaging/packages/qemu/-/blob/main/PKGBUILDC’est un peu le même style. C’est même pire pour
vlcetqemuque poursystemd…Enfin c’était pas pour te contredire sur le fond, mais voilà
vlcetqemuc’est pas mieux (mais ça tourne pas en root sur le PID 1)[^] # Re: C’est bien, mais !
Posté par Christophe . Évalué à 7 (+5/-0). Dernière modification le 11 juillet 2025 à 19:18.
bah quand même, on n'est pas sur le même niveau de séparation…
systemd:
- les libs de base
- resolvconf (pourquoi en faire un cas particulier ? je l'ignore)
- quasi tout le reste de systemd
- les tests
- ukify, dont j'ignorais l'existence même dans systemd jusqu'à aujourd'hui
vlc:
- les libs de base
- la partie CLI
- les GUIs, une par paquet
- chaque plugin a sont petit paquet
- des groupes de plugins sont aussi proposés pour simplifier
Il n'y a pas photo: dans un cas on installe quasiment tout chez tout le monde, dans l'autre on peut piocher selon les besoins.
NB: je viens de découvrir que Debian fait une séparation assez sympa des paquets systemd:
- une base commune pour la gestion des services,timers,sockets,etc
- gestion du boot (UEFI)
- gestion des containers
- gestion des HOME "portables" (systemd-homed)
- repartitionnement (systemd-repart)
- DNS resolver
- userdb
- NTP
- gestion du chiffrement
Voilà, là on a un effort de séparation, on pioche dans ce qu'on a besoin. J'aimerais que Archlinux s'en inspire !
[^] # Re: C’est bien, mais !
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Oui en effet. C’est donc bien l’OS (ici Arch ou Debian) qui décide comment découper un projet monolithique en paquets.
Arch découpe peu Systemd, Debian le découpe plus. Mais les sources sont bien monolithiques. Idem pour vlc, tu ne compiles par un plugin vlc après la compilation de base. C’est juste le packageur de l’OS qui décide de découper les fichiers produits.
[^] # Re: C’est bien, mais !
Posté par Renault (site web personnel) . Évalué à 7 (+4/-0).
Tu ne peux pas partir sur le nombre de paquets pour définir la modularité d'un logiciel.
Par exemple le noyau Linux est monolithique d'un point de vue architecture du noyau, mais tu peux avoir des milliers de modules et techniquement on peut les fournir individuellement dans un paquet à part même si personne ne le fait car le ratio effort / utilité est faible.
Pour systemd c'est pareil, quand tu fais ton firmware avec tu as le moyen de compiler ce dont tu as besoin et tu as des paquets plus fins que ce que ArchLinux propose. Sans doute parce que pour ArchLinux c'est plus simple de faire ainsi.
Chaque distro et mainteneur a ses spécificités à cet égard.
[^] # Re: C’est bien, mais !
Posté par Marotte ⛧ . Évalué à 4 (+1/-0).
Je dirais que vu le but d’un systemd la comparaison avec vlc ou qemu me semble pas hyper pertinente.
En fait ce que tu veux dire c’est qu’il devrait être possible d’utiliser des bouts de systemd, à commencer par l’init, sans avoir à se résoudre obligatoirement à utiliser tout le reste du bousin ?
J’avais jamais vu ça comme ça mais en effet, peut-être qu’un packaging plus fin aurait/pourrait rendre le tout moins invasif.
[^] # Re: C’est bien, mais !
Posté par Voltairine . Évalué à 10 (+8/-0).
Il aurait été préférable de mettre l'article original en lien plutôt qu'OSNews…
Je pense que le ressenti de l'auteur est commun à de très nombreux adminsys : systemd a amélioré la gestion des services et grandement simplifié la configuration.
Sur les autres aspects : journald, timerd, etc. c'est plus discutable. Je ne sais toujours pas par exemple, comment avoir des rotations différenciées des logs par service. Ni comment envoyer simplement* un courriel à l'administrateur lors de l'exécution d'une tâche planifiée.
--
(*) aussi simplement qu'avec cron
[^] # Re: C’est bien, mais !
Posté par oau . Évalué à 6 (+5/-0).
Très honnêtement ce qui à changé ma vie d'admin c'est pas systemd. C'est kubernetes. Et pas genre à la marge. Totalement. Jamais on pourrait gérer des centaines de postgresql, des milliers d'applications web sans ça. Et on est juste 5. On gère plus d'équipements à 5 tech et deux chef de projet/service manager que à 40 dans mon ancien taf. Par contre c'est vrai qu'on a moins de clients mais des clients qui ont bien plus de prod. Là où darty.fr et bien c'est une prod. On a des clients qui en ont des centaines.
[^] # Re: C’est bien, mais !
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+10/-0).
Dans ma vie de dev de système embarqué Linux, systemd a clairement changé les choses.
ça répond à des tas de besoins qui m'auraient pris des années soit à développer moi-même, soit à intégrer des briques existantes qui ne sont pas faites pour aller ensemble.
Alors oui, il a ses limites. On n'utilise pas son client NTP parce qu'on a besoin de se synchroniser avec un récepteur GPS et de faire d'autres trucs tordus. On a eu un peu de mal à mettre en place certaines dépendances compliquées.
Mais dans l'ensemble, ça relance les services quand ils plantent, on récupère les logs dans un format facile à exploiter sans avoir à mettre en place un service rsyslog séparé, la gestion des dépendances marche toute seule, et surtout, la documentation est très complète et répond à énormément de questions.
Et puis, comme c'est un système embarqué, on compile tout nous-mêmes. On peut donc désactiver les parties qui ne nous intéressent pas si vraiment ça pose problème (spoiler alert: on a jamais eu besoin de le faire). La modularité apporte de la complexité dont on se passe bien dans ce cas ci.
[^] # Re: C’est bien, mais !
Posté par Christophe . Évalué à 5 (+3/-0).
Un problème de systemd dans l'embarqué, c'est que sur du très vieux matos où on n'a qu'un très vieux Linux, on ne peut pas utiliser de systemd récent, ou du moins ça peut devenir assez compliqué.
[^] # Re: C’est bien, mais !
Posté par da_kal . Évalué à 2 (+1/-0). Dernière modification le 11 juillet 2025 à 13:46.
Ça signifie que s6 serait également en mesure de changer ta vie une nouvelle fois, quel bonheur! La gestion des logs, des dépendances, le redémarrage auto du service (à toi de le spécifier). En revanche, la doc .. c'est une aventure.
[^] # Re: C’est bien, mais !
Posté par Letho . Évalué à 4 (+3/-1).
Petite question en passant :
K8s me change la vie (en mieux) sur la gestion de l'infra de ma boîte, mais je reste hésitant pour les SGBD, qui tournent encore sur des VPS classiques.
Pas de souci particulier avec Postgres ?
[^] # Re: C’est bien, mais !
Posté par oau . Évalué à 2 (+2/-1).
Aucun, c'est tellement simple. 4 lignes de yaml et j'ai un cluster, répliqué, backupé, avec les wal dans le s3, du pitr, le monitoring. La totale.
[^] # Re: C’est bien, mais !
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 12 juillet 2025 à 14:52.
Bon tout ça est à pondérer avec la qualité de la solution utilisée une fois les tests de pannes réellement effectué. J'ai utilisé par exemple kubedb il y a quelques année (je crois qu'il n'y avait pas de charts helm dispos) et il n'était clairement pas près à ce moment là. Oui ton cluster était créé mais parfois la réplication n'avait pas lieu et en cas de network split, d'arrêt de noeud et de changement de node primaire…tu te retrouvais avec une base soudainement vide et il fallait la réinitialiser depuis le dernier bon snapshot.
[^] # Re: C’est bien, mais !
Posté par Letho . Évalué à 3 (+1/-0).
C'est sûr que présenté ainsi, ça laisser rêveur :)
Vous utilisez quel opérateur ?
[^] # Re: C’est bien, mais !
Posté par oau . Évalué à 2 (+1/-0).
Pour moi après avoir utilisé stolon puis celui de Zalando j'en suis a cloud native pg. C'est le plus abouti pour le moment.
[^] # Re: C’est bien, mais !
Posté par Marotte ⛧ . Évalué à 5 (+2/-0).
Kubernetes ? Tu veux dire system-containerd et systemd-podctl ?
Je raconte n’imp’ à cette heure tardive…
M’enfin depuis que par inadvertance je me suis retrouvé avec un system-bootd à la place de GRUB je m’attends à tout en terme de system-serviced et systemd-toolctl.
[^] # Re: C’est bien, mais !
Posté par GnunuX (site web personnel) . Évalué à 10 (+8/-0).
Ce n'est une question technique.
Techniquement Systemd fonctionne et a résolu tout un tas de problèmes de façon élégante. A court terme la réponse est donc "oui".
Si la réponse devient "non" dans le futur, il y aura une solution autre qui émergera.
[^] # Re: C’est bien, mais !
Posté par Marotte ⛧ . Évalué à 3 (+0/-0).
Je suis entièrement d’accord avec toi. Et je pense qu’en effet, et c’est un des intérêt fondamental du libre : si techniquement c’est voué à disparaître/être remplacé, alors rien n’interdit/n’empêchera que ce le soit.
Tout comme jadis, s’il n’y avait pas eu d’intérêt technique à systemd, il n’aurait pas vu le jour.
[^] # Re: C’est bien, mais !
Posté par inkey . Évalué à 1 (+0/-0).
Je ne sais pas ce qu'est souhaitable mais dans mon cas de serveur personnel, j'essaye de limiter au maximum la douleur de la maintenance qu'est de revenir 6 mois après et de devoir réapprendre la configuration de tel ou tel outil, et il faut bien le dire, les fichiers de configuration ini sont plutôt plaisant que ce soit systemd, networkd ou même quadlet (extérieur au projet).
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.