Non mais attendre qu'une société (créée à la base par des chercheurs mais développée comme un effort industriel) donne des rapports de bugs tout cuits à analyser, faire quelques changements et puis râler contre les faux positifs, ce n'est pas ce que j'appelle un précédent. C'est de l'assistanat, pas une collaboration.
Pour information, les gens qui ont travaillé sur les outils d'analyse statique de drivers sur Windows reportent des taux de fausses alarmes très bas. Au moment où l'outil a été vraiment déployé (donc après une longue période de tests progressifs et de collaboration entre les chercheurs et l'équipe produit), 96% des alarmes étaient jugées utiles. Les gens de Facebook disent aussi que les fausses alarmes ne sont pas un problème pour Infer.
J'ai dis qu'il fallait démontrer la supériorité d'une solution avant que celle-ci soit mis en œuvre.
Ce dont je parle ici (mais c'est loin d'être la seule sorte de recherche qui pourraitêtre utile au noyau) c'est d'éliminer, par des outils d'analyse, des classes entières de bugs possibles du code du noyau (use-after-free, accès à de la mémoire non initialisée, usage incorrect des verrous...). Tu écris comme si l'utilité de ce résultat final restait à démontrer, ce qui me semble complètement fou—évidemment c'est utile, et évidemment un noyau qui a su mettre ces outils en place va se retrouver loin devant un noyau qui ne l'a pas fait sur le long terme, en terme de robustesse et de qualité.
Long terme: je pense que si les gens s'y mettaient sérieusement aujourd'hui il faudrait de l'ordre de 10-15 ans pour ça porte ses fruits. Le projet SLAM a officiellement commencé à Microsoft en 2001, mais les chercheurs bossaient sans doute déjà sur ça avant. Bill Gates en a parlé dans une keynote en Avril 2002, donc à ce moment il y avait déjà un soutien de l'entreprise à un très haut niveau.
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.
C'est vrai pour n'importe quel développement. Et c'est exactement pour cette raisons que la plus part des outils libres sont directement utile à leurs auteurs, il est très rare d'avoir de bon outils libre, uniquement utile à d'autres.
Dans le cas du noyau, cela serait bosser dessus, dans le but de faire un outil utile pour vous, comme exemple de passage à l'échelle.
"utile pour vous" ne veut rien dire. Encore une fois, le principe de la recherche n'est pas qu'on développe des programmes C pour dominer le monde, et qu'on va se faire des outils d'analyse statique pour nos propres besoin. C'est de comprendre les problèmes difficiles à résoudre qui affectent tout le monde, et d'essayer de les étudier dans un cadre simplifié, qui permet de se concentrer sur les problèmes de fond.
Il y a une grande distance et des années d'effort entre "un outil utile pour un programme C qui expose les principaux problèmes scientifiques" (ce que les chercheurs font dans le cadre de le travail) et "un outil qui peut marcher sur le noyau". Le boulot pour passer de l'un à l'autre comprend en partie de la recherche, mais aussi beaucoup d'implémentation et de travail chiant (par exemple s'intégrer au build system du kernel). Personne dans la communauté de recherche ne peut s'investir dans ce travail sans visibilité si ça va être utile à terme parce qu'il y a une envie de s'en servir dans le projet—ce serait sacrifier des années de sa vie et mettre sa carrière en pause pour un travail au final presque inutile. Cet effort de passage à l'échelle a été fait pour Microsoft, pour Airbus, pour Facebook, parce que ces boîtes ont une politique volontariste et ont montré une volonté de prendre ces outils au sérieux.
Encore une fois, s'il n'y a pas de volonté de la part de la communauté Linux, c'est très dommage et ça veut dire que le noyau passe à côté d'opportunités de l'améliorer. Tu essaies d'argumenter que ce comportement idiot est, d'une façon ou d'une autre, inhérent au développement de logiciel libre, mais ce n'est pas vrai du tout. On peut développer un logiciel libre et avoir une vision à long terme, ouverte à la collaboration avec les autres. Une culture de communauté peut évoluer quand elle est mauvaise sur certains points.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Non mais attendre qu'une société (créée à la base par des chercheurs mais développée comme un effort industriel) donne des rapports de bugs tout cuits à analyser, faire quelques changements et puis râler contre les faux positifs, ce n'est pas ce que j'appelle un précédent. C'est de l'assistanat, pas une collaboration.
Pour information, les gens qui ont travaillé sur les outils d'analyse statique de drivers sur Windows reportent des taux de fausses alarmes très bas. Au moment où l'outil a été vraiment déployé (donc après une longue période de tests progressifs et de collaboration entre les chercheurs et l'équipe produit), 96% des alarmes étaient jugées utiles. Les gens de Facebook disent aussi que les fausses alarmes ne sont pas un problème pour Infer.
Ce dont je parle ici (mais c'est loin d'être la seule sorte de recherche qui pourraitêtre utile au noyau) c'est d'éliminer, par des outils d'analyse, des classes entières de bugs possibles du code du noyau (use-after-free, accès à de la mémoire non initialisée, usage incorrect des verrous...). Tu écris comme si l'utilité de ce résultat final restait à démontrer, ce qui me semble complètement fou—évidemment c'est utile, et évidemment un noyau qui a su mettre ces outils en place va se retrouver loin devant un noyau qui ne l'a pas fait sur le long terme, en terme de robustesse et de qualité.
Long terme: je pense que si les gens s'y mettaient sérieusement aujourd'hui il faudrait de l'ordre de 10-15 ans pour ça porte ses fruits. Le projet SLAM a officiellement commencé à Microsoft en 2001, mais les chercheurs bossaient sans doute déjà sur ça avant. Bill Gates en a parlé dans une keynote en Avril 2002, donc à ce moment il y avait déjà un soutien de l'entreprise à un très haut niveau.
"utile pour vous" ne veut rien dire. Encore une fois, le principe de la recherche n'est pas qu'on développe des programmes C pour dominer le monde, et qu'on va se faire des outils d'analyse statique pour nos propres besoin. C'est de comprendre les problèmes difficiles à résoudre qui affectent tout le monde, et d'essayer de les étudier dans un cadre simplifié, qui permet de se concentrer sur les problèmes de fond.
Il y a une grande distance et des années d'effort entre "un outil utile pour un programme C qui expose les principaux problèmes scientifiques" (ce que les chercheurs font dans le cadre de le travail) et "un outil qui peut marcher sur le noyau". Le boulot pour passer de l'un à l'autre comprend en partie de la recherche, mais aussi beaucoup d'implémentation et de travail chiant (par exemple s'intégrer au build system du kernel). Personne dans la communauté de recherche ne peut s'investir dans ce travail sans visibilité si ça va être utile à terme parce qu'il y a une envie de s'en servir dans le projet—ce serait sacrifier des années de sa vie et mettre sa carrière en pause pour un travail au final presque inutile. Cet effort de passage à l'échelle a été fait pour Microsoft, pour Airbus, pour Facebook, parce que ces boîtes ont une politique volontariste et ont montré une volonté de prendre ces outils au sérieux.
Encore une fois, s'il n'y a pas de volonté de la part de la communauté Linux, c'est très dommage et ça veut dire que le noyau passe à côté d'opportunités de l'améliorer. Tu essaies d'argumenter que ce comportement idiot est, d'une façon ou d'une autre, inhérent au développement de logiciel libre, mais ce n'est pas vrai du tout. On peut développer un logiciel libre et avoir une vision à long terme, ouverte à la collaboration avec les autres. Une culture de communauté peut évoluer quand elle est mauvaise sur certains points.