La crise des patchs du noyau

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
1
mar.
2002
Noyau
Le gourou de l'Open Source, Eric Raymond, a dit que la création de patchs du noyau Linux est en crise et il a renouvelé son appel pour que quelqu'un viennne en aide à Linus Torvalds en tant que "penguin patch lieutenant."

S'exprimant lors d'une conférence organisée par le "UK Unix Users Group" à Londres mercredi soir, Raymond précise que les patchs du kernel sont l'un des vestiges de la centralisation dans le développement Open Source.
Il a dit aussi que Linus a "atteint ses limites de stress" et qu'une personne seule ne pouvait traiter tous les patchs proposés par les développeurs du noyau.
Les patchs, dont beaucoup pourraient aider au développement de Linux, ne sont pas pris en compte et ce sans raison apparente a observé Raymond.

Avis aux amateurs!

Aller plus loin

  • # Les patch-penguins non-officiels

    Posté par  . Évalué à 10.

    Il faut savoir qu'il existe déjà des patch-penguins (= des personnes chargées de centraliser, tester, nettoyer les patches dans une branche parallèle du noyau avant de les soumettre au mainteneur), il s'agit d'Alan Cox pour la branche 2.4 et de Dave Jones pour la branche 2.5. Ils n'ont aucun statut "officiel", mais ils font néanmoins un très bon boulot.

    Le principal problème est que Linus et Marcelo veulent tous les deux contrôler et vérifier au moins rapidement l'ensemble des patchs qu'ils intégrent (ce qui est compréhensible) et qu'avec l'accroissement du nombre de contribueurs ils n'ont plus le temps de les analyser tous et encore moins d'expliquer les raisons de leur refus lorsqu'un patch ne convient pas (Linus a tendance à discarder les patchs sans rien dire).

    Le problème est assez compliqué et les débats sur la LKML pas toujours facile à suivre, mais c'est en gros ce que j'ai compris.

    • [^] # BitKeeper?

      Posté par  . Évalué à 10.

      Linus n'a t'il pas commencé a utiliser BitKeeper pour cette raison il y a quelques semaines?

      Il faudrait peut etre attendre un peu pour voir si les choses s'ameliorent avant de se (re)mettre a gueuler.

      • [^] # Re: BitKeeper?

        Posté par  . Évalué à 6.

        Oui, on peut suivre toutes ces histoires résumées toutes les semaines dans la sections kernel de la linux weekly news.

        Ils ne font pas que reprendre les propos des intervenants, ils essayent de prendre un peu de recule sur la situation, de voir les enjeux, ...

        Pour l'histoire de BitKeeper par exemple, c'est ici : http://lwn.net/2002/0207/kernel.php3(...)
        "...
        The real potential of BitKeeper will be realized when a sufficient number of other kernel developers start using it. BitKeeper makes it easy to move specific patches between repositories, and provides some seriously slick tools for handling merges. With luck, a more productive kernel development team will emerge from the testing period. Meanwhile, however, as Larry points out:

        On the other hand, he's only been using it for a week and he isn't saying it is the best thing since sliced bread. So it's a bit premature to predict whether he will be using it in a month or not. We hope so, and we'll keep working to make you happy with it, but Linus is a harsh judge - if BK doesn't help out, he'll kick it out the door.

        Stay tuned.

        ..."


        C'est beaucoup plus simple que de suivre les résumés de le lkml.

    • [^] # Re: Les patch-penguins non-officiels

      Posté par  . Évalué à 10.

      Je crois qu'il ne faut pas aussi perdre de vue qu'il y a aussi des "mainteneurs" officiels de différentes parties du noyau (de mémoire Alan Cox est celui qui s'occupe des pilotes 3com par exemple).
      De cette façon, une dévellopeur produisant un patch devrait normalement le soumettre d'abord à ce genre de personne, parceque d'une part ils sont sensés être moins occupés que Linus ou Marcello, de plus, ces gens ont la confiance des grands gourous, ce qui fait qu'une fois que le patch est vérifié par un mainteneur, il n'y a plus de raison pour qu'il ne soit pas intégré de suite.

      Mais bon, ça c'est de la théorie, et je suis pas sûr que tout puisse se résoudre ainsi...

      Mais comme le précise l'article de gentoo http://www.gentoo.org/news/20020226-guru2.html(...) qui suit celui qui a été mis en avant sur LinuxFr du [25/25] "Les patches oubliés" le problème est quand même très compliqué puisqu'il ne suffit pas de corriger un bug pour que ça fonctionne bien avec une certaine plateforme, si c'est pour que ça marche plus sur une autre.
      Linux à l'avantage d'être multi-plateforme, n'oublions pas que c'est ça fait fait sa force (entre autres)

      Salut chez vous!
      Guillaume

  • # plus d'info

    Posté par  . Évalué à 10.

    Il me semble que Linus delegue certaines parties. Par exemple Alsa qui est enorme a ete rapidement integre.

    Si quelqu'un se promene dans les mailing-list kernel, peut-il confirmer qu'il y a de reels problemes (et non des plaintes isolees) ?

    Quel est l'avis de Linus ?

    Je crois que c'est Eric qui pique une petite crise comme le sous-entend lwn.net :
    "Eric, of course, is increasingly frustrated that HIS patches have not yet gone in... "

    Domage que linuxfr colporte ce type de news (c'est l'avis d'une personne et non ce qui resort de kernel-traffic par exemple).

    • [^] # certes, mais...

      Posté par  . Évalué à 10.

      ...puisque tu lis kt, tu sais aussi que de toutes façons ce sont les prises de bec, les désaccords, les petites guerres entre devs qui font avancer le shmilblick. Puisque le developement est ouvert, le process est transparent. Pour quelqu'un habitué au bullshit marketoïde du monde proprio où tout va bien dans le meilleur des mondes avec des devs tout gentils qui font les meilleurs produits du monde (enfin on nous le dit puisqu'on ne les connait pas et que la com est vérouillée à un niveau où la technique n'a plus d'importance en elle-même), ça doit être déconcertant de voir l'aspect darwinien du dev de Linux : les meilleurs (oublions les critères) patchs survivent, les autres crevent. En gros tout le monde se fout sur la gueule et à la fin ça finit par un banquet (en fait c'est très gaulois comme style de dev).

      • [^] # Re : certes, mais...

        Posté par  . Évalué à 10.

        C'est hyper juste.

        Hors querelle de cloche, je vois que linux evolu super vite et bien. Surtout compare aux Unix commerciaux.
        Certain vont dire qu'il n'est pas normal d'attendre pres d'un an pour un 2.4 stable. Moi ca me choque pas compte tenu des fonctionnalites et du nombre de drivers.
        Les boites qui utilisent des Unix commerciaux et veulent un systeme fiable ne prennent pas la version sortie l'annee precedante !

        C'est pareille pour Linux (c'est meme mieux).

        Certain pense que si Linux etait sous CVS avec droit d'ecriture ca irait plus vite.
        Plus vite peut-etre mais avec plus de bordel c'est sure.
        La lourdeur (relative) du developpement de Linux est lie a toutes les phases de controle/concertation (que les meme qui veulent un developpement plus rapide trouve insuffisant).

        Bref, plein cul des gens qui gueulent alors que Linux est recent et est presque la rolls des noyaux Unix :
        - plein de drivers et de tres loin.
        - multi-plateforme.
        - 32 et 64 bits.
        - modulable.
        - version temps reel.
        - le top en reseau (ipv6, firewall, etc...).
        - etc...

        Je trouve les linuxiens limite cassent couilles. Ils gueulent car un petit patch n'est pas applique alors qu'un windowien se felicite que Microsoft est corrige un trou de securite vieux de 3 mois.

        Le plus choquant est le manque de respect pour les developpeurs (souvent benevoles) et qui merite notre consideration.

        • [^] # Trou de sécurité

          Posté par  . Évalué à 6.

          un windowien se felicite que Microsoft est corrige un trou de securite vieux de 3 mois.
          Ce qui prends 3 mois, c'est pas de corriger le trou mais de faire les tests de QA (assurance qualité) pour vérifier que quel que soit la configuration possible (DLL, version de windows) ça ne plantera pas à cause d'un conflit stupide (Unix a aussi ses problèmes de libc et de dépendance): c'est le revers du plug'n'play.

          Un admin UNIX qui corrige lui-même un trou, acceptera si le programme plante, de chercher à cause de quoi il y a un conflit, de le résoudre voir de revenir en arrière sur sa modif.

          En même temps, si tu as un grand nombre (disons plusieurs centaines) de serveurs à administrer, la solution du patch "plug'n'play" peut être la seule envisagable, en contrepartie elle a l'inconvénient d'introduire plus de délais dans la sortie du patch.

        • [^] # Re: Re : certes, mais...

          Posté par  . Évalué à -7.

          alors qu'un windowien se felicite que Microsoft est corrige un trou de securite vieux de 3 mois.

          C'est con alors, parce qu'on prend moins de temps que les gars de Debian pour sortir nos patchs.

      • [^] # Re: certes, mais...

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

        [...]
        > ...puisque tu lis kt, tu sais aussi que de toutes façons ce sont les prises de bec, les désaccords,
        > les petites guerres entre devs qui font avancer le shmilblick.

        Si on ote le bruit dont il ne sort rien et dont la l-k est coutumière, les discussions constructives
        viennent essentiellement de personnes dont le comportement est plutôt professionnel et qui ne
        donnent guère dans le sentiment ou le pissing-contest.
        Les discussions ne demandent qu'à diverger si l'occasion se présente pour le /.eur de venir
        mettre son grain de sel. L'effort consiste à s'abstenir de toute considération inutile.
        Les exceptions sont rares.

        Quand ESR sera capable de fournir au public de la l-k ce qui l'intéresse dans son travail sans
        l'obliger à se farcir tout le reste, une partie des pseudo-problèmes liés au développement du
        noyau aura trouvé sa solution. C'est malheureux à dire.

    • [^] # Re: plus d'info

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

      ben ca fait plus de trois ans que je lis les listes du kernel et je ne pense pas qu'il y ait un problème. En fait il n'y a que esr qui a un problème. Son patch (cml2) est rejeté plus ou moins unaniment parcequ'il a tout réécrit au lieu de corriger l'existant. Son "excuse", c'est que l'ancien système ne peut être corrigé mais beaucoup de gens (alan cox par exemple) lui ont prouvé le contraire.

      Il a été prouvé à maintes reprises qu'intégrer un gros patch crée plus de problème que ca n'en résoud (vm par exemple). Le mode de fonctionnement correct est par exemple celui d'al viro (mainteneur du vfs) qui est en train d'intégrer une réécriture complète du vfs par petit morceau. Evidemment ca demande plus de travail pour le développeur. Si esr avait travaillé par étapes, il ne serait pas obligé de troller comme un fou sur les mailings lists.

      • [^] # Re: plus d'info

        Posté par  . Évalué à 10.

        Effectivement.

        Pourtant de mon cote je me suis laisse seduire par la publicite de ESR sur cml2. Ca a l'air bien son truc, sur le papier tout du moins, je ne l'ai pas testé.
        Je pense qu'il faudra bien l'integrer un jour ...
        ce serai dommage de jeter ce travail si il est pas mal fait. Il devra surement le scinder en petits patchs ou alors Linus va finalement accepter (sur le 2.5 c'est quand meme pas trop risque surtout que c'est le debut du 2.5).

        Il y avait le meme probleme pour les patchs pcmcia, ou meme usb il me semble. soit ils ont ete integre petit a petit (scindés donc), soit Linus a cracké a force d'arguments (mais avec la promesse du mainteneur que l'on ne l'y reprendrait plus).

        qui vivra verra...

        • [^] # ESR et cml2

          Posté par  . Évalué à 7.

          Son truc a l'air effectivement tres bien, mais il necessite une version recente de python pour fonctionner. Et ca, un bon nombre de developpeurs n'en veulent pas.

          • [^] # Re: ESR et cml2

            Posté par  . Évalué à 8.

            J'avoue que moi aussi j'ai bien aimé son appli. pour ceux qui veulent apprendre l'OOP, le code source est un modèle du genre et d'une clarté incroyable.

            il necessite une version recente de python
            c'est faux, du moins en théorie.
            Il est tout à fait possible (en tout cas beaucoup le disent) de fabriquer un executable "standalone" à partir d'un application python.
            je crois que l'utilitaire s'appelle py2exe ou quelque chose comme ça. Il permet d'intégrer dans l'appli les lib nécessaires ainsi que l'interpréteur, et permet donc de l'utiliser sans avoir python installé sur la machine.

            nombre de developpeurs n'en veulent pas
            Je ne suis pas beaucoup kt, pourrait-tu me dire quels sont leurs arguments ?

            d'autre part, en regardant sur la page de cml2 http://tuxedo.org/~esr/cml2/(...) , il y a un lien vers le projet "cml2-to-C compiler", qui permettrait de mettre tout le monde d'accord, a moins que certains ne veuillent même pas de C dans le kernel ;)

            C'est vrai qu'esr est un fan de python, il l'a utilisé pour écrire fetchmail entre autres. Il explique son choix de python dans un article du linux journal : http://www.linuxjournal.com/article.php?sid=3882(...)

      • [^] # ESR a un problème...

        Posté par  . Évalué à 3.

        ... mais c'est plus au niveau de l'ego à mon avis qu'au niveau de cml2.

    • [^] # Re: plus d'info

      Posté par  . Évalué à 10.

      Et bien je dirais qu'il y a réellement quelques problèmes, mais qu'ils ne sont pas du tout aussi important qu'ESR ne le laisse croire. Le plus gros problème qu'il y a eu AMHA est sur la VM, où Linus a ignoré tous les patchs de Rik du noyau 2.4.0 au 2.4.9, ce qui fait que la VM des noyaux "officiels" < 2.4.10 marche très mal, alors que les noyaux -ac de la même période, avec les patchs de Rik, marchent beaucoup mieux (enfin, beaucoup moins mal diront certains).

      Sinon il est vrai aussi que Linus (en général) ignore les patchs qui ne lui plaisent pas, au lieu de signaler la raison de son refus à l'auteur du patch (que celui-ci puisse corriger), mais je comprends qu'il n'aie pas du tout le temps de faire ça.

      • [^] # Re: plus d'info

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

        Linus c'est expliqué sur le pourquoi il semble ignorer les patchs. Le problème c'est que si il répond un truc genre "locking is incorrect", il est sur que la personne va lui renvoyer un mail lui demandant d'être plus explicite. Et il va perdre 15 minutes à lui répondre. C'est pour ça que les patchs ne doivent jamais aller directement à linus, mais au mainteneur du sous système correspondant.

        • [^] # Re: plus d'info

          Posté par  . Évalué à 10.

          Et quand c'est le mainteneur du sous-système qui envoie le patch ? Comme Rik pour la VM au début du 2.4 ?
          Je suis parfaitement conscient que Linus ne peut pas justifier tous ses refus, mais ça pose quand même un réel problème, AMHA.

          • [^] # Re: plus d'info

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

            Pour la vm de rik, c'est spécial. C'est linus qui a vu passé le patch sur la mailing list et l'a appliqué. Mais rik ne l'avait pas envoyé à linus en demandant l'inclusion.

  • # Mouais

    Posté par  . Évalué à -4.

    Ca peut vouloir dire plein de choses cette information : une lutte de pouvoir, ou bien est-ce la popularité de linux elle-même qui est stressante ?

  • # Bof.

    Posté par  . Évalué à 3.

    Eric Raymond a aussi dit que selon lui des que les PC seraient en dessous de xx $, ce serait la fin de Microsoft car leur OS serait trop cher.

    Ce qui est stupide, car il suffira alors a Microsoft de reduire le cout de son OS!

    Non il dit un peu trop de betises en ce moment..

    • [^] # Re: Bof.

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

      D'autant que le prix de l'OS est masqué par la vente forcée de l'OS, dont le prix est inclus dans le prix du matériel...
      Une baisse du prix final peut donc se faire sur la baisse du matériel, et sans récrimination des utilisateurs concernant le prix de l'OS.

  • # Contribute ....

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

    Salut,

    Comme je l'ai lu un peu plus haut, le développement sur le kernel est partagé entre plusieurs personnes...

    Linus ne fait pas évoluer le kernel tout seul...

    Pour faire appliquer un patch, il faut avant tout s'adresser à la personne qui a développé la partie du noyau concernée.

    C'est pas bien compliqué, en fait à la racine du noyau linux vous avez un fichier CONTRIBUTE qui liste toutes les personnes qui ont participées au développement du noyau, sur quelles parties, avec les emails (ou comment les contacter)

    Donc a priori faire appliquer un patch, ça reste possible du moment qu'on a un bon dossier à coté qui explique le problême, la portée de la correction, les parties du sources que cela modifie, etc ... Envoyer un code brut meme si il est génial, ça ne donne pas envie de le consulter.

    @+
    Code34

    • [^] # Re: Contribute ....

      Posté par  . Évalué à 5.

      Et oui, je tiens à rappeler que commenter et documenter son code, expliquer ce qui est fait, comment et pourquoi est *très* important dans un projet de cette ampleur, contrairerement à ce que prétend un certain A.A. (cela étant dit sans aucune animosité particulière... ;) )

Suivre le flux des commentaires

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