 Bonjour à tous et bienvenue à cette présentation qui commence dans quelques minutes. Accueillez notre présentatrice, Mindy Preston, qui travaille sur le projet MirageOS et qui vous parlera aujourd'hui des systèmes de clotation sous forme de librairie. Si vous êtes du genre, si c'est Docker et que les systèmes trop lourds, c'est pas votre truc. Applaudissement pour Mindy. Bonjour, merci. Si vous ne pouvez pas lire ça, dites-le maintenant, mais on dirait que ça marche. Alors aujourd'hui je vais parler des différentes façons qu'on a d'utiliser des systèmes de clotation sous forme de librairie pour rejeter la réalité actuelle ou les abstractions actuelles et mettre les notes à la place. Donc rapidement le plan que je vais c'est aujourd'hui, cette présentation partie de la résilience de cette conférence, c'est une nouvelle piste et je pense que la résilience, c'est quelque chose qui est très important par rapport au travail qu'on fait nous sur les unies carnelles. Et je parlerai des choses et des propriétés qu'un projet peut avoir pour être plus robuste, plus résilient. En particulier, je vais parler de est-ce que les projets, c'est des choses qu'on peut comprendre. Ensuite je vais parler de ce que je considère comme la pire des dépendances qu'un projet peut avoir, qui est ainsi une clotation inutile. Je vais parler ensuite de comment on peut remplacer cette clotation par des librairies qu'on choisit et qu'on décide d'utiliser. Et enfin je parlais de comment est-ce qu'on peut améliorer la résilience d'un projet en choisissant ces librairies de façon consciente. Et comment est-ce qu'on peut améliorer le processus de développement comme ça. Alors il y a deux concepts très importants à mes yeux pour la résilience d'un projet. La première c'est combien d'humains peuvent disparaître avant que le projet arrête d'avancer. Alors ça ça a un nom, on appelle ça le bus factor en anglais, ou bus number. Et la façon simple d'augmenter ce bus number c'est assez simple et il suffit d'ajouter plus de gens qui travaillent dessus et de les avoir avec assez de connaissances chacun pour que si un entre disparaissent ce soit pas grave. Mais c'est pas si simple parce qu'on peut pas dire juste quelqu'un qui travaille ou qui connaît ce projet connaît suffisamment pour garder ce projet actif et faire en sorte que ce projet continue à exister. Donc une façon de faire ça c'est de rendre le projet plus simple à comprendre. Ce qui fait que les gens en général entendent ça savoir suffisamment pour que le projet continue à avancer. Mais il y a une chose importante, un projet c'est pas juste le code qu'on a écrit. On peut pas simplement tout refactoriser et tout documenter et utiliser que certaines fonctionnalités de langage. Donc il y a d'autres choses, par exemple il faut penser au langage qu'on utilise pour programmer et toutes les choses comme comment est-ce qu'on interagit avec ce code, comment est-ce qu'on le compile, ou est-ce qu'on l'exécute, de quels outils on a besoin pour l'utiliser d'une façon qui fait sens. Notre projet c'est pas juste le code qui est dans notre repository, c'est aussi toutes les choses dont il dépend. Et vous vous dites peut-être, mais mon projet il n'a pas vraiment de dépendance où il y en a très très peu, elles sont très simples, je les comprends, c'est pas un problème. Et moi ce que je vais vous dire c'est que c'est probablement pas vrai. C'est très probable que vous ayez au minimum une dépendance extrêmement lourde dans votre projet qui est un système d'utilisation conventionnelle. Alors j'ai fait ici un petit diagramme en Asciart qui montre comment est-ce que moi je pense, comment est-ce que moi je vois une application, ses dépendances et l'OS. Et si on met toutes ces choses dans la même catégorie et qu'on dit j'ai besoin de toutes ces choses là. Dans ce diagramme j'ai un petit peu triché, on peut dire à cette dépendance elle est vraiment grosse mais de fait elle est vraiment grosse. Le système d'utilisation c'est quelque chose de très très gros. C'est probablement quelque chose qui contient plein de choses dont vous n'avez pas besoin et la façon dont vous avez, la façon que vous avez d'interagir avec c'est d'une façon qui est unique. Vous n'interagissez pas avec d'autres choses que cette OS de cette façon là. Vous ne pouvez pas débugger votre système d'utilisation de la même façon que votre code. Vous utilisez des outils complètement différents. Et quand vous écrivez du code qui s'interface avec le système de notation ça utilise probablement des API qui n'ont rien à voir avec les API que vous utilisez quand vous faites du code au niveau de l'application. Pour vous donner un exemple concret. Voilà des extraits de la page de manes sur les sockets dans les nukes. Donc là on a la signature de la fonction. Donc la fonction c'est socket qu'on appelle dès qu'on veut faire quoi que ce soit avec du réseau. Et ce cas prend un nom qui est un peu magique et un autre nom qui est un peu magique et un autre nom qui est un peu magique et ça nous donnera un autre nom qui est magique ou alors un autre nom qui est magique qui nous dit qu'il y a une erreur. Et pour interpréter ce nombre magique il faut lire ailleurs une liste de nombres magiques. Si vous programmez dans des langages qui ne sont pas assez c'est probablement pas le langageté. C'est probablement des choses qui sont pas du tout idiomatiques pour vous. Mais ce qui est pire c'est que ce nombre magique qu'on récupère à partir de ce quête on doit le passer à une autre fonction connect qui va prendre encore d'autres nombres magiques et qui va retourner encore d'autres nombres magiques pour nous indiquer les erreurs. Donc vous pouvez vous dire ok bon si je fais des développements d'application et que vous dites l'application elle est mauvaise parce que l'interface est mauvaise parce que c'est du C Utilise passer c'est un langage de bas niveau c'est normal. Mais en fait même dans un langage du plus haut niveau on voit ce genre d'API. Par exemple ça c'est du camel, de l'eau camel, un langage que moi j'utilise très souvent. C'est un langage qu'on peut considérer quand même étant de plus haut niveau et à plus part des gens seront d'accord avec ça. Donc je vais résumé très rapidement comment on peut lire les signatures de type en eau camel. Voilà donc ça c'est la fonction équivalente à ce quête qui s'appelle de la même façon. Ce qui est plutôt pratique c'est une fonction qui prend un paramètre des arguments. Donc ça c'est les types des arguments. Le type socket domain c'est aussi un nombre magique mais il est restreint à seulement quelques valeurs possibles. De même pour socket type c'est aussi un nombre magique pour le type de protocole. Mais au moins dans la documentation on nous dit 0 c'est la valeur par défaut et des chiffres pour d'autres choses. Et ça nous donne un type file descriptor qui sous les couvertures c'est aussi un nombre magique mais on ne le voit pas. Et en cas d'erreur on récupère une exception. Et si vous avez programmé en eau camel ou dans pas mal de langages quand vous voyez des choses qui jettent des descriptions c'est généralement pas très bien parce que connect c'est quelque chose qui peut échouer dans beaucoup de cas. Et connect c'est encore pire puisque ça va prendre notre descripteur de fichier qu'on a pris. Ça prend un socketaire et ça ne retourne absolument rien. C'est l'équivalent de void en C. Ça nous dit ici j'ai fait quelque chose j'ai fait des effets de bord t'inquiète pas de ce que ça fait. Et dans ce cas ça peut aussi nous faire une exception qui se contente d'enrober l'information qu'il y avait dans ERNO qui venait dans la PIC. Et ça c'est quelque chose qui n'est pas du tout intéressant ou amusant pour programmer en eau camel. Mais on peut très facilement voir pourquoi est-ce que cette API ressemble à ça. C'est simplement une adaptation et une très fine couche au-dessus de l'API qu'il y avait en C. Donc il n'y a pas grand chose qu'on peut faire ici quand on est dans cette situation et qu'on veut s'interfacer avec le système de causation. Si on avait une application de plus haut niveau on pourrait faire des abstractions plus utilisables et ça ça nous rapporterait plus des idiomes qu'on utilise quand on développe du niveau applicatif. Mais quelque part dans les couches basses on est obligés de passer par des API comme ça. Et si on ne voulait pas faire ça tiens. Alors dans le monde d'open source on pourrait dire ok moi j'aime pas cette API donc je vais la changer moi-même. Et je vais dire c'est quelque chose qui n'est pas facile pour la plupart des gens qui veulent juste écrire du code qui veulent faire tourner. Si je veux changer les interfaces du kernel et faire quelque chose. Bon déjà il faut que j'apprenne le langage de programmation du kernel qui est peut-être pas le langage que l'on utilise tous les jours. Il faut ensuite que j'apprenne comment est-ce qu'on programme dans le kernel ce qui est une compétence assez importante et que je n'ai probablement pas. Ensuite il faut que je fasse un patch de bonne qualité pour ce code et que je trouve un moyen de le faire accepter. La communauté à laquelle je vais devoir parler pour faire ça c'est pas la communauté à laquelle j'ai l'habitude de parler c'est pas la communauté de mon projet ou de mon langage. Il y a des normes et des processus différents pour parler à cette communauté et cette communauté est probablement pas spécialement intéressée par ce patch que j'ai fait pour mes propres besoins pour mon propre langage. Le kernel n'a pas besoin de savoir ce que je fais dans le user space et qui ne m'intéresse que moi. Et si vous pensez que c'est juste moi qui me plaint qui dit « c'est difficile le programme pour le kernel » je veux dire, il n'y a pas que moi. Vous avez peut-être entendu parler du challenge EDIPTULA qui était une série d'exercices pour apprendre à programmer le kernel Linux. C'était fait entièrement par correspondance à distance. On commençait par créer des modules pour le kernel très simples. Et puis on envoyait un patch qui résolvait le challenge et on recevait le challenge suivant et on pouvait travailler dessus. On peut prendre du temps. Les gens prenaient le temps de lire le code qu'on avait fait avant de nous envoyer le suivant. C'était une vraie revue. Donc il y avait un bon challenge. Il y a à peu près 19 000 personnes qui avaient commencé dont moi. Il y a seulement 160 personnes qui l'ont terminé, pas moi. Et ce que je dirais c'est qu'on a 1% de succès sur ça ça indique probablement que c'était déjà motivé. Donc 1% de succès seulement ça indique probablement qu'il y a un vrai problème dans la difficulté de faire quelque chose. Et puisqu'on parle de résilience, je voudrais dire quelque chose de plus. Les gens qui travaillent sur votre projet veulent peut-être éviter de s'exposer aux communautés qui sont connues pour être hostiles ou toxiques. Ils ont décidé d'être dans votre communauté, ils n'ont pas décidé dans toutes les communautés des dépendances de votre projet. Et ça, une façon de nous protéger nous-mêmes et les membres de ça c'est d'éviter d'exposer les membres de nos projets à des communautés dans lesquelles ils ne se sentent pas forcément en sécurité. Il y a des communautés comme par exemple je ne vais pas citer mais il y a des carnelles monolithiques assez connues dans lesquelles les communautés sont connues pour être plutôt toxiques. Ça c'est plutôt embêtant mais réfléchissons un peu. Qu'est-ce que l'OS fait pour nous au final ? Je vais zoomer un petit peu et on va regarder un petit peu le diagramme de tout à l'heure plus en détail avec notre application, dépendance et ce qu'il y a de dents. Comment est-ce qu'on communique avec les choses qui sont en dessous, plus bas dans la stack ? Et quelque chose de crucial, j'ai mis ce dernier bloc ici. D'habitude quand on déploie des applications dans ce contexte où on a un OS sur lequel on tourne l'OS généralement tourne pas directement sur ce qu'on considérera du matériel nu. Généralement il y a une couche de virtualisation, un hyperviseur. Cet hyperviseur, ça dépend comment on réfléchit à ça mais généralement c'est quelque chose qui est très bas niveau et qui en dessous de l'hyperviseur il y a encore de la gestion des ressources physiques. Donc ce qu'on voit du point de vue de l'application c'est que l'OS s'occupe de tout ce qui est scheduling, gestion de la mémoire, réseau, ces nouveaux fichiers, horloge, vidéo, etc. En vrai l'hyperviseur est responsable de ça dans la plupart des cas, dans la plupart des environnements. Donc ce que fait le système d'exploitation en général c'est qu'ils se contentent de passer les appels à l'hyperviseur pour ces choses-là ou alors ils se contentent de désagréger un petit peu les ressources pour les offrir de façon un petit peu plus fine aux applications. Alors, et si on pouvait parler à l'hyperviseur directement et si on pouvait avoir ce même genre d'interface virtualisée que l'OS reçoit de l'hyperviseur quand ils tournent dans ce contexte virtualisé et si on utilisait des librairies pour faire ces choses que normalement le kernel ferait pour nous. Des choses comme, par exemple, le réseau c'est pas juste il faut que je mette ce paquet sur une carte réseau, il faut d'abord que je crée ce paquet que je gère des flots TCP, que je fasse des requêtes DNS et pour le disque, voilà, j'ai pas juste mettre ces bits quelque part dans ce secteur du disque, généralement il y a quand même le système des fichiers. La façon qu'on a de gérer l'horloge c'est pas juste donne-moi l'heure. Mais on peut implémenter ces choses dans des librairies qui sont écrites dans les langages qu'on a l'habitude d'utiliser et qu'on sait utiliser. Et une fois qu'on a ça, on peut décider que les morceaux compliqués d'un OS classique, par exemple, tous les pilotes, ce qui en fait est faux parce que quand il y a un hyperviseur, les pilotes sont très simples et ça on peut simplement les remplacer par des petits bout de code dans un langage qu'on connaît. Et ça, c'est un concept qu'on appelle un unicarnel. Donc je vais vous montrer quelques exemples de à quoi ces librairies peuvent ressembler. Et je vais prendre, pour exemple, Mirage OS, qui est le unicarnel, la 6e application librairie que moi j'utilise. On a des définitions communes, donc on dit ce qu'on appelle des types de modules, qui nous permettent de dire si tu es une horloge, tu dois avoir ces fonctions là que le gens peuvent appeler. Si tu es un système de réseau bas niveau, tu dois avoir des fonctions pour envoyer un paquet. Si tu es un module qui implemente TCP, tu dois avoir quelque chose qui permet de gérer des flux TCP. Et on a plusieurs implementations de chacune de ces interfaces. Par exemple, on a des exemples types spécifiques de systèmes de fichiers ou de piles pour le réseau, ou des façons de gérer le réseau sous divers hyperviseurs, ce qui permet dans le code applicatif d'être générique et ensuite de le compiler pour une cible précise sur laquelle on va réellement tourner. Alors regardons cette fonction dont moi je me planisais tout à l'heure quand on regardait les pages de man dans la PI en C et dans l'interface au camel qui se basait sur la PIC. Dans Mirage OS, on a un type de module TCP qui dit je dois exposer cette fonction create connection qui prend un paramètre donc la signature de type, cette fonction est plus idiomatique en OCaml, ce qui est un petit peu plus difficile à expliquer si vous n'êtes pas un développeur OCaml, mais je vais tenter de l'expliquer quand même. En OCaml, on a généralement un contexte ou un état pour les choses, une chose qu'on appelle généralement T. C'est le type de l'état dans lequel on se trouve quand on va envoyer des choses sur TCP. On va prendre en paramètre une adresse IP et un port et le type de retour pour ça c'est soit un flow TCP, une connexion et les détails de fonctionnement seront fournis par le reste de la programmation de ce module TCP ou alors ça peut retourner une erreur dont les valeurs sont limitées ici ce type de retour flow error ça dit soit j'ai un flux, soit j'ai une erreur et si j'ai une erreur ça me dit qu'elle est l'erreur et ça c'est paramétré sur IO qui est un type de concurrence puisque cette opération peut bloquer et du coup on expose des moyens pour faire du multitouch coopératif facilement et sans utiliser trop de ressources donc cette signature de type en particulier utilise également quelque chose qui a été ajouté assez récemment à la librairie standard d'OCaml ce type de retour en particulier avant c'était quelque chose qu'il fallait implémenter soi-même mais récemment sur la version 403 d'OCaml ça a été ajouté en standard excusez moi je reviens à ce qu'on avait avant donc on a pu changer toutes ces signatures de type de module qui avaient avant des types spécifiques des types maisons pour les retours et maintenant on peut utiliser des types standards donc ça c'est quelque chose que j'ai pu faire quelques mois seulement après que cette fonctionnalité est ajoutée à OCaml ça c'est quelque chose que vous ne verriez pas en général dans la plupart des cités d'influitation les API doivent rester stables sur des années pas des mois on regarde un peu l'implémentation si on regarde ce que fait Create Connection en OCaml ça crée pas des buffers, ça ne touche pas de l'état global ça se contente de dire ok donne-moi la connexion TCP donne-moi l'adresse et le port je vais créer un PCB pour ça et si ça marche je te donne le flux de connexion sinon je te dis quel erreur j'ai récupéré donc comment est-ce qu'on peut assembler ça comment est-ce qu'on peut les utiliser en pratique on a, ce que je vous ai montré jusqu'à présent c'est conceptuellement une façon d'utiliser ces implementations différentes et qu'est-ce qu'elles sont mais ce qu'on peut faire dans MirageOS c'est prendre l'application que l'utilisateur veut faire tourner, une liste de dépendance une liste d'implémentation qui peuvent satisfaire les dépendances pendant le processus de compilation et ça on peut remplacer on peut aussi des implementations qui se contentent d'utiliser les API du système d'utilisation si on tourne sur un système d'utilisation ou alors on peut avoir une machine minimaliste qui tourne directement sur les hyperviseurs que j'ai montré à quelques slides donc ça peut tourner sur des hyperviseurs différents et je vais montrer une démo par exemple de à quoi ça ressemble d'interagir avec ça donc là j'ai une page web donc j'ai une application web, une web app donc cette web app tourne dans un unicarnel MirageOS il y a une liste de choses dont il a besoin ça c'est le document de configuration de l'unicarnel qui inclut de l'information sur comment est-ce que je veux utiliser le réseau par exemple donc là je dis donne-moi une stack IPv4 l'utilisateur pourra décider au moment de la compilation comment est-ce qu'il veut avoir un IPv4 ça ça dit qu'est-ce que je vais faire donc je vais avoir un serveur HTTP, je vais utiliser TLS là je peux personnaliser un petit peu les ports là j'indique où est-ce que je vais récupérer mon certificat pour la connexion TLS un peu plus de configuration pour les ports HTTP ça c'est des paquets dont j'ai besoin au niveau applicatif donc par exemple la gestion d'URL ou des choses comme ça et là on a quelques propositions qui disent assemble tout ça j'ai besoin de quelques autres trucs de l'OS j'ai besoin d'une horloge compatible POSIX j'ai besoin de deux choses une pour pouvoir recevoir les informations qui me disent qu'est-ce que je dois servir et une pour pouvoir charger mes certificats et c'est bon la logique en elle-même de mon application est dans ce fichier Dispatch je vais pas le montrer parce que c'est pas mal de camel et c'est pas vraiment ça dont je veux parler ce dont je vais montrer c'est comment ça s'utilise donc quand j'appelle Mirage Configure ça me dit ok j'ai regardé ce qu'il y a dans cette configuration et la liste des choses que tu as dit que tu voulais et moi je vais voir comment est-ce que je peux assembler tout ça donc ça me génère un make file moi je vais taper make, ça va compiler mon application et ça ça me fait un binaire qui s'appelle made.native je peux le lancer et on peut voir que j'ai ma page web merci alors et si on faisait un unique Arnais avec ça ce que je vais vous montrer là c'était je peux le déployer sur Google Cloud Google Cloud ça veut les perviseurs sur Google Cloud veulent quelque chose qui peut parler à Virtaio donc je vais dire à Mirage fais-moi un unique Arnais qui marchera dans cet environnement fais ça donc je le compile et maintenant ce que j'ai c'est ce fichier HTTPS.virtaio que je vais vous montrer plus en détail donc j'ai 16 megawatt et ça ça représente une machine virtuelle entière qui va servir ce site web là vous pouvez dire 16 meg c'est gros enfin c'est juste un site web mais là j'ai tout le contenu de cette page qui est dans un système de fichiers en mémoire donc c'est une des raisons pour laquelle ça prend la place et une chose que je devrais dire pour ajuste c'est que le fichier que j'ai construit pour Linux bon là c'est un lien mais je vais vous montrer la taille du fichier qui tourne sous Linux et ce fichier en fait est plus gros donc j'espère que que je vous ai au moins donné envie de regarder un petit peu pour vos projets, est-ce que ce serait quelque chose d'intéressant d'utiliser un OS sous forme de librairie et j'espère que vous bosser dans un langage qui vous plaît suffisamment pour que vous vous disiez ah ça serait cool d'utiliser ce langage pour construire des choses qui ressemblent à la 6e installation et ce que j'espère c'est aussi que je vous ai convaincu que utiliser ces langages de haut niveau et les outils qui vont avec c'est des outils adaptés pour ce que vous voulez faire et pour construire des systèmes d'opploitation dans les OS librairies il y a des idées intéressantes le ROM kernel c'était un projet qui avait commencé dans la communauté NetBSD et le but c'était de faire en sorte que NetBSD soit un petit peu plus comme une librairie et la personne qui a pris le temps de faire ça a tweeté récemment que l'idée originale c'était de rendre possible de débugger et tester les pilotes dans le kernel puisque c'est quelque chose de très difficile mais si c'est une librairie on peut probablement lancer beaucoup plus de codes en user space et utiliser le debugger c'est beaucoup plus facile d'analyser ce qui se passe donc c'est beaucoup plus facile en général de travailler avec donc les tests qu'on écrit pour Mirage OS c'est des tests tout à fait classiques qu'on écrirait pour n'importe quel code au camel ça c'est un test qui vérifie quelque chose qui est assez facile de rater qu'on implemente TCP c'est du code qui bidouille des bits à droite à gauche dans les paquets TCP donc c'est facile de se planter et ce test vérifie que c'est bon c'est une feature du code ennuyeux de le lire et lancer ce test c'est quelque chose qui est aussi ennuyeux, il n'y a rien de remarquable à propos de ça c'est comme on exécuterait n'importe quel test n'importe quel test en au camel il n'y a rien de spécial il n'y a pas besoin de mettre un environnement spécial ou magique autour de ça une autre fonctionnalité quand on utilise une librairie pour notre OS c'est qu'on peut la remplacer en général on va utiliser une implementation qui nous fournit quelque chose qui marche bien mais par exemple pour du test j'ai envie d'avoir quelque chose qui est cassé j'ai envie de voir ce que mon application fait quand quelque chose ne se passe pas comme prévu dans Mirage OS on a plusieurs implementations amusantes en tout cas si vous aimez casser les choses c'est amusant comme des interfaces réseaux qui ont toujours des nouveaux paquets en attendant vous pouvez avoir des générateurs de nombre aléatoires où on peut toujours fournir des nombres prévisibles ce qui est difficile à faire au niveau de l'OS normalement là on peut fournir une liste de nombre aléatoires qui sera retournée quand elle est à l'avance on peut avoir aussi des sources d'entropie qui bloquent toujours c'est assez intéressant il y a beaucoup d'applications qui ne marchent pas si le système de fichiers est plein les disques sont occupés ou alors vous pouvez aussi avoir des applications qui font des choses stupides si votre DNS a été détourné et ça c'est facile à tester quand les parties du système de fichiers sont juste des modules que vous pouvez remplacer à la volée vous pouvez implémenter ce que vous voulez et penser que c'est cool il y a d'autres choses qu'on peut faire qui sont peut-être moins évidentes dans un OS on a beaucoup d'étagues globales et la façon qu'on a d'interagir avec cet état pour voir ce qu'il se passe c'est qu'on ouvre un shell et on bidouille on regarde différents fichiers dans Slashprock par exemple pour voir ce que ça fait dans un unicarnel on a accès à l'état que ces modules maintiennent on peut voir comment est-ce que cet état est mis à disposition de l'application au lieu d'avoir à débuguer en disant je sais pas pourquoi mon application fait ça on peut réfléchir en disant il y a quand même beaucoup d'étagues globales dans notre OS qui affectent la façon dont l'application tourne ici on peut avoir l'OS qui nous dit directement quel est l'état et pourquoi elle est dans cet état on a essayé des choses intéressantes en utilisant cette libraire qui s'appelle Hermine qui est un système de stockage distribué et ça fournit des interfaces qui ressemblent beaucoup conceptuellement à Git et ça nous permet de voir et si tout les changements qu'on fait à l'état du système de production avaient un message de comite à chaque fois que je change quelque chose dans l'état de l'OS je dois dire pourquoi et du coup on a la liste de tous les pourquoi et maintenant quand j'ai un état que je comprends pas dans mon OS je peux voir pourquoi ça a été changé quand ça a été changé on a aussi dans les applications dans les OS des schedulers donc dans mon OS librairie je peux le remplacer et un de mes collègues Thomas Leonard a écrit un visualiseur pour le scheduler donc ça permet de voir exactement toutes les décisions que le scheduler coopératif d'Amirage OS fait et pourquoi pourquoi ce qu'il a donné la priorité à tel thread, pourquoi tel thread ne s'est pas exécuté et on peut le voir graphiquement en deux dimensions, c'est super pratique donc ok tu m'as convaincu j'ai plus besoin de l'OS mais j'ai quand même besoin de l'hyperviseur et l'hyperviseur c'est pas quelque chose de petit c'est quand même une grosse dépendance donc qu'est ce que tu en dis c'est malin et bien ce que je dirais c'est qu'on peut aussi faire des trucs avec les hyperviseurs il y a un projet très intéressant solo5 qui a un composant UKVM et ça ça prend une liste de dépendance que sont les périphériques et ça ça permet d'avoir un hyperviseur qui expose uniquement les périphériques nécessaires par exemple si j'ai pas besoin de réseaux mon hyperviseur ne m'exposera rien qui est en rapport avec le réseau je m'attraie des liens je pense que c'est un projet vraiment cool, vraiment intéressant et puis on a d'autres efforts sur lesquels on bosse d'avoir le support de plus d'hyperviseurs pour que vous puissiez faire tourner plus d'hyperviseurs sur plus de test-hop et on travaille aussi à apprendre ces librairies et puis aller faire tourner en dehors de nos librairies OS vous pouvez les utiliser dans du code utilisateur, il n'y a rien qui vous limite à le faire tourner ailleurs on a beaucoup travaillé aussi avec Qubes OS donc ça c'est la deuxième notation pour pc individuel c'est ce que je fais tourner sur mon laptop, les slides que vous voyez tournent là-dessous et ça c'est un hypervisor et ensuite ça a des VMs qui permet de vraiment isoler les différentes choses que vous faites tourner un des problèmes de Qubes OS c'est que avec des OS standard il faut utiliser beaucoup beaucoup d'espace disque pour stocker toutes ces images de VM on peut partager un peu de données mais c'est quand même beaucoup de mémoire aussi qu'il faut utiliser ce serait bien d'avoir quelque chose de plus léger en termes de taille, en termes d'utilisation de RAM nous on a beaucoup de projets en cours pour remplacer des petits morceaux de Qubes OS qui tournent à l'heure actuelle sur des grosses machines Linux et pour les remplacer par des unicarnels très léger, un des trucs qui marchent bien c'est le firewall de Qubes OS avant c'était une VM Fedora qui avait besoin de quelque chose comme 2 giga de RAM non pas autant 500 mega octets de RAM et je l'ai remplacé par un unicarnel qu'on a besoin de 32 mega octets on a d'autres projets sur les Columbus, si ça vous intéresse vous pouvez remontrer les slides après et vous pouvez ajouter vos idées ici il y a plein de trucs intéressants à faire qu'on peut faire avec les OS librairies il y a beaucoup d'espace à explorer ça m'intéresse beaucoup d'entendre vos idées je pense qu'on a sûrement le temps pour une question merci beaucoup pour votre attention merci Mindy on a le temps pour une question effectivement et on va prendre celle du signal engine non pas question de l'interne pas de question qui vient d'IRC donc une question qui vient du micro numéro 1 est-ce que vous avez essayé d'utiliser des langages basés sur QWERTYC comme par exemple le projet Emili qui utilise des versions de camel qui font une meilleure isolation entre les processus ce qui permet de raisonner plus simplement sur quel morceau d'une application peuvent avoir de l'état alors je n'ai pas essayé je connais Emili mais je savais pas qu'il y avait cette fonctionnalité intéressante donc je regarderai ça, merci beaucoup ok, c'est tout pour le temps, si vous avez d'autres questions vous pouvez trouver Mindy en dehors de la salle merci Mindy, ton air d'applaudissement s'il vous plaît