Journal Busybox retire le support de systemd ?

Posté par . Licence CC by-sa
Tags :
20
13
nov.
2015

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 . Évalué à 1.

    L'adresse ves le site de busybox est incorrecte. Si quelqu'un peut corriger ?

  • # impact: syslog

    Posté par . Évalué à 1.

    Bonjour,

    J'ai parcouru un peu le commit, ça semble « seulement » lié à syslogd.
    Je dirai donc :

    • qu'au mieux, on ne peut plus utiliser le système de log de systemd,
    • et qu'au pire, on ne peut plus utiliser du tout le syslog.

    Je penche pour la première option.

  • # Musl / uclibc

    Posté par . Évalué à 10. Dernière modification le 13/11/15 à 14:30.

    Rappelons, comme je le disais ici, que

    Le souci de portabilité ne concerne pas que les BSD => un exemple qui m'agace : musl-libc semble très prometteuse, et certaines distributions comme Alpine l'ont déjà adopté. Mais systemd ne marche qu'avec la glibc et Lennard a clairement dit qu'il refusait de résoudre le problème ("we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes". Dit autrement: l'API de référence est pour lui la glibc avec toutes ses extensions et GNUisms et non juste POSIX, les autres libc n'ont qu'à réimplémenter le bloat…).

    (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 . É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 . Évalué à 7.

        Mais dans ce type d'environnement embarqué, est-ce que systemd se justifie ?

        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 . É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 . É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 . Évalué à 2.

              Je n’ai pas dit le contraire; merci des détails supplémentaires.

      • [^] # Re: Musl / uclibc

        Posté par (page perso) . Évalué à 10.

        dans ce type d'environnement embarqué, est-ce que systemd se justifie ?

        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 . É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 . Évalué à 10.

        Parce que ces patches consistent à maintenir des fonctionnalités manquantes de musl-libc (par exemple) par rapport à glibc

        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 (page perso) . Évalué à 0.

          Ce ne sont pas des fonctionnalités manquantes.

          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 . Évalué à 9.

            Ben elles manquent, c'est factuel.

            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…

            systemd refuse de l'implémenter, c'est un méchant.

            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 . Évalué à 1.

          La question c’est surtout pourquoi les spécificités linux se retrouvent dans la glibc plutôt que dans une liblinux.

          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 . É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 . É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 . Évalué à 5.

        c'est à musl-libc qu'il faut envoyer ces patches évidemment

        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 . Évalué à 5.

          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.

          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 . Évalué à 2.

            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 ?

            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 . Évalué à 0.

          1°/ Musl-libc n'a pas vocation à reproduire tout le bloat et extensions "propriétaires" de la glibc.

          Systemd encore moins, c'est même la raison pour laquelle il utilise la Glibc au lieu de s'en recréer une.

          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

          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.

          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)

          Factuellement faux puisque le noyau et Linus fonctionnent exactement de la même façon.

          • [^] # Re: Musl / uclibc

            Posté par . Évalué à 5.

            Factuellement faux puisque le noyau et Linus fonctionnent exactement de la même façon.

            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 . Évalué à -1. Dernière modification le 16/11/15 à 15:49.

              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.

              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 . É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 (page perso) . Évalué à 1. Dernière modification le 13/11/15 à 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…

  • # Fonctionnalité du patch

    Posté par . É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…

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.