Journal Vitesse vs. Qualite, vous choisissez quoi ?

Posté par  .
Étiquettes :
22
11
déc.
2008
D'ici a ce que la plupart d'entres vous se reveillent il sera Vendredi, donc ...

Une des frequentes critiques emises ici vis a vis de Windows est que Microsoft met beaucoup de temps a sortir ses patchs de securite.

Ces memes critiques mettent en avant la rapidite fulgurante avec laquelle les patchs de differentes distributions Linux sortent.

Je ne comptes plus le nombre de fois ou j'ai trolle explique que la plupart du temps pris pour faire un patch se situait dans le test, mais cela n'avait semble-t-il pas convaincu grand monde...

Aujourd'hui, suivant un journal plus bas, je suis tombe sur http://blogs.gnome.org/hughsie/2008/12/08/cve-2008-4311-dbus(...)
et je me suis retrouve avec un melange d'effarement et de rire...

Il est clair et net que Fedora sort ses updates beaucoup plus vite que MS, mais au vu des resultats, il vaut mieux visiblement attendre que d'autres cobayes utilisateurs aient installes les updates avant de les installer soi-meme...

( Oui MS aussi a des regressions, mais des updates qui mettent hors service quasiment le systeme entier(cups, gdm, automatic updates...) sur quasiment tous les systemes, ca ne leur arrive pas par contre... )

La question est donc :

Etes vous pret a prendre ce genre de risques pour votre (vos) systeme(s) en echange d'une vitesse de sortie accrue des patchs ?

Je predis un score de -42 pour ce journal...

  • # C'est un choix, çà ?

    Posté par  . Évalué à 10.

    Vitesse vs. Qualite, vous choisissez quoi ?

    Je prends les deux, merci.

    • [^] # Re: C'est un choix, çà ?

      Posté par  . Évalué à 2.

      Ben en partie oui, tester un patch prend du temps.

      Si tu veux sortir vite, t'as moins de temps --> moins de tests...

      Si tu fais plus de tests -> plus de temps --> moins vite...

      • [^] # Re: C'est un choix, çà ?

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

        Tout est une question de compromis... et de méthodologie.

        • [^] # Re: C'est un choix, çà ?

          Posté par  . Évalué à 1.

          Tout a fait, la question est donc : ou est le juste milieu ?

          • [^] # Re: C'est un choix, çà ?

            Posté par  . Évalué à 4.

            Avec une bonne architecture logicielle et une méthodologie rigoureuse, il n'y a pas à chercher un juste milieu: tu obtiens les deux critères d'un coup. Et, typiquement je pense, les problèmes de sécurité étant des buffer overflow, c'est bien quelque chose qui peut-être facilement évité avec un peu de rigueur...

          • [^] # Re: C'est un choix, çà ?

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

            Il n'y a pas à choisir. Souvent, il faut un "quick fix" pour les machines importantes et vulnérable. Ensuite, on peut avoir un patch plus clean.

            Je crois que cela s'était passé en 2 temps pour le problème ptrace de linux.

            C'est une histoire de prendre un risque ou pas : est-ce plus couteux d'avoir un patch un peu foireux ou de prendre le risque d'un piratage. Cela dépend de la machine.

            "La première sécurité est la liberté"

    • [^] # Re: C'est un choix, çà ?

      Posté par  . Évalué à 10.

      Je ne vois pas où est le débàt.
      Fedora c'est pour les cobayes qui acceptent de subir les conséquences des dernieres technologies. C'est aussi pour cela que redhat ne pense pas être prêt pour le desktop.
      Sur CentOS/RHEL, là ce serait problèmatique.

  • # Windows aussi en casse des choses...

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

    Non, la, je ne défendrai pas Windows, pour une fois ;-).

    Tu parles de vitesse avec merdes (Linux) vs plus lent mais parfait (Windows), en donnant un exemple pour Linux et en concluant que c'est tout le temps pareil, alors que bon :
    - Tu prends exemple sur une distrib faite pour la beta : Fedora n'est pas conseillé pour les débutant, mais comme un beta-test pour Redhat. Ca ne veut pas dire que les distrib plus "final user" vont faire pareil.
    - Tu associe lenteur à bon patch. sauf que Microsoft en a fait de belles aussi en filant des patchs merdiques. J'ai la flemme de chercher dans mes archives, mais plus d'une fois Microsoft a tout cassé et fillé un patch du patch.

    Donc au final je préfère un truc rapide qui casse parfois (Linux) à un truc lent qui casse parfois (Windows)

    • [^] # Re: Windows aussi en casse des choses...

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

      Tu veux dire... comme avec le service pack 3 de Windows XP, qui bloquait un certain nombre de machine sous AMD?

      Mais bon, ceci dit, il faut quand même reconnaitre que c'est plutôt exceptionnel chez Microsoft, et que ça l'est sans doute un peu moins sous la plupart des éditions linux.

      • [^] # Re: Windows aussi en casse des choses...

        Posté par  . Évalué à 5.

        Meme pas...

        Les problemes du SP3 sur AMD etaient pour la plupart dus a une chose :

        Des OEMs qui avaient une image Windows generee pour CPUs Intel qu'ils appliquaient sur leurs machines AMD.

        Bref, les OEMs se sont mechamment plantes dans leur config, le SP3 lui-meme n'etait pas la cause du probleme, sur une installation correcte il s'installait sans probleme, et on ne peut evidemment pas garantir une installation correcte du SP sur une mauvaise image.

        • [^] # Re: Windows aussi en casse des choses...

          Posté par  . Évalué à 10.

          Ouais, t'as raison, interdisons les ventes OEM

        • [^] # Re: Windows aussi en casse des choses...

          Posté par  . Évalué à 8.

          Bref, les OEMs se sont mechamment plantes dans leur config, le SP3 lui-meme n'etait pas la cause du probleme, sur une installation correcte il s'installait sans probleme, et on ne peut evidemment pas garantir une installation correcte du SP sur une mauvaise image.

          Tu t'auto-trolles je pense. Tu dis que Microsoft prend le temps de tester avant de sortir des updates. Or, tu sais très bien que le gros du business de Microsoft est l'OEM et ils n'auraient pas rencontré ces problèmes avant?

          Et puis, si l'image était incorrecte, genre il manquait typiquement un module, non? Dans ce cas, pourquoi ne pas l'installer pendant la mise à jour? Ce n'est pas très compliqué de détecter les composants HW d'un système et d'en installer les éléments manquants lors d'une mise à jour... Au pire, sachant que ça ne fonctionnerait pas, le logiciel de mise à jour pourrait en interdire l'installation.

          Après, il y a peut-être un problème architectural dans l'OS de Microsoft qui empêche de prendre ce genre de mesures.

          • [^] # Re: Windows aussi en casse des choses...

            Posté par  . Évalué à 4.

            Tu t'auto-trolles je pense. Tu dis que Microsoft prend le temps de tester avant de sortir des updates. Or, tu sais très bien que le gros du business de Microsoft est l'OEM et ils n'auraient pas rencontré ces problèmes avant?

            Justement non car cela depend des modeles. Les laptops AMD d'HP n'avaient pas de probleme par exemple car leur image etait bonne. Bref, fallait tomber sur le bon modele qui avait une image pourrie.

            Et puis, si l'image était incorrecte, genre il manquait typiquement un module, non?

            Non, HP avait specifie dans la base de registre qu'il fallait charger le driver de power management d'Intel, mais n'avait pas le driver sur le disque, donc sans SP pas de probleme.
            Mais a l'installation du SP, l\installer en voyant cette entree a fait ce qu'il est sense faire : il a installe le driver.

            On peut difficilement demander au service pack de faire autre chose que ce qu'il lui est dit de faire, il n'est pas sense deviner que HP lui ment et il n'est pas sense gerer l'infinie combinaison de configurations corrompues qu'il pourrait rencontrer, ca serait ingerable...

            • [^] # Re: Windows aussi en casse des choses...

              Posté par  . Évalué à -1.

              Bref, fallait tomber sur le bon modele qui avait une image pourrie.

              Tu appelle ça le bon modèle, ça explique beaucoup chose à propos du service qualité de Microsoft.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Windows aussi en casse des choses...

      Posté par  . Évalué à 9.

      Je suis tout a fait d'accord qu'on casse qqe trucs de temps en temps, personne n'est parfait, on ne l'est certainement pas.

      Maintenant, tu remarqueras qu'on n'a, si ma memoire est bonne, jamais sorti un patch totalement loufoque qui mettait toutes les machines en rade...

      Sinon, oui Fedora est _sense_ etre une beta pour Redhat, mais quel est le sens d'avoir Fedora 9, Fedora 10, ... si elles sont toutes des versions alpha qui peuvent tout casser ? Quel est le sens d'avoir un repository testing separe ?

      En realite tout le monde considere Fedora comme une distrib a part entiere au meme titre que Mandriva, OpenSuse, Debian, ... car je n'ai jamais vu linuxfr.org faire des news pour la sortie de la beta d'une beta( http://www.linuxfr.org/2008/11/05/24644.html ), des install party pour une version beta ( http://www.linuxfr.org/2008/11/25/24721.html ), ...

      Et on remarquera que Fedora n'est pas le seul a se brouter de la sorte : https://linuxfr.org/~Tiberium/22450.html

      Le plus drole c'est que les distribs qui mettent du temps a sortir un patch (RH, Suse) sont moins touchees par le phenomene...

      • [^] # Re: Windows aussi en casse des choses...

        Posté par  . Évalué à 7.

        En realite tout le monde considere Fedora comme une distrib a part entiere au meme titre que Mandriva, OpenSuse, Debian, ... car je n'ai jamais vu linuxfr.org faire des news pour la sortie de la beta d'une beta, des install party pour une version beta, ...

        Je trouve que c'est une très bonne remarque :)

        La notion de "stabilité" est effectivement différente selon la distribution. Mais à mon sens, on "fête" pas une nouvelle version d'une distribution pour sa stabilité, mais plus pour la "nouvelle étape" dans l'objectif du développement de cette distribution, quelle qu'elle soit (c'est valable pour tout os d'ailleurs).

        • [^] # Re: Windows aussi en casse des choses...

          Posté par  . Évalué à 3.

          Allez, une fois n'est pas coutûme, je prends 30min d'avance...

          Je suis d'accord avec toi, la preuve, en faisant une petite recherche sur la page blanche qui trouve tout, on a accès à des petits articles relatant des fêtes pour Windows..

          Quoique, en lisant un peu mieux, il semblerait que ce ne soit que pour ses 23ans que la fête a été faite ! (...)

      • [^] # Re: Windows aussi en casse des choses...

        Posté par  . Évalué à 1.

        Hello,

        pour ce qui est de fedora, ils ont une politique assez agressive concernant les updates:
        Si version la version 1.6.x comprend un bug mais que la 2.x n'en souffre pas -> update, on attends pas forcément les patchs. Les différentes versions de Fedora s'incrémentent par ajout de fonctionnalités (xen en standard, pulseaudio ou autre...).

        Le cycle de release est plus agressif que bien d'autre distrib (quasiment une nouvelle tous les 6 mois) avec un support de packages très court (1 an ou un peu plus mais je n'en suis pas sûr)

        Donc c'est vraiment pas une distrib à mettre sur un serveur :P
        Il s'agit certes, d'une distrib à part entière, mais où la stabilité (en parlant serveur) n'est pas la cible.

        C'est ce que j'en ai plus ou moins compris.

        my 2 .torrents

  • # Révisons les jours de la semaine

    Posté par  . Évalué à 10.

    Mardi ! C'est le mardi que les mises à jour sont prête.
    Le patch est fini le lundi ? alors il sera prêt mardi.
    Le patch est fini le mercredi ? alors il sera prêt mardi.

    "Quoi ? une faille de sécurité ultra-critique ? On fait le patch et on attend mardi."

  • # Vitesse puis qualité

    Posté par  . Évalué à 2.

    Pour moi, c'est d'abord la vitesse pour corriger le gros problème. Quitte à casser une ou deux applications. Si ça bloque quelques utilisateurs, tant pis pour eux.

    Après vient la qualité, et les trucs testés.

    Envoyé depuis mon lapin.

    • [^] # Re: Vitesse puis qualité

      Posté par  . Évalué à 1.

      Et tu mets ou la barriere ?

      Parce qu'evidemment plus tu testes, plus t'es sur de la qualite du bousin.

      T'es pret a recevoir un patch totalement non teste ?

      • [^] # Re: Vitesse puis qualité

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

        http://www.heise-online.co.uk/security/MS-Malicious-Software(...)

        Avec la mise à jour du 10 décembre (2008), le Malicous Software Removal Tool (MSRT) s'est mis à détecter de faux positifs et proposer de supprimer les logiciels comme « Vegas Movie Studio Platinum 8.0 » ou « Microsoft Flight Simulator » (haha). Question qualité, c'est pas terrible.

        • [^] # Re: Vitesse puis qualité

          Posté par  . Évalué à 1.

          Certainement, c'est un bug et il est pas beau.

          Maintenant, est-ce qu'il rend toutes les machines inoperables ? Non, il cause des problemes dans des cas bien definis seulement et il ne plante pas le systeme.

          Bref, qqe chose de bien plus difficile a attraper lors des tests que "j'installes le patch, la machine fonctionne plus".

        • [^] # Re: Vitesse puis qualité

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

          Nan mais t'as pas compris, ils font de la qualité chez Microsoft, et la qualité elle ne passe pas son temps à jouer ou regarder des films ;-)

          hein quoi, des régressions, bin non c'est passé par la qualité, et la qualité elle ne passe pas son temps à jouer ou regarder des films ;-)

          (clair que la méthode coué ça marche très bien pour un système qui passe son temps à vouloir s'auto-détruire...).

        • [^] # Re: Vitesse puis qualité

          Posté par  . Évalué à 4.

          It is not a bug ! It is a feature.
          Bah oui, sinon ça ne serait pas passé aux tests draconiens !

  • # Hum, qualité ok, mais de là à attendre 7 ans ...

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

    http://www.heise-online.co.uk/security/Microsoft-explains-th(...)

    Microsoft a publié un correctif nombre dernier (2008) pour corriger une faille SMB sur l'authentification par le réseau connue depuis 2001. La justification de Microsoft : corriger la faille plus tôt aurait empêcher des applications comme Outlook de fonctionner. J'espère avoir bien résumé, suivez les liens pour les détails.

    Bon, ça aurait été vraiment grave si la faille avait été exploitée, mais là ce n'est pas le cas. Quoique...
    http://www.tarasco.org/security/smbrelay/

    • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

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

      Bon, si vous voulez rire un bon coup, lisez le billet de Sid sur le dernier Patch Tuesday qui est particulièrement gratiné :
      http://sid.rstack.org/blog/index.php/311-patch-tuesday-grati(...)

      « vingt-huit failles ; vingt-sept en exécution de code à distance ; (...) vingt-cinq sont jugées critiques ; (...) ; une est gratifiée d'un exploit depuis août dernier... »

      Je préfère recevoir régulièrement les patchs tous les jours via apt-get qu'attendre un mois pour pousser une vingtaine de correctifs d'un coup. Et puis bon, sous Linux il est très rare d'avoir à rebooter un serveur pour appliquer un correctif de sécurité (même pour le noyau, on peut s'en passer !).

      • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

        Posté par  . Évalué à 2.

        « vingt-huit failles ; vingt-sept en exécution de code à distance ; (...) vingt-cinq sont jugées critiques ; (...) ; une est gratifiée d'un exploit depuis août dernier... »

        Ouaip, et ce dernier n'etait pas activement exploite, raison pour laquelle on a prefere tester le patch plus longtemps. C'est une approche, j'imagines que d'autres prefereraient qu'on sorte le patch de maniere urgente.

        Et puis bon, sous Linux il est très rare d'avoir à rebooter un serveur pour appliquer un correctif de sécurité (même pour le noyau, on peut s'en passer !).

        Et non, si tu regardes les patchs kernel de Redhat par exemple, tu noteras qu'il y a nombre de correctifs venant avec, qui vont certainement rendre le patch impossible a hotpatcher (changement de structure, ...)

        Bref, dans la majorite des cas, impossible.

        Sinon, la raison du groupement des patchs c'est justement que les entreprises le demandent, et cela pour une raisons simple :

        A chaque patch elles doivent revalider leurs applications, il est plus simple pour elles de le faire une fois pour tous les patchs que tous les 5 jours.

        • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

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

          Sinon, la raison du groupement des patchs c'est justement que les entreprises le demandent

          elles demandent aussi l'inverse : pouvoir ne sélectionner que ce qui les intéresse plutôt qu'un gros foutoir de 224 Mo sans changelog ou identification des dépendances.

        • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

          Posté par  . Évalué à 2.

          Et non, si tu regardes les patchs kernel de Redhat par exemple, tu noteras qu'il y a nombre de correctifs venant avec, qui vont certainement rendre le patch impossible a hotpatcher (changement de structure, ...)

          Juste pour troller t'as pas lu les "dernières" news sur LWN. (bon ok ils en arrivent à faire des trucs tordu pour supporter certains truc qu'on aurait cru "insupportable" :p )

          Je pense qu'il faut s'en tenir à "peut-être" plutôt que "certainement".

          • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

            Posté par  . Évalué à 1.

            Si c'est celui du 11 decembre non vu que je suis pas abonne, et j'ai rien vu de relatif au sujet dernierement, j'imagines qu'ils ont trouve un moyen tordu de supporter des changements plus serieux niveau hotpatching, lequel ?

            • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

              Posté par  . Évalué à 4.

              Hm j'ai une trop bonne mémoire c'est pas si récent que ça en fait (24 novembre) :P

              http://lwn.net/Articles/308409/

              C'est assez cinglé comme technique mais les trucs cinglés dans les noyaux ne m'étonnent plus trop -- je me souviens par contre de l'époque où j'avais eu un choc en découvrant le hotpatching supprimant les spinlock sur monoprocesseur ;).

              Ceci étant, avis à toutes les fashions victimes, prière de réserver le hotpatching aux cas où c'est vraiment absolument indispensable.

              • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                Posté par  . Évalué à 1.

                C'est effectivement cingle, ca a l'air d'etre un processus sacrement lourd pour generer ces patchs et j'ai du mal a imaginer que cela va tourner en qqe chose d'utilisable de maniere reguliere, mais on ne sait jamais...

                • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                  Posté par  . Évalué à 2.

                  En même temps difficile de faire mieux sans alourdir par avance toutes les structures du système pour quelque chose que finalement peu de monde utilisera (qu'elle est la proportion des machines ne pouvant tolérer un reboot ? -- j'espère faible car que ce passerait-il en cas de défaillance de telles machines...)

        • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

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

          ce dernier n'etait pas activement exploite, raison pour laquelle on a prefere tester le patch plus longtemps

          Je trouve cet argumentation irrecevable. Il faut attendre que la faille soit ACTIVEMENT exploitée pour qu'elle soit patchée ? Il y a un vrai marché noir des exploits : un acheteur pourrait très bien demander l'exclusivité et l'utiliser pour des cibles précises. Bien sûr, la personne qui découvre la faille peut aussi choisir de ne pas la diffuser et l'exploiter pour sa pomme. Microsoft attend que suffisamment de sociétés soient impactées pour patcher ?

          Et non, si tu regardes les patchs kernel de Redhat par exemple (...)

          Pourquoi tu te focalises sur RedHat, tu as un dent contre eux ? Est-ce que RedHat entre en concurrence avec Microsoft, c'est pour ça qu'il faut absolument trouver les défauts de cet OS ?

          [au sujet du patchage de noyau à chaud] Bref, dans la majorite des cas, impossible.

          Renseigne toi un peu au lieu de diffuser de fausses informations :
          http://www.ksplice.com/cve-evaluation

          Un étudiant motivé a réussi à tenir 2 ans sans rebooter tout en patchant son noyau (84% des patchs appliqués à chaud sans modif, et les autres avec modif). Il semble qu'une boîte ait été fondée autour de ce service qui se vend maintenant (tout en restant GPL).

          la raison du groupement des patchs c'est justement que les entreprises le demandent (...) A chaque patch elles doivent revalider leurs applications, il est plus simple pour elles de le faire une fois pour tous les patchs que tous les 5 jours.

          Je ne comprend pas en quoi c'est plus simple. Disons pour l'exemple qu'Ubuntu propose une mise à jour par jour et que Windows en propose 30 par mois (ce qui donne aussi 1 par jour). Bah si tu prends 3 jours pour étudier (tester/valider) une màj Ubuntu, tu seras exposé durant 3 jours à une faille donnée. Si tu prends 2 jours pour étudier les 30 màj Windows, tu seras exposé à 30 failles durant 2 jours. Je pense donc que Windows est plus longtemps exposés aux failles. J'ai pris des nombres un peu au pif juste pour illustrer mon idée.

          Le travers de la solution Microsoft est que si une faille apparait le lendemain de la publication de toutes les màj, il faudra attendre un mois pour qu'elle soit corrigée. La période d'exposition à la faille est plus longue.

          Il semble que Microsoft n'aime pas la mesure de la durée durant laquelle l'OS est exposé à une faille donnée. Je pense que justement avec cette mesure ils s'en sortent moins bien que les autres, or ça me semble être la plus proche de la réalité.

          • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

            Posté par  . Évalué à 1.

            Je trouve cet argumentation irrecevable. Il faut attendre que la faille soit ACTIVEMENT exploitée pour qu'elle soit patchée ? Il y a un vrai marché noir des exploits : un acheteur pourrait très bien demander l'exclusivité et l'utiliser pour des cibles précises. Bien sûr, la personne qui découvre la faille peut aussi choisir de ne pas la diffuser et l'exploiter pour sa pomme. Microsoft attend que suffisamment de sociétés soient impactées pour patcher ?

            Non, mais tu veux pas non plus pousser les patchs dehors sans les tester, parce que les societes si elles voient regulierement des patchs qui foutent le bordel, elles se mettent a ne plus les installer (eh oui ca peut sembler dingue, mais bcp preferent stabilite a securite)

            Pourquoi tu te focalises sur RedHat, tu as un dent contre eux ? Est-ce que RedHat entre en concurrence avec Microsoft, c'est pour ça qu'il faut absolument trouver les défauts de cet OS ?

            Au contraire, je considere que Redhat est celui qui fait le meilleur boulot du cote "linux professionel", c'est pour cela que je les prends eux, compare a ce qui selon moi se fait de mieux de l'autre cote.

            Un étudiant motivé a réussi à tenir 2 ans sans rebooter tout en patchant son noyau (84% des patchs appliqués à chaud sans modif, et les autres avec modif). Il semble qu'une boîte ait été fondée autour de ce service qui se vend maintenant (tout en restant GPL).

            Mais je connais tres bien ksplice, le probleme c'est que personne ne s'amuse a creer un patch de securite qui ne contient que le code du patch en question.
            Tu regardes chez Redhat, tu verras que leurs patchs, c'est un ensemble de correctifs, pas juste une ligne qui corrige un buffer overflow.
            On a exactement la meme techno que ksplice dans Windows depuis 2003, on a vu les limitations.

            Je ne comprend pas en quoi c'est plus simple. Disons pour l'exemple qu'Ubuntu propose une mise à jour par jour et que Windows en propose 30 par mois (ce qui donne aussi 1 par jour). Bah si tu prends 3 jours pour étudier (tester/valider) une màj Ubuntu, tu seras exposé durant 3 jours à une faille donnée. Si tu prends 2 jours pour étudier les 30 màj Windows, tu seras exposé à 30 failles durant 2 jours. Je pense donc que Windows est plus longtemps exposés aux failles. J'ai pris des nombres un peu au pif juste pour illustrer mon idée.

            C'est parce que tu ne regardes que du point de vue securite.

            Je t'expose le cote de l'enterprise :

            Ubuntu sort en moyenne un patch par semaine (disons, chiffre au pif).
            L'entreprise peut soit :
            a) Attendre un mois et tester les 4 patchs Ubuntu en meme temps, mais se retrouver avec une fenetre d'exposition d'un mois pour le 1er patch, 3 semaines pour le 2eme, ...
            b) Tester les patchs quand ils sortent, vu qu'il n'y a pas d'annonce, c'est branle bas de combat a chaque fois, et c'est 2 jours de perdus chaque semaine en moyenne

            Tu compares la solution MS :
            Les patchs sortent un jour precis chaque mois --> On sait quand on va faire nos tests, ca prend 3 jours, pas 4x2 jours, et on est expose que ces 3 jours d'habitude.
            Si qqe chose de super critique se produit (faille en exploitation active), le patch sort des que possible, sans attendre la date mensuelle, c'est rare donc ca prend peu de temps additionel au final.

            Faut comprendre que MS faisait comme les distrib Linux avant, si on a change c'est notamment parce qu'on nous l'a demande...

          • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

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

            la raison du groupement des patchs c'est justement que les entreprises le demandent (...) A chaque patch elles doivent revalider leurs applications, il est plus simple pour elles de le faire une fois pour tous les patchs que tous les 5 jours.

            Je ne comprend pas en quoi c'est plus simple. Disons pour l'exemple qu'Ubuntu propose une mise à jour par jour et que Windows en propose 30 par mois (ce qui donne aussi 1 par jour). Bah si tu prends 3 jours pour étudier (tester/valider) une màj Ubuntu, tu seras exposé durant 3 jours à une faille donnée. Si tu prends 2 jours pour étudier les 30 màj Windows, tu seras exposé à 30 failles durant 2 jours. Je pense donc que Windows est plus longtemps exposés aux failles. J'ai pris des nombres un peu au pif juste pour illustrer mon idée.

            Faudra que tu viennes faire un tour en entreprise avant de dire des bêtises : si tu me files un patch par jour à la place de 30 patch tous les mois, je vire ton appli : rouler toute la procédure de test et de déploiement tous les jours avec les multiples validations internes, ça va gaver très très vite.
            Une machine perso? Si tu veux, c'est pas grave si ça merde. Un machine pro? c'est autre chose! Beaucoup d'applis doivent être validées à la main pour être sûr que l'interface utilisateur fonctionne bien, c'est plus facile de tester une fois pour 30 patch, que 30 fois pour 1 patch, avant de déployer.

            Il y a une chose souvent oubliée : Microsoft s'adapte à la demande du client, il ne dit pas "mais tu n'as qu'à faire comme ça". Un client pro ne veux pas de un patch par jour.

            • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

              Posté par  . Évalué à 4.

              C'est pas parce que tu as régulièrement des mise à jour que tu es obligé des les appliquées dans la minute, en plus la plupart des distributions sépares les mise à jour critiques des corrections de bug, donc il est facile de faire le tri et de regroupé les test une fois par mois.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                Posté par  . Évalué à 0.

                Justement, regrouper a la fin du mois n'est pas une bonne solution, parce qu'une fois le patch sorti, nos chers amis du cote obscur se mettent a regarder ce qui a cause le bug et voir ce qu'ils peuvent faire avec.

                Faut pas oublier que l'enorme majorite des failles sont "secretes" jusqu'au moment de la publication des patchs, seul la personne qui a rapporte le bug et l'editeur la connaissent habituellement jusqu'a ce moment ce qui limite les risques(raison pour laquelle Mozilla/RH/... bloquent l'acces a ces bugs dans leur bugzilla jusqu'a la sortie du patch). Une fois le patch sorti par contre, c'est la course a celui qui cree l'exploit le plus vite possible.

                Bref, je suis pas sur que tu aies envie d'attendre le 30 Juillet pour tester un patch sorti le 2 Juillet...

                • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                  Posté par  . Évalué à 2.

                  C'est pour ça que je dis qu'elle sépare les mise à jour critiques des autres, après à chacun de voire en fonction de ce qu'il utilise. Et puis comme beaucoup de distribution utilise les même programmes, une fois qu'une a sorti un patch, les autres doivent le faire pour être cohérent et pas laissé une faille bien visible.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

              Posté par  . Évalué à 6.

              Il y a une chose souvent oubliée : Microsoft s'adapte à la demande du client, il ne dit pas "mais tu n'as qu'à faire comme ça". Un client pro ne veux pas de un patch par jour.

              Ah bon ?

              Chacun son concept de "pro"...


              Ici on a un démon perl qui récupère les annonces de debian security, et compare avec la liste des applis installées sur nos machines (chaque jour la db est mise à jour en fonction du dpkg -l de chaque machine).

              À partir de là, on sait combien d'applis ont une faille de sécurité, sur combien de machines et si c'est du remote ou pas.

              C'est quand même un peu plus pratique :
              * Nos serveurs sont au mieux patchés rapidement (moins de 24h), au pire il faut deux ou trois jours pour les serveurs les plus critiques le temps de se préparer un peu, alerter les utilisateurs impactés, prévoir la procédure de mise à jour etc. Bref, c'est moins que le temps que ce que doit faire Windows pour publier ses patches.
              * On n'a pas besoin de mettre à jour des machines pour rien : Si on a une faille kernel qui permet une escalade des privilèges sur un serveur dans notre DMZ parano (celle dans laquelle une seule machine est autorisée à faire du ssh vers toutes les autres machines, la machine en question ne disposant que de ssh).
              * Personne n'a privilégié la vitesse à la qualité. Ici on utilise du debian stable, on a dont les deux. Fedora n'a rien à faire en entreprise (enfin pas sur les serveurs en tout cas, sur les postes clients pourquoi pas. J'ai bien du Debian testing/unstable ici).


              Ah oui, un petit détail : Certains de nos serveurs réalisent des transferts d'argents assez conséquents (genre quelques millions d'euros à la semaine, sur tous les serveurs ça dépasse parfois le milliard). Donc vous comprendrez aisément que le "on a un patch, mais faut attendre deux semaines pour mettre à jour", ça passe moins bien que "la machine sera patchée 3 heures après qu'on ait eu l'information".

              • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

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

                Tu compares l'incomparable : tu administres des machines avec beaucoup de temps consacré sur la gestion des MAJ.
                Dans d'autres entreprises, ce temps-la est moins disponible : juste le temps de faire ce qu'une personne externe ne peut faire (tester ses propres applis)

                Donc dans ton cas effectivement ta méthode est la meilleure. Sauf qu'elle n'est pas applicable à la grosse majorité des entreprises qui n'ont ni les compétences, ni le temps (argent) à consacrer à la chose.

            • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

              Posté par  . Évalué à 4.

              C'est genial windows tout de meme et les admins windows tout de meme.
              C'est rigolo je trouve. <mode ironique>Il est clairement plus simple de verifier sur les machines tests que les 30 patch passent tout les mois plutot que appliquer les patchs independemment sur la machine test, verifier que aucun individuellement de fout le merdier, regrpouper bousin et l'appliquer globalement.

              Enfin la logique des microsftiens me surprendras toujours...

              Il y a une chose souvent oubliée : Microsoft s'adapte à la demande du client, il ne dit pas "mais tu n'as qu'à faire comme ça". Un client pro ne veux pas de un patch par jour.

              C'est sur que les clients pro ils preferent avoir des trous de securite exploitable et exploite... Ceci demontre un profond professionnalisme ! J'ai plutot l'impression que les admins windows sont de grosses feignasses qui se bougent le cul une fois par mois mais je suis pas persuade que les patrons seraient d'accord avec cela. Enfin il est vrai aussi que sous windows a la moindre mise a jour/installation l'OS te demande de redemarrer (m'en tape que ce soit pas forcement necessaire puisque le systeme le demande c'est qu'il y a une raison ou que cela fait aussi parti de la programmation avec les pieds ou que si c'est parceque a chaque mise a jour cela veut dire que le kernel a ete patche c'est legerement inquietant sur la qualite du bousin et on revient au point precedent...).

              • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                Posté par  . Évalué à -1.

                verifier que aucun individuellement de fout le merdier, regrpouper bousin et l'appliquer globalement.

                !!!!

                C'est bon de rire parfois...

                • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                  Posté par  . Évalué à 3.

                  le vendredi, c'est dinde au whisky

                  • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                    Posté par  . Évalué à 3.

                    Non non, c'est pas ca qui me fait rire.

                    C'est plutot le fait qu'albert, grand expert en securite et en stabilite si on en croit ses piques recurrentes sur MS, considere que tester separement des patchs est une politique fiable.

                    Comme si on avait jamais vu des patchs marcher correctement separement tout peter une fois mis ensemble.

                    • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                      Posté par  . Évalué à 1.

                      alors que le clone de pbpg pense que ecrire un programme de 42000 lignes sans faire un seul test c'est sur que cela va fonctionner du premier coup....

                      Ouhais c'est un peu le meme principe ton truc. Si jamais tu as un patch qui fout la merde de facon individuel (naturellement il n'est pas exclu surtout avec microsoft que la combinaison des patchs posent probleme) c'est archement plus simple de le trouver lorsque tu appliques les yeux fermes un ensemble. Ouhais en gros toi tu as une ampoule qui grille de facon recurrente dans ta maison et le meilleur moyen de reparer ca c'est de refaire l'installation electrique au total? Certes dans cette periode de crise c'est une facon de relancer la consommation je suis pas sur que cela soit la facon la plus economique (j'ai failli dire la plus intelligente mais comment puis je moi grand debile profond utiliser ce mot?)

                      • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                        Posté par  . Évalué à -2.

                        Un truc que j'adore avec toi, c'est te mettre le nez dans tes idioties et te voir faire des pirouettes pour te rattraper aux branches (qui cassent toutes tres vite)....

                        Ton message en dit long sur ta vision de la validation (ou sur ton honnetete intellectuelle, c'est selon).

                      • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                        Posté par  . Évalué à 0.

                        J'oubliais, la petite pique de 42 000 lignes.
                        Ta comprehension du francais pourtant suffisament correcte ne s'ameliore pas.

                        Je te renvoie a mes messages des 2 derniers jours, n'hesite pas a prendre un dictionnaire et un bescherelle pour les mots que tu ne comprends pas.
                        Voire fait toi aider par un ami (si tu en as) pour etre sur que tu as bien lu les mots.

                      • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                        Posté par  . Évalué à -1.

                        Ouhais c'est un peu le meme principe ton truc. Si jamais tu as un patch qui fout la merde de facon individuel (naturellement il n'est pas exclu surtout avec microsoft que la combinaison des patchs posent probleme) c'est archement plus simple de le trouver lorsque tu appliques les yeux fermes un ensemble.

                        Si tu savais de quoi tu parles, ce qui n'est visiblement pas le cas du tout, tu saurais que c'est la methode preferee des entreprises.

                        Tout simplement car les problemes sont assez rares pour valoir cette approche :

                        On installe tous les patchs qu'on va installer au final sur nos machines, on regarde si il y a un probleme.
                        Si il y en a un, on enleve les patchs et on isole le patch fautif.

                        Mais bon, un jour peut-etre il te viendra a l'idee de t'informer avant de sortir des idioties sur un sujet auquel tu ne connais rien...

                        • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                          Posté par  . Évalué à 1.

                          \o/ Zorro arrive sur son cheval pour soutenir le faible et l'opprime.

                          Tout simplement car les problemes sont assez rares pour valoir cette approche

                          Ben le jour ou le "assez rare" se passe c'est legerement embettant. Tu vois c'est comme ubuntu avec ses 2 problemes d'updates en 4 ou 5 ans, tu en fais encore des gorges chaudes. Comme la tu t'extasie devant des problemes de mise a jour d'une version de test. Franchement il t'en faut vraiment peu dommage que tu sois pas aussi rigoureux dans ton boulot et donc que l'OS sur lequel tu bosses soit pas parfait cela casse un peu la credibilite de ton discours et de tes attaques.

                          • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                            Posté par  . Évalué à 0.

                            tu sais, le seul qui attaque ici, c'est toi...

                            Don "Albert" Quichotte contre les moulins...

                            Tiens, tant que j'y pense, cette pile tcp qui viendrait de bsd...
                            On attends toujours tes references.

                            • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                              Posté par  . Évalué à 0.

                              Franchement un vrai clone de pbpg avec les memes remarques. Sache que traite les gens d'idiot est une forme d'attaque.

                              Pour la pile BSD (dont je vois absolument ni la raison de ta demande ni le rapport avec le shmiblick) je te laisse utiliser tout seul la fonction de recherche inclu dans le site car les liens ont deja ete donne et je n'ai ni l'envie ni le temps de m'amuser a ce genre de chose aujourd'hui. Enfin il faudrait que osit tu achete une extension memoire soit suivre un peu mieux les trolls.

                              • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                                Posté par  . Évalué à 2.

                                je te laisse utiliser tout seul la fonction de recherche inclu dans le site car les liens ont deja ete donne
                                Ah bon?
                                Moi je me rappelle surtout que t'avais pretendu que pb pg avait dit que la pile tcp n'avait jamais contenu de code bsd.
                                Ce a quoi je t'avais fourni des liens de commentaire de pb pg disant exactement le contraire.

                                Et juste apres, t'avais disparu...

                                'tention, tu casses des grosses branches la...

                          • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                            Posté par  . Évalué à 1.

                            Ben le jour ou le "assez rare" se passe c'est legerement embettant. Tu vois c'est comme ubuntu avec ses 2 problemes d'updates en 4 ou 5 ans, tu en fais encore des gorges chaudes.

                            Allez petite demonstration prouvant a quel point tu ne comprends rien au sujet.

                            Disons que tester les apps sur un systeme prend 6h

                            Tester 30 patchs separement :

                            30x6h +1x6h pour tester les patchs ensemble

                            Tester 30 patchs ensemble :

                            1x6h + max 30x6h si il y a un probleme pour isoler le patch responsable, ce qui est rare, en moyenne ca sera moins que 30x6 vu que c'est patch par patch jusqu'a ce que le fautif soit trouve et pas jusqu'a 30

                            Bref, sur un an, en imaginant des problemes 3 mois sur 12 :

                            Tester separament: 12*31*6 = 2232h
                            Tester ensemble: 12*6+3*30*6 = 612h

                            Tu realiseras que meme avec des problemes 12 mois par an, tu arrives au meme nombre d'heures. Bref, ta solution est perdante dans tous le cas.

                            Merci d'avoir joue, tu es tres tres fort pour causer, dommage que tu sois tres tres faible lorsqu'il s'agit de dire des trucs intelligents.

                            • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                              Posté par  . Évalué à 0.

                              6h pour effectuer un test unitaire d'un seul patch ?

                              C'est plus des patchs c'est des tracteurs ! (et des gros !!)


                              Ah, ou alors c'est peut-être que chez microsoft on ne fait pas de tests unitaires automatisés, ça expliquerait beaucoup de choses en fait.

                              Non, parce que si au lieu de faire des tests unitaires d'abord, pendant le cycle de développement, puis un test global (automatique), puis si tout marche un test "à la main", vous vous contentez du test à la main, ça explique beaucoup de choses.

                              Et même, là, j'avoue, si c'est votre méthodologie de travail, là je dis que oui, je suis fan de microsoft. Je veux dire, arriver à faire un système d'exploitation, et même la pire des usines à gaz, et arriver à la faire fonctionner, avec ce genre de méthodes, ça relève de l'héroïsme.

                              Je veux dire, c'est comme un mec que tu verrais se taper répétitivement la tête contre un mur, au point qu'il y ait une petite fente dans le mur, si il le fait juste pour le plaisir de se taper la tête contre un mur c'est un peu con, mais si il le fait dans le but de faire s'effondrer le mur, c'est héroïque...

                              • [^] # Re: Hum, qualité ok, mais de là à attendre 7 ans ...

                                Posté par  . Évalué à 2.

                                Avis personnel:

                                Avant de jouer a l'arrogant, je te suggeres de savoir de quoi tu parles, ca t'evitera de passer pour un idiot complet.

                                Au hasard, j'imagines que tu n'as jamais entendu parler de :
                                - localization testing
                                - stress testing
                                - interoperability testing
                                - application compatibiltiy testing
                                ...

                                Les tests unitaires c'est une infime partie du test d'un soft, c'est encore plus infime lorsqu'il s'agit d'un OS

                                Sans parler du fait que mon post parlait d'une entreprise testant ses softs avec les patchs installes, pas MS testant ses patchs.

                                Bref, ton post, a part etre arrogant et provocant, est completement stupide, a cote de la plaque, et te fais passer pour un clown du niveau d'Albert.

                                Si ton intention est de pourrir les debats t'es sur le bon chemin, mais tu ne vas pas te faire beaucoup d'amis en suivant ce chemin.

  • # Fedora

    Posté par  . Évalué à 6.

    Il est clair et net que Fedora sort ses updates beaucoup plus vite que MS, mais au vu des resultats, il vaut mieux visiblement attendre que d'autres cobayes utilisateurs aient installes les updates avant de les installer soi-meme...

    Eheh, certains soft sont libres, c'est pas pour autant qu'il n'y a pas un prix à payer :P (gniarf gniarf gniarf)

    Vu le prix pécunier des licences MS la moindre des choses c'est qu'ils testent leur softs comme des malades. J'espère d'ailleurs que RH n'a pas pas le même genre de laisser aller que Fedora sur ce point.

    • [^] # Re: Fedora

      Posté par  . Évalué à 4.

      "Laisser-aller", c'est vite dit :
      - comme dit plus haut, Fedora c'est dès le départ une distro "bleeding-edge", rien d'étonnant à ce que la stabilité ne soit pas la priorité
      - selon le blog de Richard Hugues, pointé par le journal, le patch foireux a été appliqué à la branche instable de Fedora. Pour du bleeding-bleeding-edge, rien d'étonnant.
      - et encore, le même Richard Hugues s'étonne qu'un truc aussi gros ait pu passer, apparemment ce n'est pas la procédure habituelle.

      Et malgré ça, 3 jours après la date du billet le correctif définitif et débuggé était poussé sur les dépôts. Dans l'intervalle je suppose que les utilisateurs concernés ont downgradé le package fautif. Donc on a quand même une correction rapide et efficace du problème. Pas besoin d'attendre un mardi.

      Et puis on n'est pas non plus dans le cas de la monoculture Microsoft : sur toutes les distros existantes, et toutes leurs versions, seule la Fedora instable a été touchée.

      • [^] # Re: Fedora

        Posté par  . Évalué à 4.

        Et puis quand on utilise une distrib en instable on se prépare à se genre de truc...

      • [^] # Re: Fedora

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

        rien d'étonnant à ce que la stabilité ne soit pas la priorité
        Moi ça me fait marrer l'utilisation du terme "stabilité", on dirait du politiquement correct. Pourquoi ne pas dire les choses franchement :
        rien d'étonnant à ce que la qualité ne soit pas la priorité
        Voir d'être encore plus honnête :
        ils n'ont pas les moyens de faire de la qualité

        • [^] # Re: Fedora

          Posté par  . Évalué à 2.

          Voir d'être encore plus honnête :
          ils n'ont pas les moyens de faire de la qualité

          Toi pas comprendre toi tout melanger.

          Ne pas melanger la notion de version de developpement et version stable. En gros tu pretend que Windows seven devrait deja etre aussi stable que Vista... Oups mauvais exemple ca c'est pas difficile. Un meilleur exemple serait de comparer la F1 (avant les derniers changement) terrain de test des nouvelles technos automobile et les voitures vendu chez le concessionaires. Ce n'est ni le meme but ni la meme stabilite qui est atteint.

          • [^] # Re: Fedora

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

            Toi non plus y'en a rien comprendre.
            Je ne critiques pas Fedora et ce qu'elle vise et ce qu'elle est. Je dis juste que le problème dont on parle dans ce journal n'est pas un problème de stabilité mais un problème de qualité.
            Moi la stabilité, c'est quand ma machine a des comportements parfois aléatoire, une appli qui plante de temps en temps. Quand par contre tu fais une update qui rend ta machine inutilisable, là c'est pas de la stabilité, c'est un bug fonctionnel critique. C'est un problème de qualité qui n'est pas de la stabilité.

            • [^] # Re: Fedora

              Posté par  . Évalué à 6.

              Ah c'est pour ca que tu reponds a un message parlant du fait que c'est la partie instable de la distribution qui a ete pointe par le journal?
              Tu n'as rien compris au message auquel tu reponds point barre.

              Tout ton message c'est d'arriver a pretendre que RH ne peut pas faire de la qualite c'est du n'importe quoi et un FUD enorme.

              Ce que dit le monsieur, c'est que ce n'est pas RHEL qui a eu le probleme, le probleme a eu lieu dans la version instable de la version de developpement en gros c'est comparer Windows seven et windows XP. Alors maintenant si tu utilises cette partie de fedora c'est en connaissance de cause et tu n'as pas a te plaindre d'instabiliter (si ce n'est en faisant remonter les bugs). Dans le meme principe c'est comme si un utilisateur windows disait que Windows seven etait une merde sans nom alors que c'est qu'une version de developpement qui est propose pour les testeurs.

              Comparons des pommes avec des pommes et des oranges avec des oranges.

              • [^] # Re: Fedora

                Posté par  . Évalué à 3.

                et encore dans ma comparaison je suis gentil la vrai comparaison ce serait "comparer windows seven interne de microsoft au jour le jour" Ce qui n'est clairement pas faisable et je suis a peu pres persuade que dedans il y a eu des bugs bien pire!

              • [^] # Re: Fedora

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

                Ah c'est pour ca que tu reponds a un message parlant du fait que c'est la partie instable de la distribution qui a ete pointe par le journal?
                bah oui. Justement pour dire que l'argument "instable" donc "faut s'y attendre" est bidon. C'est pas un problème de stabilité, c'est un problème fonctionnel critique et au final un gros manque de qualité.
                Ca s'explique très bien vu le contexte de Fedora, mais faut dire les choses comme elles sont et appeler un chat un chat.

                Tu n'as rien compris au message auquel tu reponds point barre.
                T'as rien compris à ce que j'ai dis, comme d'hab, point barre.

                Comparons des pommes avec des pommes et des oranges avec des oranges.
                Y'a que toi qui fait des comparaisons de merde, moi je compares rien, y'a rien à comparer, juste un constat : c'est pas un problème de stabilité.

                • [^] # Re: Fedora

                  Posté par  . Évalué à 1.

                  Mais bien sûr que si que c'est un problème de dépot stable / instable (j'avais pas pris en compte plus haut que c'était sur un dépot instable, je croyais que c'était plus grave que ça). Le système des dépots à plusieurs niveau de stabilité fait parti intégrante du processus de qualité des distributions, et le fait que le problème ait été détecté sur un dépôt instable au lieu d'exploser à la gueule de tout le monde montre que le processus fonctionne. L'existence même du dépôt instable est en partie due à la nécessité de tester en public et de limiter l'impact des erreurs qui auraient pu ne pas être remarquées par les mainteneurs et autres personnes intéressées par la modification pendant leur tests persos (qui eux aussi sont généralement en partie public avec un dialogue généralement basé sur une ML publique ou un tracker public, etc.)

                  À noter finalement qu'il ne faut pas comprendre de travers le sens des mots stables / instables qui désigne en priorité le rythme des modifications dans ce cas, et non de manière directe la propension à crasher / tout casser / etc. (bien de manière indirecte et même voulu une distribution stable, ayant vu un effort de qualité supérieur, présente moins de risque de problème qu'une instable pris au pif et freezée).

            • [^] # Re: Fedora

              Posté par  . Évalué à 2.

              dernier truc avant que j'arrete de repondre a ton message:

              Explique moi comment tu fais des tests de qualite si tu ne peux pas mettre de code dans la version instable de la version de developpement d'une distribution? Je suis bien curieux d'avoir une solution a ceci...

              • [^] # Re: Fedora

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

                j'appelle ma branch de developpement devel, pas instable. et quand j'ai un problème de ce genre, je parle pas de stabilité.

              • [^] # Re: Fedora

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

                Et puis bon le plus drôle dans l'histoire, c'est que même "instable" c'est pas assez politiquement correct. Sur le site de Fedora :
                "Fedora is a Linux based operating system that provides users with access to the latest free and open source software, in a stable, secure and easy to manage form. "

                • [^] # Re: Fedora

                  Posté par  . Évalué à 2.

                  ON TE PARLE DE LA BRANCHE DE DEVELOPPEMENT INSTABLE DE FEDORA. Tu vas dire que c'est anormal que la branche du kernel 2.6.29-dev-qui'test-des-choses introduit des bugs?

                  Tu vas arriver a te l'enfoncer dans la tete qu'il n'est question ni de RHEL (ton attaque sur Redhat) ni de Fedora (version dite stable de la distrib blending edge). La encore tu melanges des pommes et des poires. En gros tu consideres Windows Home edition l'equivalent de Windows Server pour prendre des analogies que tu peux aprehender.

                  • [^] # Re: Fedora

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

                    ON TE PARLE DE LA BRANCHE DE DEVELOPPEMENT INSTABLE DE FEDORA
                    T'es vraiment du mal, je répondais à la phrase :
                    "comme dit plus haut, Fedora c'est dès le départ une distro "bleeding-edge", rien d'étonnant à ce que la stabilité ne soit pas la priorité"
                    Concernant le fait que c'est dans la branche "testing", je l'ai déjà dis et je le répète, je comprends tout à fait qu'un tel problème arrive.
                    Et arrête tes comparaisons avec windows, c'est pas le sujet.

                  • [^] # Re: Fedora

                    Posté par  . Évalué à 2.

                    Fedora 10 c'est la branche de developpement instable ?

                    http://lwn.net/Articles/311146/

                    C'est la branche stable qui a ete touchee, pas la branche instable.

  • # Troll magnifique, bravo... chapeau bas

    Posté par  . Évalué à 5.

    0_o J'ai déjà lu quelques commentaires de pas Bill pas Gates pour ne pas être trop étonné, mais là, c'est très fort.

    Associer "windows" et "qualité", c'est comment dire... le monde de Disney. :-o

    • [^] # Re: Troll magnifique, bravo... chapeau bas

      Posté par  . Évalué à 5.

      Il y a longtemps qu'il n'a plus honte de rien.

    • [^] # Re: Troll magnifique, bravo... chapeau bas

      Posté par  . Évalué à 6.

      Je pense que tu as tort, le défaut de windows, c'est les drivers non certifiés. Le problème est le même sous Linux, install le un driver nvidia pourri, et ton noyau peu également planter.

      Windows, j'aime pas, mais c'est pas une raison pour écrire des conneries.

      • [^] # Re: Troll magnifique, bravo... chapeau bas

        Posté par  . Évalué à 1.

        Je pense que tu as tort, le défaut de windows, c'est les drivers non certifiés. Le problème est le même sous Linux, install le un driver nvidia pourri, et ton noyau peu également planter.

        Pas du tout efface, 1) les drivers windows sont certifie 2) installe windows dans un virtualbox, rajoute deux trois applis bizarre et fournis par une boite qui l'est encore plus tel que Microsoft Office (facultatif) 3) fait les mise a jour de securite demande par l'autoupdate du systeme
        et la miracle le systeme par en boucle de arret/redemarrage ininterrompu... Probablement un patch qui s'installait/configurait mal...

        Cela avec une version boite de windows legalement achete, non OEM et avec uniquement les drivers fournis par le bousin.

        (Je precise que l'installation c'est fait dans une virtualbox car la version en question refuse de s'installer sur le portable en question enfin si mais il faut aimer les 256 couleurs et les resolutions 640x480 vu que les drivers ATI certifie microsoft, refuse de s'installer. En gros seul la version OEM passe dessus mais comme ce dernier me prend 10 Gigs (apres avoir vire le merdier) elle est pas reste longtemps.)

        Enfin dernier point comme nous l'a deja dit notre cher troller microsfien pbpg, la certification microsoft d'un driver te dit juste que le driver s'installe pas forcement qu'il fonctionne et qu'il fout pas le merdier dans le systeme. (Ah les celebres drivers, certifie microsoft, iomega pour lecteur zip qui faisaient un kernel panic au redemarrage de NT4...)

      • [^] # Re: Troll magnifique, bravo... chapeau bas

        Posté par  . Évalué à 4.

        Conneries ?Ne soyons pas vulgaires et évitons les gros mots...

        J'exprimais simplement mon admiration, un jour de troll, d'oser associer de façon faussement candide deux termes pour lesquels l'association d'idées relève de la contorsion : "windows" et "qualité".

        Maintenant, chacun peut croire en ce qu'il veut, même en ça... Mais à ce moment là, c'est du domaine de la religion et non de la raison. Et la foi, ce n'est pas raisonnable ;-)

  • # lol

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

    Ouais, enfin vous êtes pas mal chez vous non plus quand même ^_^
    http://www.generation-nt.com/microsoft-exploit-ie-vulnerabil(...)

  • # La qualité d'abord

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

    Personnellement, quel que soit le système, je choisi la qualité, raison pour laquelle je laisse les autres essuyer les plâtres...

    Par exemple, je suis passé à Ubuntu 8.04 en octobre.

    • [^] # Re: La qualité d'abord

      Posté par  . Évalué à 10.

      je choisis la qualité … je suis passé à Ubuntu…

      On est vendredi, mais quand même !

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

      • [^] # Re: La qualité d'abord

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

        Arf !!

        Pour être plus explicite, j'ai installé une version sortie depuis plus de 6 mois, au lieu de la dernière mouture qui venait juste de sortir quelques jour auparavant.
        De plus c'est une version LTS que j'ai choisi.

        • [^] # Re: La qualité d'abord

          Posté par  . Évalué à 1.

          Ubuntu même en LTS après 6 mois, c'est pas trop ça. Moi j'ai été content de passer à la nouvelle version en octobre. Lenny étant en phase de stabilisation, la nouvelle m'a semblé bien plus stable, et je pense qu'elle l'est.

          Envoyé depuis mon lapin.

    • [^] # Re: La qualité d'abord

      Posté par  . Évalué à 4.

      <mode troll>Ubuntu et qualite dans la meme phrase? :)</>

  • # mes2cents

    Posté par  (Mastodon) . Évalué à 2.

    Etes vous pret a prendre ce genre de risques pour votre (vos) systeme(s) en echange d'une vitesse de sortie accrue des patchs ?

    Cette question ne (me) semble valable que si on pose d' abord la question de la saveur choisie de la distribution. Tu sembles sous entendre une distribution stable, objectif Mr michu.

    Ok, alors on peut éliminer de suite : Fedora, OpenSuSe, Ubuntu et Mandriva cooker.
    Dans les grandes à destination de Mr Michu, il reste donc : RedHat, SuSe, Debian & Mandriva, et bien sûr Ubuntu lts.

    Pour reprendre les propos de PasBillPasGates, avec lequel je partage cette vision : un patch ne peux pas prévoir toutes situations. Donc on élimine les installations foireuses et les Mr Brico-Michu...

    Sortir des patchs toujours le même jour me semble stupide. Il faut les sortir quant il y en a besoin. Cela fait un peu "les oiseaux volent" mais c est tellement vrai ... (surtout en considerant une architecture distribuée pour l' envoi des patchs...)

    Enfin il faut aussi voir la saveur de la saveur :p ie : l' emploi choisi pour la distribution. Mr Michu ayant un serveur sous Debian n' a pas le même système installé que Mr Michu ayant un laptop au top de la techno sous Mandriva ou Ubuntu. C' est pratique parceque pour le coup le patch critique pour un serveur a moins de chance de casser quelque chose... ce qui permet de le distribuer plus vite... et un serveur, ça tombe bien, en a besoin rapidement...
    Mr Michu avec son laptop, il peux attendre un peu, que la QA ait pris le temps de tester un maximum d' impact dans un maximum de possibilités...

    Cdlt.

    ps : au modèle classique Editeur->patch il faut aussi ajouter le nouveau modèle que linux en train de rendre possible : celui Editeur->Constructeur->Patch. Exemple : sur un Acer Aspire One avec une base Linpus Linux Lite (base Fedora) C' est Acer qui se charge de la QA et de la distribution des patchs. Et en tant que Mr Michu je n' ai pas eu en m' en plaindre ...

    • [^] # Re: mes2cents

      Posté par  (Mastodon) . Évalué à 2.

      Donc on élimine les installations foireuses et les Mr Brico-Michu... Et si MS et Linux n' élimine pas les Mr Brico-Michu de la même manière... Sous Windows ils n' ont pas le droit d' exister et sous Linux ils peuvent faire ce qu' ils veulent et ils assument.

  • # QA Microsftienne == QA ubuntu

    Posté par  . Évalué à 2.

    on commence bien l'annee tout de meme. Microsoft a meme pas attendu une seconde pour feter dignement celle annee 2009 et prouve l'excellence du QA redmondien :)

    Ah le zune franchement une des plus belle reussite de ces derniers annees :D

    http://www.aeroxp.org/2009/01/lesson-on-infinite-loops/

Suivre le flux des commentaires

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