 Bonjour à tous ! C'est un plaisir d'être ici pour cette démonstration de l'Enbedis Linux. C'est mon premier temps ici à TLC. Je suis principalement professeur de l'académie, parce que je suis professeur de l'université de France. Je suis un scientifique en réaction. Nous avons travaillé sur le software en général, et en particulier sur les variants de software. Il y a aussi des keywords comme « software product line » « configurable system » « generators » « our relevant topics » Et bien sûr, Linux était dans notre radar, parce que c'est un projet très intéressant pour beaucoup de perspective. Et ce taux est principalement un taux pour ces deux papiers. C'est principalement une introduction à des résultats qu'on a. Donc si vous voulez avoir plus de détails, vous pouvez avoir un look. Je suis vraiment bienvenu à avoir des réponses sur ça. Et c'est un travail joint avec beaucoup de gens ici à Tren. Donc vous pouvez voir la liste ici. Donc, sur notre sujet, Linux. Linux est intéressant de beaucoup de perspective. Et peut-être qu'une majorité de Linux est la configurabilité haute. C'est incroyable. Vous pouvez mettre Linux dans des petits modèles. Vous pouvez le faire sur la application de desktop, sur la compétition de cloud, sur la compétition de Edge, sur la compétition de Supercomputing. Pourquoi? Parce que vous avez des options que vous pouvez combiner pour assurer vos récréments. Je vais juste mettre un excerpt d'un file Kconfig, documentant deux options. L'une est des options Boolean. Oui ou non. Vous pouvez voir que c'est beaucoup de dépendances et de documentation. Il y a un autre qui est en trois states. Il peut prendre non ou de la valeur moduelle. Et encore, il y a une sorte de dépendance. Si vous avez un utilisateur de kernel, vous pouvez configurer Linux avec un configurateur ou l'éditing d'un file Kconfig qui respecte les constraints du file Kconfig. Et ce que nous observons c'est qu'il y a une augmentation dans les nombreuses options. Et il ne s'arrête pas. Je l'ai pris juste pour l'architecture, x86 et ARM, mais c'est le même trend pour toute l'architecture. Nous avons gagné quelque chose de 3000 options entre Linux 4 et Linux 5. C'est incroyable. Vous avez 15 000 options que vous pouvez combiner. C'est même. C'est pourquoi Linux est tellement populaire. C'est parce que vous pouvez combiner toute cette option pour des recommandations. Mais il peut aussi être une sorte de nightmare. Parce qu'il y a beaucoup de défauts que vous avez faits à cause de l'interaction contre les options. Vous vous activez deux options ensemble. Et soudainement, il y a quelque chose d'accord. Il y a un bug. C'est très spécifique pour cette combination. Les développeurs et les maintenance sont en train d'attirer les bugs. Je peux le voir dans la main linéaire. On peut le voir dans la main linéaire. Et j'espère qu'ils peuvent fixer les bugs. Il peut prendre des bugs. Donc, pour vous dire, qu'il y a des bugs randoms, je pense qu'il y a des configurations randomes qui causent ces bugs. Et c'est pourquoi c'est tellement fou. En pratique, nous utilisons beaucoup d'analyses statiques. Et elles sont très utiles pour éviter des bugs. Mais il peut y avoir des bugs. Et nous sommes en train de tester. Ça signifie que vous prendrez quelques configs et vous construirez et vous testez leurs propriétés. Il y a d'autres initiatives, comme l'Ontario de l'Intel ou l'Ontario de l'Ontario de l'Ontario de l'Ontario de l'Ontario de l'Ontario. Ils sont en train de tester les kernels dans l'arch. Un autre problème plus relative à l'objet fonctionnel. Si je vous donne une configuration de kernels, un file de config dot-config peut-il donner la taille de la kernels, de la binary ou de la taille de compression. Est-ce qu'il y a personne dans les rues qui peut le faire ? Oui. C'est un peu difficile. Ce n'est pas juste parce qu'il y a beaucoup d'options et beaucoup d'interactions possibles entre l'option et l'option que c'est difficile d'antécipiter toutes les cases. Mais il y a des configurations et des valeurs d'option qui sont utilisées par des connaissances. Il y a des documentations qui restent d'options qui ont un effectif ou pas, mais en pratique c'est un know-how. Il y a des expériences, des tests et des tests. Le problème général c'est d'améliorer la configuration de l'espace. Donc par améliorer, je veux dire, comprendre les effets de toutes les combinations possibles de l'option sur la date de construction, sur la stabilité, sur le temps, sur la performance, sur la sécurité, etc. Et oui, le problème est le nombre d'options. 15 000 options. Si j'ai fait des statistiques, la plupart des options sont 3 states. Oui, il n'y a pas de modules, donc il peut prendre 3 valeurs. Il y a beaucoup de valeurs de bouillons donc seulement 2. Mais si tu combines tous les deux, ça peut être un grand nombre de configurations. Bon, je suis volontairement exageré ici. Parce que je ne compte pas les constraints. Mais ça vous donnait l'adresse de la complexité. C'est un problème ouvert pour savoir combien de configurations il y a dans les Canadiens. C'est intéressant. Et oui, on va mettre ce nombre en perspective. Une configuration, c'est aussi quelque chose de réel. C'est un kernel que tu dois construire, mesurer, etc. Donc, on va mettre le nombre en perspective. Avec cette nouvelle huge nombre de configurations, c'est beaucoup plus que le nombre estimé dans l'univers. C'est beaucoup plus que le nombre estimé de possible positions de chairs. Shannon a fait une approximation et maintenant c'est 10 à 40 ce qui est quelque chose. Et oui, juste pour faire une comparaison, si on regarde AlphaZero, tu sais, la superintelligence artificielle qui joue un excellent test. Donc, il y a ce nombre de possible configurations qui sont différents. Mais aussi, si on regarde l'exploration de la configuration space, en Linux, il prend 10 minutes d'avantage pour compiler un kernel sur une récente machine. Donc, sur TinyConfig, il y a quelques secondes. Mais ça peut être une heure d'avantage. En chairs et Go, c'est très bien d'explorer la configuration space. Il ne faut pas attendre 10 minutes pour savoir l'arrivée de la position, je dirais. Une autre différence est que dans AlphaZero, il y a un simulateur parfait. Si tu veux mesurer le bon temps, tu vas avoir à répéter peut-être les expériments. Tu vas avoir à attention du hardware. Donc, est-ce que la configuration space de Linux kernel est plus que AlphaZero ? Il est comparé d'autres choses, mais c'est juste de mettre le problème en perspective et de montrer que c'est le nombre de configurations. Mais c'est aussi le cost d'explorer la configuration et de techniquement instrumenter le processus. Ok, tu ne peux pas construire ce nombre de configurations. Ce n'est pas possible. Donc, l'approche d'appuyer est d'utiliser le statistique de l'appuyer parce que c'est vraiment le problème. Les idées sont que tu prends seulement un sample de configuration qui est utilisé comme exemple. Tu trains ton algorithme de la configuration space. Donc, si je prends l'exemple d'une configuration de build ou de fail, ça peut être un problème de classification. Donc, tu construis une configuration, tu observes si c'est un build ou pas. Donc, tu attaches un label à chaque configuration build, failure, build, failure. Et puis, tu peux trainer un classifier qui peut predicter la valeur de l'option de l'appuyer ce qui sera l'outrecomment. Donc, tu prends ça comme exemple de ton algorithme de l'appuyer. Si je prends l'exemple, ça fait la même histoire. Tu peux avoir un corpus de configuration pour lequel tu as la mesure d'intérêt. Tu utilises ce sample pour trainer ton algorithme et puis tu as un new.config peut-être que tu peux predicter dans un de l'accurate façon ce qui sera l'option de l'option de l'option de l'appuyer. Donc, c'est la vraie idée que c'est la direction qu'on a pris. Donc, c'est la grande picture, on a TuxML, c'est une variante de Tuxx qui est capable de predicter le futur, je dirais, d'exagérer un peu. Et, c'est peut-être si il s'est construit ou pas. Il peut être la taille, c'est un bon temps, quoi-même. Dans cette histoire, je vais me concentrer sur le statut de construit et la taille. Mais l'application semble assez générale. Mais, comme research, on était intriguant par cette idée parce que, ok, beaucoup de gens ont essayé cette idée. Ils utilisent la technique de mesurer, mais, à la scale de Linux, oui, on ne sait pas. Donc, comme scientifique, nous sommes très intéressés à savoir si ça fonctionne ou pas. Donc, dans le reste de la taille, je vais vous proposer des résultats que nous avons et comment nous instrumentons le processus, comment nous agirons les données. Je vais vous montrer deux applications. L'une est de construire l'understand et la prévention. Donc, ça peut aider à identifier quelle combination d'options sont responsables d'un failure. Et ça peut être utilisé pour protéger les bugs au niveau de l'intégration. Et l'autre application est la prediction de la taille. Et ça peut être utilisé pour protéger la taille sans l'accompagner. Et puis, je vais conclure avec vous de la discussion sur des défis. Donc, nous avons développé ce tool 2 ans d'arrivée. Il a commencé lentement. Et le set-up bas est comme ça. La configuration. Donc, nous faisons ça dans le large. Et nous utilisons le roundconfig, qui est une utilité dans la source kernel qui est capable de générer un file de configuration consistant de la configuration semantics et constraintes. C'est un bon tool et vous pouvez le coller beaucoup de fois et vous pouvez le conclure. Et puis, nous avons un processus de build qui est automatique, qui compile chaque config et qui observe quelque chose sur le processus de build. Donc, nous observons à un moment, deux choses, qu'est-ce qu'il construit ou pas. Nous collons beaucoup de choses, comme messages de warnings, messages de défaits, ou toutes les messages OK. Et puis, nous collons OK, donc c'est le processus général. Et puis, la idée est que nous avons cette grande table que nous pouvons utiliser pour entraîner un classifier. Et ici, nous pouvons utiliser une machine statistique. Donc, nous avons un outil, c'est l'open source, c'est un GitHub. C'est basé sur Docker et Python. Pourquoi Docker ? C'est parce que nous aimerons un environnement plus prédisable avec tous les outils qu'on a besoin et pour contrôler la version de la fine graine. Et aussi, nous voulons déployer le système sur différentes machines parce que, vous savez, nous ne voulons pas compiler avec ma machine, donc nous devons être smarts ici. Donc, vous pouvez utiliser et populer le database. Donc, ce que nous computons c'est que, à la fin, nous avons une grande database quand nous avons créé des informations sur la compétition de temps, la file de configuration, beaucoup d'erreurs, les warnings, etc. Les compétences de kernel size et beaucoup de compétences de kernel size. Donc, nous avons fait ça pour deux versions de Linux. Donc, nous sommes un peu en date, parce que nous avons commencé et c'est pourquoi nous targetons cette version 4.13.3. Donc, ce n'est pas que nous sommes obsés par cette version, c'est juste que c'était une version stable et intéressante en temps. Et, oui, nous avons cette grande database de 95 000 configurations. Donc, juste pour Linux 4.13. Et nous avons distribué la compétition de la compétition que nous avons à Inria, et nous comptons 15 000 heures de compétition. C'est beaucoup d'investissement, je dirais, même si je ne suis pas payé. Ok? Et nous avons fait ça aussi pour Linux 4.15. Et pour les deux versions, nous restons un peu l'espace de configuration, nous n'avons qu'à targeter et même plus, nous targetons x86 sur 64 bits. C'était notre décision arbitraire. Ok? Juste pour focusser sur l'architecture en temps. Donc, les résultats que nous présenterons sont seulement 4.13. Nous avons d'autres résultats, mais ce n'est pas encore publié. Ok, donc nous avons ces résultats et, oui, nous avons plus de 3000 configurations de faillite. Ça signifie que 6 % d'intérêt de faillite. Donc, doit-on envoyer 3000 reports sur la liste de mail? Non, nous n'avons pas. Nous n'avons pas. Parce que nous regardons un peu pourquoi il y a tellement de faillite. Donc, la première observation, maintenant c'est un peu objeu, mais c'est que, en fait, quand vous avez une configuration de bug, ça peut lead à beaucoup de configurations de faillite. Donc, pour exemple, nous observons un faillite recurrent avec un message recurrent. Il s'appuie plus de 300 fois. Mais c'est dû à la même combination de bug d'option, qui est la vidéo de l'allocateur générique. Si vous faites des valeurs aux options spécifiques, c'est une bonne chose, immédiatement, pour ce genre de faillite. Donc, en fait, vous pouvez summariser un cluster de faillite avec un bug. C'est la première bonne news pour expliquer et louer le numéro. Et, en fait, un état statistique peut automatiquement identifier quelle option peut causer ce faillite. Donc, nous venons de cette conclusion, la vidéo de la vidéo de l'allocateur générique par l'utilisation de l'application statistique. Donc, la principale c'est comme ça, vous avez un état de train, faillite, faillite, faillite, faillite, faillite, et, à la fin de la journée, vous avez une grande matrice, avec 95 rôles, chaque configuration et 12 000 options parce que sur x86, c'est moins, et, oui, peut-être que vous pouvez reconnaître la patte ici, ça lead à un faillite. Donc, c'est relativement, c'est relativement à la vidéo de la vidéo de l'allocateur générique. Donc, bien sûr, comme un humain, vous voulez analyser cette matrice, il y a des outils pour ça. Et, c'est là qu'on applique l'application statistique. Et, il y a beaucoup d'algorithmes là-bas d'une agression clinique pour les networks neurales. Et l'un d'entre nous est la classification parce que c'est un bon traitement entre l'interprétabilité et l'accuracité. Donc, par interprétabilité, je veux dire que vous pouvez sortir de l'application des rôles, dans quel état il faut construire ou de la faillite. Et la classification de la classification, je suis sûr que vous pouvez voir la vidéo de l'allocateur générique. Il s'agit d'une boxe orange qui est une faillite. Et, juste avant, vous observez qu'il y a des autres options. 3 options individuelles Juste d'activer cette option, il s'agit d'une faillite. Je vais revenir à ces quelques minutes. Ok. Ok, donc, on utilise l'application statistique et on trouve que c'est intéressant. Mais l'un des choses qui s'est passé et qui n'était pas si évident c'est que des bugs de configuration peuvent vraiment masquer d'autres bugs de configuration. Donc, je ne sais si vous êtes aware de ça ou si c'est bien connu dans la communauté de Linux. Mais, basiquement, le bug avec la vidéo de la boxe de l'allocateur générique était parfois combiné avec un autre bug. Et donc, c'est un message de faillite. Donc, je ne veux pas entrer dans les détails, mais, basiquement, l'application statistique n'est pas suffisante. Vous devez aussi combiner les messages de faillite ensemble. Et puis, la idée est de considérer que ce n'est qu'une faillite mais que le genre de faillite s'y distingue. Et grâce à ça, on peut identifier des bugs de masque, je dirais. Oui. Mais, c'est un important insight, parce que le trend est vraiment appréhendant. Il y a des configurations avec 3 bugs en même temps, et beaucoup avec 2 bugs en même temps. C'est un problème, non? Donc, Air, Air est la liste. Et maintenant, j'ai une bonne news aussi pour la communauté de Linux. C'est que le nombre de faillite est énorme, c'est parce que nous avons 3 configurations de bugs expliquent beaucoup de la faillite, en fait. Et c'était grâce à notre infrastructure. Donc, on peut dire qu'on est un peu stupide et, oui, nous n'avons pas assez de connaissances sur Linux, mais en fait nous regardons la documentation de Kconfig sur cette option. Et ça a été réveillé avec une nouvelle instruction. Ils reconnaissent qu'il n'était pas bien expliqué comment utiliser cette option, parce que elle réveillait des tools spécifiques. C'était difficile d'antécipiter tout dès le début. Donc, à la fin, il y a seulement 16 bugs de Linux, qui est assez incroyable. Nous avons fait beaucoup de computations, non? Pas beaucoup. Donc, la main lesson d'application, il y a beaucoup plus de détails que ça. D'abord, ne croyez pas sur l'infrastructure de la configuration. Mais je pense que ça peut être une sorte d'application d'approche, comme 0-day ou je ne sais pas si vous avez ce genre de problèmes, que vous avez une sorte de fausse positive. C'est parce que c'est la façon dont vous instrumentez le processus de build. En fait, c'est en train d'appeler beaucoup au-delà de Linux. Il faut vraiment préventer des bugs comme possible. C'est un peu obus. Mais ici, j'ai un argument additionnel, c'est que d'autres fois, vous ne verrez pas d'autres bugs, parce que certains bugs sont dans l'autre. Et avec duxML, on peut avoir un bug d'une manière de compter Si on a un processus de construction, un système d'intégration continue, il peut être smart pour ne pas construire la configuration pour laquelle vous savez que ce sera de plus en plus de défauts. Encore une fois, vous avez perdu beaucoup de ressources. C'est ce que nous avons fait, en fait. Et donc maintenant, nous avons un mécanisme pour anticiper ce genre. Et bien sûr, des fixés peuvent sauver le place, mais ça peut être après un mois, deux mois, ou autre chose. Ok, donc c'est tout pour la première application. Maintenant, j'ai une deuxième application. C'est différent en termes de motivation, mais fondamentale, pour moi, c'est quelque chose d'autre. Donc, il y a beaucoup de discussions sur kernel size. Donc, il y a des points, including at Ampedit Linux conference, il y a eu un bon bif avec Alexander Sack, un très bon talk of Miquel, on boule-t-le en boot-time reduction, et beaucoup de trucs étaient tout de même allés au kernel size. Et je ne sais pas si je peux dire ça, mais j'ai l'impression que personne ne connaît l'effet précisé d'option de kernel size. Donc, il y a des documentations sur Kconfig, mais oui, il n'y a que quelques, et oui, c'est des documentations, donc ce n'est pas vraiment actionnable, je dirais. Il y a des détails dans le papier. Donc, notre idée était, ok, let's use a sampling, measuring, and learning approach. Nous essayons d'entraîner un predictor, un regressor, ici, qui peut predicter une quantité de valeur, qui est le size de la kernel. Et la idée est que, basé sur cela, nous pouvons construire des outils qui souteniront la configuration smarte, je dirais. Donc, basiquement, vous pouvez déactiver l'option, et sans le construire, sans avoir le cost de le construire, vous pouvez déjà savoir ce qui sera le size. Donc, nous pouvons envisager un optimiser, comme, donnez-moi le plus petit kernel, recommandez, comme, vous devriez activer cette option, vous activez cette, bla bla bla, et vous avez votre objectif, ou, c'est, je dirais, un configurateur smarter, que nous utilisons dans le processus de configuration. Notre autre idée est d'améliorer la documentation, d'identifier quelles sont les options influenciales. Donc, nous avons déclenché le processus, je dois être rapide ici, donc, basiquement, nous améliorons le size, et nous améliorons beaucoup, beaucoup de choses. Donc, nous améliorons le size de la Linux, et le size aussi de la size compressée. Et ensuite, nous utilisons un état statistique, avec des mécanismes advancements, nous essayons beaucoup d'algorithmes, et comme un outil, nous avons des numéros sur comment nous améliorons notre modèle, et sur les options influenciales en termes de size. Donc, sur le size, comme je disais, nous améliorons beaucoup de types de sizes, donc, la Linux, et les sizes compressées, donc, bref, bref, bref, bref, je vais commenter sur le size compressé. Donc, ici, il n'y a pas d'application, mais donc, ce sont des resultats ronds. Donc, donc c'est-à-dire, vous savez, il y a beaucoup de options de compressions dans la Linux, donc vous avez l-z, ou l-z, etc. Et ce que nous observons, c'est que, en effet, le XZ est le meilleur dans le termes de rate d'accompression. Donc c'est une sorte d'affirmation. Il y a quelques éléments documents, c'est un peu de fun de comparer les numéros et les insights. Donc si vous êtes intéressé par cet aspect, je peux vous partager le numéro. Mais ça c'est juste un résultat dans le journal. Et ce que nous avons fait c'est de predicter le nombre de lignes de lignes de lignes de lignes de compréhension. Donc ici je vais focusser sur le nombre de lignes de lignes de lignes de lignes de lignes. Donc la distribution est de ce type, la cédert아니 céderte de la cédertiere qui est une de la convivience săle en ça. Gratleness au créateur de la config céderte de la convivience, c'est la stratégie de lignes. Enaji de la config il est tout le monde sur la devine de gérer 4 ou 5 options. Et pour ce maximum, il peut être plus qu'il doit mettre très bien plus de spitale, à la maximum, oui, ça peut être plus que 1 gigabyte, c'est un peu plus, donc vous activez tout, vous débugz, etc., et vous avez ça. Donc la question que nous avons demandé, c'est, est-ce qu'on est accueillis ? Est-ce que nous pouvons predicter les numéros de droite ? Donc la table est un peu technique pour comprendre, mais à la gauche, il y a beaucoup de types de algorithmes pour une très basée liste ordinaire, standard de régression, qui est très basée, deux networks numéros, qui sont assez avancés, et les uns sont plus ou moins interprétables, donc les networks numéros, c'est difficile de ensuite extracter les features, par exemple, et nous utilisons une sélection technique dans laquelle vous n'utilisez pas toutes les options pour faire l'exercice, mais aussi un subset. Et la sélection des features peut être automatisée. Ce n'était pas un knowledge humain, ou c'était purement automatisé. Et nous avons des bonnes news. Donc la première, je pense, est une erreur de production basée. C'est, oui, quelque chose comme 7, qui est, ok, et ça peut être à 5 en fin de compte. Et la autre bonne nouvelle, je pense que la plus importante, c'est que seulement quelques features, quelques options, ont une influence sur la sélection. Et pour la sélection de compression, c'est plus facile de prédire. Donc c'est à peu près 3%. On a des tableaux similaires. Donc ça veut dire que nous pouvons avoir une bonne prédiction, et nous pouvons avoir une vision pour avoir une sorte de configuration smart à l'assisté. La autre importante résultat est que, grâce à notre modèle de prédiction, nous pouvons identifier les options influentales. Donc on utilise des modèles interprétables, bien sûr. Et nous avons une liste, une liste d'ordres. Donc pour VM Linux, la première est « Debug Info ». Ok. Bonne idée. La deuxième est « Yes ». C'est ce que « Yes » veut dire. C'est le nombre d'options qui ont la valeur « Yes » dans le file de configuration. Donc c'est une feature dérivée. Nous pensions que c'était intéressant de le mettre en place. Et c'est la deuxième. Donc ça ressemble à « Abruse ». C'est-à-dire que si vous voulez réduire votre quantité de canal, vous pouvez retirer des options. Vous pouvez mettre « Non, non, non, non, non ». C'est la stratégie la plus efficace, beaucoup plus qu'un tweet que d'autres. Et « Tiny Config » en fait vint pour cette raison particulière. Et « Tiny Config » aussi vint parce qu'il déactivé toutes les options influenciées. Et vous pouvez avoir une liste. Donc nous travaillons sur ça, mais on a confronté notre résultat sur la documentation. Nous avons trouvé une option qui n'est pas documentée et qui a un impact en size. Nous avons aussi trouvé des casques dans lesquels nous avons mis des options. C'est-à-dire parce que nous n'avons pas dans notre data set l'activité de l'option, pour exemple. Donc ce n'était pas la faute de l'entraînement, c'était la faute de l'exploration de l'espace de configuration. Donc ce que nous espérons c'est que nous pouvons augmenter la documentation. Et nous travaillons avec un peu de personnes ici. Et si vous êtes intéressés à nous aider à valider notre résultat et à basicément à augmenter l'knowledge sur les options de configuration, vous êtes vraiment bienvenus. Ok, donc pour summariser, nous avons utilisé l'application statistique pour prédire l'entraînement, pour protéger des bords, pour comprendre des bords. Il y a beaucoup d'interessants, et les résultats ressemblent à la programmation. Mais encore, nous pouvons discuter de beaucoup d'insights. Donc retrospectivement, et en spite de notre énorme quantité de computations, nous avons trouvé quelques bugs sur Linux. Donc, il y a trois hypothèses. La première est parce que la communauté Linux. Je pense que tout le monde est là pour ça. Et oui, c'est incroyable, le nombre de contributaires qui sont là pour un projet d'opinion. Donc ça peut être fait par la raison. Et congrès à vous, congrès à tous les uns, mais nous pouvons aussi avoir d'autres hypothèses. Peut-être que c'est par la version spécifique de Linux que nous avons choisi. Peut-être que c'était trop stable, je ne sais pas. Nous sommes répliquant cet expériment, maintenant. Et peut-être que c'est par la façon dont nous sommes sample. Exactement, nous sommes en train de travailler avec Run Config. Mais Run Config ne produit pas des samples randomes. Et nous savons pourquoi, parce que c'est un problème très difficile de produire des samples randomes parmi les constraints sur les variables Boolean. C'est une grande recherche à faire, maintenant. Mais, bien sûr, Run Config a une grande utilité. Et une autre hypothèse, c'est peut-être que l'effort de test n'a pas trop d'effort sur Run Config. Donc je pense qu'on a besoin de plus d'innovation. Et nous sommes en train d'explorer différemment l'espèce de configuration. Un autre challenge, c'est la course. Voilà. Si nous devons faire tous nos expériments sur chaque comité, sur chaque phase, il n'y a pas de manière. Ok, donc il y a deux idées. L'une est l'incrumentation de la configuration. Parce que, maintenant, chaque fois que nous construisons la configuration, nous commençons de scratch, parce que de la randomité. Et d'être sûrs qu'il n'y a pas d'interference mais peut-être que nous pouvons être smarts ici et avoir un plus d'incrumentation. C'est une idée qu'on investigue. Il peut diminuer l'amount de temps que vous avez besoin pour obtenir le statut. Une autre idée, c'est de transférer le modèle de production. Donc bugs ne transférent pas le moelle parce que les fixations sont rapides, mais on peut espérer qu'on puisse transférer. Je veux dire, on a des connaissances que nous avons utilisées pendant notre temps. Donc, j'espère que nous pouvons transférer notre modèle de production d'une version à l'autre. Il y a des techniques ici et on peut réduire la coste drastically. Une autre challenge, c'est que... Je suis très connu avec la communauté. Je trouve que le CRNLCI initiative est incroyable. Oui, nous devons vraiment avoir une initiative intégrée pour collecter des données. Notre focus est beaucoup plus dans la configuration de la large. Et on croit aussi que la technologie de formation peut être utilisée pour le CRNLCI sur un jour à l'autre. Donc, nous cherchons les données et nous cherchons nos données et nous utilisons vos données. Donc, on peut unifier la force. Et bien sûr, il y a d'autres propriétés qu'on veut predicter. Beaucoup de données. Beaucoup de données de sécurité. Donc, pour quelle définition de sécurité que vous avez, nous avons aussi des données intéressantes sur les warnings. Il y a beaucoup de warnings qui passent. En fait, 90 % de la configuration sont souhaitées pour les warnings. Donc, et des messages différents. Et ce que nous pensons est que ce n'est pas seulement sur la formation et c'est vraiment en communiquant les résultats avec la communauté et aussi nous avons besoin de la communauté pour aider la formation. Par exemple, vous avez besoin d'une certaine connaissance pour appliquer la sample smart. Parce que vous savez que certaines options sont intéressantes à regarder. Ou vous avez des connaissances sur les options importantes et vous pouvez valider la prediction. Donc, nous avons besoin de vous. C'est tout. Je suis en train de sortir de l'heure. Mais on peut avoir des questions, peut-être. Je utilise tout mon temps pour présenter tout. Je suis très désolé pour ça. Mais nous pouvons avoir des questions. Donc, merci, c'est tout pour ce talk.