Les patches oubliés

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
26
fév.
2002
Noyau
Un slashdotter signale un article intéressant paru sur le site de Gentoo Linux.



Pour résumer, certains gros vendeurs Linux, tels que RedHat ou Mandrake, fixent de nombreux bogues plus ou moins mineurs dans les kernels qu'ils distribuent. Et ces patches, le plus souvent, ne sont jamais intégrés dans la distribution officielle. Après tout, la GPL n'oblige personne à envoyer ses modifications au mainteneur du code.



Est-ce un bien ou un mal, ces patches sont-ils de mauvaise qualité ? En tous cas Gentoo pense que des gens devraient se pencher sur le problème, tels que les membres du Kernel Janitor project.

Aller plus loin

  • # Perplexe...

    Posté par  . Évalué à -5.

    J'aime beaucoup gentoo (que j'utilise avec grand plaisir), mais sur ce coup la je m'interroge...

    Ne serait-ce pas pour eux un moyen de ternir l'image des distros "mainstreams" en esperant recuperer des users?

    Oh et puis a la limite ca serait de bonne guerre: qu'elle continue! ;)

    • [^] # Re: Perplexe...

      Posté par  . Évalué à 10.

      Je vois pas comment cela pourrait ternir l'image des distribs les plus connues. Au contraire. L'auteur dis justement que les distribent fournissent des patches pour corriger les problèmes.

      A mon avis, cet article n'est pas fait pour dénigrer qui que se soit, mais pour faire prendre conscience aux mainteneurs du noyau qu'il y a peut-être des patches a intégrer.

      • [^] # Re: Perplexe...

        Posté par  . Évalué à 10.

        > mais pour faire prendre conscience aux mainteneurs du noyau qu'il y a peut-être des patches a intégre.

        Mouais.

        Je crois qu'un noyau RH officiel (2.4.9) a pres de 150 patchs (la pluspart ne sont pas specifiques RH) et RH (comme d'autre) se balade dans la mailing kernel et ne demande pas mieux que leur patch soit integre au noyau officiel : Un patch de moins a maintenir :-> .

    • [^] # Re: Perplexe...

      Posté par  . Évalué à 10.

      Je suis assez d'accord. L'importance donnée par gentoo à ce sujet me semble démesurée.
      Les kernels hackers de toutes les grosses distributions font deja tout pour se coordoner (a quelques exceptions près), et la chose n'est pas facile.

      PS: ici, tout les bugfixes internes sont soumis au kernel maintainer.

  • # Bof

    Posté par  . Évalué à 10.

    Quand on sait le temps que peut mettre un bugfix pour arriver dans le noyau officiel...

    Serieux, l'article c'est du vent.

    Linus est toujours deborde, les patchs sont disponibles pour ceux que ca interressent ...

    Enfin, le noyau Linus est surtout une "infrastructure" (propre, multi-plateforme, stable, sure, etc...). Apres les derniers perfectionnements/optimisation (meme dangereux), le petit patch qui va bien, etc... ce n'est pas le boulot des developpeurs de Linux (je pense Marcelo, Linux, Alan).
    Si l'experience montre qu'un patch RH (par exemple) est stable et indispensable Alan va le proposer. Il va pas faire genre : pas vu, pas pri.

    Ou est le probleme ?

    • [^] # D'accord.

      Posté par  . Évalué à 10.

      En effet, je pense que les responsables du noyau savent de quoi ils parlent et dans quel sens ils veulent aller.

      Libre à chaque distribution de faire les modifications ou de patcher les noyau pour répondre aux spécificités ou aux spécialités qui veulent développer. Je pense par exemple au patch de supermount inclu dans la mdk.

      Personnellement, je trouve que le travail autour du noyau est impressionnant et efficace et je ne vais pas du tout dénigrer une nouvelle version du noyau car elle n'a pas intégré une toute nouvelle fonctionnalité interressante que telle distribution propose. Libre à chacun de configurer, patcher, modifier ses sources. C'est bien ça le monde du libre, non ?

      • [^] # Re: D'accord.

        Posté par  . Évalué à 10.

        Il me semble que l'auteur de l'article ne parle pas des patch qui ajoutent des fonctionnalités au noyau, mais bel et bien de correction de bug.

        Encore une fois, cet article (lis le, tu verras, il est pas long), ne dénigre pas l'équipe du noyau.

        • [^] # Re: D'accord.

          Posté par  . Évalué à 10.

          L'article n'est pas mechant.

          Mais que conclure ?
          - Que les mainteneurs font mal leur boulot ?
          - Que les distribs font mal leur boulot ?
          - Que la "communaute" n'"emmerde" pas asser les mainteneurs pour des petits patchs.

          Regarde le nouveau 2.4.18 et son nombre de correction apportes (la 2.4 a presque 14 mois !).

          Pourquoi un bug-fixe n'est pas applique :
          - pas le temps et mineur.
          - pas propre.
          - travail d'evolution en court la ou est applique le bug-fix.
          - perdu ! etc...

          Bref il y a plein de raisons bonnes et moins bonnes.

          Mais la perfection n'est pas de ce monde.
          Une comparaison avec la concurrence commerciale montre de les corrections de bug se perdent moins souvent et sont tres prioritaire.

    • [^] # Re: Bof

      Posté par  . Évalué à 5.

      >Si l'experience montre qu'un patch RH (par exemple) est stable et indispensable Alan va le proposer.

      ouais mais pour ça faudrait qu'Alan sache ce que font les mainteneurs du kernel chez RedHat.

      ok, je --> []

      • [^] # Re: Bof

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

        Je vais dire une betise mais, par le plus grand des hasards, Alan Cox ne bosserait-il pas pour RH ?

        2c
        Laurent

        • [^] # Re: Bof

          Posté par  . Évalué à 3.

          ... je crois que c'était une plaisanterie ...

        • [^] # Re: Bof

          Posté par  . Évalué à 10.

          De mémoire (comprendre, je me trompe surement):

          Alan travaille pour Linux UK ou il bosse pour la partie SAV de RedHat. La plus grande partie de son temps est consacrée a l'écriture de drivers pour faire fonctionner tel ou tel materiel sous Linux (d'ou le côté SAV).

          Il ne travaille absolument pas sur le kernel de RH, maintenu principalement par un autre employé de RH (dont j'oublie completement le nom) qui travaille aux Etats-Unis.

  • # Pour info : le 2.4.18 est sorti

    Posté par  . Évalué à -2.

    tout est dans le titre.

    • [^] # Re: Pour info : le 2.4.18 est sorti

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

      Et pour info, contrairement à d'habitude, il vaut mieux prendre l'archive que le patch.
      En effet, il manque à celui-ci un bug-fix (mineur certes, mais quand même).

      • [^] # Re: Pour info : le 2.4.18 est sorti

        Posté par  . Évalué à 10.

        L'info comme quoi le tar.gz (contenant le -rc4) et pas le patch est fausse.
        Les 2 sont au stade du -rc3, et la correction du -rc4 n'est que ds la 2.4.19-pre1.
        Voir kernel-trap pour une explication claire (et slashdot pour vous embrouiller :)).

        • [^] # Re: Pour info : le 2.4.18 est sorti

          Posté par  . Évalué à 10.

          Pour être correct et précis: le noyau 2.4.18 n'est ni le 2.4.18-rc3 ni le 2.4.18-rc4; il y une partie du patch -rc4 dedans mais pas la totalité.

          Le pb que ce patch corrige est lié à l'exécution de binaires statiques sur certaines archis (x86 non comprises). Donc, pour 95% d'entre nous qui utilise GNU/Linux sur un x86, le 2.4.18-rc3, -rc4 ou -final revient au même.

          Pour ceux qui ne sont pas sur x86, il vaut mieux prendre le -rc4.

      • [^] # non x86

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

        Si linuxfr avait passe ma news, les lecteurs sauraient que ce patch concernent les architectures autres que x86 ...

        Steph

  • # c'est un avis comme un autre

    Posté par  . Évalué à 5.

    Oui, des gens peuvent raler que leurs patches sont ou pas pris en compte. Il n'empeche que tout integrer rapidement impliquerait bacler un tant soit peu la chose, et quand on sait ce que ca donne (sans troller), surtout si le but est de creer quelque chose de stable...
    d'ailleurs, NDLR : Linux is the property of Linus Torvalds.

    • [^] # Re: c'est un avis comme un autre

      Posté par  . Évalué à -3.

      Toujours est-il que si les testeurs de distribs font le choix d'intégrer ces patch, c'est que ce n'est pas tant que cela du baclage.

      « NDLR : Linux is the property of Linus Torvalds. »

      Je trouve étrange qu'il ne délegue pas un minimum. Apparement il est incapable de gérer l'afflux de patchs...

      • [^] # Re: c'est un avis comme un autre

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

        Je trouve étrange qu'il ne délegue pas un minimum. Apparement il est incapable de gérer l'afflux de patchs...
        Surtout qu'il existe des outils libres permettant de travailler de manière collaborative, genre CVS quoi... Mais Linus est une tête de mule, donc...

        • [^] # Re: c'est un avis comme un autre

          Posté par  . Évalué à 2.

          T'es dur avec lui. Il s'est mis a bitkeeper, et ca a l'air pas mal.
          CVS reste trop limité pour le noyau. CVS marche bien si on a un seul repository, mais pour Linux c'est pas faisable (trop de développeurs).
          BitKeeper semble être pas mal de ce côté là. Mais le sujet a déjà été discuté lors d'une autre news...

      • [^] # Re: c'est un avis comme un autre

        Posté par  . Évalué à 10.

        De toute façon ce n'est plus Linus qui s'occupe de la branche 2.4 mais Marcelo Tosatti; Linus ne s'occupe que du 2.5.

        Marcelo Tosatti est assez surchargé, et c'est compréhensible, et c'est pour cela qu'Alan Cox maintient sa branche (-ac) dans laquelle il intègre plus de patchs, qu'il soumet à Marcelo lorsqu'il les trouve assez propres et testés (note: je simplifie énormément le fonctionnel réel...)

      • [^] # Re: c'est un avis comme un autre

        Posté par  . Évalué à 2.

        > Apparement il est incapable de gérer l'afflux de patchs...

        Vu la vitesse de developpement il se debrouille bien le gaillard pour tout faire !

        > Je trouve étrange qu'il ne délegue pas un minimum.

        Il delegue. Pour les personnes de confiance, il applique les patchs les "yeux fermes" (c'est le but de son nouvel outil dont j'ai oublie le nom).

        > Linux is the property of Linus Torvalds.

        Le nom "Linux" seulement. Libre a toi de faire un fork et d'appliquer les patchs plus vite que lui ... et au moins de facon aussi pertinante et sans te faire allume par les autres developpeurs...

    • [^] # Re: c'est un avis comme un autre

      Posté par  . Évalué à 2.

      Je dirais meme:

      Il vaudrait mieux que certains ralent car leurs patchs ne sont pas ou peu pris en compte.

      Sinon ca voudrait dire que les mainteneurs du kernel ne regardent pas trop ce qui finit dans le kernel et acceptent n'importe quoi.

      Mais bon, le tout est de trouver un juste milieu entre tout accepter tout de suite et ne rien accepter.

  • # A propos du patch utilisé comme exemple

    Posté par  . Évalué à 10.

    Lire le commentaire d'Alan Cox dans la nouvelle sur shashdot. Le patch pris comme exemple a en fait bien été soumis, mais comme le fait qu'il soit correct n'était évident, que tout ce qu'il corrigeait était une surallocation d'une page mémoire, les développeurs ont décidé d'attendre 2.5 pour l'incoporer.

  • # sympa gentoo

    Posté par  . Évalué à 8.

    j'aime bien gentoo, ils se bougent bien et se penchent sur plein de problemes trop souvent negligee par les autres distro
    je crois que leurs presence est un plus pour tout le monde, ca fait un peu bouger les choses.

  • # kernel 2.5 le bug no limit ;))

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

    Je ne sais pas pour vous, mais j'ai tenté plusieurs fois d'installer les versions 2.5.x, chez moi c est completement buggé...

    ca me balance pas mal d'érreur avec les systèmes de fichier, et l'adressage mémoire des disk ide...

    Je sais que les impairs c est des versions instables, je crois que c est pas bon de passer au 2.5 sauf pour les kernels hacker ;()

    @+ Code34

    • [^] # Re: kernel 2.5 le bug no limit ;))

      Posté par  . Évalué à 5.

      les versions impaires dites "instables" sont meme carrement des versions de developpement. Le dernier numero est incremente parfois plusieurs fois dans la meme journee et des modifications profondes du noyau sont acceptées. Il n'est pas impossible par exemple que certains systemes de fichiers ne fonctionnent plus pendant plusieurs release de version "impaire" du noyau sans que cela ne gene personne: c'est réservé aux développeurs.

      La premiere version (2.5.0) vient directement de la branche 2.4 donc assez stable mais rien a gagner autant utiliser le dernier 2.4.x
      Puis les modifications les plus profondes sont faites dès le départ. les premières versions d'un noyau impair sont donc TRES INSTABLES. Quand toutes les modifications "dangereuses" ont été faites, il reste a fiabiliser, puis le dernier 2.5.x deviendra un 2.6.0 (donc les derniers 2.5.X seront utilisables pour les plus avantureux, tous les fs fonctionnent, etc).

      En ce moment on est pile poil dans la période ou le 2.5.x est ULTRA INSTABLE. Ce ne serait meme pas étonnant que certaines release ne compilent pas.
      <troll>
      ca c'est meme vu sur des release dites stables alors vous pensez bien ..
      </troll>

Suivre le flux des commentaires

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