Journal Debian migre de la GNU libc à EGLIBC

Posté par  (site web personnel) .
Étiquettes :
22
6
mai
2009
Aurélien Jarno, développeur Debian, vient de pousser le paquet « eglibc » qui est une variante de la GNU libc. Cette variante semble plus ouverte aux contributions externes, a un meilleur support des architectures embarquées, backporte les correctifs dans les branches « stables » (alors que Debian doit le faire pour la GNU libc : find debian/patches/ -name "cvs-*" donne une vingtaine de patches), etc.

Informations sur le blog d'Aurélien Jarno :
http://blog.aurel32.net/?p=47

Site du projet EGLIBC :
http://www.eglibc.org/

Il me semble clair que la finalité de la chose est de contourner le mainteneur de la GNU libc, le célèbre Ulrich Drepper (célèbre pour ses réactions violentes aux rapports de bugs ou propositions d'amélioration de la libc).

Selon le billet d'Aurélien Jarno, Debian va bientôt remplacer la GNU libc par EGLIBC.

De ce que j'en ai vu, EGLIBC semble être un fork : basé sur les sources de la GNU libc, utilise CVS, et exige aussi de céder ses droits à la FSF.

La libc, bibliothèque standard C, est utilisée par à peu près 99,9% des programmes sous Linux. Elle est donc hautement critique. Le gros problème est que son mainteneur, Ulrich Drepper, semble plutôt opposé à toute contribution externe et se « vexe » dès qu'on rapporte un bug. Debian contient plus de 200 patchs pour le paquet libc6, ce qui est énorme ! Peu (une quarantaine) ont été envoyé upstream. Certains patchs datent de plusieurs années (et corrigent de vrais bugs bien sûr).

  • # ça utilise svn

    Posté par  (site web personnel) . Évalué à 5.

    Si j'en croit ceci : http://www.eglibc.org/repository , c'est du svn

    Et la glibc passe à git dans 4 jours : http://sourceware.org/ml/libc-alpha/2009-04/msg00034.html

    • [^] # Re: ça utilise svn

      Posté par  (site web personnel) . Évalué à 3.

      Il semble qu'EGLIBC soit régulièrement synchronisé (mergé) avec la libc « FSF » (la GNU libc). Je vois aussi que le dépôt SVN d'EGLIBC a été crée le 16 août 2006.

      Je pense que c'est une bonne chose que la GNU libc migre à git. Ça va faciliter la maintenance des patchs non inclus upstream (git rebase). Par contre, je doute fortement que ça change quoi ce soit au niveau de l'acception des contributions.

  • # cool

    Posté par  . Évalué à 8.

    on aura le droit à strlcpy ? :)

    • [^] # Re: cool

      Posté par  (site web personnel) . Évalué à 10.

      Petit rappel des faits (ce que j'ai compris de l'affaire) : à force d'auditer du code source C, Todd C. Miller et Theo de Raadt ont eu l'idée d'écrire des fonctions strlcpy() et strlcat() pour remplacer strcpy(), strncpy(), strcat() et strncat() (quand c'est opportun). strlcpy() et strlcat() ont divers avantages (ex: strlcpy garantit que la chaîne est terminée par un octet nul contrairement à strcat, strlcpy est plus rapide car ne remplit pas la fin par des zéros : en écrit un seul) et défauts (ex: strlcat calcule la taille de la source même si elle a été tronquée et est donc plus lent). En dehors du débat qualités/défauts, c'est surtout un bras de fer entre OpenBSD et les développeurs de la GNU libc : fierté, jalousie, ou que sais je.

      De mon point de vue, strlcpy() est bien meilleur que strncpy() et plus sûr (limite les erreurs de programmation). Je ne trouve pas les arguments en défaveur de strlcpy() et strlcat() recevables, et je trouve ça dommage que finalement le choix soit « politique ».

      Oui, on peut espérer que les développeurs d'EGLIBC soient plus « ouverts ». Il y a déjà eu des patchs acceptés dans EGLIBC qui risquent de ne jamais être accepté dans la GNU libc (ex: supporter un autre shell que bash). Ça rappelle effectivement les scissions Xfree86/X.org ou Sodipodi/Inkscape qui visaient elles aussi à se passer de développeurs peu coopératifs (cf. plutôt l'inverse de coopératif).

      • [^] # Re: cool

        Posté par  . Évalué à 2.

        Ce qui est "drôle" c'est que je crois que strlcpy & co ont été proposés pour inclusion dans POSIX, donc sauf à moins de vouloir devenir radicalement incompatible les développeurs de la GNU libc n'auront peut-être pas d'autre choix que de les intégrer dans quelques années.

    • [^] # Re: cool

      Posté par  (site web personnel) . Évalué à 2.

      Pour strlcpy, je conseille d'utiliser libbsd: http://libbsd.freedesktop.org/wiki/

  • # C'est le retour du bâton

    Posté par  . Évalué à 8.

    Je n'ai pas trop suivi l'histoire, mais si Ulrich Drepper (aussi calé techniquement soit-il) pose vraiment de gros problèmes en empêchant un coopération saine, c'est une très bonne chose de forker. Quand on voit le résultat avec X.Org, je ne peux qu'être d'accord.

    D'ailleurs est-ce que quelqu'un sait où en est XFree86? Car la dernière version date de décembre 2008. Mais à côté de toutes les améliorations qu'a connu et connaît X.Org, j'ai plutôt l'impression que le projet est moribond...

  • # Glibc 2.10

    Posté par  (site web personnel) . Évalué à 6.

    A noter qu'Ulrich a quand même fait un effort méritoire puisqu'il a publié sur son blog une grosse description des nouveautés de la Glibc 2.10 : http://udrepper.livejournal.com/20948.html

    Peut-être qu'il sort un peu de sa tour d'ivoire ? En tout cas, aussi caractériel puisse-il être, ce serait amha complètement con d'initier une guerre des libc. Drepper est une super pointure techniquement et il est super légitime auprès des devs.
    J'espère que l'initiative EGLIBC va juste l'inciter à avoir un comportement un peu plus sociable et qu'il va y avoir une réunification par la suite.

    • [^] # Re: Glibc 2.10

      Posté par  . Évalué à 6.

      Le vrai gros avantage de la eglibc par rapport à glibc la dernière fois que j'ai regardé, c'était surtout qu'il était beaucoup plus facile de compiler une cross-toolchain. Les inter-dépendances entre la gcc et la glibc sont un vrai cauchemar pour mettre en œuvre une cross-toolchain (le plus facile étant les GNU binutils).
      En effet, la compilation native n'est qu'un cas particulier de la compilation croisée (passons les trolls sur la compilation canadienne), pourtant énormément de paquets de sources logiciels sont codés en dur, ou de vrais cauchemars, pour la compilation croisée. C'est pour cela qu'il est bon de se forcer un peu au début d'un projet de bien utiliser les GNU autotools qui donne accès à un framework de compilation croisée pour gratuit.
      U.D. est difficile, mais les derniers choix qu'il a fait (nouveau cycle de release, passage à git) et ses compétences (voir son papier sur le fait que la RAM est lente et que pour de la vraie performance il fallait gérer la mémoire cache) compensent largement le fait qu'il hurle à la mort à chaque fois qu'un patch casse la compatibilité avec le HURD (véridique).
      Accessoirement, il fait parti des gens qui font POSIX...
      trollS:
      - automake en C... mon rêve.
      - eglibc passe à git, ça c'est une bonne idée
      - Je rêve d'une GNU/Linux gentoo où portage est en C et surtout pensé dés le départ pour de la compilation/déploiement croisé car pour le moment, cette fonctionnalité est monkey patché progressivement dans portage et... bof bof.

      • [^] # Re: Glibc 2.10

        Posté par  (site web personnel) . Évalué à 10.

        U.D. est difficile, mais les derniers choix qu'il a fait (...) et ses compétences (...) compensent largement (...)

        Tiens, je me souviens du bras de fer dans Linux 2.6 pour un nouvel ordonnanceur de processus : il y avait deux concurrents, donc l'un était meilleur techniquement, mais l'autre acceptait les critiques et n'hésitait pas à expliquer ses choix. Bah c'est le second qui a gagné ;-) La technique n'est pas un argument suffisant.

      • [^] # Re: Glibc 2.10

        Posté par  (site web personnel) . Évalué à 6.

        Je ne contredit pas le fait que Ulrich Drepper est quelqu'un de très bon techniquement. Mais celà ne fait pas tout.

        Une partie des architectures qui ne l'intéresse pas ont été migrées vers le repository ports, afin de pouvoir être maintenu pas d'autre personnes. Cependant dans le code commun (qui lui n'est pas dans ports), des hypothèses qui sont parfois fausses sur ces architectures sont faites. La plupart du temps ces changements nécessaires sont refusés, ou encore pire ignorés.

        Debian supporte un grand nombre d'architectures, et la EGLIBC apporte une réponse à ce problème.

    • [^] # Re: Glibc 2.10

      Posté par  . Évalué à 10.

      Drepper est une super pointure techniquement et il est super légitime auprès des devs.

      Super légitime ?
      Vu les réactions liées au-dessus, j'imagine que toute personne rebutée par son caractère de cochon s'abstiendra de contribuer à la glibc. Donc, par défaut, effectivement, ceux qui restent dans le projet adhèrent forcément à sa façon de faire. Une sorte de sélection négative.

  • # Et les performances ?

    Posté par  (site web personnel) . Évalué à 3.

    Il y a t-il des différences de performances entre ces deux libc, il y a des bench "douteux" ?

    • [^] # Re: Et les performances ?

      Posté par  (site web personnel) . Évalué à 2.

      Il est possible de compiler la EGLIBC avec -Os, et donc d'obtenir un code plus compact qui est en général plus rapide sur les CPU avec peu de cache (ce qui est souvent le cas sur MIPS ou ARM).

      Par exemple Moblin 2 est compilé avec sse3, -Os, et -march=core2.

    • [^] # malloc()

      Posté par  . Évalué à 1.

      Ce serait bien si ils intégraient un malloc() un peu moins antédiluvien.
      Au hasard ptmalloc3,jemalloc, voir hoard (bof pour les machines avec beaucoup de cpus).

  • # Fork ?

    Posté par  (site web personnel) . Évalué à 6.

    De ce que j'en ai vu, EGLIBC semble être un fork : basé sur les sources de la GNU libc, utilise CVS, et exige aussi de céder ses droits à la FSF.

    En fait il ne faut pas vraiment voir ça comme un fork qui évolue dans son coin, mais plutôt comme un ensemble de patches qui sont appliqués à la GLIBC. Ça évite aux mainteneurs de chacune des distributions de maintenir ou de backporter des patches dans son coin, et ainsi partager les améliorations qui sont refusés dans la GLIBC (exemple le support des shells autres que bash). À noter aussi que EGLIBC a le support du MPCore sur ARM, on l'attend toujours sur GLIBC.

    • [^] # Re: Fork ?

      Posté par  (site web personnel) . Évalué à 4.

      Est-ce qu'il serait envisageable qui si un nombre suffisant de distributions (Linux et autres OS) et des développeurs migrent à EGLIBC, la version « officielle » de la libc « FSF » deviennent finalement EGLIBC ? (et que la GNU libc actuelle soit simplement abandonnée)

  • # Annonce reprise par

    Posté par  (site web personnel) . Évalué à 1.

    http://www.h-online.com/open/Debian-changes-from-GLIBC-to-EG(...)
    http://lwn.net/Articles/332000/

Suivre le flux des commentaires

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