Salut, Nal' !
Je vais encore te parler de systemd, et je compte sur toi pour ne pas troller : on aime ou on aime pas systemd, là n'est pas le débat.
Le projet Busybox a récemment décidé de supprimer le support de systemd suite à un désaccord avec les développeurs de système d'init d'après ce qu'on peut comprendre du commentaire de commit, dont voici une traduction (certainement pas la meilleure qu'il soit) rédigée par votre serviteur :
Les développeurs de systemd ne semblent pas souhaiter coopérer gentiment avec le reste du monde. Par conséquent il n'y a aucune raison pour que le reste du monde coopère avec eux.
Je ne suis pas expert en la matière, ainsi le contenu du commit ne m'aide pas vraiment à comprendre le problème, toutefois le premier commentaire sur ce post parle juste de la suppression de quelque chose d'optionnel (qui permet de communiquer par socket avec systemd sans passer par libsystemd, d'après ce que je comprends).
Si tu as plus d'informations, je serais heureux d'en savoir plus : qu'est-ce que ce commit implique vraiment en terme de support de systemd par Busybox ? Les deux pourrons toujours fonctionner ensemble ?
Merci d'avance si tu as des détails à me donner sur cette informations !
# adresse incorrecte
Posté par François GUÉRIN (Mastodon) . Évalué à 1.
L'adresse ves le site de busybox est incorrecte. Si quelqu'un peut corriger ?
[^] # Re: adresse incorrecte
Posté par smumu . Évalué à 1.
Effectivement, le "http://" en double m'a échappé … Mille excuses !
[^] # Re: adresse incorrecte
Posté par ZeroHeure (site web personnel) . Évalué à 1.
Corrigé, merci.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# impact: syslog
Posté par purplepsycho . Évalué à 1.
Bonjour,
J'ai parcouru un peu le commit, ça semble « seulement » lié à syslogd.
Je dirai donc :
Je penche pour la première option.
# Musl / uclibc
Posté par karteum59 . Évalué à 10. Dernière modification le 13 novembre 2015 à 14:30.
Rappelons, comme je le disais ici, que
(N.B. quand je dis "refuser de résoudre le problème", je ne blame pas le fait qu'il ne s'investisse pas personnellement dans un problème qui ne le concerne/motive pas, mais surtout qu'il refuse les patchs qui sont destinés à résoudre le problème). Pour du Linux embarqué e.g. OpenWRT (mais pas seulement, cf. Alpine), uclibc et musl sont particulièrement appropriées, et Busybox fonctionne essentiellement dans ce type d'environnement donc cette décision ne me semble pas surprenante.
[^] # Re: Musl / uclibc
Posté par Frédéric COIFFIER . Évalué à 4.
Mais dans ce type d'environnement embarqué, est-ce que systemd se justifie ?
Sur Buildroot/Yocto, on s'en passe encore (même s'il est installable).
[^] # Re: Musl / uclibc
Posté par xcomcmdr . Évalué à 7.
On dirait que oui, surtout pour le support des watchdogs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Musl / uclibc
Posté par Aissen . Évalué à 1.
Et c’est possible de faire la même chose sans systemd.
Je pense que c’est une tempête dans un verre d’eau ici, surtout étant donné l’étendue du "support" de systemd dans busybox (vous pouvez voir le commit, il ne supprime pas grand chose).
[^] # Re: Musl / uclibc
Posté par xcomcmdr . Évalué à 1.
Bien sûr que c'est possible ! C'est ce qu'on faisait avant.
Mais si tu avais lu les liens, les avantages de systemd sont :
- tu n'a pas à rajouter le support des watchdogs toi-même
- ou à intégrer une solution bancale
- les autres points que résout systemd sont aussi bons pour l'embarqué (démarrage en parallèle, gestion propre des dépendances, etc…)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Musl / uclibc
Posté par Aissen . Évalué à 2.
Je n’ai pas dit le contraire; merci des détails supplémentaires.
[^] # Re: Musl / uclibc
Posté par Kerro . Évalué à 10.
Dans 2 ou 3 ans il sera compliqué de faire fonctionner quelque chose sans systemd, car de plus en plus de choses vont dépendre indirectement de systemd. Et pas forcément pour de bonnes raisons.
C'est pourquoi il est important que systemd fonctionne correctement ailleurs que sur la machine de son auteur principal.
[^] # Re: Musl / uclibc
Posté par ookaze . Évalué à 9.
Et il a parfaitement raison de refuser ces patchs.
Ce qui est demandé par ces distributions n'a aucun sens, et c'est évident à n'importe qui comprenant de quoi il s'agit.
Accepter des patches de ce genre, cela signifie tout simplement d'accepter de maintenir une sorte de fork de glibc dans systemd. Parce que ces patches consistent à maintenir des fonctionnalités manquantes de musl-libc (par exemple) par rapport à glibc, dans systemd.
systemd n'a pas la vocation d'être une libc, c'est à musl-libc qu'il faut envoyer ces patches évidemment. Et bien sûr cela a été fait, mais qu'ont répondu ces différents libc ? Elles ont refusé !
Et évidemment, on essaie de porter le blâme sur systemd.
Pour le système de logs de systemd dans BusyBox, cela n'avait de toutes façons aucun sens, systemd venant avec son système de logs. En fait cela ne change rien en pratique.
[^] # Re: Musl / uclibc
Posté par Moonz . Évalué à 10.
Ce ne sont pas des fonctionnalités manquantes. musl-libc (et autres) ont vocation à implémenter la librairie standard du C, et uniquement ceci. Les spécificités Linux/GNU sont hors de l’objectif du projet.
La question c’est surtout pourquoi les spécificités linux se retrouvent dans la glibc plutôt que dans une liblinux.
[^] # Re: Musl / uclibc
Posté par Zenitram (site web personnel) . Évalué à 0.
Ben elles manquent, c'est factuel.
2 projets. 1 fonctionnalité manquante.
systemd refuse de l'implémenter, c'est un méchant.
x (non systemd) refuse de l'implémenter, c'est un gentil.
euh… toujours le 2 poids, 2 mesures, on ne peut pas dire par exemple qu'ils ont exactement la même réaction (autant l'un que l'autre a la même position sur ce qui est en "extra", ils n'en veulent pas, l'un n'a pas plus raison que l'autre).
maintenant, si quelqu'un veut mettre systemd avec musl-libc, ben c'est simple : il créé et maintient le projet qui implémente ce qui manque à la place d'accuser l'un ou l'autre. Ouais, c'est moins marrant de bosser que d'accuser un autre.
Au final, ce patch est juste un gros troll pourri, et si il reste il faudra sans doute que les utilisateurs se posent la question de la pérennité à long terme du projet (quand un projet priorise la politique au projet, il y a des risques que ça explose pas longtemps après).
[^] # Re: Musl / uclibc
Posté par Moonz . Évalué à 9.
Tout comme c’est factuel qu’il manque un navigateur internet et une suite bureautique dans Mediainfo. So what ? Il me semble pas que « navigateur internet » entre dans les objectifs de Mediainfo, donc ça a beau être « factuel », ça reste débile de l’utiliser comme un argument dans une discussion sur Mediainfo. Ben exactement pareil pour les linuxeries dans musl-libc. Oui c’est pas présent dans le projet, mais c’est pas dans les objectifs non plus…
J’ai dit ça moi, ou c’est encore ta capacité de lire ce que je n’ai jamais écrit ?
Au contraire, je dis que si il fallait chercher un méchant, ce serait du côté des mainteneurs de glibc qui auraient pu séparer les deux (libc/linuxeries). Mais c’est un bien grand « si » : jusqu’ici ça gênait personne, ça aurait été du boulot supplémentaire pour finalement aucun apport, on peut pas vraiment leur reprocher d’avoir fait ce choix.
Et oui, parfois il y a des merdes qui arrivent sans aucun coupable clair. C’est triste pour ceux qui aiment troller sur la méchanceté/incompétence/flemmardise du camp d’en face (insérez votre camp ici), mais c’est la vie.
[^] # Re: Musl / uclibc
Posté par xcomcmdr . Évalué à 1.
Et ça ferait quoi à part déplacer le problème ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Musl / uclibc
Posté par robin . Évalué à 10.
Qu'on pourrait utiliser Xlibc + liblinux + systemd, sans que Xlibc ne se préoccupe des linuxeries, et tout en permettant à systemd d'avoir les linuxeries dont il a besoin. Par conséquent, on pourrait choisir sa libc.
bépo powered
[^] # Re: Musl / uclibc
Posté par barmic . Évalué à 4.
Ça met en évidence ces différences plutôt que les mélanger avec le standard.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Musl / uclibc
Posté par karteum59 . Évalué à 5.
1°/ Musl-libc n'a pas vocation à reproduire tout le bloat et extensions "propriétaires" de la glibc.
2°/ Ton approche signifie que musl doit reproduire 100% des extensions propriétaires de la glibc, alors que peut-être 20% sont utilisées (et nécessiteraient d'être backportées) dans systemd
3°/ Personne ne demande à Lennard de coder lui-même lesdites fonctionnalités, juste de ne pas bloquer les contributions de ceux qui souhaitent que ça marche ailleurs que sur Linux/Redhat/glibc/sa_machine. Si Linus avait eu le même comportement, je ne suis pas sûr que Linux marcherait sur ARM/MIPS/Alpha/…/Amiga/… (et pourtant, le support de ARM était un joyeux bazar avant l'avènement du DT)
[^] # Re: Musl / uclibc
Posté par xcomcmdr . Évalué à 5.
Nombre de patchs sont bloqués par Linus pour les mêmes raisons (pas le moyen de les maintenir sur la durée / bloat / rien à voir avec le projet / etc).
Là, est-ce que le patch est bon ? Est-ce qu'il n'est pas trop invasif ? Par qui sera--t-il maintenu ? Est il suffisant pour résoudre le problème ?
On en sait rien, mais on se permet de juger tout de même. Je parie que si ça avait été Linus, on aurait pas la même réaction épidermique.
Déjà il est redondant avec la glibc, libc qui fait partie de la cible de systemd. Donc, qu'on le veuille ou non, d'un point de vue maintenance ça n'a déjà que peu de sens…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Musl / uclibc
Posté par barmic . Évalué à 2.
Ce n'est pas le patch qui est jugé, mais la raison du refut. Ce qui n'a rien avoir, le patch est peut être buggé ou il crée une faille de sécurité, mais ce n'est pas le sujet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Musl / uclibc
Posté par ookaze . Évalué à 0.
Systemd encore moins, c'est même la raison pour laquelle il utilise la Glibc au lieu de s'en recréer une.
Non, mon approche signifie qu'il ne faut taper ni sur musl ni sur glibc, mais implémenter soi-même les fonctionnalités manquantes dans un fork de systemd. Ce qui revient au même puisque ceux-là même qui veulent mettre le patch upstream vont le maintenir. En fait, c'est même exactement de cette façon que c'est fait pour nombre de patchs du noyau Linux non acceptés upstream : ils sont maintenus dans une branche séparée, merci git.
Un systemd-musl n'est pas accepté upstream, mais rien n'empêche aux mainteneurs de proposer leur fork/branche.
Factuellement faux puisque le noyau et Linus fonctionnent exactement de la même façon.
[^] # Re: Musl / uclibc
Posté par barmic . Évalué à 5.
Linus accepte les patches qui ont pour objectifs de permettre la compilation avec un autre compilateur que gcc (clang en tête). Il n'accepte pas n'importe quel patch, mais il ne refuse pas une contribution sous-prétexte que la portabilité sur d'autres environnements l'ennui.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Musl / uclibc
Posté par ookaze . Évalué à -1. Dernière modification le 16 novembre 2015 à 15:49.
Quel est l’intérêt de cette remarque qui n’a rien à voir avec le sujet ?
Déjà, il me semble que le noyau Linux n'est porté que sur le noyau Linux !
Linus n’accepte pas les patches qui selon lui n’ont rien à faire dans le noyau (d’où les difficultés de kdbus par exemple), systemd n’accepte pas les patches qui n’ont rien à faire dans systemd : c’est pareil.
Et la preuve est que ces fonctionnalités (des API pour des appels système sous Linux) sont présentes dans la glibc (qui pourtant filtre ce qui est disponible sur un unique noyau), et qu’elles fonctionnent très bien et sont maintenues.
Pour information, ce n’est pas la première fois qu’un développeur demande à systemd d’implémenter des fonctions de la glibc parce que la libc qu’il utilise ne veut pas le faire.
Multiplier les implémentations d’API dans de multiples projets est très mauvais, c’est une très bonne raison de ne pas réimplémenter la roue dans systemd.
Bien sûr, ça va à l’encontre de l’histoire comme quoi systemd veut tout réimplémenter (glibc, GNU par exemple) au sein de son code, mais les incohérences n’arrêtent pas les trolls.
systemd est spécifique GNU/Linux, c’était clair dès le début.
Certains n’ont pas voulu l’entendre de cette oreille et ont décidé que c’était possible et pas un énorme boulot de gérer la compatibilité avec d’autres OS, pour décrédibiliser les développeurs systemd.
Seulement, arrivé dans la réalité, tous ces beaux parleurs jettent l’éponge les uns après les autres devant l’ampleur de la tâche, comme uselessd, prouvant par là même la compétence des dévs systemd et leur propre irresponsable incompétence.
[^] # Re: Musl / uclibc
Posté par barmic . Évalué à 4.
Ce que je dis c'est que Linux ré-implémente des fonctions que l'on trouve dans gcc, pour pouvoir compiler avec clang. Linus ne considère pas cela comme hors scope. Il lui arrive de refuser ce genre de patch mais parce qu'il ne considère pas la qualité du patch comme suffisante.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Explication
Posté par gnumdk (site web personnel) . Évalué à 1. Dernière modification le 13 novembre 2015 à 14:34.
La raison est surement ici: https://bugs.busybox.net/show_bug.cgi?id=8421#c2
Et le commentaire du commit un gros troll…
[^] # Re: Explication
Posté par Thomas Petazzoni (site web personnel) . Évalué à 9.
Absolument aucun rapport. Le bug que tu pointes est un bug de Buildroot, pas de Busybox.
# Fonctionnalité du patch
Posté par benoar . Évalué à 5.
Mon interprétation ce que que permettait le « support » de systemd qui a été enlevé : à priori, c'était juste pour avoir l'activation automatique (je ne sais pas si ça s'appelle comme ça exactement, mais je parle de la possibilité que systemd écoute sur un socket à la place d'une application, pour la lancer seulement à la demande) du démon syslog sur un système avec systemd. Pas de quoi casser trois pattes à un canard…
[^] # Re: Fonctionnalité du patch
Posté par Misc (site web personnel) . Évalué à 5.
Oui, c'est ça.
Pour compléter, l'activation par socket permet en effet l'activation automatique, mais pas uniquement, ça permet aussi de démarrer les choses plus ou moins dans le désordre sans avoir des races conditions compliqués à déboguer (cf http://0pointer.de/blog/projects/systemd.html).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.