Le site Distrowatch propose un très intéressant tableau comparatif pour voir le temps de réaction des principales distributions lors de la récente alerte de sécurité du noyau Linux.
Quel a été le délai entre la publication générale de l'alerte sur tous les sites (le 11 février) et la mise à disposition du patch correcteur par les différentes distributions ?
Distribution => Delay
Debian GNU/Linux => +0 hours
Fedora => +8 hours
Slackware Linux => +12 hours
Mandriva Linux => +19 hours
Frugalware Linux => +21 hours
openSUSE => +23 hours
rPath Linux => +26 hours
Red Hat Enterprise Linux => +27 hours
Ubuntu => +27 hours
CentOS => +37 hours
Le site Distrowatch souligne néanmoins qu'il ne faut pas surinterpréter ces chiffres. Certaines distros proposent le support de diverses architectures alors que d'autres ne sont disponibles pour les CPU les plus répandus. Il est évident que le temps de réaction ne sera pas le même.
De même les grosses distros commerciales (Red et Suse) testent certainement plus longtemps leurs patchs car les clients qui payent n'aiment pas les problèmes lors des mises à jour.
L'article de Distrowatch indique également que certaines distros (Arch ou Zenwalk par exemple) n'ont toujours pas proposé le patch correcteur à leurs utilisateurs.
Quel a été le délai entre la publication générale de l'alerte sur tous les sites (le 11 février) et la mise à disposition du patch correcteur par les différentes distributions ?
Distribution => Delay
Debian GNU/Linux => +0 hours
Fedora => +8 hours
Slackware Linux => +12 hours
Mandriva Linux => +19 hours
Frugalware Linux => +21 hours
openSUSE => +23 hours
rPath Linux => +26 hours
Red Hat Enterprise Linux => +27 hours
Ubuntu => +27 hours
CentOS => +37 hours
Le site Distrowatch souligne néanmoins qu'il ne faut pas surinterpréter ces chiffres. Certaines distros proposent le support de diverses architectures alors que d'autres ne sont disponibles pour les CPU les plus répandus. Il est évident que le temps de réaction ne sera pas le même.
De même les grosses distros commerciales (Red et Suse) testent certainement plus longtemps leurs patchs car les clients qui payent n'aiment pas les problèmes lors des mises à jour.
L'article de Distrowatch indique également que certaines distros (Arch ou Zenwalk par exemple) n'ont toujours pas proposé le patch correcteur à leurs utilisateurs.
> Lire le journal (33 commentaires, moyenne: 2,9).
Vous avez demandé le commentaire #905566.
Run by 
Cette page a été générée par Templeet en 0.0539s (dont 0.0055 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Pas compris
Je trouve étrange de lire "Certaines distros proposent le support de diverses architectures alors que d'autres ne sont disponibles pour les CPU les plus répandus" alors que d'après le tableau, debian qui tourne sur un paquet d'architectures arrive première avec "0 hours".
Bref, je sais pas ce qu'on peut vraiment tirer de ces chiffres, mais cette phrase ne m'a pas l'air pertinente.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Pas compris
cette phrase ne vise pas debian.
Si elle existait "officiellemen" sur autant d'architectures que debian, je ne crois pas que slackware aurait été la 3ème plus rapide étant donnée le nombre de mainteneur restreint.
[^]Re: Pas compris
C'était juste une mise en garde pour éviter les trolls.
Frugalware par exemple ne supporte que les x86 et x86_64 alors que Red Hat Enterprise Linux support beaucoup plus d'archis.
[^]Re: Pas compris
Je l'ai interprété comme une attaque subtile contre Ubuntu : Ubuntu, dérivée de Debian et qui supporte moins d'architectures a eu besoin de 27h pour fournir un correctif.
Je suis paranoïaque ?
[^]Re: Pas compris
bah au moins on sait pourquoi il ne faudra pas se tourner vers une LTS en tatn que serveur...
http://astrolix.org
[^]Re: Pas compris
La LTS actuelle (Dapper) tournant sur 2.6.15, elle n'était pas impactée.
Claws Mail - it bites!
[^]Re: Pas compris
>>> Je suis paranoïaque ?
Oui puisque je suis ubuntiste.