Sur tes mesures, j'ai compris dans les grandes lignes comment tu as pu ressortir ces chiffres mais est-ce qu'ils ont réellement une pertinence ?
C'est déjà plus pertinent que de dire "y'a cette faille" sans mettre de comparatif à côté :)
Sinon: non, c'est pas pertinent, parce que ces chiffres sont bruts, on ne sait pas facilement si le système affecté est bien dans un OS précis (freebsd,openbsd, debian/kLinux, debian/kHurd, windows NT4, etc) ou par un logiciel tiers.
On ne sait pas non plus si les gens qui ont écrit le code s'en torchent ou pas, de la sécurité et de la stabilité, et je pense que le langage est largement secondaire comparé à l'outillage et les procédures mises en places pour gérer les bugs: analyse statique, preuve de coq pour les plus matheux, test unitaires, fuzzing, etc.
Hors, dans ce cas, on parle de jeter l'histo des correctifs de bugs de plusieurs centaines d'applications pour réimplémenter dans un langage qui lave plus blanc que blanc... enfin, c'est l'impression que ça me donne quand les gens en parlent.
La vrai question serait plutôt : est-ce que les garantis de sécurité de Rust qui ne sont pas disponible dans C sont suffisamment pertinentes pour le remplacer ?
Ajoutes la question: est-ce que les garanties qu'offre un langage non standardisé, ne disposant que d'une seule implémentation de compilateur, sont assez pertinente pour écrire un OS qui prétend remplacer les distributions GNU/Linux, et on aura un meilleur débat :)
Je t'avoues avoir juste grep le bloc... par contre, on reviens sur ce que je dis plus haut:
4701: touche "IBM DB2 for Linux, UNIX and Windows (" donc un logiciel tiers ne faisant partie d'aucun de ces OS (d'aucun OS peut-être?)
8249: "the Pulse Secure Desktop Client" m'a tout l'air d'être proprio, donc si ça fait partie d'un OS, lequel? Pas Debian/kLinux ni voidlinux en tout cas.
28575: Trend Micro ServerProtect... bref, j'ai besoin de continuer?
Redox-os embarque des outils en C, c'est dans le journal: netsurf. La différence, c'est qu'ici, netsurf est considéré comme partie de la distro, de l'OS. Ces outils peuvent peut-être aussi tourner pour redox-os, et si c'est le cas, comment le fait que la plupart de l'OS soit écrit en rust aide en quoique ce soit?
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par freem . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 4.
C'est déjà plus pertinent que de dire "y'a cette faille" sans mettre de comparatif à côté :)
Sinon: non, c'est pas pertinent, parce que ces chiffres sont bruts, on ne sait pas facilement si le système affecté est bien dans un OS précis (freebsd,openbsd, debian/kLinux, debian/kHurd, windows NT4, etc) ou par un logiciel tiers.
On ne sait pas non plus si les gens qui ont écrit le code s'en torchent ou pas, de la sécurité et de la stabilité, et je pense que le langage est largement secondaire comparé à l'outillage et les procédures mises en places pour gérer les bugs: analyse statique, preuve de coq pour les plus matheux, test unitaires, fuzzing, etc.
Hors, dans ce cas, on parle de jeter l'histo des correctifs de bugs de plusieurs centaines d'applications pour réimplémenter dans un langage qui lave plus blanc que blanc... enfin, c'est l'impression que ça me donne quand les gens en parlent.
Ajoutes la question: est-ce que les garanties qu'offre un langage non standardisé, ne disposant que d'une seule implémentation de compilateur, sont assez pertinente pour écrire un OS qui prétend remplacer les distributions GNU/Linux, et on aura un meilleur débat :)
Je t'avoues avoir juste grep le bloc... par contre, on reviens sur ce que je dis plus haut:
Redox-os embarque des outils en C, c'est dans le journal: netsurf. La différence, c'est qu'ici, netsurf est considéré comme partie de la distro, de l'OS. Ces outils peuvent peut-être aussi tourner pour redox-os, et si c'est le cas, comment le fait que la plupart de l'OS soit écrit en rust aide en quoique ce soit?