Journal Noyau Linux : Chasse aux Bugs.

Posté par  .
Étiquettes : aucune
0
10
mai
2006
http://www.generation-nt.com/actualites/14733/linux-kernel-m(...)

Articles de génération NT qui affirme que "selon Andrew Morton, le kernel de Linux dans sa version actuelle 2.6, connaît un nombre croissant de bogues. [..] Morton a fait part de ses inquiétudes en relation directe avec ses fonctions au sein de l' Open Source Development Labs : " Je crois que le kernel 2.6 devient lentement de plus en plus bogué, il semble que nous ajoutons des bogues plus vite que nous n'en corrigeons "."

Je trouve ça interressant, il me semble que c'est cyclique que les developpeurs se pose une seconde, gèle les fonctions et se mettent à une chasse aux bugs.

  • # info

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

    Propos qui ont fait sensation au grand damne de Linus :
    "Réponse de Linus Torvalds ! Le père spirituel du système libre déplore le côté sensationnel avec lequel ces propos ont été tenus, même s’il ne nie pas la présence et l’existence de ces bogues. Torvalds se veut rassurant : aucune nouveauté ne devrait être ajoutée à la prochaine mise à jour du noyau, 2.6.18, l’occasion très certainement de se concentrer exclusivement sur la correction des imperfections actuelles."
    ( http://www.toolinux.com/news/opinion/trop_de_bogues_tuent_le(...) )

    On me souffle que le troll du micro-kernel pourrait réapparaître...

    • [^] # Re: info

      Posté par  . Évalué à 10.

      mais ce n'est pas un troll , un trol c est gros et grand, un micro-kernel c'est totu petit, rapide est sans bogue enfin !!!


      je suis dehors---->[]

  • # Confirme

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

    Les bugs, je les confirme, il y en a qui n’était pas présent avant... De puis que je suis passé en 2.6.10 je n'arrête pas d'avoir des messages d'erreur du genre sheduling while atomic .... ou de gros plantage sur le système de fichier (avec une trace sur un appel de fonction noyau inode....). Récemment j’ai même eu un plantage mais aucune trace dans les fichiers de trace. Les touches magiques ne fonctionnant même pas.

    Pour la première, ce n'est pas quelque chose de grave, pour l'autre j'essaierai de soumettre un bug, si elle se reproduit.

    Néanmoins je comprends qu'un système peut avoir des bugs. De toute façon c'est ma faute, je n'avais qu'a pas m'empresser de compiler le dernier noyau a peine il venait de sortir.

    • [^] # Re: Confirme

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

      >> je n'avais qu'a pas m'empresser de compiler le dernier noyau a peine il venait de sortir.

      heuuu....le 2.6.10 il est sorti y'a un moment déja !
      On en est au 2.6.16 maintenant (2.6.16.15 pour être exact).

      • [^] # Re: Confirme

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

        Ce n'est pas faux. Mais je l'installe à partir de kernel-source sous Debian, donc j'attends que les sources soit packager avant de le recompiler (d'où un petit délai).

        Et il est vrai que je suis peut-être dans une autre version depuis (je recompile à chaque nouvelle version pour voir si j'ai moins de problème).

        Mais c'est depuis le 2.6.10 que j'ai commencé à avoir des problèmes.

        • [^] # Re: Confirme

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

          Mais je l'installe à partir de kernel-source sous Debian, donc j'attends que les sources soit packager avant de le recompiler (d'où un petit délai).


          Il faut utiliser le paquet linux-source (au lieu de kernel-source). L'équipe de mainteneurs du noyau dans Debian est maintenant très réactive.

          Olivier;

          • [^] # Re: Confirme

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

            Oui, c'est ce que je voulais dire. (Pour le 2.6, je pense que kernel-source n'existe d'ailleur plus)

    • [^] # Re: Confirme

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

      Hum, je suis en 2.6.16.6 et je n'ai aucun soucis. J'ai compilé mon noyau aux petits oignons et RAS, aucun plantage. S'il plante, c'est parceque je me bat avec les drivers pourris binaires d'ati pour avoir une acceleration graphique et c'est tout... mais depuis que je suis repassé avec les libres, plus aucun soucis.

      • [^] # Re: Confirme

        Posté par  . Évalué à 6.

        On ne parle pas ici d'un noyau inutilisable, mais d'un noyau présentant de plus ne plus de bugs.
        On ne les voit pas forcement car tout le monde n'utilise pas stcp avec des cartes 10Ge.
        Faut pas psychoser non plus...

    • [^] # Re: Confirme

      Posté par  . Évalué à 2.

      De toute façon c'est ma faute, je n'avais qu'a pas m'empresser de compiler le dernier noyau a peine il venait de sortir.


      Je ne suis pas d'accord, si le noyau avait été sortie en version 2.6.10, c'est qu'il était jugé comme stable (depuis quand on release quelque chose d'instable ?)

      Je suis d'accord que pour une partie, ce sont des développeurs bénévoles qui font ça sur leur temps libre. Je les en remercie fortement.

      Néanmoins, ce n'est pas une raison pour accepter qu'un noyau qui sort soit instable/buggué. Ils n'ont qu'a releaser (beurk) moins souvent mais mieux. Il me semble qu'un dieu du kernel Linux (dont les initiales sont L T) a dit que si ça compile c'est bien, si ça boot c'est super et que donc les tests unitaires ne servait à rien... C'est le retour de baton on dirait...

      PS : c'est quoi le mot français pour release ?

      • [^] # Re: Confirme

        Posté par  . Évalué à 2.

        PS : c'est quoi le mot français pour release ?


        Le grand dictionnaire terminologique de nos cousins québécois donne « mise en production » et « mise à jour » comme équivalents.

        • [^] # Re: Confirme

          Posté par  . Évalué à 10.

          Quelques suggestions :

          "The release of X v.2 is planned..." (verbe substantivé) = "la sortie de X v.2 est prévue..."
          "The 2.6 release of..." = "La version 2.6 de..."
          "Linux 2.6.16.15 was released on..." = "La version 2.6.16.15 de Linux est sortie le..."

      • [^] # Re: Confirme

        Posté par  . Évalué à -6.

        Néanmoins, ce n'est pas une raison pour accepter qu'un noyau qui sort soit instable/buggué. Ils n'ont qu'a releaser (beurk) moins souvent mais mieux. Il me semble qu'un dieu du kernel Linux (dont les initiales sont L T) a dit que si ça compile c'est bien, si ça boot c'est super et que donc les tests unitaires ne servait à rien... C'est le retour de baton on dirait...


        Et on est tous persuadé que tu va :
        1- En écrire pour leur montrer l'exemple (non mais c'est vrai c'est qui ces guignoles qui savent même pas bosser, heureusement que tu es là pour leurs ouvrir les yeux)
        2- Convaincre touts les Ldevs d'en faire
        3- En oublier strictement aucun

        ça me fait penser à deux distributions bien connus dont l'une à décidée de faire des releases de choses à peine sortie qui ont des problèmes de retro-compatibilité et des bugs encore non dévoilé. Quand l'autre prend son temps (3 ans) pour ne sortir que du stable qui finalement reçoit des patchs la semaine suivante.

        • [^] # Re: Confirme

          Posté par  . Évalué à 6.

          Et on est tous persuadé que tu va :
          1- En écrire pour leur montrer l'exemple (non mais c'est vrai c'est qui ces guignoles qui savent même pas bosser, heureusement que tu es là pour leurs ouvrir les yeux)
          2- Convaincre touts les Ldevs d'en faire
          3- En oublier strictement aucun


          Je n'ai jamais dis (ni même pensé) qu'ils étaient des "guignoles". Il ne fait aucun doute qu'en développement système, ils sont bien meilleurs que moi.

          Cependant, je pense qu'il y a des bonnes pratiques pour coder. J'ai malheureusement l'impression que les devs du noyau Linux n'en respectent pas beaucoup :
          - API qui change tous les 4 matins
          (exemple du pilote NVidia qui devient incompatible à chaque version)
          - Absence de tests unitaires
          (problèmes de non-régression, vu ici même : un pilote qui marchait pour une version n et plus pour la version n+1, tout re-marchait à n+2)

          Pour ma part, j'évite de modifier une API sans y réfléchir. L'agrandir, OK, en modifier/supprimer des fonctions, non.

          J'impose aussi à l'équipe dont j'ai la responsabilité de réfléchir aux tests unitaires et seulement ensuite de les coder. De cette façon, j'espère qu'aucun tests n'est oubliés. Un jour quelqu'un m'a dit que une fonctionnalité non testée est équivalent à une fonctionnalité non implémentée. Je trouve cette remarque tout à fait censée.

          ça me fait penser à deux distributions bien connus dont l'une à décidée de faire des releases de choses à peine sortie qui ont des problèmes de retro-compatibilité et des bugs encore non dévoilé. Quand l'autre prend son temps (3 ans) pour ne sortir que du stable qui finalement reçoit des patchs la semaine suivante.

          Ouf, j'évite le troll, je n'utilise ni l'une ni l'autre...

          Plus sérieusement, avoir de "bonnes pratiques" n'impose pas d'être lent... On code la fonctionnalité, on code les tests et c'est bon. Ca rajoute juste une petite tâche supplémentaire au début.

          Ensuite, c'est un gain de temps car il suffit de lancer les tests à chaque modification pour vérifier que tout va bien. À chaque fois qu'un bug auquel on avait pas pensé survient, on rajoute le test qui va bien pour vérifier qu'il ne reapparait pas plus tard sous une autre forme.

          • [^] # Re: Confirme

            Posté par  . Évalué à 3.

            - API qui change tous les 4 matins
            (exemple du pilote NVidia qui devient incompatible à chaque version)

            On en a déjà parlé plein de fois ici, mais c'est pas l'API qui n'est pas stable, mais l'ABI. Et comme tes pilotes NVidia sont des binaires, bah tu es dépendant bon vouloir de cette société pour sortir une nouvelle version compatible...

            • [^] # Re: Confirme

              Posté par  . Évalué à 1.

              Je n'ai pas trouvé d'informations à ce sujet alors je pose la question :

              Puisque NVidia fourni avec le binaire quelques fichiers servant à faire la liaison entre le noyau Linux et le binaire, ne serait-ce pas plutôt un problème d'API ?

              Généralement, il suffit de modifier les fichiers sources en question pour permettre la compilation sur les nouvelles version de Linux.

              Autrement, je suis d'accord pour dire qu'une ABI stable permettrait de juste copier le binaire dans le répertoire kivabien pour que tout fonctionne, ce qui serait nettement plus simple que la procédure actuelle. Pour faire encore plus simple, l'idéal serait d'avoir des pilotes libres (mais ce n'est pas le sujet).

              • [^] # Re: Confirme

                Posté par  . Évalué à 4.

                non non, c'est bien un probleme d'abi (enfin je dis pas que les problemes d'api ne se posent jamais, mais l'abi pose aussi probleme).

                En gros, ton pilote binaire, il a ete builde contre une certaine abi.
                Donc quand il recupere une structure du kernel, il s'attend a la trouver sous une certaine forme.
                Si l'abi change, cette forme peut changer, et ce meme si l'api derriere n'a pas bronché d'un iota.
                Et du coup ton pilote se vautre comme une otarie bourree a la biere.

                • [^] # Re: Confirme

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

                  En gros, ton pilote binaire, il a ete builde contre une certaine abi.

                  Ce que dit le monsieur, c'est que l'abi contre laquelle le pilote est compilée, c'est l'abi d'une "colle" fournie par ce même pilote.
                  Lorsque l'api du noyau change, tu recompile la colle, qui s'adapte donc à la nouvelle abi du noyau. Mais l'abi de cette colle ne change pas, et donc le pilote marche toujours.

      • [^] # Re: Confirme

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

        Néanmoins, ce n'est pas une raison pour accepter qu'un noyau qui sort soit instable/buggué. Ils n'ont qu'a releaser (beurk) moins souvent mais mieux. Il me semble qu'un dieu du kernel Linux (dont les initiales sont L T) a dit que si ça compile c'est bien, si ça boot c'est super et que donc les tests unitaires ne servait à rien... C'est le retour de baton on dirait...


        "Release early, release often" comme dirait l'autre...
        Si tu n'es pas content de cette politique, pourquoi ne pas utiliser un autre noyau? De plus rien ne t'oblige à utiliser la dernière version du noyau, regarde chez slackware par exemple

        • [^] # Re: Confirme

          Posté par  . Évalué à 1.

          Tout à fait. C'est d'ailleurs un peu pour ça (et aussi parce que j'aime la nouveauté) que je lorgne du coté de FreeBSD.

          Mais j'ai un gros problème : mon /home c'est 370Go de données sur deux disques durs en LVM. Et ça, aucun BSD ne le gère pour l'instant (et peut être jamais)...

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

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

      • [^] # Re: Confirme

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

        Hmmmm !
        J'ai le driver nvidia proprio. Ce qui expliquerai les touches magiques qui ne fonctionne pas.

        Mais je l'ai installé car sinon, mon PC est lent, et la moindre ouverture de fenêtre prend 100% du CPU.

      • [^] # Re: Confirme

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

        oui mon noyau est teinté. j'utilise les drivers proprio pour profiter des beaux ecrans de veille de xscreensaver-gl, un peu limité comme utilisation, certes !
        Les touches magiques ne marchent egalement pas lorsque le driver ati a planté et a donc fait planté toute la machine.

  • # Le retour du 2.7 ?

    Posté par  . Évalué à 3.

    Est-ce que le fait que la méthode de développement ait changée, avec la disparition des noyaux "impairs" de développement y est pour quelque chose ?

    Avant, le principe était d'ajouter des fonctionnalités (et le bugs qui vont avec) dans le noyau de dev et de faire principalement de la correction de bug dans la branche "stable". Aujourd'hui on intègre directement les fonctionnalités dans la branche stable, elles ont donc forcément été moins dépoussiérées et il reste donc forcément plus de bugs...

    Enfin moi je dis ça.... Ils avaient certainement de bonnes raisons d'abandonner ce système de dev.

    • [^] # Re: Le retour du 2.7 ?

      Posté par  . Évalué à 3.

      Ils ont abandonné ce système car il y avait peu de béta-testeurs lors du développement de la branche 2.5 (tout le monde préférait le 2.4).

      Ils n'ont pas voulu réitérer la même situation avec le 2.6/2.7, et donc maintenant tous les changements sont intégrés directement dans le 2.6. La nuance en gros c'est que les utilisateurs finaux sont en pratique béta-testeurs.

      • [^] # Re: Le retour du 2.7 ?

        Posté par  . Évalué à 9.

        C'est sympa ca, je me souviens d'une societe americains dont les gens ici se moquent souvent avec cette exacte rengaine : les utilisateurs finaux sont des beta-testeurs.

        Visiblement, ici cela ne derange pas, va comprendre...

        • [^] # Re: Le retour du 2.7 ?

          Posté par  . Évalué à 10.

          Je n'ai pas dit que j'étais fan de ce nouveau mode de développement (c'est mon avis d'humble utilisateur). J'aimais bien l'ancien système.

          Cela dit, pour la société américaine dont tu parles, la subtile différence est que elle elle vend ses produits, et à un prix non négligeable. La moindre des choses, ça serait que les produits marchent correctement, et que cette société soit un peu plus modeste dans ses prétentions (cf l'arrogante campagne Get The Facts).

          Télécharger une distribution Linux complète, ça ne m'a jamais couté un radis, je serais bien mesquin de critiquer un travail bénévole de cette qualité. Si ça ne marche pas, je fais un rapport de bug, les développeurs sont d'ailleurs en général bcp plus réactifs que ceux de la société sus-cités.

          PS: ah bon, un troll, où ça ? ;)

        • [^] # Re: Le retour du 2.7 ?

          Posté par  . Évalué à 6.

          C'est sympa ca, je me souviens d'une societe americains dont les gens ici se moquent souvent avec cette exacte rengaine : les utilisateurs finaux sont des beta-testeurs.

          Disons que pour Linux, les utilisateurs finaux ne payent pas une centaine d'euros pour tester des bugs.

          • [^] # Re: Le retour du 2.7 ?

            Posté par  . Évalué à 2.

            https://www.redhat.com/apps/commerce/

            ;-)

            • [^] # Re: Le retour du 2.7 ?

              Posté par  . Évalué à 3.

              Voyons, voyons, soyons sérieux. Tout le monde sait que la version beta-test de RedHat est la Fedora qui est gratuite

              • [^] # Re: Le retour du 2.7 ?

                Posté par  . Évalué à 2.

                moui, enfin, elles ont grosso modo le meme kernel, en tout cas un 2.6 chacune, ce qui est le sujet de la discussion ici...

                • [^] # Re: Le retour du 2.7 ?

                  Posté par  . Évalué à 1.

                  Enfin il me semble qu'il patch le noyau.
                  On peut donc imaginer que le noyau livre a moins de bug que le dernier noyau disponible.
                  Il me semble que dans le noyau 2.6.n des distrib (d'autant plus celles payantes)sont backportes les corrections de bugs des noyau 2.6.n+x.

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 2.

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

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

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

          • [^] # Re: Le retour du 2.7 ?

            Posté par  . Évalué à 1.

            Donc en gros tu fais encore ton FUD a melanger clients et utilisateurs. MS vend son kernel et son windows donc tu es client donc tu as des droits (tu te rappelles le post sur ta voiture que tu achetes et qui s'arrete au bout de 10 km??), linus donne son kernel tu es utilisateur a tes risques et perils!

            Encore une fois, c'est pas le probleme.

            Je suis 100% d'accord sur le fait que MS a une obligation de fournir un produit de qualite a ses clients, qui l'ont paye.

            Le remarque concerne simplement les gens qui repetent a tue tete que la qualite du code de Linux est X fois mieux que Windows qui parait-il est mal code et teste par les utilisateurs.

            Hors, ce journal montre tres clairement que ce n'est pas le cas.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 3.

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

              • [^] # Re: Le retour du 2.7 ?

                Posté par  . Évalué à 2.

                Mais par contre dire que le rapport qualite prix du code de windows par rapport a celui de linux est vraiment pourri ca on peut le dire. Mis a part dans un monde de lawyer a la MS, personne ne peut battre un truc a 0$ qui fonctionne (meme imparfaitement) avec un trux a Nx~200$.

                Ca depend, tu comptes quoi dans le rapport qualite/prix ?

                Juste le prix du logiciel ? Dans ce cas oui, Linux est imbattable.

                Si tu comptes ce que tout le monde appelle le TCO(parce que bon, tu t'amuses pas a acheter un logiciel juste pour l'acheter d'habitude, il est sense te faciliter la tache), en comptant le temps et l'effort que tu mets a accomplir la tache X, ca devient tout de suite moins clair.

                Bref, est-ce qu'acheter un logiciel 200$ qui te sauve 12h est plus cher qu'un logiciel gratuit qui te sauve 2h ? (les chiffres sont fictifs pour l'exemple hein, pas de troll la dessus svp) Ca c'est la vraie question, le prix de base du soft est pas le plus important.

                en tant que client (force) je ne me gene pas pour critiquer MS, j'ai PAYE un service que je n'ai pas et donc je le denonce c'est normal surtout vu le service apres-vente de ta boite!

                T'es libre de gueuler en tant que client, tant que tes critiques sont justifiees.

                Dans ton exemple c'est tres clair, si le probleme vient des drivers Iomega, faut aller gueuler chez Iomega, MS va pas pouvoir te livrer un patch pour un driver dont ils n'ont pas le code, c'est assez logique pourtant... Tu envoies un e-mail a Linus quand le driver fait par NVidia plante ? Je ne crois pas...

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 2.

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

Suivre le flux des commentaires

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