A tu des elements de comparaisons pour dire qu'il y a plus de bugs que dans les versions precedentes/chez les concurents ?
Ce n'est généralement pas comme ça qu'on procède dans le domaine de la sécu informatique : on parle des bugs connus (« n'utilisez pas le produit x version y pour faire telle chose, il présente des déficiences notable sur le plan sécurité »). Ne serait-ce que pour encourager ceux qui maintiennent le produit à corriger leur failles prompto (et à tacher d'éviter d'en faire d'autres du même genre la prochaine fois), ou permettre à ceux qui utilisent le produit de ne pas tomber dans le cas d'utilisation qui expose le problème. Le boulot des journalistes et des professionnels de la sécurité informatique est de nous avertir pour faire bouger les choses : Cyrix, qui produisait des procs sensiblement buggués en sait quelque chose : ils l'ont senti passer, et heureusement qu'on n'a pas gardé le silence.
Deuxièmement, on parle ici d'un type de bugs un peu particulier, surtout pour le monde du matériel : ce sont des bugs ayant un potentiel fort d'impact sur la sécurité.
Concernant les hypothétiques mais probables bugs « dont on ne sait rien », on peut bien sûr se perdre en conjectures... mais est-ce bien utile ? ça ne l'est surement pas s'il s'agit de dédouaner ceux dont les bugs sont connus !
Tout les cores aussi complexe que les x86 ont forcement des bugs
Et ? faut-il s'abstenir de faire état des problèmes dont on apprend l'existence ? Tu imagine si nous réagissions comme ça pour le logiciel « (n'en parlons pas | ne jetons pas la pierre ) parce que tout logiciel de plus de 1000 lignes contient forcément des bugs » ?
Certains fournisseurs ne publient pas les bugs
Souhaitons que quelques bonnes vieilles full disclosure vienne leur boter le train. Encore une fois, le précédent de Cyrix devrait les inciter à la prudence (je pense à ce sujet qu'AMD est méchamment sur le déclin, et depuis leur rachat d'ATI ils sont sur ma liste noire de constructeurs travaillant comme des cochons, ne filant ni specs ni code libre pour leurs chipsets).
[^] # Re: Linus a dit : « c'est totalement insignifiant »
Posté par herodiade . En réponse au journal l'Intel Core 2 Duo considéré dangereux par Theo de Raadt. Évalué à 5.
Ce n'est généralement pas comme ça qu'on procède dans le domaine de la sécu informatique : on parle des bugs connus (« n'utilisez pas le produit x version y pour faire telle chose, il présente des déficiences notable sur le plan sécurité »). Ne serait-ce que pour encourager ceux qui maintiennent le produit à corriger leur failles prompto (et à tacher d'éviter d'en faire d'autres du même genre la prochaine fois), ou permettre à ceux qui utilisent le produit de ne pas tomber dans le cas d'utilisation qui expose le problème. Le boulot des journalistes et des professionnels de la sécurité informatique est de nous avertir pour faire bouger les choses : Cyrix, qui produisait des procs sensiblement buggués en sait quelque chose : ils l'ont senti passer, et heureusement qu'on n'a pas gardé le silence.
Deuxièmement, on parle ici d'un type de bugs un peu particulier, surtout pour le monde du matériel : ce sont des bugs ayant un potentiel fort d'impact sur la sécurité.
Concernant les hypothétiques mais probables bugs « dont on ne sait rien », on peut bien sûr se perdre en conjectures... mais est-ce bien utile ? ça ne l'est surement pas s'il s'agit de dédouaner ceux dont les bugs sont connus !
Tout les cores aussi complexe que les x86 ont forcement des bugs
Et ? faut-il s'abstenir de faire état des problèmes dont on apprend l'existence ? Tu imagine si nous réagissions comme ça pour le logiciel « (n'en parlons pas | ne jetons pas la pierre ) parce que tout logiciel de plus de 1000 lignes contient forcément des bugs » ?
Certains fournisseurs ne publient pas les bugs
Souhaitons que quelques bonnes vieilles full disclosure vienne leur boter le train. Encore une fois, le précédent de Cyrix devrait les inciter à la prudence (je pense à ce sujet qu'AMD est méchamment sur le déclin, et depuis leur rachat d'ATI ils sont sur ma liste noire de constructeurs travaillant comme des cochons, ne filant ni specs ni code libre pour leurs chipsets).