Le contrat à l'extérieur ne marche pas forcément, mais tout internaliser a aussi ses propres problèmes, au moins quand la taille du projet est trop petite (ou ses finances) pour avoir plus d'un seul développeur. Avec un prestataire extérieur, si tu as la chance de trouver des gens compétents (oui, ça existe), tu peux espérer avoir plusieurs personnes qui travaillent sur le projet à temps partiel, ou au moins un seul développeur qui a beaucoup d'expérience de travail en équipe.
(Bien) travailler à plusieurs et (bien) travailler tout seul c'est très différent, le premier est un peu moins efficace sur le court terme (coûts de communication, conventions à adopter, mécompréhensions etc.), mais il incite beaucoup plus à avoir de la documentation écrite, des processus de développement/bugfix/release/etc. explicités, et se prête donc plus naturellement à un passage de bâton (partiel ou total) à d'autres développeurs ensuite.
Quand on travaille tout seul (même quand on est compétent et qu'on fait attention), c'est facile de s'enfermer sans s'en rendre compte dans un projet où on a tout en tête mais peu de choses écrites pour d'autres, dans des choix d'architectures non-standards qui rendent le projet plus difficile à comprendre pour d'autres, et au final avec quelque chose qui, si on doit se faire remplacer pour une raison quelconque, est beaucoup plus difficile à prendre en main pour les suivants.
Idéalement je pense que si j'étais demandeur d'une prestation informatique, j'essaierais de trouver un compromis entre "la boîte de prestation opaque" et "le développeur tout seul en interne". Soit une petite boîte avec un petit nombre de personnes en local avec qui j'ai de bons rapports, soit essayer de gérer les responsabilités en interne pour avoir plus d'une personne sur le backend (par exemple, au lieu d'avoir un développeur et un webmaster, chercher deux personnes polyvalentes qui se partagent les tâches sur les deux fronts).
En dév., j’essaye toujours d’avoir des algo en O(1). Quitte quand on a pas le choix, à chercher un élément dans une liste et quand on le trouve, on fini de parcourir quand même la liste.
Il doit y avoir une incompréhension entre toi et nous, parce qu'arrêter de chercher une liste quand on a trouvé, ça reste en O(1). O(1) veut dire "plus petit qu'une constante", donc faire moins de calculs préserve toujours la propriété d'être O(1).
Il y a des domaines où on veut non seulement faire du O(1), mais en plus que le calcul consomme toujours les mêmes ressources (temps, mémoire, énergie) : c'est quand on veut éviter les attaques par canaux auxiliaires dans un protocole cryptographique. Mais tu parlais plutôt de systèmes temps-réel dur dans ton message.
Qui a été crée hier ou aujourd'hui visiblement, après mon journal. Merci pour le lien !
Cependant, la page n'est pas encore listée sur la page du projet ou le blog du projet, qui mentionnent uniquement Patreon et Tipeee, je n'ai reçu aucune communication à ce sujet de la part des auteurs (ça va peut-être venir plus tard), donc pour l'instant il est difficile de savoir ce qui est encouragé de leur part.
(Par exemple, certains créateurs attachent de l'importance au fait de recevoir une somme pas trop grosse mais pas trop petite non plus sur Patreon chaque mois, parce que les utilisateurs sont moins motivés pour donner s'ils ont l'impression que le projet fait un flop complet. Du coup j'aime mieux attendre un message expliquant l'intention ou les préférences des créateurs avant de changer de mode de financement.)
Je me rends compte que, puisque j'ai mentionné (comme exemples) les projets libres que je soutenais sur Patreon, il serait naturel de mentionner aussi le projet que je soutiens sur Libeparay depuis longtemps, à savoir Matrix.org (sur liberapay), les développeurs de la plateforme de communication en ligne Matrix—qui est en particulier le meilleur concurrent libre de Slack, avec un pont IRC étonnamment agréable à utiliser.
Je soutiens aussi Liberapay, la plateforme elle-même, qui essaie de se financer par dons comme tous les autres projets.
(Si vous avez d'autres tuyaux de projets libres à soutenir sur Liberapay, n'hésitez pas à poster un commentaire.)
Donc il faudrait quelqu'un se dévoue pour mobiliser des employés [techniques] pour aider les chercheurs.
Non, pas spécialement besoin d'aide là-dessus, encore une fois il suffit de les gens demander des contacts, etc. Il y a besoin d'aide administrative (pour les transferts d'argent il faut de la paperasse), la fondation a du personnel administratif pour ces choses-là.
En soit oui, rien d'impossible, mais le manque de centralisation de cette communauté rend cela difficile si aucun partenaire industriel ne force la main ou prend cela en charge en grande partie.
La communauté universitaire est aussi très décentralisée et pourtant on arrive à monter des projets.
C'est plus difficile qu'au sein de Microsoft où un manager peut dire "maintenant vous faites ça, point barre", mais ce n'est pas si difficile en soit. Je pense que l'approche par financement de projet que je propose marcherait bien.
Mouais, cela demande quand même d'évaluer la recherche, sa pertinence, les ressources nécessaires, de comprendre aussi les rouages suivant le pays en question
Pour évaluer les propositions, il suffit de demander leur avis à des gens qui connaissent le sujet. Tu envoies un mail "salut, pouvez-vous lire cette proposition de 6 pages et donner votre avis sur la faisabilité du truc, ou sinon me conseiller deux personnes qui s'y connaissent mieux que vous ?" à trois personnes, et les gens se montrent plein de bonne volonté en pratique. (Encore une fois, le milieu universitaire, décentralisé, fonctionne très bien comme cela.)
Pour une fondation avec moins de 50 personnes, envoyer l'un de ses membres les plus influents pendant 1 an, ce n'est pas si négligeable que cela.
Non mais ce n'est pas comme ça que ça c'est passé, c'est GKH qui a décidé de passer un an à Paris et qui a prévenu les gens qui l'emploient qu'il allait faire ça, et il a dit ok. Et il est payé pareil, où qu'il habite.
La Linux Fondation peut juste inciter quelqu'un de le faire, mais ne peut pas forcer cette personne.
Je rend des services tous les mois à des gens d'une autre université, d'un autre pays que moi, sans transfert d'argent ou qu'on fasse partie de la même institution. Personne n'est forcé, on me demande gentiment et j'accepte quand ça m'intéresse. Ça peut se passer comme cela là-aussi.
Ce que je dis, c’est qu’il faut aussi des développeurs noyau qui aient du temps pour faire ça. Or, la fondation n’a pas les ressources en personnel pour ça.
Mais non, il suffit que la fondation dise : "s'il y a des chercheurs et des développeurs qui veulent travailler ensemble sur un projet bien défini, nous on apporte des sous pour financer ça en partie". Après les gens se trouvent de la façon qu'ils veulent (ils s'envoient des emails pour se proposer le projet, utilise leurs contacts pour savoir qui serait intéressé par tel ou tel truc, etc.).
Il faut donc que [les développeurs Linux] montrent un intérêt préalable pour que ce soit lancé.
Bah ça c'est facile à tester, il suffit de poser la questions aux gens et d'envoyer des mails sur les mailing-list : "On envisage de faire ça, qu'en pensez-vous ? Contactez-nous si vous seriez prêt à aider un peu dans les domaines qui vous concernent.".
La communication aussi c'est facile. C'est à moi de faire ce boulot ou quoi ? "Nous on est trop innovants de la mort et donc on monte un programme de financement des sujets de recherche en qualité logicielle (test et analyse de programme) autour de Linux. Les développeurs X et Y, et le chef du laboratoire de recherche Z du MIT, confirment que c'est une super idée."
L'important c'est juste de dire : "on se rend compte que c'est un sujet intéressant/important et on est prêt à faire preuve de bonne volonté pour faciliter les choses". (Et si possible : on donne un peu des sous pour ça.) Si aujourd'hui je suis un chercheur et je me demande si je peux collaborer avec des gens, c'est beaucoup plus facile d'aller entrer en contact avec des gens qui ont fait signe qu'ils étaient intéressé qu'à des gens qui s'en foutent. Et les gens de Linux, aujourd'hui, ils s'en foutent.
Tu veux dire que la fondation, qui n’a aucune équipe de R&D est mieux placé que ceux qui en ont une ?
Il n'y a pas besoin d'équipe de R&D pour dire : "on veut plus de collaboration et si des gens nous contactent pour en faire, on va les aiguiller vers des interlocuteurs au sein du projet et on peut les financer un peu".
La communauté Linux est en retard en terme d'intégration des techniques de recherche sur la qualité logicielle (test et analyse de programme).
Elle a un problème de culture et de dynamique interne qui rend les collaborations difficiles.
Une façon de faciliter les échanges avec le milieu universitaire (très à court de sous en ce moment) est de donner de l'argent et, ça tombe bien, il se trouve que le projet Linux en a (plein d'entreprises qui soutiennent le projet en ont), et justement il existe une structure qui centralise de l'argent pour des projets, la Linux Foundation, qui pourrait facilement se lancer là-dedans.
Je ne dis pas que c'est "juste la faute du noyau"; les universitaires aussi ont des efforts à faire pour avoir plus de collaboration, et je fais aussi ce que je peux pour le dire aux gens quand je discute au sein de cette communauté. Mais ici je parle des problèmes qui existent dans la communauté du noyau et de façon d'avancer vers des solutions.
Pour préciser, les financements se passeraient par exemple comme ça : pour avoir des sous, il faut qu'une équipe envoie une proposition de projet à la Linux Foundation, qui décrit un projet de recherche appliquée au noyau. L'équipe qui a monté comprend des académiques et des développeurs du noyau, et surtout des gens qui vont surtout regarder/superviser et des gens qui vont vraiment faire le boulot (en général un ou plusieurs étudiants). La fondation paie des gens pour relire les propositions et dire si ça leur a l'air plausible (si c'est une idée intéressante, utile pour le noyau, réaliste scientifiquement, qui peut donner lieu à des suites intéressantes), et si oui la fondation donne un peu d'argent—$5000 dollars pour un en-plus qui motive mais qui ne suffit pas à financer, ou alors six mois de salaire pour un étudiant ou alors, pour une thèse complète, une année ou deux (mettons $50000).
Une fois que c'est en place, la Linux Foundation dit aux devs Linux "si vous connaissez des chercheurs dont le travail vous intéresse, parlez-leur de cet appel à projet", et contacte les chercheurs qui ont déjà bossé sur Linux pour leur en parler. Ensuite c'est aux chercheurs qui sont intéressés par ces financement d'entrer en contact avec des gens, de monter un projet, et de candidater. S'il peut y avoir des pointeurs pour des contacts (sur le site web, "si vous voulez savoir qui est intéressé par le sujet X, vous pouvez demander à Y qui est un bon d'entrée dans la communauté noyau"), c'est mieux.
Tout cela est au final assez simple, ça demande juste un peu de travail (pour coordonner le tout il faut des gens non-techniques, qui peuvent être payées pour ce boulot comme la Linux Fondation embauche ou sous-traite déjà du travail) et surtout de la bonne volonté.
Je trouve que tu as une vision totalement étriquée de la situation.
Moi j'ai surtout l'impression d'être en face d'un barrage de mauvaise foi. Je parle quand même de chose que je connais relativement bien (je participe comme contributeur à des projets libres, donc bon "il y a des exigences de qualité" et "on n'est pas des petits esclaves", c'est évident pour moi), et on m'oppose des arguments vraiment loin de la réalité : "non mais la Linux Foundation c'est juste 6 personnes qui n'ont pas le temps".
Personne ne serait forcé à faire une chose ou une autre, mais le fait de mettre une structure en place pour encourager ces collaborations (et de l'argent pour les faciliter) peut avoir beaucoup d'impact.
Et tu minimisais l'importance de Greg à l'Inria, pourtant il me semble que c'est un signal fort que la fondation envoie pendant un an (probablement à ses frais) l'un des mainteneurs les plus importants à bosser dans le milieu de la recherche.
Je suis passé dans les bureaux de cette équipe de recherche au moment où Greg y était. C'est sympa, il a fait un séminaire pour parler aux étudiants pour parler du développement Linux, et je suis sûr qu'il a bien discuté avec Julia Lawall de ce qui lui l'intéresserait dans son travail à elle, et donné des idées de choses à faire. C'était aussi une bonne occasion de faire de la communication des deux côté (Linux : "vous voyez, on est en contact avec la recherche"; INRIA : "vous voyez, on est bien vus par le monde des gens qui font des vrais trucs"). Mais après GKH a surtout passé une année sympa à Paris à bosser sur ses trucs qu'il fait d'habitude dans un bureau différent, et eu plus d'opportunités pour discuter. Ça a un impact, mais comme je l'ai dit, c'est une goutte d'eau.
Note par ailleurs que sans chercher très longtemps je suis tombé sur des recherches autour du noyau Linux mais bien sûr fait par une entreprise ou université elle même. D’ailleurs l'Université de Louvain-la-Neuve planche sur le mulltipath TCP avec Linux comme implémentation de référence. Tu as aussi des universités (essentiellement américaines et chinoises) qui sont membres de la Linux Fondation (donc à même de proposer des projets de recherche), etc.
Encore une fois, c'est de la recherche en systèmes; il y a des chercheurs qui contribuent à Linux dans ce domaine et c'est très bien. Moi je parle de recherche en qualité logicielle (test et analyse de code), et là c'est beaucoup moins clair—à part Coccinelle.
Je ne crois pas que la Linux Fondation, de part la nature de la communauté du noyau, soit à même de faire ce que Mozilla ou Microsoft font de leur côté.
Ben si, pourquoi pas ? Il suffit de bonne volonté (ça manque) et d'un peu d'argent (il y en a). Pour Mozilla, ce n'est pas très compliqué de dire à l'un de ses employés "si tu veux, on te paie pour aller pendant une semaine à la conférence machin qui t'intéresse, et quand tu discutes avec des gens là-bas, dis-leur bien qu'on est intéressé par le fait de financer des collaborations". Ce ne serait pas très compliqué pour la communauté Linux de faire la même chose.
Et bien sûr, le code accepté ne l'est que si ça répond aux exigences de qualité d'une part et si ça apporte quelque chose considéré comme utile d'autres part. Ce n'est pas parce que c'est taggué "recherche universitaire" que c'est accepté.
De toute façon, ce dont je parle ce n'est pas de faire rentrer des bases de code dans le noyau, c'est plutôt d'évaluer des outils de test ou d'analyse statique sur le kernel, de les adapter pour passer à l'échelle, et si possible de faire des changements dans le code qui facilitent leur application.
Je ne comprends pas ce que ton commentaire essaie d'apporter à cette conversation.
Ce que j'ai proposé c'est que les gens de la Linux Foundation essaient d'encourager les collaborations entre les développeurs Linux et le milieu académique en (1) faisant de la communication à ce sujet et en (2) finançant des travaux de recherche appliquée au noyau. Ça ne suffit pas à changer la chose du tout au tout (il faut un changement de culture d'ensemble dans la communauté du noyau, je pense, mais ça c'est progressif sur le long terme), mais ça ne peut que renforcer des dynamiques. Ce sont des actions bien délimitées, qui sont largement à portée de ses missions, de ses financements et de son personnel (parce que non, ce n'est pas Linus dans son garage qui a fait le site web flambant de la fondation, et qui maintient le gâteau administratif des versements de sous, etc; il y a du personnel de support).
Clairement une partie importante des entreprises qui soutiennent la fondation le font pour avoir l'impression de contribuer à l'écosystème Linux. Si la fondation leur propose une stratégie nouvelle (parmi d'autres) pour améliorer la qualité du noyau, elles seront certainement contentes de financer ça, mais c'est un endroit beaucoup plus neutre et beaucoup plus centralisé pour lancer ce genre d'effort qu'une entreprise en particulier. Par ailleurs, dans les entreprises de la Fondation, il n'y en a pas beaucoup qui ont des équipes de R&D de qualité sur les sujets dont je discutais (les outils d'analyse de programme); Microsoft en a, Facebook en a, IBM en a, mais ce n'est pas courant—il n'y a pas d'entreprise qui soit clairement mieux placée que la fondation pour lancer quelque chose là-dessus.
N'importe quoi. La Linux Foundation est un regroupement d'entreprises qui mettent un paquet d'argent en commun pour faire des choses autour du libre. Tu as choisi de montrer les 6 personnes qu'elle embauche à plein temps pour programmer, mais il y a un "Technical advisory board" de 10 personnes, une "Leadership team" de 24 personnes, des centaines d'entreprises qui sont membres (ils disent "plus de 800"), et en 2015 (dernière année pour les infos publiques sur les taxes) ils ont brassé 40 millions de dollar (avec presque 4 millions en bénéfices nets cette année-là).
Autrement dit : ce serait tout à fait la bonne entité pour diriger un effort d'encouragement à la collaboration avec les milieux universitaires autour du noyau Linux.
Il n'y a pas besoin de "faire de la recherche" pour être légitime dans ce domaine—la R&D, l'idée n'est pas en général de produire de la recherche nouvelle (même si parfois ça arrive), mais quand même d'avoir le niveau scientifique pour pouvoir interagir avec la recherche du domaine (les travaux écrits et/ou le personnel de recherche). Mais oui, embaucher des docteurs peut aider pour ça — et c'est quelque chose que les entreprises françaises ne font peut-être pas assez par rapport aux américaines par exemple.
Il n'y a pas de contact avec la recherche, ni le même vocabulaire.
Si tu es dans un département R&D mais que tu ne peux pas entrer en contact avec la recherche, c'est que soit tu es mal formé (initialement, peut-être, mais aussi et surtout la formation continue qu'une boîte de R&D doit assurer en encourageant ses employés à suivre l'état de l'art, par exemple en allant aux conférences importantes du domaines), soit on se moque de toi et le titre "R&D" est juste là pour faire plus prestigieux et prendre des crédits impôts-recherche, mais est vidé en pratique de sa substance.
C'est très courant, surtout dans les boîtes qui n'ont en fait pas de problème technique difficile à résoudre et n'ont donc pas vraiment besoin d'une branche R&D qui fait du vrai boulot. Ou alors des boîtes qui ne se rendent pas compte de l'intérêt qu'elles auraient à faire sérieusement de la R&D — parce que ça veut dire accepter des projets exploratoires, une incertitude sur le moyen terme, des besoins importants de réelle formation continue, etc., et que tout ça n'est pas facile à manager.
(Il y a aussi des boîtes avec de la vraie R&D. Quand on discute avec les gens de la R&D d'EDF par exemple, on sent qu'ils sont très câlés sur leurs sujets.)
Oui, vu les auteurs en commun c'est bien le même projet.
Dans le genre, un autre DSL issu de la recherche et qui pourrait intéresser les gens de Gimp (par exemple) est Halide.
Un tel DSL serait énorme pour un projet comme The Gimp ou CIMG, mais je ne suis pas sûr qu'ils aient la compétence pour le mettre en œuvre.
C'est une bonne idée, tu devrais envoyer un mail aux gens de Gimp/CIMG pour leur demander s'ils ont étudié ces DSLs et envisagé de les utiliser. (Je crois que les gens de CIMG n'ont pas du tout réfléchi à comment migrer des calculs sur des GPUs, pour l'instant, mais ces langages pourraient déjà accélérer les implémentations CPU.)
Juste petite précision, la Fondation Linux et la recherche travaillent ensemble.
Tu as des informations plus précises là-dessus ? Combien de stages, combien de thèses ont été financées par la Fondation Linux, sur quels sujets ? À quelles conférences est-ce que des membres de la fondation sont venus parler de leurs problématiques et entrer en contact avec des gens ? Y a-t-il des choses qui ont été écrites publiquement (blogs, mailing-list) sur un désir de la Linux Foundation d'interagir avec les milieux de recherche, et sur la stratégie qu'ils ont décidé de mettre en place pour faciliter cela ? Y a-t-il sur le site web de la fondation une ou des pages dédiées à la recherche, qui indique par exemple comment les contacter pour monter un projet de collaboration ?
(Je demande semi-naïvement : je ne suis pas de prêt ce que fait la fondation, donc je pourrais être positivement surpris, mais à ma connaissance la réponse à toutes ces questions est "zéro", "aucune" et/ou "non".)
C'est très bien que GKH soit venu un an à Paris et ait discuté de Coccinelle (et il y a même de temps en temps quelques développeurs Linux qui s'en servent). Tu dis que l'usage n'est "pas anecdotique", mais pour moi c'est une goutte d'eau. Et ça a demandé de la part des gens qui travaillent sur Coccinelle des efforts considérables. Une telle collaboration ne devrait pas être exceptionnelle mais un exemple parmi d'autres.
Qui pourrait faire ça ? C'est ça qui me pose le plus de problème. Qui est assez doué pour comprendre le "langage de la recherche" et en même temps en faire un produit industriel.
Déjà, il y a des gens dont c'est le métier, c'est appelé la R&D, Recherche et Développement. Les ingénieurs R&D sont (en théorie) là pour faire le transfert entre la recherche et l'industrie.
Ensuite, il me semble qu'une autre réponse (en particulier dans le cadre du logiciel libre) c'est : "une équipe avec des compétences mixtes". Tu mets des chercheurs et des développeurs noyau ensemble, et tu les fais discuter, sur le long terme.
Un des rôles de la recherche est de transmettre le savoir, certes, mais on ne peut pas forcer les gens à écouter si ça ne les intéresse pas, s'ils ne sont pas prêt à faire un effort pour comprendre et participer. Si la volonté est là, c'est très facile d'obtenir d'un chercheur qu'il parle d'une façon compréhensible à des ingénieurs, il suffit d'envoyer un mail pour lui poser des questions, et de signaler quand on ne comprend pas quelque chose. (Ou alors d'aller à ses cours et ses exposés, et de poser des questions ensuite.)
Mais il faut que les gens se lançant dans une telle discussion soient conscients des rôles de chacun pour qu'elle soit productive. Si tu commences à discuter en espérant, au bout de quelques emails, pouvoir appliquer directement le résultat développé dans un cadre simplifié, purifié à ton gros projet de la vraie vie, tu vas sans doute être assez déçu. Il faut être prêt à entrer dans une boucle d'itération sur le moyen/long terme, avec des choses qui marchent partiellement au milieu.
Il y a des gens qui le font, par exemple qui testent Compcert sur tous les paquets OpenBSD et qui font des rapports d'erreur quand quelque chose coince (exemple). Ce travail peut mettre quelques années à aboutir, et le résultat (qu'on peut compiler OpenBSD avec un compilateur vérifié) n'est qu'une brique de base qui pourrait servir à d'autres choses ensuite.
Encore une fois, une bonne façon de faciliter encore ces échanges et de faire avancer les choses plus vite, c'est aussi de donner des sous (les chercheurs sont contraints en temps et en financement). Si la Linux Foundation avait sérieusement envie de faire avancer le sujet, elle pourrait facilement financer des thèses, dans des laboratoires de recherche, appliquées sur le noyau Linux. Les gens de Mozilla font ça, ils viennent à nos conférences (de recherche) et ils disent, clairement, "si vous avez des gens qui veulent travailler sur des sujets qui nous concernent, on peut les financer, les accueillir en stage chez nous pour leur faire découvrir nos problématiques, contactez nous". Et ça a un effet direct sur l'évolution de Rust par exemple.
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.
L'idée est sympa. J'imagine que les usagers de ce genre de DSL sont docteur en mathématique pour le calcul linéaire. Je ne vois pas qui d'autres pourraient s'en servir vu le formalisme mathématique retenu.
Encore une fois, ce n'est pas le métier des chercheurs que de développer une interface facile d'accès à leur travail. Il y a un petit prototype pour démontrer l'idée, qui fait mieux que l'existant question performance. Si quelqu'un veut prendre ça et en faire une bibliothèque grand public, je suis sûr que les auteurs de ce travail seraient volontaires pour donner des conseils et participer et aider, mais ce serait déraisonnable de leur part de s'y attaquer seuls—parce que ce n'est pas leur métier et que les gens qui les emploient leur demanderaient des compte sur l'usage de leur temps de travail.
C'est un peu facile de ta part : tu commences par dire qu'il n'y a pas de recherche sur des langages efficaces (que le milieu de recherche n'a pas les priorités qui t'intéressent), et maintenant je te montres qu'il y en a et ta réponse c'est que c'est trop de la recherche ! Tu voudrais un truc tout cuit, mieux que l'existant, déjà prêt pour être utilisé par tout le monde, et puis un café aussi ?
Il y a une incompréhension de fond sur la façon dont les universitaires travaillent, quel est leur but. Je trouve assez déplacé de me dire ensuite que (quand je parle en tant que chercheur) je suis ignorant et méprisant, alors que moi justement je fait l'effort de bien connaître et de comprendre ces deux milieux dont je suis membre, et de dire ensuite ce qui me semble poser problème.
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.
En sécurité, la plus part des bugs sont trouvé avec des fuzzers. Concernant l'analyse statique, il existe https://en.wikipedia.org/wiki/Sparse qui permet de vérifier des propriétés statiques (gestion de mutex, d'espace mémoire, etc…).
Ces outils sont développés par les développeurs noyaux, qui n'ont pas en général de bagage en recherche dans le domaine concerné (test aléatoire, analyse statique). Au bout d'un moment ils pensent à un outil et ils en développent un from scratch pour leurs besoins. C'est une approche classique d'ingénieur et louable, mais les outils en question restent en général loin derrière l'état de l'art, les problèmes sur lesquels travaillent les chercheurs qui bossent dans le domaine. La recherche en analyse statique c'est Astrée par exemple, un outil qui prouve l'absence de comportement indéfini (segfault compris) dans l'ensemble du code de contrôle de certains Airbus. On est très, très loin devant Sparse en terme de puissance.
Ce que j'aimerais voir, si les développeurs Linux étaient plus ouverts au fait d'intégrer des résultats de recherche, c'est des outils qui sont développés pour le kernel par une collaboration d'universitaires et de développeurs noyaux actifs (il y a des chercheurs qui sont aussi développeurs noyaux). C'est le cas par exemple des travaux sur la formalisation du modèle mémoire de Linux et en particulier de RCU, qui est fait par un mélange d'universitaires et de développeurs—et il y a quelques développeurs qui se laissent parfois convaincre d'écrire des patches Coccinelle. Mais c'est très rare, ce n'est pas dans la culture de la communauté qui développe le noyau; c'est dommage.
Bien sûr, les prototypes issus de la recherche ne sont pas utilisables en l'état sur un logiciel aussi gros et compliqué que le noyau. C'est pour ça qu'il faut une collaboration entre les deux communautés, pour que les universitaires aient des retours sur les besoins du noyau, soient forcés de rendre leurs outils plus généraux et plus faciles à utiliser sur de vrais projets, et aient aussi l'assurance qu'il y a des gens prêt à les adopter derrière, qu'un effort de passage à l'échelle ne sera pas fourni à perte. Encore une fois, pour ça il faut une culture volontaire du côté des développeurs, et elle manque pour le noyau Linux (alors qu'elle est présente pour Windows, en partie parce que Microsoft n'a pas laissé le choix à ses développeurs). On peut dire que beaucoup de développeurs ont déjà plein de boulot et n'ont pas le temps de jouer à tester des prototypes d'outils pour le noyau, mais encore une fois, c'est une question de priorité (des personnes, et des organisations : la Linux Foundation pourrait financer ce genre de travaux si elle en avait envie).
Je n'ai pas vu de DSL.
Un exemple concret, dans la communauté que je connais mieux (et qui n'est pas celle qui travaille le plus sur la génération de code efficace, c'est plutôt un à-côté pour nous), serait Generating performance portable code using rewrite rules: from high-level functional expressions to high-performance OpenCL code par Michel Steuwer, Christian Fensch, Sam Lindley, et Christophe Dubach, 2015. Ils définissent un petit langage très simple pour composer des expressions qui décrivent des calculs sur GPU, et une façon de le compiler qui donne des programmes qui vont plus vite que des versions écrites à la main par des experts. Par exemple le code pour décrire une multiplication matrice/vecteur (GEMV en BLAS) dans ce langage est
et le résultat de la compilation va un peu plus vite que les bibliothèques fournies par les vendeurs de GPU (CUBLAS sur un GPU Nvidia, clBLAS sur un GPU AMD, et la MKL pour un CPU Intel), et est entre 2 et 5 fois plus rapide qu'une implémentation OpenCL portable selon la machine sur laquelle on la fait tourner.
Il y a plein de situations de recherche dans lequel la présence, à côté du personnel de recherche, de responsables de "valorisation" ou "partenariat" peut être utile. Pour ce que j'en ai personnellement aperçu, elles peuvent souvent se repérer au fait que les chercheurs ou chercheuses sont déjà en contact avec une enterprise spécifique intéressée par leurs travaux, et pourrait avoir intérêt à participer à leurs financements. Du côté de l'entreprise comme du côté de l'équipe de recherche, la complexité administrative et juridique de ce transfert d'argent peut être très importante (l'entreprise a des règles internes sur comment payer, elle veut bien acheter des licences mais pas du support, ou alors l'inverse, financer un produit mais pas un développement futur, ou alors l'inverse, etc.; l'équipe de recherche évolue dans un environnement réglementaire compliqué aussi, il faut reverser une partie à l'institut, donner de l'argent au laboratoire plutôt qu'aux personnes, etc.), et avoir des professionnels pour s'en occuper peut permettre aux choses de se faire dans l'intérêt de tous.
C'est une vision des services de valorisation qui leur fait porter leur nom : des services, présents pour soutenir une activité quand on les sollicite.
Le problème c'est que souvent les gens qui sont plus hauts dans l'organigramme administratif de la recherche publique ont envie de diriger, plutôt que de servir. Ça commence tout en haut, avec un gouvernement qui croit hélas bon de commander des recherches sur des domaines particuliers, au risque d'imposer des mécanismes d'encouragement lourds, coûteux en complexité et en temps, et contre-productifs. Mais c'est vrai aux niveaux en-dessous, et l'image montrée dans ce journal en est un exemple criant.
Ce document n'est pas là pour informer le personnel de recherche de ce qu'il peut faire pour trouver des financements privés pour sa recherche. Le document essaie de dire ce que le personnel doit faire. C'est à rapprocher du document récent (formaté dans le même style "on vous informe mais en fait on ordonne") de l'université de Strasbourg, interdisant au personnel de recherche de parler à des journalistes sans l'accord du service de communication de l'université (article sur EducPros).
Je pense que c'est très dangereux de s'habituer à un tel niveau de directivité, de l'accepter. Laisser des gens qui ne pratiquent pas la recherche décider de comment elle doit être conduite, c'est ouvrir la porte à toutes les dérives. On a des hommes et des femmes politique qui n'hésitent pas, par exemple, à dé-financer des sujets de recherche pour gagner des points auprès de leur électorat. Aujourd'hui on demande de ne pas publier de résultats sans envisager les possibilités de monétisation avant, demain il faudra peut-être demander aussi l'accord des gens chargés d'évaluer si un des mécènes (privés ou public) de l'université ou institut de recherche pourrait ne pas apprécier les résultats. Ou bien du service qui vérifie qu'on ne co-publie pas avec un laboratoire d'une institution qui a refusé le dernier projet de fusion.
La recherche publique est efficace quand elle est libre et diffuse largement. Il faut la soutenir (et il est légitime que la société fasse des choix sur le niveau, la nature et la forme de ce soutient), faire respecter et encourager des méthodes de travail qui sont dans l'intérêt collectif, mais il est dangereux d'essayer de la diriger.
En soit, tiré de son contexte, aucun, surtout si ça permet de financer plus de recherche et là ça peut carrément être positif. Mais le soucis c'est que c'est rarement sans contrepartie. Par exemple, si ça demande de limiter la diffusion des résultats (pour pouvoir les monnayer), là il y a un problème, car on s'écarte de la mission première de la recherche publique, la création et diffusion des savoirs, dans la recherche du profit direct (qui n'est pas une mission de la recherche).
Le document dont il est question dans ce billet est le témoin du fait que les gens qui l'ont écrit pensent que c'est normal de ne pas parler de sa recherche s'il y a la moindre chance que cela rende plus facile par la suite de gagner de l'argent avec. C'est de ça que je parle.
Quand on fait de la recherche publique et qu'on publie, on n'écrit pas pour "des personnes" en particulier, on écrit pour tout le monde.
D'ailleurs l'idée d'une "propriété intellectuelle" sur cette recherche me paraît dérangeante, même si malheureusement le droit français lui donne sens—je ne sais pas ce qu'il en est d'autres pays francophones. Aux États-Unis, les connaissances produites par les employés fédéraux sont automatiquement libres de droit, cela me semble bien plus naturel. Bien sûr, beaucoup des schémas actuels de monétisation de la recherche sont encouragés par la radinerie du gouvernement français : la question ne se poserait pas, ou alors seulement dans des domaines spécifiques à recherche expérimentale lourde, si les laboratoires étaient financés correctement.
Un commentaire très raisonnable, même si je suis un peu déçu que tu ne mentionnes pas l'atteinte sous-jacente à la liberté universitaire : c'est quand même très très lourd de dire à des chercheurs à qui et comment ils ont le droit de parler de leur recherche.
Enfin, [forcer l'ouverture] mettrait fin à tous les partenariats avec les industriels, puisque les industriels ne verraient pas l'intérêt de contribuer à un effort de recherche qui sera mis à disposition de ses concurrents.
Je ne suis pas d'accord. Pour moi il y a un vrai intérêt à un industriel à avoir un canal privilégié avec des chercheurs, même si les résultats de la recherche sont publics. Ça permet d'influer sur les problèmes qu'ils se posent (leur pointer du doigt ses problèmes spécifiques), d'avoir des contact pour faciliter la formation interne sur les technologies développées (on amène des ingénieurs à une discussion avec les chercheurs), etc. Globalement l'idée qu'une diffusion publque veut dire que tout le monde est à égalité suppose qu'il y a une communication des savoirs parfaite et instantanée entre tous les acteurs, ce qui n'est pas vrai en pratique.
Prendre en compte l'inégalité dans l'accès à la connaissance a un peu changé ma vision de certaines pratiques de la recherche, je pense que c'est important à prendre en compte. Par exemple, ça nous dit aussi que l'argument "travailler avec les militaires ne peut pas poser de problème éthique tant que les résultats de la recherche sont ouverts" n'est pas vrai dans l'absolu, et à considérer avec beaucoup de prudence.
Il me semble qu'en gros, ce document ne dit pas de fermer l'accès aux résultats de la recherche mais de faire attention.
Non, pour moi ce document est clairement rédigé par des gens qui voudraient que les chercheurs ferment l'accès à leur recherche et contactent des "experts de la valorisation" à chaque fois qu'ils ont une nouvelle idée, pour se demander comment faire du fric avec au lieu de bêtement la publier publiquement le plus clairement possible (ce qu'on fait en dernier recours, quand on ne voit vraiment pas comment la vendre à la place).
C'est très clair par exemple ici : "Je discute (avec un partenaire socio-économique), JE DOIS parler uniquement de résultats publiés ou déjà accessibles". Ce poster, quand il est diffusé aux chercheurs par leur hiérarchie, leur demande de ne pas parler de recherche en cours à quelqu'un à qui on pourrait peut-être tirer du fric (c'est-à-dire tout le monde). On est bien dans une demande de fermeture des résultats de la recherche—et même si c'était dit moins crûment, il faudrait être réaliste sur l'intention derrière et l'état d'esprit des gens qui écrivent ça.
Pour moi une dépêche c'est sérieux, c'est sur la page d'accueil, il faut que ça soit bien léché et accessible au plus grand nombre (et en plus les autres gens viennent mettre leur grain de sel dans le texte, ce qui est parfois bien et parfois casse-pieds), alors qu'un journal c'est un espace d'expression plus libre et plus brute, on peut mettre des trucs dessus et voir si ça colle—ou pas. Je trouve les deux très différents, du point de vue des auteurs comme de celui des lecteurs, et je pense que mélanger les deux notions serait une perte.
[^] # Re: Vécu
Posté par gasche . En réponse au journal Optimisez votre code !. Évalué à 6.
Le contrat à l'extérieur ne marche pas forcément, mais tout internaliser a aussi ses propres problèmes, au moins quand la taille du projet est trop petite (ou ses finances) pour avoir plus d'un seul développeur. Avec un prestataire extérieur, si tu as la chance de trouver des gens compétents (oui, ça existe), tu peux espérer avoir plusieurs personnes qui travaillent sur le projet à temps partiel, ou au moins un seul développeur qui a beaucoup d'expérience de travail en équipe.
(Bien) travailler à plusieurs et (bien) travailler tout seul c'est très différent, le premier est un peu moins efficace sur le court terme (coûts de communication, conventions à adopter, mécompréhensions etc.), mais il incite beaucoup plus à avoir de la documentation écrite, des processus de développement/bugfix/release/etc. explicités, et se prête donc plus naturellement à un passage de bâton (partiel ou total) à d'autres développeurs ensuite.
Quand on travaille tout seul (même quand on est compétent et qu'on fait attention), c'est facile de s'enfermer sans s'en rendre compte dans un projet où on a tout en tête mais peu de choses écrites pour d'autres, dans des choix d'architectures non-standards qui rendent le projet plus difficile à comprendre pour d'autres, et au final avec quelque chose qui, si on doit se faire remplacer pour une raison quelconque, est beaucoup plus difficile à prendre en main pour les suivants.
Idéalement je pense que si j'étais demandeur d'une prestation informatique, j'essaierais de trouver un compromis entre "la boîte de prestation opaque" et "le développeur tout seul en interne". Soit une petite boîte avec un petit nombre de personnes en local avec qui j'ai de bons rapports, soit essayer de gérer les responsabilités en interne pour avoir plus d'une personne sur le backend (par exemple, au lieu d'avoir un développeur et un webmaster, chercher deux personnes polyvalentes qui se partagent les tâches sur les deux fronts).
[^] # Re: Bémol
Posté par gasche . En réponse au journal Optimisez votre code !. Évalué à 5.
Il doit y avoir une incompréhension entre toi et nous, parce qu'arrêter de chercher une liste quand on a trouvé, ça reste en O(1). O(1) veut dire "plus petit qu'une constante", donc faire moins de calculs préserve toujours la propriété d'être O(1).
Il y a des domaines où on veut non seulement faire du O(1), mais en plus que le calcul consomme toujours les mêmes ressources (temps, mémoire, énergie) : c'est quand on veut éviter les attaques par canaux auxiliaires dans un protocole cryptographique. Mais tu parlais plutôt de systèmes temps-réel dur dans ton message.
[^] # Re: ZeMarmot ?
Posté par gasche . En réponse au journal Vent de révolte sur Patreon qui profite à Liberapay. Évalué à 3.
Qui a été crée hier ou aujourd'hui visiblement, après mon journal. Merci pour le lien !
Cependant, la page n'est pas encore listée sur la page du projet ou le blog du projet, qui mentionnent uniquement Patreon et Tipeee, je n'ai reçu aucune communication à ce sujet de la part des auteurs (ça va peut-être venir plus tard), donc pour l'instant il est difficile de savoir ce qui est encouragé de leur part.
(Par exemple, certains créateurs attachent de l'importance au fait de recevoir une somme pas trop grosse mais pas trop petite non plus sur Patreon chaque mois, parce que les utilisateurs sont moins motivés pour donner s'ils ont l'impression que le projet fait un flop complet. Du coup j'aime mieux attendre un message expliquant l'intention ou les préférences des créateurs avant de changer de mode de financement.)
# Autres projets libres sur Liberapay
Posté par gasche . En réponse au journal Vent de révolte sur Patreon qui profite à Liberapay. Évalué à 8.
Je me rends compte que, puisque j'ai mentionné (comme exemples) les projets libres que je soutenais sur Patreon, il serait naturel de mentionner aussi le projet que je soutiens sur Libeparay depuis longtemps, à savoir Matrix.org (sur liberapay), les développeurs de la plateforme de communication en ligne Matrix—qui est en particulier le meilleur concurrent libre de Slack, avec un pont IRC étonnamment agréable à utiliser.
Je soutiens aussi Liberapay, la plateforme elle-même, qui essaie de se financer par dons comme tous les autres projets.
(Si vous avez d'autres tuyaux de projets libres à soutenir sur Liberapay, n'hésitez pas à poster un commentaire.)
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Tu penses à de faux problèmes.
Non, pas spécialement besoin d'aide là-dessus, encore une fois il suffit de les gens demander des contacts, etc. Il y a besoin d'aide administrative (pour les transferts d'argent il faut de la paperasse), la fondation a du personnel administratif pour ces choses-là.
La communauté universitaire est aussi très décentralisée et pourtant on arrive à monter des projets.
C'est plus difficile qu'au sein de Microsoft où un manager peut dire "maintenant vous faites ça, point barre", mais ce n'est pas si difficile en soit. Je pense que l'approche par financement de projet que je propose marcherait bien.
Pour évaluer les propositions, il suffit de demander leur avis à des gens qui connaissent le sujet. Tu envoies un mail "salut, pouvez-vous lire cette proposition de 6 pages et donner votre avis sur la faisabilité du truc, ou sinon me conseiller deux personnes qui s'y connaissent mieux que vous ?" à trois personnes, et les gens se montrent plein de bonne volonté en pratique. (Encore une fois, le milieu universitaire, décentralisé, fonctionne très bien comme cela.)
Non mais ce n'est pas comme ça que ça c'est passé, c'est GKH qui a décidé de passer un an à Paris et qui a prévenu les gens qui l'emploient qu'il allait faire ça, et il a dit ok. Et il est payé pareil, où qu'il habite.
Je rend des services tous les mois à des gens d'une autre université, d'un autre pays que moi, sans transfert d'argent ou qu'on fasse partie de la même institution. Personne n'est forcé, on me demande gentiment et j'accepte quand ça m'intéresse. Ça peut se passer comme cela là-aussi.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Mais non, il suffit que la fondation dise : "s'il y a des chercheurs et des développeurs qui veulent travailler ensemble sur un projet bien défini, nous on apporte des sous pour financer ça en partie". Après les gens se trouvent de la façon qu'ils veulent (ils s'envoient des emails pour se proposer le projet, utilise leurs contacts pour savoir qui serait intéressé par tel ou tel truc, etc.).
Bah ça c'est facile à tester, il suffit de poser la questions aux gens et d'envoyer des mails sur les mailing-list : "On envisage de faire ça, qu'en pensez-vous ? Contactez-nous si vous seriez prêt à aider un peu dans les domaines qui vous concernent.".
La communication aussi c'est facile. C'est à moi de faire ce boulot ou quoi ? "Nous on est trop innovants de la mort et donc on monte un programme de financement des sujets de recherche en qualité logicielle (test et analyse de programme) autour de Linux. Les développeurs X et Y, et le chef du laboratoire de recherche Z du MIT, confirment que c'est une super idée."
L'important c'est juste de dire : "on se rend compte que c'est un sujet intéressant/important et on est prêt à faire preuve de bonne volonté pour faciliter les choses". (Et si possible : on donne un peu des sous pour ça.) Si aujourd'hui je suis un chercheur et je me demande si je peux collaborer avec des gens, c'est beaucoup plus facile d'aller entrer en contact avec des gens qui ont fait signe qu'ils étaient intéressé qu'à des gens qui s'en foutent. Et les gens de Linux, aujourd'hui, ils s'en foutent.
Il n'y a pas besoin d'équipe de R&D pour dire : "on veut plus de collaboration et si des gens nous contactent pour en faire, on va les aiguiller vers des interlocuteurs au sein du projet et on peut les financer un peu".
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3. Dernière modification le 04 novembre 2017 à 17:43.
Ce que je dis :
Je ne dis pas que c'est "juste la faute du noyau"; les universitaires aussi ont des efforts à faire pour avoir plus de collaboration, et je fais aussi ce que je peux pour le dire aux gens quand je discute au sein de cette communauté. Mais ici je parle des problèmes qui existent dans la communauté du noyau et de façon d'avancer vers des solutions.
Pour préciser, les financements se passeraient par exemple comme ça : pour avoir des sous, il faut qu'une équipe envoie une proposition de projet à la Linux Foundation, qui décrit un projet de recherche appliquée au noyau. L'équipe qui a monté comprend des académiques et des développeurs du noyau, et surtout des gens qui vont surtout regarder/superviser et des gens qui vont vraiment faire le boulot (en général un ou plusieurs étudiants). La fondation paie des gens pour relire les propositions et dire si ça leur a l'air plausible (si c'est une idée intéressante, utile pour le noyau, réaliste scientifiquement, qui peut donner lieu à des suites intéressantes), et si oui la fondation donne un peu d'argent—$5000 dollars pour un en-plus qui motive mais qui ne suffit pas à financer, ou alors six mois de salaire pour un étudiant ou alors, pour une thèse complète, une année ou deux (mettons $50000).
Une fois que c'est en place, la Linux Foundation dit aux devs Linux "si vous connaissez des chercheurs dont le travail vous intéresse, parlez-leur de cet appel à projet", et contacte les chercheurs qui ont déjà bossé sur Linux pour leur en parler. Ensuite c'est aux chercheurs qui sont intéressés par ces financement d'entrer en contact avec des gens, de monter un projet, et de candidater. S'il peut y avoir des pointeurs pour des contacts (sur le site web, "si vous voulez savoir qui est intéressé par le sujet X, vous pouvez demander à Y qui est un bon d'entrée dans la communauté noyau"), c'est mieux.
Tout cela est au final assez simple, ça demande juste un peu de travail (pour coordonner le tout il faut des gens non-techniques, qui peuvent être payées pour ce boulot comme la Linux Fondation embauche ou sous-traite déjà du travail) et surtout de la bonne volonté.
Moi j'ai surtout l'impression d'être en face d'un barrage de mauvaise foi. Je parle quand même de chose que je connais relativement bien (je participe comme contributeur à des projets libres, donc bon "il y a des exigences de qualité" et "on n'est pas des petits esclaves", c'est évident pour moi), et on m'oppose des arguments vraiment loin de la réalité : "non mais la Linux Foundation c'est juste 6 personnes qui n'ont pas le temps".
Personne ne serait forcé à faire une chose ou une autre, mais le fait de mettre une structure en place pour encourager ces collaborations (et de l'argent pour les faciliter) peut avoir beaucoup d'impact.
Je suis passé dans les bureaux de cette équipe de recherche au moment où Greg y était. C'est sympa, il a fait un séminaire pour parler aux étudiants pour parler du développement Linux, et je suis sûr qu'il a bien discuté avec Julia Lawall de ce qui lui l'intéresserait dans son travail à elle, et donné des idées de choses à faire. C'était aussi une bonne occasion de faire de la communication des deux côté (Linux : "vous voyez, on est en contact avec la recherche"; INRIA : "vous voyez, on est bien vus par le monde des gens qui font des vrais trucs"). Mais après GKH a surtout passé une année sympa à Paris à bosser sur ses trucs qu'il fait d'habitude dans un bureau différent, et eu plus d'opportunités pour discuter. Ça a un impact, mais comme je l'ai dit, c'est une goutte d'eau.
Encore une fois, c'est de la recherche en systèmes; il y a des chercheurs qui contribuent à Linux dans ce domaine et c'est très bien. Moi je parle de recherche en qualité logicielle (test et analyse de code), et là c'est beaucoup moins clair—à part Coccinelle.
Ben si, pourquoi pas ? Il suffit de bonne volonté (ça manque) et d'un peu d'argent (il y en a). Pour Mozilla, ce n'est pas très compliqué de dire à l'un de ses employés "si tu veux, on te paie pour aller pendant une semaine à la conférence machin qui t'intéresse, et quand tu discutes avec des gens là-bas, dis-leur bien qu'on est intéressé par le fait de financer des collaborations". Ce ne serait pas très compliqué pour la communauté Linux de faire la même chose.
De toute façon, ce dont je parle ce n'est pas de faire rentrer des bases de code dans le noyau, c'est plutôt d'évaluer des outils de test ou d'analyse statique sur le kernel, de les adapter pour passer à l'échelle, et si possible de faire des changements dans le code qui facilitent leur application.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Je ne comprends pas ce que ton commentaire essaie d'apporter à cette conversation.
Ce que j'ai proposé c'est que les gens de la Linux Foundation essaient d'encourager les collaborations entre les développeurs Linux et le milieu académique en (1) faisant de la communication à ce sujet et en (2) finançant des travaux de recherche appliquée au noyau. Ça ne suffit pas à changer la chose du tout au tout (il faut un changement de culture d'ensemble dans la communauté du noyau, je pense, mais ça c'est progressif sur le long terme), mais ça ne peut que renforcer des dynamiques. Ce sont des actions bien délimitées, qui sont largement à portée de ses missions, de ses financements et de son personnel (parce que non, ce n'est pas Linus dans son garage qui a fait le site web flambant de la fondation, et qui maintient le gâteau administratif des versements de sous, etc; il y a du personnel de support).
Clairement une partie importante des entreprises qui soutiennent la fondation le font pour avoir l'impression de contribuer à l'écosystème Linux. Si la fondation leur propose une stratégie nouvelle (parmi d'autres) pour améliorer la qualité du noyau, elles seront certainement contentes de financer ça, mais c'est un endroit beaucoup plus neutre et beaucoup plus centralisé pour lancer ce genre d'effort qu'une entreprise en particulier. Par ailleurs, dans les entreprises de la Fondation, il n'y en a pas beaucoup qui ont des équipes de R&D de qualité sur les sujets dont je discutais (les outils d'analyse de programme); Microsoft en a, Facebook en a, IBM en a, mais ce n'est pas courant—il n'y a pas d'entreprise qui soit clairement mieux placée que la fondation pour lancer quelque chose là-dessus.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
N'importe quoi. La Linux Foundation est un regroupement d'entreprises qui mettent un paquet d'argent en commun pour faire des choses autour du libre. Tu as choisi de montrer les 6 personnes qu'elle embauche à plein temps pour programmer, mais il y a un "Technical advisory board" de 10 personnes, une "Leadership team" de 24 personnes, des centaines d'entreprises qui sont membres (ils disent "plus de 800"), et en 2015 (dernière année pour les infos publiques sur les taxes) ils ont brassé 40 millions de dollar (avec presque 4 millions en bénéfices nets cette année-là).
Autrement dit : ce serait tout à fait la bonne entité pour diriger un effort d'encouragement à la collaboration avec les milieux universitaires autour du noyau Linux.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 5.
Il n'y a pas besoin de "faire de la recherche" pour être légitime dans ce domaine—la R&D, l'idée n'est pas en général de produire de la recherche nouvelle (même si parfois ça arrive), mais quand même d'avoir le niveau scientifique pour pouvoir interagir avec la recherche du domaine (les travaux écrits et/ou le personnel de recherche). Mais oui, embaucher des docteurs peut aider pour ça — et c'est quelque chose que les entreprises françaises ne font peut-être pas assez par rapport aux américaines par exemple.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 5.
Si tu es dans un département R&D mais que tu ne peux pas entrer en contact avec la recherche, c'est que soit tu es mal formé (initialement, peut-être, mais aussi et surtout la formation continue qu'une boîte de R&D doit assurer en encourageant ses employés à suivre l'état de l'art, par exemple en allant aux conférences importantes du domaines), soit on se moque de toi et le titre "R&D" est juste là pour faire plus prestigieux et prendre des crédits impôts-recherche, mais est vidé en pratique de sa substance.
C'est très courant, surtout dans les boîtes qui n'ont en fait pas de problème technique difficile à résoudre et n'ont donc pas vraiment besoin d'une branche R&D qui fait du vrai boulot. Ou alors des boîtes qui ne se rendent pas compte de l'intérêt qu'elles auraient à faire sérieusement de la R&D — parce que ça veut dire accepter des projets exploratoires, une incertitude sur le moyen terme, des besoins importants de réelle formation continue, etc., et que tout ça n'est pas facile à manager.
(Il y a aussi des boîtes avec de la vraie R&D. Quand on discute avec les gens de la R&D d'EDF par exemple, on sent qu'ils sont très câlés sur leurs sujets.)
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Oui, vu les auteurs en commun c'est bien le même projet.
Dans le genre, un autre DSL issu de la recherche et qui pourrait intéresser les gens de Gimp (par exemple) est Halide.
C'est une bonne idée, tu devrais envoyer un mail aux gens de Gimp/CIMG pour leur demander s'ils ont étudié ces DSLs et envisagé de les utiliser. (Je crois que les gens de CIMG n'ont pas du tout réfléchi à comment migrer des calculs sur des GPUs, pour l'instant, mais ces langages pourraient déjà accélérer les implémentations CPU.)
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Tu as des informations plus précises là-dessus ? Combien de stages, combien de thèses ont été financées par la Fondation Linux, sur quels sujets ? À quelles conférences est-ce que des membres de la fondation sont venus parler de leurs problématiques et entrer en contact avec des gens ? Y a-t-il des choses qui ont été écrites publiquement (blogs, mailing-list) sur un désir de la Linux Foundation d'interagir avec les milieux de recherche, et sur la stratégie qu'ils ont décidé de mettre en place pour faciliter cela ? Y a-t-il sur le site web de la fondation une ou des pages dédiées à la recherche, qui indique par exemple comment les contacter pour monter un projet de collaboration ?
(Je demande semi-naïvement : je ne suis pas de prêt ce que fait la fondation, donc je pourrais être positivement surpris, mais à ma connaissance la réponse à toutes ces questions est "zéro", "aucune" et/ou "non".)
C'est très bien que GKH soit venu un an à Paris et ait discuté de Coccinelle (et il y a même de temps en temps quelques développeurs Linux qui s'en servent). Tu dis que l'usage n'est "pas anecdotique", mais pour moi c'est une goutte d'eau. Et ça a demandé de la part des gens qui travaillent sur Coccinelle des efforts considérables. Une telle collaboration ne devrait pas être exceptionnelle mais un exemple parmi d'autres.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Déjà, il y a des gens dont c'est le métier, c'est appelé la R&D, Recherche et Développement. Les ingénieurs R&D sont (en théorie) là pour faire le transfert entre la recherche et l'industrie.
Ensuite, il me semble qu'une autre réponse (en particulier dans le cadre du logiciel libre) c'est : "une équipe avec des compétences mixtes". Tu mets des chercheurs et des développeurs noyau ensemble, et tu les fais discuter, sur le long terme.
Un des rôles de la recherche est de transmettre le savoir, certes, mais on ne peut pas forcer les gens à écouter si ça ne les intéresse pas, s'ils ne sont pas prêt à faire un effort pour comprendre et participer. Si la volonté est là, c'est très facile d'obtenir d'un chercheur qu'il parle d'une façon compréhensible à des ingénieurs, il suffit d'envoyer un mail pour lui poser des questions, et de signaler quand on ne comprend pas quelque chose. (Ou alors d'aller à ses cours et ses exposés, et de poser des questions ensuite.)
Mais il faut que les gens se lançant dans une telle discussion soient conscients des rôles de chacun pour qu'elle soit productive. Si tu commences à discuter en espérant, au bout de quelques emails, pouvoir appliquer directement le résultat développé dans un cadre simplifié, purifié à ton gros projet de la vraie vie, tu vas sans doute être assez déçu. Il faut être prêt à entrer dans une boucle d'itération sur le moyen/long terme, avec des choses qui marchent partiellement au milieu.
Il y a des gens qui le font, par exemple qui testent Compcert sur tous les paquets OpenBSD et qui font des rapports d'erreur quand quelque chose coince (exemple). Ce travail peut mettre quelques années à aboutir, et le résultat (qu'on peut compiler OpenBSD avec un compilateur vérifié) n'est qu'une brique de base qui pourrait servir à d'autres choses ensuite.
Encore une fois, une bonne façon de faciliter encore ces échanges et de faire avancer les choses plus vite, c'est aussi de donner des sous (les chercheurs sont contraints en temps et en financement). Si la Linux Foundation avait sérieusement envie de faire avancer le sujet, elle pourrait facilement financer des thèses, dans des laboratoires de recherche, appliquées sur le noyau Linux. Les gens de Mozilla font ça, ils viennent à nos conférences (de recherche) et ils disent, clairement, "si vous avez des gens qui veulent travailler sur des sujets qui nous concernent, on peut les financer, les accueillir en stage chez nous pour leur faire découvrir nos problématiques, contactez nous". Et ça a un effet direct sur l'évolution de Rust par exemple.
[^] # 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.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 8.
Encore une fois, ce n'est pas le métier des chercheurs que de développer une interface facile d'accès à leur travail. Il y a un petit prototype pour démontrer l'idée, qui fait mieux que l'existant question performance. Si quelqu'un veut prendre ça et en faire une bibliothèque grand public, je suis sûr que les auteurs de ce travail seraient volontaires pour donner des conseils et participer et aider, mais ce serait déraisonnable de leur part de s'y attaquer seuls—parce que ce n'est pas leur métier et que les gens qui les emploient leur demanderaient des compte sur l'usage de leur temps de travail.
C'est un peu facile de ta part : tu commences par dire qu'il n'y a pas de recherche sur des langages efficaces (que le milieu de recherche n'a pas les priorités qui t'intéressent), et maintenant je te montres qu'il y en a et ta réponse c'est que c'est trop de la recherche ! Tu voudrais un truc tout cuit, mieux que l'existant, déjà prêt pour être utilisé par tout le monde, et puis un café aussi ?
Il y a une incompréhension de fond sur la façon dont les universitaires travaillent, quel est leur but. Je trouve assez déplacé de me dire ensuite que (quand je parle en tant que chercheur) je suis ignorant et méprisant, alors que moi justement je fait l'effort de bien connaître et de comprendre ces deux milieux dont je suis membre, et de dire ensuite ce qui me semble poser problème.
[^] # 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.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 9.
Ces outils sont développés par les développeurs noyaux, qui n'ont pas en général de bagage en recherche dans le domaine concerné (test aléatoire, analyse statique). Au bout d'un moment ils pensent à un outil et ils en développent un from scratch pour leurs besoins. C'est une approche classique d'ingénieur et louable, mais les outils en question restent en général loin derrière l'état de l'art, les problèmes sur lesquels travaillent les chercheurs qui bossent dans le domaine. La recherche en analyse statique c'est Astrée par exemple, un outil qui prouve l'absence de comportement indéfini (segfault compris) dans l'ensemble du code de contrôle de certains Airbus. On est très, très loin devant Sparse en terme de puissance.
Les développeurs du noyau Windows ont aussi des outils très fins, avec une vraie collaboration avec la communauté de recherche sur l'analyse statique de fonctions noyau et des kernels, qui demande des annotations utilisées en pratique par les développeurs; voir SAL 2.0 Annotations for Windows Drivers par exemple, ou l'énorme travail sur le "whitebox testing" des composants Windows et de .NET ( par exemple, https://www.microsoft.com/en-us/research/publication/pex-white-box-test-generation-for-net/ ).
Ce que j'aimerais voir, si les développeurs Linux étaient plus ouverts au fait d'intégrer des résultats de recherche, c'est des outils qui sont développés pour le kernel par une collaboration d'universitaires et de développeurs noyaux actifs (il y a des chercheurs qui sont aussi développeurs noyaux). C'est le cas par exemple des travaux sur la formalisation du modèle mémoire de Linux et en particulier de RCU, qui est fait par un mélange d'universitaires et de développeurs—et il y a quelques développeurs qui se laissent parfois convaincre d'écrire des patches Coccinelle. Mais c'est très rare, ce n'est pas dans la culture de la communauté qui développe le noyau; c'est dommage.
Bien sûr, les prototypes issus de la recherche ne sont pas utilisables en l'état sur un logiciel aussi gros et compliqué que le noyau. C'est pour ça qu'il faut une collaboration entre les deux communautés, pour que les universitaires aient des retours sur les besoins du noyau, soient forcés de rendre leurs outils plus généraux et plus faciles à utiliser sur de vrais projets, et aient aussi l'assurance qu'il y a des gens prêt à les adopter derrière, qu'un effort de passage à l'échelle ne sera pas fourni à perte. Encore une fois, pour ça il faut une culture volontaire du côté des développeurs, et elle manque pour le noyau Linux (alors qu'elle est présente pour Windows, en partie parce que Microsoft n'a pas laissé le choix à ses développeurs). On peut dire que beaucoup de développeurs ont déjà plein de boulot et n'ont pas le temps de jouer à tester des prototypes d'outils pour le noyau, mais encore une fois, c'est une question de priorité (des personnes, et des organisations : la Linux Foundation pourrait financer ce genre de travaux si elle en avait envie).
Un exemple concret, dans la communauté que je connais mieux (et qui n'est pas celle qui travaille le plus sur la génération de code efficace, c'est plutôt un à-côté pour nous), serait Generating performance portable code using rewrite rules: from high-level functional expressions to high-performance OpenCL code par Michel Steuwer, Christian Fensch, Sam Lindley, et Christophe Dubach, 2015. Ils définissent un petit langage très simple pour composer des expressions qui décrivent des calculs sur GPU, et une façon de le compiler qui donne des programmes qui vont plus vite que des versions écrites à la main par des experts. Par exemple le code pour décrire une multiplication matrice/vecteur (GEMV en BLAS) dans ce langage est
et le résultat de la compilation va un peu plus vite que les bibliothèques fournies par les vendeurs de GPU (CUBLAS sur un GPU Nvidia, clBLAS sur un GPU AMD, et la MKL pour un CPU Intel), et est entre 2 et 5 fois plus rapide qu'une implémentation OpenCL portable selon la machine sur laquelle on la fait tourner.
# Soutenir, pas diriger
Posté par gasche . En réponse au journal Propriété intellectuelle dans la recherche public. Évalué à 7. Dernière modification le 28 octobre 2017 à 21:40.
Il y a plein de situations de recherche dans lequel la présence, à côté du personnel de recherche, de responsables de "valorisation" ou "partenariat" peut être utile. Pour ce que j'en ai personnellement aperçu, elles peuvent souvent se repérer au fait que les chercheurs ou chercheuses sont déjà en contact avec une enterprise spécifique intéressée par leurs travaux, et pourrait avoir intérêt à participer à leurs financements. Du côté de l'entreprise comme du côté de l'équipe de recherche, la complexité administrative et juridique de ce transfert d'argent peut être très importante (l'entreprise a des règles internes sur comment payer, elle veut bien acheter des licences mais pas du support, ou alors l'inverse, financer un produit mais pas un développement futur, ou alors l'inverse, etc.; l'équipe de recherche évolue dans un environnement réglementaire compliqué aussi, il faut reverser une partie à l'institut, donner de l'argent au laboratoire plutôt qu'aux personnes, etc.), et avoir des professionnels pour s'en occuper peut permettre aux choses de se faire dans l'intérêt de tous.
C'est une vision des services de valorisation qui leur fait porter leur nom : des services, présents pour soutenir une activité quand on les sollicite.
Le problème c'est que souvent les gens qui sont plus hauts dans l'organigramme administratif de la recherche publique ont envie de diriger, plutôt que de servir. Ça commence tout en haut, avec un gouvernement qui croit hélas bon de commander des recherches sur des domaines particuliers, au risque d'imposer des mécanismes d'encouragement lourds, coûteux en complexité et en temps, et contre-productifs. Mais c'est vrai aux niveaux en-dessous, et l'image montrée dans ce journal en est un exemple criant.
Ce document n'est pas là pour informer le personnel de recherche de ce qu'il peut faire pour trouver des financements privés pour sa recherche. Le document essaie de dire ce que le personnel doit faire. C'est à rapprocher du document récent (formaté dans le même style "on vous informe mais en fait on ordonne") de l'université de Strasbourg, interdisant au personnel de recherche de parler à des journalistes sans l'accord du service de communication de l'université (article sur EducPros).
Je pense que c'est très dangereux de s'habituer à un tel niveau de directivité, de l'accepter. Laisser des gens qui ne pratiquent pas la recherche décider de comment elle doit être conduite, c'est ouvrir la porte à toutes les dérives. On a des hommes et des femmes politique qui n'hésitent pas, par exemple, à dé-financer des sujets de recherche pour gagner des points auprès de leur électorat. Aujourd'hui on demande de ne pas publier de résultats sans envisager les possibilités de monétisation avant, demain il faudra peut-être demander aussi l'accord des gens chargés d'évaluer si un des mécènes (privés ou public) de l'université ou institut de recherche pourrait ne pas apprécier les résultats. Ou bien du service qui vérifie qu'on ne co-publie pas avec un laboratoire d'une institution qui a refusé le dernier projet de fusion.
La recherche publique est efficace quand elle est libre et diffuse largement. Il faut la soutenir (et il est légitime que la société fasse des choix sur le niveau, la nature et la forme de ce soutient), faire respecter et encourager des méthodes de travail qui sont dans l'intérêt collectif, mais il est dangereux d'essayer de la diriger.
[^] # Re: Une information un peu orientée, mais pas forcément stupide...
Posté par gasche . En réponse au journal Propriété intellectuelle dans la recherche public. Évalué à 9.
En soit, tiré de son contexte, aucun, surtout si ça permet de financer plus de recherche et là ça peut carrément être positif. Mais le soucis c'est que c'est rarement sans contrepartie. Par exemple, si ça demande de limiter la diffusion des résultats (pour pouvoir les monnayer), là il y a un problème, car on s'écarte de la mission première de la recherche publique, la création et diffusion des savoirs, dans la recherche du profit direct (qui n'est pas une mission de la recherche).
Le document dont il est question dans ce billet est le témoin du fait que les gens qui l'ont écrit pensent que c'est normal de ne pas parler de sa recherche s'il y a la moindre chance que cela rende plus facile par la suite de gagner de l'argent avec. C'est de ça que je parle.
[^] # Re: propriété intellectuelle
Posté par gasche . En réponse au journal Propriété intellectuelle dans la recherche public. Évalué à 6.
Quand on fait de la recherche publique et qu'on publie, on n'écrit pas pour "des personnes" en particulier, on écrit pour tout le monde.
D'ailleurs l'idée d'une "propriété intellectuelle" sur cette recherche me paraît dérangeante, même si malheureusement le droit français lui donne sens—je ne sais pas ce qu'il en est d'autres pays francophones. Aux États-Unis, les connaissances produites par les employés fédéraux sont automatiquement libres de droit, cela me semble bien plus naturel. Bien sûr, beaucoup des schémas actuels de monétisation de la recherche sont encouragés par la radinerie du gouvernement français : la question ne se poserait pas, ou alors seulement dans des domaines spécifiques à recherche expérimentale lourde, si les laboratoires étaient financés correctement.
[^] # Re: Il ne faut pas débarquer
Posté par gasche . En réponse au journal Propriété intellectuelle dans la recherche public. Évalué à 5.
Un commentaire très raisonnable, même si je suis un peu déçu que tu ne mentionnes pas l'atteinte sous-jacente à la liberté universitaire : c'est quand même très très lourd de dire à des chercheurs à qui et comment ils ont le droit de parler de leur recherche.
Je ne suis pas d'accord. Pour moi il y a un vrai intérêt à un industriel à avoir un canal privilégié avec des chercheurs, même si les résultats de la recherche sont publics. Ça permet d'influer sur les problèmes qu'ils se posent (leur pointer du doigt ses problèmes spécifiques), d'avoir des contact pour faciliter la formation interne sur les technologies développées (on amène des ingénieurs à une discussion avec les chercheurs), etc. Globalement l'idée qu'une diffusion publque veut dire que tout le monde est à égalité suppose qu'il y a une communication des savoirs parfaite et instantanée entre tous les acteurs, ce qui n'est pas vrai en pratique.
Prendre en compte l'inégalité dans l'accès à la connaissance a un peu changé ma vision de certaines pratiques de la recherche, je pense que c'est important à prendre en compte. Par exemple, ça nous dit aussi que l'argument "travailler avec les militaires ne peut pas poser de problème éthique tant que les résultats de la recherche sont ouverts" n'est pas vrai dans l'absolu, et à considérer avec beaucoup de prudence.
[^] # Re: propriété intellectuelle
Posté par gasche . En réponse au journal Propriété intellectuelle dans la recherche public. Évalué à 3.
Moi je trouve ça choquant qu'on se permette de dire à des chercheurs comment ils ont le droit, ou pas, de diffuser le résultat de leurs recherches.
[^] # Re: Une information un peu orientée, mais pas forcément stupide...
Posté par gasche . En réponse au journal Propriété intellectuelle dans la recherche public. Évalué à 8.
Non, pour moi ce document est clairement rédigé par des gens qui voudraient que les chercheurs ferment l'accès à leur recherche et contactent des "experts de la valorisation" à chaque fois qu'ils ont une nouvelle idée, pour se demander comment faire du fric avec au lieu de bêtement la publier publiquement le plus clairement possible (ce qu'on fait en dernier recours, quand on ne voit vraiment pas comment la vendre à la place).
C'est très clair par exemple ici : "Je discute (avec un partenaire socio-économique), JE DOIS parler uniquement de résultats publiés ou déjà accessibles". Ce poster, quand il est diffusé aux chercheurs par leur hiérarchie, leur demande de ne pas parler de recherche en cours à quelqu'un à qui on pourrait peut-être tirer du fric (c'est-à-dire tout le monde). On est bien dans une demande de fermeture des résultats de la recherche—et même si c'était dit moins crûment, il faudrait être réaliste sur l'intention derrière et l'état d'esprit des gens qui écrivent ça.
[^] # Re: Journal VS depeche
Posté par gasche . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 7.
Pour moi une dépêche c'est sérieux, c'est sur la page d'accueil, il faut que ça soit bien léché et accessible au plus grand nombre (et en plus les autres gens viennent mettre leur grain de sel dans le texte, ce qui est parfois bien et parfois casse-pieds), alors qu'un journal c'est un espace d'expression plus libre et plus brute, on peut mettre des trucs dessus et voir si ça colle—ou pas. Je trouve les deux très différents, du point de vue des auteurs comme de celui des lecteurs, et je pense que mélanger les deux notions serait une perte.