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 Misc (site web personnel) . Évalué à 5.
Et la glibc passe à git dans 4 jours : http://sourceware.org/ml/libc-alpha/2009-04/msg00034.html
[^] # Re: ça utilise svn
Posté par Victor STINNER (site web personnel) . Évalué à 3.
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 Guillaume Knispel . Évalué à 8.
[^] # Re: cool
Posté par Victor STINNER (site web personnel) . Évalué à 10.
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 Guillaume Knispel . Évalué à 2.
[^] # Re: cool
Posté par Aurélien Jarno (site web personnel) . Évalué à 2.
# C'est le retour du bâton
Posté par sanao . Évalué à 8.
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...
[^] # Re: C'est le retour du bâton
Posté par Troy McClure (site web personnel) . Évalué à 8.
[^] # Re: C'est le retour du bâton
Posté par IsNotGood . Évalué à 1.
S'il ferme le rapport de bug et qu'aucun développeur de la libc ne lui donne tort, ben c'est qu'il a raison.
[^] # Re: C'est le retour du bâton
Posté par Julien Humbert . Évalué à 5.
Personnellement j'ai aucune idée de ce qui s'y passe mais ça donne pas trop envie de se ramener la-bas.
Ensuite faut souligner que c'est pas la seule raison. Donc au final c'est pas forcément mauvais, mais ce que je trouve inquiétant par contre c'est la mention : Retain API and ABI compatability with GLIBC wherever feasible.
Casser la compatibilité avec les autres distributions serait pas avantageux !
[^] # Re: C'est le retour du bâton
Posté par Misc (site web personnel) . Évalué à 3.
[^] # Re: C'est le retour du bâton
Posté par Aurélien Jarno (site web personnel) . Évalué à 2.
- Dans le cas on certains composants sont désactivés (exemple les locales), il n'est pas possible de garder la compatibilité binaire, car des fonctions sont supprimées. Ce ne sera pas le cas dans Debian (sauf peut-être pour emdebian ou debian-installer).
- Pour ajouter des fonctionnalités sur certaines architectures, qui pourront être à terme mergées dans la GLIBC. On peut citer l'exemple de de l'EABI sur ARM.
Il serait suicidaire pour la EGLIBC de casser la compatibilité binaire sur des architectures très communes tel que x86 et X86_64.
[^] # Re: C'est le retour du bâton
Posté par Troy McClure (site web personnel) . Évalué à 10.
Ptet qu'ils ont les chocottes
[^] # Re: C'est le retour du bâton
Posté par Misc (site web personnel) . Évalué à 4.
sur sa communication, ça veut dire que les autres trouvent ça normal, ou qu'ils n'osent pas lui dire ce qu'ils pensent.
Dans les 2 cas, ça veut dire qu'il y a un problème vis à vis des codeurs autour de la glibc.
[^] # Re: C'est le retour du bâton
Posté par Aurélien Jarno (site web personnel) . Évalué à 4.
[^] # Re: C'est le retour du bâton
Posté par Aurélien Jarno (site web personnel) . Évalué à 2.
# Glibc 2.10
Posté par patrick_g (site web personnel) . Évalué à 6.
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 blubliblo . Évalué à 6.
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 Victor STINNER (site web personnel) . Évalué à 10.
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 Aurélien Jarno (site web personnel) . Évalué à 6.
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 Antoine . Évalué à 10.
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 Frédéric Massot (site web personnel) . Évalué à 3.
[^] # Re: Et les performances ?
Posté par Aurélien Jarno (site web personnel) . Évalué à 2.
Par exemple Moblin 2 est compilé avec sse3, -Os, et -march=core2.
[^] # malloc()
Posté par geb . Évalué à 1.
Au hasard ptmalloc3,jemalloc, voir hoard (bof pour les machines avec beaucoup de cpus).
# Fork ?
Posté par Aurélien Jarno (site web personnel) . Évalué à 6.
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 Victor STINNER (site web personnel) . Évalué à 4.
[^] # Re: Fork ?
Posté par Octabrain . Évalué à 3.
# Annonce reprise par
Posté par Victor STINNER (site web personnel) . Évalué à 1.
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.