Journal Debian lenny est sortie...

Posté par  .
Étiquettes :
-6
10
jan.
2009
En effet, debian lenny est sortie en février 2008 mais personne ne le savait.

Pour preuve, si on regarde le graphique de suivi des bogues critiques ici : http://bugs.debian.org/release-critical/ , on peut remarquer que le nombre de bogues critiques sur la courbe bleue (représentant la debian stable) augmente sans arrêt mais que la courbe verte (pour la debian testing) diminue tout le temps.
Ces deux magnifiques courbes se croisent en février 2008 environ.

Donc alors, comment peut-on qualifier de stable une distribution contenant beaucoup plus de bogues critiques que la version testing ?

A vos troll...

  • # Communiqué du Département des Daltoniens Deutéranopes et Deutéranor

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

    Les courbes en rouge et vert ça fait chié !

    Ceci était un communiqué du DDDD /o\

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # Hypothèse

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

    Quand les gens installeront des lenny sur leur serveurs, tu auras plus de bugs connus dans lenny car les gens trouvent des bugs dans les logiciels installés sur leurs machines.

    Non?

    • [^] # Re: Hypothèse

      Posté par  . Évalué à 4.

      Certes : cela dit, rien n'empêche non plus les admins consciencieux de commencer à tester ce que donnera leur serveur après la mise à jour...

      ... ce ne sont pas les moyens qui manquent : conteneurs, virtualisation complète, ...

      C'est aussi ce qui permet d'avoir une meilleure distro quand elle est déclarée stable.

    • [^] # Re: Hypothèse

      Posté par  . Évalué à 3.

      Au delà, il faut se garder des raisonnements purement quantitatifs. Lenny est la pire des 3. Certes moins nombreux, mais il faut voir la nature des bugs et la rapidité de correction. Un paquet restera cassé beaucoup moins longtemps sous Stable et Sid que sous Testing.
      Pour usage personnel, il faut utiliser stable+backports ou sid. SI on avait l'habitude dire que Testing est le compromis stabilité/nouveauté, ce n'est plus vrai aujourd'hui.

      • [^] # Re: Hypothèse

        Posté par  . Évalué à 3.

        Un paquet restera cassé beaucoup moins longtemps sous Stable

        Ce n'est pas possible d'avoir un paquet cassé sous Stable, si ?

        • [^] # Re: Hypothèse

          Posté par  . Évalué à 5.

          Jamais vu chez moi... Mais ça ne me semble pas théoriquement impossible.

          L'erreur est humaine (merde! ça voudrait dire qu'ils ne sont pas humain chez Debian? :D)

          • [^] # Re: Hypothèse

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

            Ah c'est pour ça que ubuntu c'est linux pour les êtres humains ? ;P

          • [^] # Re: Hypothèse

            Posté par  . Évalué à -5.

            Je pense que c'est possible grâce à experimental :)

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

      • [^] # Re: Hypothèse

        Posté par  . Évalué à 2.

        Actuellement (quelques mois après le freeze) Testing est un bon choix, c'est sur elle qu'il y a le plus de boulot.

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

  • # Indice...

    Posté par  . Évalué à 9.

    > comment peut-on qualifier de stable une distribution contenant beaucoup plus de bogues critiques que la version testing ?

    Indice : en apprenant ce que signifie "stable"...

    stable!=fiable

    "Stable" signifie que les paquets ne sont plus censés bouger, (hors mises à jour de sécurité, sous Debian).

    "Fiable" signifie que ça marche bien.



    De toute évidence, quand quelque chose est figé (ie "stable"), au fur et à mesure, les gens veulent faire des nouvelles choses, peut-être pas implémentées, ou moins bien, que dans des versions plus récentes : la fiabilité de la version figée n'est alors pas meilleure (par contre, c'est 'achement plus facile à administrer : on installe, et tout marche à l'identique pendant des années).

    Exemple : X.org sous Etch est un ante-diluvien 7.1, avec des vieux drivers moisis (même s'il permet, au moins, de gérer le tri-écran, ce qui ne marche plus depuis X.org 7.2...).

    Il n'y a donc a priori pas de corrélation entre "stable" et "fiable"... ce sont des choses très différentes, a priori.



    Maintenant, la plupart des gens parlent de l'état de stabilité de la fiabilité quand ils parlent de stabilité...

    Si on veut troller sur cet abus de langage, ma théorie est que cette expression doit venir de gens qui utilisent des systèmes qui peuvent se casser la gueule d'un seul coup, sans plus prévenir que pour une quelconque raison tangible, et qui passent le temps entre deux crashs à se dire "jusqu'ici, tout va bien ; pour l'instant, ça ne se casse pas la gueule ; c'est stable".



    NB : Lenny est peut-être sortie, mais elle est toujours Testing, et pas Stable (à ce moment, Squeeze et toute les suivantes sont déjà sorties). Se taper une Sid qui est peu ou prou figée étant déjà un peu chiant (d'autant que ça commence à bien laguer derrière ce qui se fait), ce ne serait pas du luxe d'éviter de se coltiner aussi des annonces bidons comme le titre de ce journal...

    • [^] # Re: Indice...

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

      Un système est fiable quand tu es certain qu'il fonctionnera comme tu t'entends à ce qu'il agisse. Donc dire qu'un système stable est fiable n'a rien d'absurde.

      Si ton système est stable, tu ne risque pas d'avoir de mauvaises surprises la prochaine fois que tu l'utilises (ni de bonnes d'ailleurs).

      Un système fiable ne veux pas forcément dire que le système fonctionne bien. La fiabilité traduit la confiance que tu peux placer dans la prédictabilité d'un événement. Si je sais que mon collègues à TOUJOURS 10 minutes de retards pile poil, je lui fait confiance pour être en retards de 10 minutes aujourd'hui aussi. Par contre je préférerais peut être qu'il soit pas en retard.

      En gros un système fiable fonctionne (bien ou moins bien), fonctionne toujours et fonctionne toujours de la même manière.

      • [^] # Re: Indice...

        Posté par  . Évalué à 4.

        > Si ton système est stable, tu ne risque pas d'avoir de mauvaises surprises la prochaine fois que tu l'utilises (ni de bonnes d'ailleurs).

        Si : mettons que tu lises sur le Net que tu peux brancher à chaud un moniteur sous X.org... tu essayes, mais pas de bol : tu es sous Etch, et tu peux te brosser.

        Dès que tu veux faire quelque chose de nouveau avec du stable, tu cours vers les mauvaises surprises, car il y a de bonnes chances que ça n'y soient pas fiable.



        > un système fiable fonctionne (bien ou moins bien)

        Je veux bien...

        > fonctionne toujours et fonctionne toujours de la même manière.

        Bah non : ça, tu peux uniquement le dire avec assurance d'un système stable. Pour un système que tu juges fiable (parce que tu as confiance en lui, comme tu le soulignais), tout ce que tu peux dire, c'est qu'il a toujours fonctionné comme tu le voulais, ou au moins, assez pour que tu lui fasses confiance...

        ... mais pas forcément de la même manière : pour ce qui est du clickodrome, je trouve Sid bien plus fiable que toutes les autres saveurs de Debian, parce que l'expérience m'a appris que c'est celle qui fonctionne le mieux pour l'usage que j'en ai (pour les pilotes, les utilitaires comme kdesudo et cie ; par contre, pour le tri-écran, Etch est bien plus fiable). Pourtant, il y a, hors période de freeze de Testing, beaucoup de changements.

        Ce que tu décris, c'est stable _et_ fiable, ce qui ne va pas toujours nécessairement de pair.

        • [^] # Re: Indice...

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


          Dès que tu veux faire quelque chose de nouveau avec du stable, tu cours vers les mauvaises surprises, car il y a de bonnes chances que ça n'y soient pas fiable.


          Évidemment puisque la stabilité d'un système¹ est une condition sinequanone de sa fiabilité. La fiabilité est une question de prédictabilté, si tu t'aventures en dehors de ce qui à été testé et éprouvé, tu t'éloigne d'un système fiable.

          Pour ce que tu dis ensuite, à mon avis tu confonds l'adaptabilité fonctionnelle et la fiabilité fonctionnelle. Sid est plus adaptable mais moins fiable car tu as moins d'assurance : tu ne peux pas fonder une grande confiance en un système instable, aussi pratique puisse-t-il être momentanément.

          La gravité est fiable : je lui fait confiance pour être encore là et pareil à elle même demain matin, même si elle n'est pas toujours des plus commode.


          ¹ Au sens générique du terme, pas spécifiquement pour un système informatique.

          • [^] # Re: Indice...

            Posté par  . Évalué à 2.

            > si tu t'aventures en dehors de ce qui à été testé et éprouvé, tu t'éloigne d'un système fiable

            Non : l'état des paquets est tout autant stable, donc il y aurait grand mal à s'éloigner d'un système stable en en utilisant un... par contre, il pourra être plus difficile d'en faire une utilisation fiable.

            Avec le même exemple de X.org 7.1 : tu apprends sur le Net que X.org (sans précision) fait du branchage d'écran à chaud. À partir de la 7.2, certes, c'est vrai, et tu peux te fier à cette information pour être exacte, et à X.org pour brancher tes écrans à chaud. Mais pas de chance : pas avec la 7.1. Tu ne peux pas te fier à cette dernière pour gérer le branchage à chaud : dans ce cas particulier, elle n'est pas fiable, bien que stable.

            En revanche, si tu veux brancher deux GPU, tu ne peux pas te fier à X.org>7.2 pour le faire (à compter n'utiliser que des pilotes libres), mais avec les versions antérieures (du moins, celles que j'ai connues ces quelques dernières années), si tu n'as pas besoin de DRI, elles seront fiables dans cette utilisation.


            > tu confonds l'adaptabilité fonctionnelle et la fiabilité fonctionnelle

            Dans le cas de Sid, et dans un cadre d'utilisation en clickodrome, oui, clairement : c'est ainsi parce qu'elle est plutôt à jour que je la trouve fiable pour cet usage.

            Si je me sers de Etch pour ça, par contre, je vais gueuler que l'imprimante de ma mère ne fonctionne pas, que la 3D sur ma X800XL est lente comme la mort, qu'il n'y a pas kdesudo, qu'il n'y a pas ath5k et que je dois installer madwifi sur mon HTPC, ...

            En revanche, pour mes serveurs, je préfère Etch, qui ne me force pas à télécharger des centaines de Mio par semaine (voire par jour)... même s'il y a des bugs qui me gênent, ils sont généralement moins fonctionnellement critiques pour un serveur, et je suis prêt à faire avec pour gagner la stabilité, qui apporte la facilité à maintenir les machines.

            Ainsi, je me fie à Debian Stable pour les serveurs, et à Debian Sid pour les clickodromes (et, si : j'y place une grande confiance, car l'expérience m'a prouvé que je pouvais clairement le faire). L'une est stable, l'autre pas du tout.

            Maintenant, pour rebondir sur l'adjectif "fonctionnel" pris tout seul, je le trouve bien adapté pour remplacer "fiable" dans mon explication précédente.


            > La gravité est fiable : je lui fait confiance pour être encore là et pareil à elle même demain matin, même si elle n'est pas toujours des plus commode.

            Oui : mais c'est aussi parce qu'elle est stable à une certaine distance de la grosse masse qui fait qu'on la subit, tant que cette grosse masse reste intacte. Donc, là encore, on parle de quelque chose de stable _et_ fiable (et même fiable parce que stable).

            Tout n'est pas comme ça pour autant.

            • [^] # Re: Indice...

              Posté par  . Évalué à 1.

              dans ce cas particulier, elle n'est pas fiable, bien que stable.

              Moi je dirais plutôt que ce n'est pas fonctionnel. C'est stable donc parce que la non-fonctionnalité sera constante ainsi que les fonctionnalités
              La fiabilité, c'est comme cela a déjà été dit, une histoire de confiance. Mais confiance en quoi... On peut avoir confiance en la stabilité et donc là on peut dire que c'est fiable.
              On peut avoir confiance sur la reconnaissance des nouveaux matériels et donc là plus on avance dans le temps et moins c'est fiable.

              Moi ce qui me gêne, c'est la notion de bogue critique, c'est critique mais personne ne corrige donc c'est que ce n'est pas critique. Là, on va me dire que urgent et critique c'est différent. Mais même si ce n'est pas urgent, ne faudrait-il pas s'en occuper un jour ?

            • [^] # Re: Indice...

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


              Avec le même exemple de X.org 7.1 : tu apprends sur le Net que X.org (sans précision) fait du branchage d'écran à chaud. À partir de la 7.2, certes, c'est vrai, et tu peux te fier à cette information pour être exacte, et à X.org pour brancher tes écrans à chaud. Mais pas de chance : pas avec la 7.1. Tu ne peux pas te fier à cette dernière pour gérer le branchage à chaud : dans ce cas particulier, elle n'est pas fiable, bien que stable.


              À mon humble avis tu mélanges maintenant la fiabilité d'une documentation trouvé sur le net et la fiabilité d'un logiciel.

              D'après ce que te me dit :
              * je peux me fier à X.org 7.2 pour gérer le branchement à chaud d'un écran;
              * je peux me fier à X.org 7.1 pour ne pas gérer le branchement à chaud d'un écran;
              * je ne peux pas me fier au fait que ce que la documentation dit pour la version 7.2 est valable pour la version 7.1 et inversement.

              L'expérience que tu as pu avoir dans un système instable ne t'apporte aucune garantie sur le fait que demain il fonctionnera encore aussi bien, parceque justement par définition demain il peut changer du tout au tout. Ça ne veut pas dire qu'un système instable est moins utile, simplement qu'on ne peut lui faire aucune confiance.

              • [^] # Re: Indice...

                Posté par  . Évalué à 2.

                La confiance, contrairement à la stabilité, de toute façon, c'est subjectif. J'ai pleinement confiance en Sid pour être, par exemple, bien plus fiable et fonctionnelle que, par exemple, les trucs de chez Canonical... jamais eu de souci avec depuis loooonnnngtemps.

                La fonctionnalité, c'est par contre relatif : ça dépend de ce qu'on cherche. Mais je suis d'accord sur le fait que c'est plus objectif que la notion de fiabilité.

                Sur le fond, ce que j'estime être non corrélé à la stabilité, c'est aussi bien la fiabilité que la fonctionnalité. Pour passer outre l'exemple qui implique une documentation en ligne, plus généralement, si j'installe une Debian Stable sur une machine que je ne connais pas, je sais que je cours le risque que ça ne supporte pas tout ce dont il y a besoin : il risque de manquer des fonctionnalités, et je ne m'y fie donc pas.

                Avec Testing, et Sid, j'ai la plus grande confiance quant à ce que ça ne parte pas en sucette, tout en m'apportant les fonctionnalités désirées. Et l'expérience m'a prouvé que j'avais raison de faire comme ça : j'utilise Sid (station de travail et portable) et Testing (HTPC) au quotidien, j'ai installé plein de Testing à plein de monde (sauf quelques cas particuliers où, puisque ce sera moi qui maintiendra la machine, j'ai mis de la Debian Stable), et il est rarissime qu'on me demande de l'aide (et en général, ce n'est pas pour grand chose).

    • [^] # Re: Indice...

      Posté par  . Évalué à 0.

      J'ai fait ma première MAJ de Debian Lenny depuis que je suis dans cette branche (4-5mois)
      et rien n'est cassé et ce n'était même pas utile :). (quelques paquest systèmes mais beaucoups plus d'appls utilisateurs genre OO.)

      Bon, j'ai juste eut à REdésinstaller ce bousin de NetworkManager* que je n'ai jamais réussi à faire tourner avec des routeurs Philips, DLINK et Thompson... bref le "standard" sur le marché grand public.

      En fait, c'est plutôt lors d'acquisition d'IP automatique via NM qui pose soucis, car à la commande avec dhclient -n eth1, ça fonctionne toujours.

      Que ça soit sur Ubuntu, Debian et Archlinux avec des pilotes libres ou ndiswrapper.

      • [^] # Re: Indice...

        Posté par  . Évalué à 0.

        Quand on parle de version stable, c'est pas plutôt le développement du code source qui est stabilisé? C'est à dire que le code source ou l'architecture ne changera quasiment plus sauf pour corrections mineurs car on est arrivé grosso modo a ce qu'on voulait faire.

        Ca ne veut absolument pas dire que l'application ou le système sera stable, mais que sont code source ou la structure ne subira plus de grosses modifications parce que dans l'ensemble ça marche.

        • [^] # Re: Indice...

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

          s/code source/paquet/
          stable c'est le paquet qui s'installe pour le code source dans sa version choisie, sauf ajout de patchs de sécurité ou correctifs évidents (segfault, quoique...).

  • # [:dionysos2001]

    Posté par  . Évalué à 1.

    BLOUB !

    Des experts (des docteurs en trous noirs attention [1] ) ont déjà rédigé des notes très sérieuses sur le sujet.

    Voir celle du regretté (assassin du pape) LLG< :
    http://charogne.net/spip.php?article22

    Il s'agissait de rendre hommage à cet auteur malheureusement disparu de ces lieux.

    [1] ou qq chose comme ça

  • # Absurde.

    Posté par  . Évalué à 8.

    Tu confonds le nombre de bugs avec le nombre de bugs connus.

    Nul ne sait si Lenny contient plus ou moins de bugs que Etch.

    Une chose est certaine, c'est que plus Etch vieillit plus le nombre de bugs connus augmente. De la même manière, lorsque Lenny sera stable depuis un certain temps, le nombre des bugs connus sera plus important que le jour de la release.

    Il n'y a vraiment rien de surprenant à ce qu'on connaisse plus les imperfections d'une distributions qui est utilisée depuis plusieurs années dans une version figée, que celles d'une distribution freezée depuis quelques mois.

    • [^] # Re: Absurde.

      Posté par  . Évalué à -1.

      On peut donc dire que le nombre de bugs est en réalité plus important que le montre le graphique. Mais à quoi ça sert de déclarer des bugs qui ne seront probablement jamais corrigés ?
      Je comprends facilement que les gens n'aient pas envie de déclarer un bug qui ne sera sans doute jamais corrigé dans Etch. En plus, j'imagine que les mainteneurs sont généralement en sid ou testing et n'ont pas de Etch sous la main pour maintenir quoique ce soit.

      • [^] # Re: Absurde.

        Posté par  . Évalué à 9.

        > à quoi ça sert de déclarer des bugs qui ne seront probablement jamais corrigés ?

        Ça sert à ceux qui n'arrivent pas à faire quelque chose : une fois le bug rapporté, il y a une trace qu'ils ne sont pas les seuls dans cette galère.

        Ça sert aussi aux mainteneurs à être au courant de problèmes, et les pousse à se renseigner sur l'état du bug chez les développeurs du projet en amont... voire, à leur transmettre.

        Souvent, un bug est marqué en "won't fix" (ne sera pas résolu) ; mais en lisant la discussion sur le rapport, on trouve souvent un "réglé dans telle ou telle version", ce qui est de première utilité aux utilisateurs et administrateurs.

        C'est peut-être de la bureaucratie que de rapporter des bugs pour des distros figées, mais c'est tout sauf inutile.

        • [^] # Re: Absurde.

          Posté par  . Évalué à 1.

          Surtout très utile pour le support du matériel, avec souvent des patchs dans les commentaires.

  • # sortez couvert

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

    Ben faut qu'elle rentre vite sinon elle va prendre froid !

  • # Journal en retard de presque deux ans...

    Posté par  . Évalué à 3.

    Ben oui, Lenny est sortie depuis un moment déjà : exactement le jour où Etch est passée stable, en avril 2007. D'ailleurs je m'en sers depuis.

    À moins que tu ne parlais du passage de Lenny en stable ?

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

  • # Réponse déjà faite avant

    Posté par  . Évalué à 2.

    CF. http://linuxfr.org/comments/873042.html#873042

    ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

  • # Debian is dying

    Posté par  . Évalué à -1.

    Debian is dying, mais elle ne le sait pas encore.

    • [^] # Re: Debian is dying

      Posté par  . Évalué à 2.

      Heureusement qu'on ne comprend pas l'anglais, là! :p

      Debian va bien, même très bien. Une distro que je n'avais pourtant pas dans mon coeur, loin s'en faut!


      Peut-être que c'est la 4.0 qui change tout, mais en tout cas, ça fichtrement plaisir d'utiliser son système sans prendre la tête!

Suivre le flux des commentaires

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