Ça marche pas comme ça. Un ministère va utiliser une distribution Linux et attendre que l'éditeur fournisse les mises à jour, quitte à payer (!) le support (ex: Red Hat).
Justement non, pourquoi est-ce que le ministere virerait Windows si c'est pour se retrouver dependant d'une autre societe qu'il ne controle pas ?
Au niveau de l'audit : pour trouver de bugs, code source/binaire compilé, même combat. Il existe des outils pour auditer les deux. Sauf que si on a les sources, on a deux fois plus d'outils, passons. Le problème est plus du côté de la manière de corriger
Oui, et le gouvernement a les sources de Windows comme tu le sais, donc c'est pas un probleme pour lui.
Dans le cas de Windows, il est presque impossible de se passer de Microsoft (enfin, de l'éditeur du logiciel dont on n'a pas les sources). Alors que pour Linux, tu peux patcher les sources et maintenir ta propre version du paquet (ça coûte pas cher en maintenance), au moins en attendant que l'éditeur patche (ou alors si tu veux garder le correctif pour toi).
Oui en theorie.
Maintenant petite question: tu es le ministere de la defense, on vient de te signaler une faille dans le kernel.
Tu vas deployer un patch kernel que tu as ecrit toi-meme sur toutes les machines critique de l'armee ? Tu es sur que ton patch :
a) corrige le probleme correctement (bref tu es un expert du kernel et tu sais exactement quoi changer et comment)
b) ne casse rien (tu comprends tous les effets de bord, on revient a l'expertise necessaire, ainsi qu'a la comprehension des dependances)
c) est complet et n'oublie aucune variante (tu as passe du temps a faire l'analyse de variantes par analyse de code, fuzzing, ...)
?
Parce que faut bien comprendre, Redhat et autres, ils ne mettent pas plusieurs semaines a sortir un patch juste parce qu'ils aiment attendre, ils ont des gens specialises dans le domaine qui bossent sur ces patchs pour faire a), b) et c) et ca leur prend bcp de temps.
Croire que qqe gars dans leurs coins peuvent faire tout ce boulot c'est totalement irrealiste. Ca demande des moyens enorme afin de limiter les risques de regression et d'assurer une recherche de variantes efficace. Soit ils finiront le boulot apres Redhat, soit il y a de tres fortes chances qu'ils baclent le travail reguiierement, soit ils se retrouvent avec une equipe assez grosse pour remplacer Redhat, ce qui coute extremement cher.
[^] # Re: Critique = faut que ça marche sans bug et tout le temps
Posté par pasBill pasGates . En réponse à la dépêche Thales met à disposition un framework à composants logiciels visant les systèmes critiques. Évalué à 0.
Justement non, pourquoi est-ce que le ministere virerait Windows si c'est pour se retrouver dependant d'une autre societe qu'il ne controle pas ?
Au niveau de l'audit : pour trouver de bugs, code source/binaire compilé, même combat. Il existe des outils pour auditer les deux. Sauf que si on a les sources, on a deux fois plus d'outils, passons. Le problème est plus du côté de la manière de corriger
Oui, et le gouvernement a les sources de Windows comme tu le sais, donc c'est pas un probleme pour lui.
Dans le cas de Windows, il est presque impossible de se passer de Microsoft (enfin, de l'éditeur du logiciel dont on n'a pas les sources). Alors que pour Linux, tu peux patcher les sources et maintenir ta propre version du paquet (ça coûte pas cher en maintenance), au moins en attendant que l'éditeur patche (ou alors si tu veux garder le correctif pour toi).
Oui en theorie.
Maintenant petite question: tu es le ministere de la defense, on vient de te signaler une faille dans le kernel.
Tu vas deployer un patch kernel que tu as ecrit toi-meme sur toutes les machines critique de l'armee ? Tu es sur que ton patch :
a) corrige le probleme correctement (bref tu es un expert du kernel et tu sais exactement quoi changer et comment)
b) ne casse rien (tu comprends tous les effets de bord, on revient a l'expertise necessaire, ainsi qu'a la comprehension des dependances)
c) est complet et n'oublie aucune variante (tu as passe du temps a faire l'analyse de variantes par analyse de code, fuzzing, ...)
?
Parce que faut bien comprendre, Redhat et autres, ils ne mettent pas plusieurs semaines a sortir un patch juste parce qu'ils aiment attendre, ils ont des gens specialises dans le domaine qui bossent sur ces patchs pour faire a), b) et c) et ca leur prend bcp de temps.
Croire que qqe gars dans leurs coins peuvent faire tout ce boulot c'est totalement irrealiste. Ca demande des moyens enorme afin de limiter les risques de regression et d'assurer une recherche de variantes efficace. Soit ils finiront le boulot apres Redhat, soit il y a de tres fortes chances qu'ils baclent le travail reguiierement, soit ils se retrouvent avec une equipe assez grosse pour remplacer Redhat, ce qui coute extremement cher.