Journal Merci aux développeurs de la GNU libc !

Posté par  . Licence CC By‑SA.
Étiquettes :
43
27
oct.
2011

Octobre 2010: Ulrich Drepper affectueusement surnommé Uli ou le dictateur (pour rester poli) partait en retraite dorée chez Goldman Sachs.
...
Octobre 2011: le lendemain du freeze final de Fedora 16, mass rebuild à cause d'une mise à jour sans motifs de la GLibc dans la prochaine branche stable. Une première en 7 ans !

Premier problème
Et on recommence la semaine suivante !

Andreas Schwab (membre de la GNU libc steering committee, l'espèce de club d'asociaux institués pour pallier aux insuffisances sociales d'Uli) et actuellement mainteneur de fait chez Fedora pousse régulièrement des snapshots de la GLibc sans motifs valables (correctifs de bogues, nouvelles fonctionnalités, etc ...) dans Fedora et ne s'embarasse pas de respecter les règles du projet.
On appréciera le "Don't use broken software" d'Andreas, seule intervention pertinente de sa part sur le ticket Fedora (une corruption mémoire avec git rapporté par Jim Meyering, mainteneur de GNU coreutils). Les interventions d'Andreas sur le bugzilla Fedora sont du même acabit, très distrayant à lire entre deux tâches (dommage que la GLibc soit pas multi-tâches friendly !)

Même après le retrait d'Uli, la GLibc respecte son héritage: Nous en avons rien à foutre de vous

  • # Navrant

    Posté par  . Évalué à 6.

    C'est navrant de voir un composant aussi primordial (la libc d'une manière générale), ne pas avoir d'organisation pour obtenir une stabilité plus importante. Quelque chose comme une LTS par exemple.

    Ils récolteront ce qu'ils ont semés : une fuite des utilisateurs. Je ne sais pas où en est Debian après cela : https://linuxfr.org/users/haypo/journaux/debian-migre-de-la-gnu-libc-%c3%a0-eglibc

    Mais ça ne me surprendrait pas que des projets comme Debian/RedHat changent de bibliothèque. Ce serait douloureux pour le glibc parce que les dérivées prendraient le même chemin 6 à 12 mois plus tard, ce serait donc pour eux perdre une grande base d'utilisateurs.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Navrant

      Posté par  . Évalué à 10.

      Je ne sais pas où en est Debian après cela

      Debian a complétement migré sur eglibc mais ça n'est pas un fork à proprement parler, mais une branche maintenue indépendamment et régulièrement synchronisée sur glibc. Bref, ils ont fait un proxy autour des mainteneurs de la glibc.

      Pour Fedora, la quasi-totalité des mainteneurs upstream (sauf Uli) à une adresse @redhat ... mais ça commence à faire chier tout le monde. Sur les 3 dernières versions, on a eu un pétage lors des freezes (béta pour F14, alpha et juste avant la finale pour F15 et là juste après la finale - quoi F16 sort dans 2 semaines -). Mais, je suis prêt à parier que ça va encore recommencer et que ça va clasher grave.

      • [^] # Re: Navrant

        Posté par  . Évalué à 4.

        régulièrement synchronisée sur glibc

        En meme temps une synchronisation tout les 7 ans c'est pas la mer a boire.

        • [^] # Re: Navrant

          Posté par  . Évalué à 8.

          Tu ne serais pas un peu jaloux parce que ta distribution n'est pas supportée aussi longtemps ?

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Navrant

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

            Je crois qu'il parlait de la mise à jour de la libc, et pas du tout de la distribution (en référence au post initial ("une première en 7 ans"))

            • [^] # Re: Navrant

              Posté par  . Évalué à 5.

              Ah ben j'ai compris que c'était en référence à Debian qui synchronise sa glibc avec la libc à chaque nouvelle stable, en se moquant gentiment du délai entre celles-ci.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Navrant

                Posté par  . Évalué à 5.

                En 2011, il y a eu deux versions majeures de la GNU libc (2.13 et 2.14) et une en 2010 (2.12), donc c'est un peu plus souvent que ça.

      • [^] # Re: Navrant

        Posté par  . Évalué à 10.

        Bref, ils ont fait un proxy autour des mainteneurs de la glibc.

        Ou plutôt un cordon sanitaire.

  • # Clarté

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

    Suis-je le seul à trouver ce journal particulièrement difficile à comprendre ?

    • [^] # Re: Clarté

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

      Non, j'ai dû relire 3 fois le journal pour y capter un peu de sens.
      Mais il est intéressant quand même!

    • [^] # Re: Clarté

      Posté par  . Évalué à -9.

      Comme ce commentaire est déjà à 10, je pertinente ici.
      J'ai cru comprendre un peu l'idée après trois lectures, puis je me suis dirigé vers les commentaires pour avoir plus d'élément... à peine mieux.

      Pour avoir un compteur à +28, l'auteur a dû ouvrir une bonne centaine de comptes fantômes...

      • [^] # Re: Clarté

        Posté par  . Évalué à 10.

        Je ne pertinente jamais mes propos, c'est d'un mauvais goût.

    • [^] # Re: Clarté

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

      Lorsque tu essayes de faire des binaires compatibles sur plusieurs distributions, je te garantie que tu le comprends très bien.

      Je garde un souvenir ému de __ctype_b

  • # Un peu d'explications sur le bug introduit

    Posté par  . Évalué à 10.

    Je ne vais pas parler ici des considérations politiques mais j'ai trouvé que le bug introduit dans la glibc est particulièrement intéressant. Pour ceux qui n'ont épluché les liens du journal, voici une tentative d'explication.

    Dans gcc 4.6 a été ajouté un attribut de fonction leaf (cf Function Attributes). Cet attribut permet de signifier qu'une fonction ne va fait appel à aucune autre fonction. Lorsque le compilateur voit qu'on appel une fonction "leaf", il sait que toutes les variables de l'unité de compilation courante qui ne sont pas passées à la fonction ne pourront être modifiées par cette fonction et peut ainsi optimiser plus agressivement. Par exemple si j'écris le code suivant :

    static int g_count; /* variable globale */

__attribute__((__leaf__))
int calcValue(int);

int incGCount()
{
    g_count++;
}

int myFunc2()
{
    int i;
    int result = 0;
    g_count=0;
    for (i=0; i != 3 && g_count != 3; i++)
    {
        result+=calcValue(i);
        ++g_count;
    }
    return result;
}

    Ici, calcValue étant marqué comme leaf, on sait que cette fonction ne va appeler aucune fonction de notre unité de compilation, en particulier elle n’appellera pas incGCount() et donc, voyant que i et g_count ont toujours la même valeur, le compilateur peut tout à fait remplacer la fonction myFunc2 par ceci :

    int myFunc2()
{
    g_count=3;
    return calcValue(0)+calcValue(1)+calcValue(2);
}

    Autre observation, les fonctions (entre autre) pthread_mutex_lock et pthread_mutex_unlock ne font appel à aucune fonction (en dehors de leur unité de compilation et elles n’appellent pas non plus de callback), donc elles ont été marquées comme leaf par les mainteneurs de la glibc. Et donc si je veux rendre myFunc2 thread-safe en protégeant l'accès à g_count par un mutex, je ferais :

    int incGCount()
{
    pthread_mutex_lock(&g_mutex);
    g_count++;
    pthread_mutex_unlock(&g_mutex);
}

int myFunc2()
{
    int i;
    int result = 0;
    pthread_mutex_lock(&g_mutex);
    g_count=0;
    pthread_mutex_unlock(&g_mutex);
    for (i=0; i != 3 && g_count != 3; i++)
    {
        result+=calcValue(i);
        pthread_mutex_lock(&g_mutex);
        g_count++;
        pthread_mutex_unlock(&g_mutex);
    }
}

    La fonction peut être optimisée par le compilateur qui sait que ni pthread_mutex_lock ni pthread_mutex_unlock ne vont consulter ou modifier g_count. Or si ces fonctions ne touchent évidemment pas g_count, en revanche le mutex sert à protéger l'accès à g_count et la prise du mutex peut bloquer parce qu'un autre thread a pris le mutex et est en train d'appeler incGCount(). Le compilateur ayant pris comme postulat que g_count n'était pas modifié a pu convertir le code comme ceci :
    int myFunc2()
{
    pthread_mutex_lock(&g_mutex); pthread_mutex_unlock(&g_mutex);
    pthread_mutex_lock(&g_mutex); pthread_mutex_unlock(&g_mutex);
    pthread_mutex_lock(&g_mutex); pthread_mutex_unlock(&g_mutex);
    pthread_mutex_lock(&g_mutex); pthread_mutex_unlock(&g_mutex);
    
    g_count=3;
    return calcValue(0)+calcValue(1)+calcValue(2);
}

    Et là c'est le drame et heap corruption via multi-threaded "git grep".

    Étienne

    • [^] # Sémantique

      Posté par  . Évalué à 10.

      On dirait que le problème c'est que le C est assez pauvre pour gérer la programmation concurente et ce genre d'effets de bord ...

      Au minimum il faudrait indiquer que la variable en question est partagée entre plusieurs processus / thread donc qu'elle est susceptible d'effet de bords (je doute pas que des flags / attributs existent pour ça) pour que le compilateur soit au courant, voir ajouter la sémantique dans le langage pour qu'il soit capable de s'en dépatouiller tout seul.

      Ici par exemple on a visiblement ce qu'on appelle une section critique, ça devrait être intégré dans le langage et pas deux bêtes appels à la libc sur le lock/delock dés qu'on dépasse le niveau le plus bas ...

      • [^] # Re: Sémantique

        Posté par  . Évalué à 10.

        On dirait que le problème c'est que le C est assez pauvre pour gérer la programmation concurente et ce genre d'effets de bord ...

        Je ne sais pas pourquoi tu as un score négatif car la remarque est tout à fait pertinente. Le langage C n'a aucune sémantique liée à la programmation concurrente (sauf éventuellement le mot clé volatile qui n'était d'ailleurs pas prévu pour ça au début). Tout ce qui existe est sous forme de bibliothèque additionnelle. Et donc on a d'un côté une sémantique du C que connait les compilateur avec les fameux "undefined behaviors" permettant au compilateur de nombreuses optimisations et de l'autre du multithreading qui, par endroit, va à l'encontre de la sémantique du C. Les extensions des compilateurs (comme __thread, __sync* de gcc) sont la preuve que le C en lui même ne suffit pas.

        Depuis quelques semaines, le C11 a été normalisé et ajoute justement quelques outils pour gérer le multithreading (mais il va falloir un peu de temps, il suffit de voir que le C99 est loin d'être très généralisé) :

        • _Thread_local : indique qu'une variable a un thread local storage, c'est à dire qu'elle n'est pas partagée entre threads (c'est disponible avec gcc depuis assez longtemps au travers du mot clé __thread)
        • _Atomic : définit une variable comme étant atomique

        Étienne

        • [^] # Re: Sémantique

          Posté par  . Évalué à 3.

          mode troll (mais avec un gros fond de vérité) : À croire qu'il ne faut pas toucher au "C" par ici :)

        • [^] # Re: Sémantique

          Posté par  . Évalué à 8.

          [HS] Avez-vous remarqué que les standards C ne sont pas protégés contre le bug de l'an 2000 ? En effet dans 88 ans, il ne sera pas possible de distinguer le C99 (de 1999) du C99 (de 2099) ! Je ne sais pas si je vais réussir à trouver le sommeil !

          • [^] # Re: Sémantique

            Posté par  . Évalué à 8.

            En effet dans 88 ans, il ne sera pas possible de distinguer le C99 (de 1999) du C99 (de 2099) !

            [HS bis]

            Une discussion que j'ai eue avec un ado :
            — Tu connais Yannick Noah ?, sous-entendu qu'il s'agissait du chanteur car il m'avait bassiné avec plusieurs groupes de rap et un DJ de l'exception culturelle française.
            — Oui, c'est un grand tennisman français, le dernier à avoir gagné Roland Garros en 1983.
            — Hein !? Quoi !? Qui !?

            Je n'irais pas jusqu'à dire qu'un modulo 10 sur les dates serait suffisant, mais presque.

            The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

    • [^] # Re: Un peu d'explications sur le bug introduit

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

      Résumé : ne pas utiliser attribute((leaf)), truc écrit par un humain et donc source de bug. Vaut mieux laisser le compilo faire de l'optimisation globale (lors du link etc...) quand possible et sinon faire comme prévu sans cet attribut.

      Parce que bon, quand le corps d'une fonction est modifiée pour ajouter un petit truc, qui va regarder partout et voir si il n'y a pas de "leaf"? A moins que j'ai mal compris, c'est l'attribut qui est surtout une bombe à retardement en puissance.

      • [^] # Re: Un peu d'explications sur le bug introduit

        Posté par  . Évalué à 5.

        Résumé : ne pas utiliser attribute((leaf)), truc écrit par un humain et donc source de bug. Vaut mieux laisser le compilo faire de l'optimisation globale (lors du link etc...) quand possible et sinon faire comme prévu sans cet attribut.

        Ou plus exactement ne l'utiliser que pour les fonctions qui ne fait que travailler sur ses paramètres. Par exemple il est tout à fait légitime que la fonction sin(3) soit marquée leaf. L'erreur, je pense, est de marquer leaf une fonction qui fait un appel système. Mais si une fonction qui recherche l'index d'un élément est un bon candidat par exemple :

        ssize_t findFirstElement(char* array, size_t arraySize, char lookup)
{
    for (ssize_t i=0; i < arraySize; i++)
    {
        if (array[i] == lookup) return i;
    }
    return -1;
}

        Les critères à réunir sont :

        1. pas d'appel de fonction non leaf
        2. pas d'utilisation de variable autre que les paramètres de la fonction (ou éventuellement à une variable statique de l'unité de compilation)
        3. pas d'appel système

        Je n'ai pas accès à un gcc 4.6 pour faire un essai mais un diagnostique pour les points 1 et 2 seraient possibles, voir même une suggestion de rajouter l'attribut (pour le point 1, ça concerne quasi exclusivement les mainteneurs de la glibc, je pense qu'ils ont compris maintenant).

        Ceci dit les gains ne doivent pas être monumentales, cela ne concerne que les optimisations liées aux variables globales, et si un code est bourré de variables globales, je pense qu'il y a d'autres priorité que de rajouter des __attribute__((__leaf__)) partout.

        Étienne

        • [^] # Re: Un peu d'explications sur le bug introduit

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

          Ou plus exactement ne l'utiliser que pour les fonctions qui ne fait que travailler sur ses paramètres.

          Comment sais-tu que dans 20 ans ce sera toujours le cas?
          Si toi tu le sais, pourquoi le compilo ne peut-il pas le savoir lors de l'optimisation globale et optimiser en conséquence?

          J'ai dû mal à voir quand cet attribut serait utile, sans être une bombe à retardement... Ca m'a l'air d'être une fausse bonne idée GNU, à voir si elle arrive à aller dans la norme C un jour, une fois qu'elle aurait passé un regard extérieur à GNU.

          • [^] # Re: Un peu d'explications sur le bug introduit

            Posté par  . Évalué à 2.

            Je doute qu'un jour une fonction comme sin() ou strlen() attrappe un effet de bord.

            • [^] # Re: Un peu d'explications sur le bug introduit

              Posté par  . Évalué à 4.

              Et pourquoi pas ? À une époque pas si lointaine, les valeurs de sinus étaient stockées dans des variables globales. On peut imaginer que pour des optimisations, des effets de bords soient ajoutés.

              • [^] # Re: Un peu d'explications sur le bug introduit

                Posté par  . Évalué à 2.

                bon alors plus simple : min/max ?

                Mais bon c'est vrai qu'a part des cas triviaux c'est assez limité et je suis plus pour laisser le compilo faire le job.

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

              • [^] # Re: Un peu d'explications sur le bug introduit

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

                ça serait vraiment idiot de rendre ces fonctions non thread-safe

              • [^] # Re: Un peu d'explications sur le bug introduit

                Posté par  . Évalué à 4.

                Dans tous les cas je pense que quel que soit l'ordre dans lequel tu appelles la fonction sinus, le résultat sera le même. De toute façon, la seule contrainte d'après la documentation est que la fonction ne doit pas retaper dans l'unité de compilation courante pendant son exécution (c'est pourquoi cet attribut a été appliqué à toutes les fonctions de la glibc qui n'utilisent pas de callback).

                Calls to external functions with this attribute must return to the current compilation unit only by return or by exception handling. In particular, leaf functions are not allowed to call callback function passed to it from the current compilation unit or directly call functions exported by the unit or longjmp into the unit. Leaf function might still call functions from other compilation units and thus they are not necessarily leaf in the sense that they contain no function calls at all.

                Le problème avec les fonctions pthread étant que, justement, elles peuvent, indirectement, retaper dans l'unité de compilation courante, même sans callback.

                Ça implique aussi que toutes les fonctions mathématiques sont "leaf", car elles sont "pure" (la sortie ne dépend que des arguments et il n'y a pas d'effet de bord visible, les opérations de cache interne, etc ne comptant pas). C'est aussi le cas de strlen que je citais précédemment.

                Many functions have no effects except the return value and their return value depends only on the parameters and/or global variables. Such a function can be subject to common subexpression elimination and loop optimization just as an arithmetic operator would be.

                Par contre, des fonctions qui ne dépendent que de leurs arguments mais qui ont un effet de bord (comme fputs et consorts) ou qui conservent un cache interne (comme strtok) sont "leaf" mais ne sont pas "pure".

              • [^] # Re: Un peu d'explications sur le bug introduit

                Posté par  . Évalué à 2.

                La "mémoïsation" (cacher les valeurs couteuses à calculer et fréquemment utiliser) est une optimisation qui est toujours d'actualité (quoique l'augmentation de la puissance CPU et la stagnation de la latence mémoire la rende moins utile) même si elle est toujours aussi chiante au niveau théorique: une fonction "pure" qui a des effets de bords, quel étrange animal!

                • [^] # Re: Un peu d'explications sur le bug introduit

                  Posté par  . Évalué à 1.

                  Ce n'est pas vraiment un effet de bord, il n'y a aucun effet sur le code appelant ou sur l'extérieur. Et la définition d'une fonction pure est respectée dans le cas de la mémoisation: la valeur retournée ne dépend que des arguments.

          • [^] # Re: Un peu d'explications sur le bug introduit

            Posté par  . Évalué à 1.

            Comment sais-tu que dans 20 ans ce sera toujours le cas?

            C'est pour ça que je mettais qu'un diagnostique par le compilateur est tout à fait possible. N'oublions pas que l'attribut vient d'être rajouté, nul besoin de se précipiter. Ajouter un diagnostique pour émettre un warnings sur les cas 1 et 2 que je présentait me parait tout à fait faisable. La sémantique est assez comparable au const du C++ par exemple, à savoir qu'avec une variable const on ne peut appeler uniquement :

            • des fonctions qui prennent la variable en paramètre const (la copie étant un cas particulier de cette règle)
            • des fonctions const de cette classe

            Peut-être que pour le leaf, cela existe déjà, mais sinon le rajouter permettrai de l'utiliser de façon sûr.

            Étienne

    • [^] # Re: Un peu d'explications sur le bug introduit

      Posté par  . Évalué à 7.

      Merci beaucoup pour ton explication.

      Je ne connais pas Fedora, mais si j'ai bien compris le reproche principal est que: l'ajout du tag 'leaf' est une optimisation des performances ce qui n'aurait pas dut être intégrer en même temps que des corrections d'erreurs..

    • [^] # Re: Un peu d'explications sur le bug introduit

      Posté par  . Évalué à 7.

      D'où l'intérêt de ne pas ajouter d'optimisations buggués dans un compilateur, surtout lorsqu'elles sont d'une utilité discutables. (Il y a déjà const et pure, et la sémantique de leaf est particulièrement mal définie; la description des conditions nécessaires et suffisantes dans le manuel est incomplète à un point inimaginable -- ce qui est la cause racine du bug.)

    • [^] # Re: Un peu d'explications sur le bug introduit

      Posté par  . Évalué à 6.

      Ahem.... donc les mainteneurs de la glibc auraient ajouté au fonctions pthread_mutex_lock/unlock un attribut qui dit au compilo "salut, nous sommes des fonctions inoffensives, tu peux nous optimiser" ?
      Ils avaient abusé de substances qui font rire, ou bien ils sont complètements crétins ?

      • [^] # Re: Un peu d'explications sur le bug introduit

        Posté par  . Évalué à 6.

        Ils avaient abusé de substances qui font rire, ou bien ils sont complètements crétins ?

        En général, c'est pas les deux à la fois ?

      • [^] # Re: Un peu d'explications sur le bug introduit

        Posté par  . Évalué à 10.

        Faut pas non plus les prendre pour des cons, c'est facile après coup quand on a l'explication de les trouver complètement crétins. Le vrai problème c'est d'avoir poussé une version non stable dans Fedora.

        D'autant que le leaf ne veut pas dire "salut, nous sommes des fonctions inoffensives, tu peux nous optimiser" ça veut dire "salut, je ne viendrais pas taper dans une autre unité de compilation que la mienne", ce qui objectivement est vrai. Si les problèmes de multi-threading étaient simples, surtout à un niveau aussi bas, ça se saurait.

        Étienne

        • [^] # Re: Un peu d'explications sur le bug introduit

          Posté par  . Évalué à 4.

          Certes, après coup, c'est toujours facile. Mais là, c'est franchement pas sérieux.

          D'autant que le leaf ... ça veut dire "salut, je ne viendrais pas taper dans une autre unité de compilation que la mienne", ce qui objectivement est vrai.

          Mais ca ne sert pas qu'a seulement le dire, n'est ce pas ? Il y a des conséquences derrière, en particulier des possibilité d'optimisation. Sinon, ce n'était pas la peine de mettre en place cet attribut.

          Si les problèmes de multi-threading étaient simples, surtout à un niveau aussi bas, ça se saurait.

          C'est justement ce que je voulais souligner : comme ce n'est pas un sujet trivial, il aurait peut etre été judicieux d'envisager toute les conséquences avant d'apporter une modification a quelque chose qui fonctionnait correctement jusqu'à présent.

        • [^] # Re: Un peu d'explications sur le bug introduit

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

          Il faut aussi voir qu'ils ont fait des tests ( deja, le jeu de test de la libc ), et que le paquet glibc a été validé par plusieurs personnes afin de passer en stable ( enfin dans la futur stable , tout comme les paquets qui ont été compilés aprés le changement.

          Alors il y a surtout un probléme du au changement de derniére minute, mais je pense pas que le commit dans la version trunk soit un souci en soit, le probléme est bien de ne pas avoir gardé trunk pour ce que ça doit être.

    • [^] # Re: Un peu d'explications sur le bug introduit

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

      Je ne vais pas parler ici des considérations politiques mais j'ai trouvé que le bug introduit dans la glibc est particulièrement intéressant. Pour ceux qui n'ont épluché les liens du journal, voici une tentative d'explication.

      Bravo pour ton explication simple et claire!

      Une point cependant me taraude: apparemment le compilateur serait capable de déterminer automatiquement si une variable est leaf ou pas, il pourrait enregistrer cette information dans les fichiers objet, enregistrer aussi les prototypes des fonctions appellées dans chaque unité de compilation et vérifier les incohérences, le tout complètement automatiquement. Ou peut-être serait-il plus approprié de déplacer ce genre de tests dans un outil d'analyse de code.

    • [^] # Re: Un peu d'explications sur le bug introduit

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

      [leaf] permet de signifier qu'une fonction ne va fait appel à aucune autre fonction.

      À une autre fonction dans la même unité de compilation. Elle peut toujours faire appel à une fonction dans une autre unité de compilation (tant qu'elle ne revient pas dans l'unité courante).

      Voir aussi http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Commentaire supprimé

    Posté par  . Évalué à 5.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: GLibc & Fedora

      Posté par  . Évalué à 3.

      Je suis assez d'accord avec toi sauf que là ce sont les développeurs de Fédora eux-même qui ne sont pas très content car les développeurs de glibc ont intégré un changement destiné a l'optimisation des performances alors que Fedora est en phase de stabilisation pour sortir une nouvelle version..

      • [^] # Re: GLibc & Fedora

        Posté par  . Évalué à 6.

        Euh, ce ne sont pas les développeurs de la glibc qui forcent Fedora à intégrer une nouvelle version, ce sont les mainteneurs de Fedora (peut-être que certains ont une double casquette). Il y a peut-être aussi un problème d'organisation ou de confiance dans les mainteneurs d'une brique aussi essentielle que la glibc chez Fedora.

        Étienne

        • [^] # Re: GLibc & Fedora

          Posté par  . Évalué à 4.

          Euh, ce ne sont pas les développeurs de la glibc qui forcent Fedora à intégrer une nouvelle version, ce sont les mainteneurs de Fedora (peut-être que certains ont une double casquette).

          ->

          Andreas Schwab (membre de la GNU libc steering committee, l'espèce de club d'asociaux institués pour pallier aux insuffisances sociales d'Uli) et actuellement mainteneur de fait chez Fedora

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: GLibc & Fedora

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

            Maintenant, Fedora sait à qui il faut retirer les droits de maintenance...

            Comment on dit déjà ailleurs? Ah oui : conflit d’intérêt.

        • [^] # Re: GLibc & Fedora

          Posté par  . Évalué à 9.

          C'est les mêmes (tous employés par RH sauf Ulrich), une des propositions sur la liste de diffusion était justement de leur retirer les droits de commits sur le git fedoraproject.org et de nommer un mainteneur "proxy" ce qui est plutôt exceptionnel chez Fedora (en général, c'est plutôt l'inverse, on encourage les développeurs upstream a (co-)maintenir le paquet fedora si ils le souhaitent)

          • [^] # Re: GLibc & Fedora

            Posté par  . Évalué à 9.

            On pourrait rebaptiser ton journal "Merci aux mainteneurs Fedora de la GNU libc" ;)

            Étienne

    • [^] # Re: GLibc & Fedora

      Posté par  . Évalué à 5.

      Il y a tout un éventail entre Archlinux et Debian/RedHat. Même si Fedora intègre des techno pas très mature, elle cherche tout de même une relative stabilité.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # C'est quoi un motif valable ?

    Posté par  . Évalué à 2.

    sans motifs valables (correctifs de bogues, nouvelles fonctionnalités, etc ...)

    Comme certains plus haut, je dois dire que je n'ai pas bien compris non plus.
    C'est à partir de quel degré de nécessité un motif valable ? Parce qu'une correction de bug, je trouve ça très valable comme motif. Ce serait une Debian stable, je ne dirais pas, mais là c'est Fedora, LA distribution qui intègre toutes les nouveautés.

    Donc il y a un truc que je n'ai pas pigé :-)

    • [^] # Re: C'est quoi un motif valable ?

      Posté par  . Évalué à 6.

      Il y a un cycle de développement à respecter, à partir de l'alpha on ne rajoute plus de fonctionnalités dans la branche destiné à devenir stable (rawhide est là pour ça).
      Dans certains cas, on peut permettre l'ajout de fonctionnalités tardives (mais en contrepartie, faut que ça soit bien avancé, avec un vrai plan de tests, et un plan de secours en cas de pépin), mais en aucun cas, on balance un snapshot git non testé juste avant le freeze final (mieux encore, on a failli se chopper un autre snapshot avant d'avoir corriger le problème précédent).

      Le but de Fedora c'est de récupérer les dernières nouveautés pour que ça soit utilisable, on n'a pas vocation -ni même le temps- à rendre utilisable la dernière GLibc toute pourrave du git la veille d'une release.

      En gros, les mainteneurs de la GLibc considérent que la prochaine stable de Fedora leur sert de bac à sable pour leurs expérimentations alors que ça doit être fait dans rawhide. Mais comme rawhide est inutilisable au quotidien, ils font chier tout le monde sur Fedora branched. De toute façon, si leur manager ne les obligeaient pas à répondre sur le bugzilla Fedora (ce qu'il font de très mauvaise grâce), ils ne le feraient même pas.

      • [^] # Re: C'est quoi un motif valable ?

        Posté par  . Évalué à 5.

        C'est marrant la gestion de projet chez Redhat. J'ai quand même l'impression que pas mal de gars qui y bossent on un égo surdimensionné. On voit le même problème dans la gestion de gnome et gtk (principalement faite par redhat), ou ils prennent beaucoup de décisions en interne (sans traçabilité: politique du "on prend nos décisions sur IRC sans en parler sur la mailing list") et envoient chier les autres développeurs s'il ne sont pas content avec leurs décisions.
        Ils devraient prendre un peut plus exemple avec le kernel linux, ou l'on a une vrai traçabilité dans la lkml.

        • [^] # Re: C'est quoi un motif valable ?

          Posté par  . Évalué à 4.

          Tu peux rajouter l'ensemble des trucs de Pottering dans la liste. Ca commence a faire legerement peur RH...

          • [^] # Re: C'est quoi un motif valable ?

            Posté par  . Évalué à 9.

            Il y a une différence majeure entre Lennart et les asociaux de GLibc, c'est qu'il est possible de communiquer avec Lennart. En tant que mainteneur Fedora, il s'implique dans la vie de la distro et joue le jeu (ce qui est loin d'être le cas de tout les @redhat), en tant que mainteneur upstream, il est très réactif et se montre coopératif avec les autres distros (pas de soucis particuliers avec Debian, OpenSuSE, Mageia, Frugalware etc ...).
            Certes, il a son franc-parler et ses positions très marquées mais c'est très loin des cas pathologiques des personnes impliqués dans la GLibc. Ce serait plus Linus que Ulrich Drepper par exemple.

            • [^] # Re: C'est quoi un motif valable ?

              Posté par  . Évalué à 6.

              Une preuve de cette distinction, c'est que tous les produits conçus par Lennart ont été intrégrés dans les distributions majeures, alors que la libc est de plus en plus remplacée (comme Debian avec glibc).

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: C'est quoi un motif valable ?

                Posté par  . Évalué à 2.

                alors que la libc est de plus en plus remplacée (comme Debian avec glibc).

                Typo : s/glibc/eglibc/

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: C'est quoi un motif valable ?

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

            Ce qui fait donc, wow, une dizaine de personnes qui font peur chez Red Hat.

            Suis je le seul à me dire que dans une boite de 4000 personnes, ç'est statistiquement risible ? ( et ça, sans remettre en cause l'affirmation "font peur", car bon, je présenterais pas une interview de John McCann à Avoriaz, aussi effrayant que ça soit pour certains, faut pas non plus déconner ).

            Bien sur, comme ils bossent sur des projets publiques, on les voit et c'est vrai qu'on peut pas en dire autant de la vaste majorité de l'industie informatique. Sauf qu'en pratique, tout les gens vont te dire qu'il y a tel con dans tel service de leur boite. Donc c'est pareil partout.

  • # Re:

    Posté par  . Évalué à -10.

    Je n'ai pas envie de lire tous les commentaires.
    Je ne comprend pas le scandale qui est fait ici. Il y a eu une modification de la libc qui n'est pas une erreur, mais ça déclenche plein d'erreurs d'autres programmes. C'est indiscutablement pénible, mais ce sont des choses qui arrivent et c'est normale surtout pour une distribution en phase de test.
    L'immobilisme ne crée pas d'erreur, mais c'est de l'immobilisme.

    Après on peut toujours discuter si cette mise à jour devait être faite pour F16 qui sort bientôt. Clairement non. Mais c'est facile à dire après coup. Ici c'est un problème de gestion de projet de Fedora et non de la libc.

    • [^] # Re:

      Posté par  . Évalué à 5.

      il y a eu une modification de la libc qui n'est pas une erreur, mais ça déclenche plein d'erreurs d'autres programmes.

      Non, Fedora 16 est en phase de finalisation (la release c'est dans deux semaines), donc ça n'est absolument pas le moment d'introduire des nouvelles fonctionnalités qui n'ont pas été testées du tout.

      Ici c'est un problème de gestion de projet de Fedora et non de la libc.

      Personne n'a critiqué les mainteneurs de la GLibc pour bosser en amont, mais qu'ils ne font pas correctement leur boulot de mainteneurs Fedora. À partir de l'alpha, on est sensé ne plus introduire de nouvelles fonctionnalités (il faut demander l'accord du comité technique et avoir un plan béton), et on ne pas balance pas des snapshots gits upstream au hasard (surtout qu'ils ne s'embarassent pas de corriger les bogues rapportés dans le bugzilla fedora).
      Sans compter qu'il n'y a aucune communication de leur part, quand on introduit des modifications sensées impacter d'autres paquets, on doit prévenir la liste de diffusion ou du moins les mainteneurs concernés.

    • [^] # Re:

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

      Je n'ai pas envie de lire tous les commentaires.

      Tu devrais. Ca éviter de répéter.

    • [^] # Re:

      Posté par  . Évalué à 1.

      En l'occurence, c'est un comportement erroné de la glibc, sauf si on considère que toutes les variables pouvant être touchées par des threads devraient être marquées comme volatile (ce qui niquerait quasi toutes les optimisations alors qu'il est plus simple de juste bloquer ces optimisations au niveau des mutex).

      • [^] # Re:

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

        Pour le point de détail, définir une variable comme volatile ne suffit pas à ce qu'elle soit thread-safe.
        Pour que ce soit le cas, il faut que le processeur puisse écrire cette variable en une instruction.
        Et je crois même que ce n'est pas une condition suffisante.

        Après recherche, en fait non c'est pas suffisant... Et même parfois il vaut mieux ne pas le mettre !

        Cf http://kerneltrap.org/Linux/Volatile_Superstition et toutes les réponses de Linus (très instructives !)

Suivre le flux des commentaires

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