Tu as raison sur le fait que les faux positifs sont un problème sur ces outils, et c'est pour cela qu'il faut une vraie collaboration entre les chercheurs qui travaillent sur ces outils et les utilisateurs intéressés, pour comprendre ce qui marche et ne marche pas, et faire des développements souvent délicats (nécessitant de la nouvelle recherche) pour améliorer les problèmes révélés par l'expérimentation sur le logiciel—ici le kernel.
Les gens de Facebook ont racheté une startup de recherche qui travaillait sur des outils d'analyse automatique de sûreté mémoire, c'est devenu Infer et c'est utilisé en production sur les codebases de Facebook. Si on peut le faire pour le logiciel (client) de Facebook et le kernel Windows, il n'y a pas de raison qu'on ne puisse pas y arriver pour le kernel Linux, mais encore une fois, ça demande une volonté et une culture favorable dans le projet.
Et au dernière nouvelles les drivers Windows ne fonctionnent pas mieux que les drivers Linux.
Je pense que tu mets la tête dans le sable quand tu dis ça. Je n'ai pas trouvé de données sur le taux de bugs dans les drivers Windows, mais c'est insensé de penser que déployer de l'analyse statique sérieuse sur les drivers et le code du kernel ne donne pas, à long terme, un avantage clair sur la qualité logicielle.
Le milieu Open Source ne fonctionne pas comme ça.
Décide qui ? Moi aussi je fais partie du milieu Open Source, et je dis ce qu'on ne fait pas bien et qu'on devrait faire mieux : on devrait mettre en place une culture d'interaction réelle avec le milieu universitaire. Il y a des projets qui ont l'intelligence de le faire (Mozilla par exemple, d'abord avec leur travail sur l'analyse statique de la codebase C++ de Firefox, et ensuite avec le développement de Rust). Je ne vois pas pourquoi ce serait incompatible avec "l'Open Source" de travailler avec des universitaires alors que Microsoft et Apple le font largement. Au contraire, l'idée d'ouverture à la base du développement libre est très proche et très compatible avec l'idée d'ouverture inhérente à la recherche universitaire publique; tous les projets libres n'ont pas les moyens financier de favoriser ces contacts, mais le noyau Linux est un projet qui les aurait (à travers la Linux Foundation par exemple) si l'envie existait.
Celui qui apporte une nouvelle techno doit démontrer sa supériorité pour convaincre.
Non mais la façon dont tu présentes les choses c'est que la recherche devrait arriver avec des outils tout cuits qui sont déjà passés à l'échelle pour pouvoir s'appliquer au noyau Linux ou à des projets conséquents. Devrait implémenter des compilateurs qui génèrent du meilleur code que Gcc. Et après seulement on discute. C'est idiot, ce n'est pas réaliste pour des universitaires de développer un produit fini (ce n'est pas leur rôle et leur métier) sans savoir s'il y a une volonté pour l'utiliser derrière. Cette mentalité fait partie de la culture aujourd'hui qui est défavorable à ces collaborations.
En gros, c'est à la communauté de la recherche de prouver que leur approche est meilleur, si vous considérez que les dev sont bêtes parce qu'ils ne vous écoutent pas, c'est mal barré.
Moi je dis qu'il doit y avoir un effort, du travail et une volonté des deux côtés—s'il n'y a pas une vraie envie de travailler ensemble, "c'est mal barré" comme tu dis. Ça fait 20 ans que c'est mal barré et ça n'a pas l'air de s'améliorer (parmi les développeurs LLVM actifs il y en a un, Nuno Lopes, qui est prêt à pousser les efforts de recherche sur LLVM, grosse victoire !). Je peux dire que "c'est bête" avec confiance, en effet. C'est bête de ne pas vouloir entendre qu'il faut de vrais efforts des deux côtés.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 6.
Tu as raison sur le fait que les faux positifs sont un problème sur ces outils, et c'est pour cela qu'il faut une vraie collaboration entre les chercheurs qui travaillent sur ces outils et les utilisateurs intéressés, pour comprendre ce qui marche et ne marche pas, et faire des développements souvent délicats (nécessitant de la nouvelle recherche) pour améliorer les problèmes révélés par l'expérimentation sur le logiciel—ici le kernel.
Les gens de Facebook ont racheté une startup de recherche qui travaillait sur des outils d'analyse automatique de sûreté mémoire, c'est devenu Infer et c'est utilisé en production sur les codebases de Facebook. Si on peut le faire pour le logiciel (client) de Facebook et le kernel Windows, il n'y a pas de raison qu'on ne puisse pas y arriver pour le kernel Linux, mais encore une fois, ça demande une volonté et une culture favorable dans le projet.
Je pense que tu mets la tête dans le sable quand tu dis ça. Je n'ai pas trouvé de données sur le taux de bugs dans les drivers Windows, mais c'est insensé de penser que déployer de l'analyse statique sérieuse sur les drivers et le code du kernel ne donne pas, à long terme, un avantage clair sur la qualité logicielle.
Décide qui ? Moi aussi je fais partie du milieu Open Source, et je dis ce qu'on ne fait pas bien et qu'on devrait faire mieux : on devrait mettre en place une culture d'interaction réelle avec le milieu universitaire. Il y a des projets qui ont l'intelligence de le faire (Mozilla par exemple, d'abord avec leur travail sur l'analyse statique de la codebase C++ de Firefox, et ensuite avec le développement de Rust). Je ne vois pas pourquoi ce serait incompatible avec "l'Open Source" de travailler avec des universitaires alors que Microsoft et Apple le font largement. Au contraire, l'idée d'ouverture à la base du développement libre est très proche et très compatible avec l'idée d'ouverture inhérente à la recherche universitaire publique; tous les projets libres n'ont pas les moyens financier de favoriser ces contacts, mais le noyau Linux est un projet qui les aurait (à travers la Linux Foundation par exemple) si l'envie existait.
Non mais la façon dont tu présentes les choses c'est que la recherche devrait arriver avec des outils tout cuits qui sont déjà passés à l'échelle pour pouvoir s'appliquer au noyau Linux ou à des projets conséquents. Devrait implémenter des compilateurs qui génèrent du meilleur code que Gcc. Et après seulement on discute. C'est idiot, ce n'est pas réaliste pour des universitaires de développer un produit fini (ce n'est pas leur rôle et leur métier) sans savoir s'il y a une volonté pour l'utiliser derrière. Cette mentalité fait partie de la culture aujourd'hui qui est défavorable à ces collaborations.
Moi je dis qu'il doit y avoir un effort, du travail et une volonté des deux côtés—s'il n'y a pas une vraie envie de travailler ensemble, "c'est mal barré" comme tu dis. Ça fait 20 ans que c'est mal barré et ça n'a pas l'air de s'améliorer (parmi les développeurs LLVM actifs il y en a un, Nuno Lopes, qui est prêt à pousser les efforts de recherche sur LLVM, grosse victoire !). Je peux dire que "c'est bête" avec confiance, en effet. C'est bête de ne pas vouloir entendre qu'il faut de vrais efforts des deux côtés.