 Hey, wonderful. Good morning to all of you on day four. I hope you made it through last my office. Und hiermit begrüßen wir auch ich auch aus der Übersetzkabine. Du hast gleich den Talk Library Operating Systems, also Library Betriebstheme vom 34. Chaos Communication Congress in der Übersetzung von Problem und Florian. Der Solution für, well, if you're dabbling in micro services. Verscheid noch mal auf den Saalton, bis der Talk wirklich losgeht. Okay, der Talk geht schon los, dann lassen wir das. Ein warmer Applaus. Hallo, thank you. Hallo. Wenn ihr das nicht lesen könnt, dann setzt der Zeitpunkt laut zu rufen, dass ihr es nicht lesen könnt. Heute rede ich mit euch über Library Operating Systems und wie man die benutzen kann, um die Standard-Realität, die da draußen so umläuft, durch unsere eigene zu ersetzen. Über was ich heute alles reden werde. Dieser Talk ist im Resilience Track, was ja einer der Tracks beim Congress ist dieses Jahr. Und mir geht es darum zu vermitteln, warum das Konzept von Resilienz sehr wichtig ist im Bereich Library Betriebssysteme und welche Eigenschaften ein Projekt haben kann, die dazu führen, dass es resilient ist, also widerstandsfähig ist. Ich spreche außerdem über das, was ich denke, was die aller schlimmste Dependency in eurem Projekt ist und wie ihr diese schlimmste Dependency, die meiner Meinung nach das Betriebssystem ist, durch etwas weniger schlimmer ersetzen könnt und wie ihr Widerstandsfähigkeit erhöhen könnt in dem wir einfach gute Software Tools aus dem wir dieses Betriebssystem zusammenbauen. Das wichtigste Konzept für mich, um zu entscheiden, wie widerstandsfähig ein Projekt ist, ist die Anzahl Menschen, die verschwinden können, bevor das Projekt stirbt. Das ist häufig bekannt unter dem Namen Busnummer, Busfaktor. Und wenn wir die erhöhen wollen, ist die relativ einfache Antwort, dass wir einfach, wenn wir mehr Menschen brauchen, dann müssen wir einfach mehr Menschen in das Projekt reinbringen. Aber, dass es in der Praxis dann tatsächlich gar nicht so einfach, denn ein Mensch, der an dem Projekt mitmacht, ist zumindest im Kontext von dem Projekt sehr fähig und diese Fähigkeiten zu erlangen, erfordert, dass wir das Projekt einfach zu verstehen machen. Und unser Projekt ist nicht nur unser Code. Also wir können zwar viele Refactoring anwenden, alles, ja, überall Best Practices anwenden, Dokumentationsschreiben, etc., aber es geht auch darum, in welcher Sprache unser Code geschrieben ist, wie wir tatsächlich mit unserem Code interagieren, wie wir ihn bauen, wo wir ihn ausführen, welche Sachen wir brauchen, um unseren Code tatsächlich auf irgendeine Bedeutung voller Art und Weise zu benutzen. Und unser Projekt ist eben diese ganze Liste dieser Dinge auf das Verabhängen. Und selbst wenn wir über Dependencies nachdenken und sagen, wir haben eigentlich gar keine, unser Projekt ist eigentlich einfach, da würde ich sagen, das ist eigentlich nicht so, denn es ist ziemlich wahrscheinlich, dass ihr eine ziemlich große Dependency habt, nämlich das konventionelle Betriebssystem, auf dem er läuft. Ich habe hier ein schönes Asciatiagramm gemacht, wie ich denke, wie man über ein monolithisches OS nachdenken muss. Und in diesem Diagramm habe ich mir etwas einfach gemacht, dass klassische Dependencies gar nicht so wichtig sind und wir schauen jetzt vor allem auf das Betriebssystem, denn das Betriebssystem ist ziemlich groß. Es hat in der Regel deutlich mehr Kram, als er tatsächlich braucht. Und man interagiert damit anders, als mit den üblichen Dependencies, den man sogar den Doku legt woanders. Man interagiert mit ihm anders. Man kann es in der Regel, wenn er nur anders debaggen, als den anderen Code, den er so schreibt. Wenn ihr Code schreibt, der darauf zugreift, nutzt ihr tatsächlich wahrscheinlich andere Apis, um darauf zuzugreifen. Und als Beispiel schauen wir uns mal Linux an. Als konkretes Beispiel gebe ich euch einen Abschnitt aus Mann 2 in Linux. Die Signatur für die Funktion ist hier. Das ist Socket. Das ist das erste, was wir aufrufen wollen, wenn wir hier Netzwerk-Kommunikation machen, machen Wochen. Socket möchte eine magische Zahl, eine magische Zahl und noch eine magische Zahl. Und es gibt uns eine andere magische Zahl zurück. Oder noch eine andere Zahl, um uns zu sagen, dass ein Fehler ist und dass wir woanders gucken muss, was der Fehler ist. Das ist vermutlich nicht das, was ihr gewöhnt seid, wenn ihr irgendwelche externen Sachen macht mit einem netten Interface. Und was noch schlimmer ist, diese magische Zahl, die wir von Socket zurückgekriegt haben, das müssen wir eine andere Funktion weitergeben, dass wir noch einen ganzen Haufen Sachen mit magischen Zahlen machen, dass es diesen seltsamen Out-of-Band-Fehlermeldungen gibt. Man sagt, okay, wenn man Applikationsentwicklung macht und euch beschwert, dass das C-Interface schlecht ist, dann ja, das ist das C-Interface. Und es ist nicht das, was ihr in eurer Higher-Level-Languages benutzt. Aber hier, das ist die Sprache, in der ich meistens arbeite. Das ist eine funktionale Sprache mit vielen interessanten Eigenschaften. Es wird von meisten Leuten als eine höher-levelige Sprache als C angesehen. Aber ich gebe euch hier eine kurze Tour durch die entsprechenden Funktionen in Okamel. Das ist hier Socket. Das ist auch eine Funktion. Das nimmt eine paar Argumente und verschippt einen Teil. Typen, der erste Typ ist Socket-Domain. Es ist auch eine magische Zahl, aber es ist zumindest auf eine kleine Zahl von möglichen Werten beschränkt. Das Gleiche für Socket-Type. Auch wir haben eine magische Nummer für den Protokoll-Typ. Und in der Dokument steht zumindest 0 für Default. Und wir kriegen einen Typ File-Descript zurück, der auch unter der Decke eine magische Zahl ist. Und im Fehlerfall kriegen wir eine Exception. Wenn ihr jemals in einer Sprache mit Exceptions gearbeitet hast, dann seid ihr vielleicht nicht glücklich, dass es hier etwas gibt, dass die Exceptions wirft als eine normale Aktion bei einer normalen Aktion. Connect ist eben schlimmer. Es nimmt einen File-Descripter, den Socket zurückgegeben haben und gibt eine Socket-Adresse und er gibt Unit zurück. Das ist das Equivalent von Void. Also das heißt im Wesentlichen, das ist ein Seiteneffekt. Guck woanders. Sucht nach den Fehlern woanders. In diesem Fall ist es eine Exception, die einfach die R&O von der zu runter liegenden API einpackt. Das ist auch nicht sehr schön. Aber wir sehen natürlich, warum diese API so ist. Das ist einfach ein Wrapper um die C-Library herum. Es hat ein paar nette Features von Okamal, aber nicht sehr viele. Was ihr machen könnt, wenn ihr in dieser Situation seid und mit dem Betriebssystem auf die Art und Weise interagieren wollt, dann könnt ihr eine höherlevelige Apeli darüber arbeiten, um zu höheren und höheren Applikationen kommen, um etwas zu kriegen, womit ihr als Anwendungsentwickler besser mitarbeiten könnt. Aber irgendwo unten müsst ihr immer damit arbeiten und damit reden. Und was, wenn ihr das nicht wollt? Wenn wir im Open Source Universum bist, wenn du wirklich diese API nicht magst, dann ändert sie einfach. Ich würde sagen, das ist nicht trivial für meisten Leute, die versuchen, die einfach Code schreiben wollen, der irgendwo laufen soll. Wenn ich deine Kernel-Interface ändern möchte, wenn ich das ändern möchte, jetzt muss ich erstmal in der Programmiersprache programmieren lernen, in der der Kernel geschrieben ist, was vermutlich nicht die Sprache ist, die ich normalerweise reden kann. Ich muss lernen, wie ich damit in einem Kernel arbeiten kann, was ein anderer Satz von Fähigkeiten ist, als normalerweise brauche. Dann muss ich einen patch, einen verdünftigen patch machen und dann muss ich irgendwie diesen patch akzeptiert kriegen. Die Community, mit der ich darüber reden muss, ist eine andere Community, als die, mit der ich normalerweise reden, ist eine andere, als die, mit die ich normalerweise reden. Es ist nicht die von meinem Projekt, das vermutlich nicht sehr begeistert darüber, über den patch, den ich eingereicht hat. Den Kernel interessiert es nicht, welchen blöden User-Level-Kram ich einfacher machen möchte. Und wenn ihr denkt, dass ich nur darüber rum jaule, dass Kernel-Entwicklung schwierig ist, das bin nicht nur ich, die denkt, dass Kernel-Entwicklung hart ist. Ihr habt vielleicht in die Eudiptiler-Challenge gehört, das eine Serie von Programmen Aufgaben für den Linux-Kernel. Die haben von einem einfachen Hello World angefangen und sind dann in der Komplexität hochgegangen und dann kann man gut einrechnen und wenn man erfolgreich eingereicht hat, kriegt man die nächste Challenge. Und es gibt 20 Schritte auf dieser Eudiptiler-Challenge. Es gibt ungefähr 19.000 Leute, die ja mit angefangen haben. Ich war dabei. Ungefähr 160 haben alle Challenges bestanden und ich war nicht dabei. Und ich denke, wenn die die Erfolgsrate von den Leuten, die damit anfangen wollen, dass sie so niedrig ist, ist ein Zeichen dafür, dass das so schwierig ist. Und da wir ja schon über Brasilien sprechen, also die Stimmfähigkeit, dann möchte ich auch noch ein anderes Thema ansprechen. Mitglieder von deinem Projekt möchten vielleicht nicht den Communities gehen, die feinselig oder einfach unschön sind. Und eine Art, wie wir uns tatsächlich schützen können für solche Communities, in denen man vielleicht gar nicht sein will, ist, dass wir einfach weniger mit ihnen zu tun haben. Und ja, es gibt einige Projekte, zum Beispiel sehr populäre, monetische Kernel, die für ihre widersprüchliche Kultur bekannt sind. Also schauen wir uns mal an, was das Betriebszentrum tatsächlich so für uns tut. Aus der Vogelperspektive können wir sehen, was dann eigentlich für Kommunikation so passiert. Also wie wir tatsächlich mit den Komponenten in einem klassischen Stack kommunizieren. Und ich habe diesen kleinen letzten Block hier eingefügt. Malerweise wenn wir Anwendungen ausführen auf irgendeinem Betriebssystem, dann läuft das Betriebszentrum heutzutage meistens nicht mehr auf der blanken Hardware, sondern es ist normalerweise virtualisiert. Das heißt, es gibt normalerweise einen Hypervisor und aus Sicht auf den ganzen Stack ist es dann quasi einfach nur eine relativ primitive Ressource, die die Ressourcen der Hardware Multiplex auf die virtuellen Maschinen und das Betriebssystem macht dann Netzwerk, Dateisysteme, Video, Clock und so weiter. Und tatsächlich ist es so, dass wenn man in einer virtualisierten Umgebung läuft, ist das der Hypervisor tatsächlich den Großteil der Arbeit, die das Betriebssystem früher mal gemacht hat, übernimmt. Und das Betriebssystem tatsächlich häufig nur noch in den Hypervisorcodes, nur noch den Hypervisor aufruft, um dieses Funktionalität zu bekommen. Das heißt, was können wir denn erreichen, wenn wir einfach direkt mit dem Hypervisor reden und das einfache virtualisierte Interface der Hardware bekommen, wenn es eben im virtualen Maschinen-Kontext läuft. Und dann bauen wir darauf einfach Libraries, die normalerweise auf einem höheren Level stattfinden. Beispielsweise Netzwerk. Es geht da meistens nicht nur darum, einfach nur irgendwelche Netzwerkpakete in die Netzwerkarte reinzuschieben, sondern man muss TCP Flows tracken und so weiter. Und das sind alles Higher-Level-Dinge. Dann gibt es Dateisysteme zum Beispiel, dann Timekeeping, also die Möglichkeit, wie man Zeit trackt, wie man Clocks produziert und so weiter. Also was hindert uns denn eigentlich daran, diese Libraries alle in einer Sprache zu schreiben, mit der wir sehr viel vertrauter sind, als einer anderen Sprache. Und tatsächlich in diesem Kontext können wir einfach kleine Abstraktionen schreiben und dann viel auf die Sprache abladen. Und tatsächlich ist dieses ganze Konzept das, was ein Unicorn ist. Wir sehen dann diese Libraries tatsächlich aus, wie fühlt es sich an, mit dem System zu interagieren. In Mirageo ist, was das Library-Betriebszimmer ist, mit dem ich arbeite. Haben wir ein Gemeinsamensatz-Interface-Definition und es gibt da etwas, das heißt Modulotypes, die im Prinzip beschreiben, beispielsweise ein Netzwerkgerät oder sowas, dann soll es eine Möglichkeit bereitstellen, ein Paket zu senden und so weiter. Und dann haben wir einen ganzen Satz Implementierung von diesen Interfaces, beispielsweise für der Teilsysteme, Netzwerkabstraktionen und so weiter. Und Komponenten, die mit verschiedenen Hypervisern klarkommen. Das heißt, wir können unseren Code allgemeinhalten und dann erst spezifisch werden, wenn es dann um ein konkretes Zielsystem geht. Ja. Gucken wir immer wie die CRPR und gucken, wie die CRPR Interface für den CRPR aussieht. In Mirageos haben wir den Modultyp TCP mit dieser Funktion Die nimmt ein, diese Typ-Signatur ist sehr viel idiomaterisches OCaml als die andere, was macht es etwas schwieriger macht, wenn da keine OCaml-Programmierer seid. Aber ich versuche es etwas zu erklären. In OCaml haben wir typischerweise ein Kontext oder Zustand, den wir mitführen. Ein Ding, das wir auf häufig T nennen. Das hier ist der, der Zustand, das wir in dem Modultyp TCP schicken wollen. Wir schicken die IP-Adresse und ein Port. Und der Rückgabbewert ist entweder ein Flow, ein Fluss oder ein Fehler, der innerhalb des Inbands zurückgegeben wird. Dieses ganze Typ, FlowErrorResult sagt, entweder ihr kriegt einen Fluss, ein Datenfluss oder ein Parameteris, was ein Nebenläufigkeitsflug ist. Weil wir einige Sachen zur Verfügung stellen, um leidgewichtiges kooperatives Multitasking zu machen. Diese Typ-Signatur benutzt auch etwas, das vor relativ kurzer Zeit in die OCaml Sprache gemirkt wurde. Dieser spezielle Resultat-Typ hatte man bis vor kurzem selbst implementieren müssen. Aber in OCaml 4.3 ist es in den Compiler gemirkt worden. Entschuldigung, dass wir mal kurz zurückgehen. Wir waren in der Lage alle diese Modultyp-Signaturen, die wir hatten, wo wir spezifische Rückgabbettypen hatten und diesen Resultat-Typ ersetzen konnten, der vor etwa 8 Monaten in der Standardpipliothek von OCaml zur Verfügung gestellt worden ist. Was sieht die Implementation aus? Das sieht auch aus wie idiomatisches OCaml. Wir gucken, was Create Connection tatsächlich macht. Es macht keinen seltsamen Buffer. Es gibt mir eine TCP-Verbindung. Es gibt mir eine Zieladresse und ein Port. Ich mache eine Adresse oder wenn es nicht schiefgegangen ist, gibt es einen Fehler. Ansonsten gibt es den Fluss zurück, den ich gekriegt habe. Wie kann man das alles zusammenbauen in Dingen, die man tatsächlich benutzen kann? Was ich euch bisher gezeigt habe, ist konzeptionell wie wir mit dieser Art von Implementation diese Liste von Implementationen umgehen und mit den Abhängigkeiten, die sie haben, was wir in MirageOS machen. Wir nehmen die Applikation, die da benutzt, laufen lassen will. Eine Liste der Abhängigkeiten, die benutzen kann und dann fühlen wir das zusammen entweder in einem Prozess, in dem es ein Betriebssystem läuft und wir haben Schimm-Layer oder eine minimale virtuelle Maschine die in einem Hypervisor-Kontext laufen kann. Es kann an verschiedenen Hypervisors laufen. Ich zeige euch eine kurze Demo, wie es aussieht bei einer Webseite, die so implementiert ist, zu interagieren. Ich habe eine Webseite. Ich habe eine Webapplikation für den MirageOS-Unikernel. Es ist ein MirageOS-Unikernel. Es hat eine Liste von Dingen, die es braucht. Das ist das Konfigurationsdokument für den Unikernel. Der ganzen Haufen Informationen darüber enthalten, wie ich zum Beispiel mein Network gegen haben möchte. Ich gebe mir einfach ein IPv4-Stack, wo es kann der Benutzer entscheiden, wenn er die Applikation baut, wie er es haben möchte. Ein Kontext ist, ich möchte ein HTTP-Server bauen. Ich gebe hier an, wie ich meine Zertifikate für die TLS-Verbindung kriege. Das ist meine Applikations-Layer Abhängigkeiten, die es braucht und ein bisschen Kompositionen, die ich all diese Sachen zusammenstecken muss. Außerdem brauche ich eine POSIX-Uhr vom Data-System. Die Daten, die ich tatsächlich zur Verfügung stellen will und dann die Zertifikate, die ich brauche. Und los geht's. Die tatsätzliche Logik für die Anwendung ist in diesem Dispatch-Datei. Das zeige ich euch jetzt nicht. Das ist ein Haufen OCaml, das jetzt hier nicht zur Sache beiträgt. Ich zeige euch wie man das startet. Also wenn ich mir das Konfig ja aufrufe, dann gucke ich in dieses Konfigurations-Dokument und die Liste der Dinge, die du haben möchtest und ich stelle heraus, wie ich das zusammenbaue. Es baut mir ein Makefall, dann sage ich einfach Make und das baut diese Applikation. Es erzeugt eine Datei, Main.Native, die kann ich laufen lassen und dann kann ich, da habe ich eine Web-Anwendung. Danke. Lasst uns einen Unicornl daraus machen. Die Sache, die ich eben gezeicht habe, habe ich einfach zu Google Cloud geschickt. Der Halberweiser auf Google Cloud möchte etwas haben. Wir wissen, wie es mit den Geräten treiben muss und ich sage mir, ich bau mir ein Unicornl, der in dieser Umgebung funktioniert. Mache mir ein davon. Jetzt, was ich jetzt habe ist diese HTML. Die ist vollständig. Ich habe 16 MB, was ist die komplette virtuelle Maschine, die ich für meine Webseite laufen lassen möchte. Und ihr möcht sagen, 16 MB ist ein Haufen nur für eine einfache Webseite. Aber ich habe all den Content und Inhalt für die Webseite darin. Das ist alles in diesen 16 MB. Ich kann sagen, dass das Binary, das wir für Unix gebaut haben, dass er die gleiche Funktionalität hat. Also, das Binary, das auf Linux läuft, ist tatsächlich größer. Das ist die gleichen Daten enthält. Also, ich hoffe, dass ich euch jetzt zumindest mal überzeugt habe, ob Library Betriebssysteme Systemeentwicklung vereinfacht. Und ich hoffe, dass ihr eine Programmiersprache habt, die ihr genug mögt, um irgendwie mit diesen Betriebssystemen zu reden. Ich hoffe, dass ich euch davon überzeugt habe, dass es besser ist, eure Tools zu benutzen, ihre Sprache bereitzustellen, und darüber eine Übung zu machen. Und ja, Library Operating Systems sind, ja, da gab es schon eine ganze Weile gute Ideen, zum Beispiel das RAM Kernel Projekt in NetBSD, das darauf abgezählt hat, die Treiber in NetBSD zu substrieren, dass es sich eher wie ein Library Betriebssystem verhält. Und die ursprüngliche Motivation dafür war, diese Kerneltreiber leichter zu debuggen und testen zu können. Weil man sie dann eben in Userspace laufen lassen kann. Oder ja, generell ist es halt eben einfacher, diese Treiber zu analysieren bei bestimmten Input. Schauen wir uns mal an, wie wir MirageOS testen. Die sehen tatsächlich genauso aus, wie Unitests für normalen Okamiko, den wir sonst so schreiben. Das ist ein Test, der Options Padding in TCP testet. Es ist ein relativ langweiliger Code, in dem man Bitmodifikationen macht, wo man sich sehr leicht vertun kann, wenn man in einer Sprache ist, die nicht speichersicher ist. Das Test Framework, das wir dann benutzen und die Tests auszuführen, ist auch ziemlich langweilig. Wir benutzen das ganz normale Test Framework, das man sonst auch benutzt. Wir fühlen die einfach aus, kein Drama oder so. Ein Vorteil, der auch ist, den wir auch haben, wenn diese Anwendung nur aus ganz vielen Libraries besteht, ist das, für tatsächlich einfach bei den Tests, dass wir einzelne Libraries simulieren können, dass sie kaputt sind und können, wie sich die Anwendung verhält, wenn irgendwas in der Library kaputt ist. In MirageOS hatten wir genau dafür ein paar interessante Ideen. Könnte sagen, sie sind lustig. Zum Beispiel Netzwerk Interfaces bei den immer neue Pakete verfügbar sind. Dann finde ich zum Beispiel den Zufallsteingenerator ganz lustig. Zum Beispiel, wenn er keinen Zufall macht und man sich dann anschauen kann, wie sich die Anwendung dann verhalten. Entropiekwellen, die immer blockieren, sind auch häufig interessant. Anwendungskort geht auch häufig kaputt, wenn das Datei-System voll ist oder ein Block-Device busy ist und so weiter. Oder wenn man aus dem Netzwerk-Layer kürzere, nicht die Anzahl an der Warte in Bites zurückbekommt und dadurch, dass wir eben unser ganzes Betriebsheim so modular aufbauen, ist es leicht, einfach diese kleinen Mocs reinzubinden und zu schauen, was passiert. Weitere Gedanken, die man so haben kann, denken wir zum Beispiel an ein traditionelles Datei-System, in dem wir ganz viel globalen Zustand haben und der traditionelle Weg dann rausfinden, was ein System gerade tut und wenn das Zustands gerade ist, dann können wir aufmachen und schauen, was da so der Zustand von diesem System ist. Bei einem Unikernel haben wir zwar Zugriff auf den Zustand der Module, aus den der Kernel aufgebaut ist, aber anstatt dass wir reingehen und schauen, was die Anwendung gerade tut, dann möchten wir uns vielleicht nicht unbedingt den ganzen globalen Zustand anschauen, der bedingt, was die Anwendung gerade tut. Wir können die Anwendung einfach sagen lassen, in welchen Zustand sie ist und warum sie in diesem Zustand ist. Wir haben zum Beispiel experimentiert mit der Library Irmin, die ein verteilter Datenspeicher ist und da haben wir ausprobiert, was denn passiert, wenn einfach jeder Zustand also jede Zustandsänderung am System mit einer Komplettnachricht verbunden sein muss und das heißt, wir können dann quasi nachher schauen, welche Zustandsänderungen zum aktuellen Zustand des Systems geführt haben. Eine andere interessante Idee ist, ich habe ja erwähnt, dass wir Scheduler haben, die wir einfach austauschen können und was ist denn, wenn wir einfach rausfinden könnten, was der Scheduler welche Entscheidungen getroffen hat und wir hatten Thomas in unserem Projekt, der eine sehr interessante Visualisierung geschrieben hat, um rauszufinden, welche oder deine Visualisierung für den Entscheidungsfluss im Scheduler geschrieben hat und das heißt, man konnte da zum Beispiel sehen, warum denn ein bestimmter Fett nicht gescheduled wurde oder Fehler verursacht hat oder sowas. So, also Okay, ihr habt mich überzeugt, dass ich kein Betriebssystem mehr brauche und wir haben auch den Hypervisor und das ist auch ein Haufen Code als Abhängigkeit. Was denkt du darüber? Klugartikel. Nun, es gibt, es gibt ein sehr interessantes Projekt Solo5, das ist ein Komponent der UKVM. Das nimmt die Geräteabhängigkeiten aus dem Gerät und konfiguriert dann die Hypervisor so, dass er keinerlei Geräte exponiert, die man nicht benötigt. Also du brauchst kein Netzwerkgeräte, ich zeig dir keine Netzwerkgeräte. Ich glaube, das ist ein sehr interessantes und sehr cooles Projekt. Wir haben ein bisschen mehr anlaufende Arbeiten. Wir versuchen mehr Hypervisor zu unterstützen, das ist auf mehr Gerätensystem laufen können. Es gibt ein paar Arbeiter auf einige dieser Bibliotheken zu benutzen, außerhalb des Library Operating Systems zu benutzen. Es gibt keinen Grund, Sie nur in dem Zusammenhang zu benutzen. Wir machen viel Interessante Arbeiten mit Cubes OS. Cubes OS ist ein Desktop-Operationssystem. Es läuft auf meinem Laptop, das powert diese Slides, die ihr ja gerade seht. Das geht davon aus, ihr habt ein Haufen virtuelle Maschinen, die um Trennung zwischen verschiedenen Aktivitäten zu haben. Wenn man das mit konventionellen virtuellen Maschinen braucht, der sehr viel Festplattenspatz und es wäre echt nett, etwas kleineres zu haben, sowohl im Punkt Dateisystem größer als auch Speicherverbrauch. Deshalb versuchen wir kleine Dinge in Cubes OS, die auf großen Unix VMs laufen, durch kleine Mirage VMs zu ersetzen. Das ist zum Beispiel Cubes Mirage Firewall. Das ersetzt eine Fedora VM, die ungefähr 300 500 megabyte Speicher bebraucht durch einen Unikernel, der 32 verbraucht. Da haben noch einiges mehr, wenn ihr interessiert seid, dann kann ich die Slides später wieder hervorhören. So, ja. Da habt ihr doch ihre Ideen, solche Sachen, die man in diesem machen kann. Ich bin daran interessiert, eure Ideen zu hören. Und ich denke, wir haben Zeit für ungefähr acht Fragen. Danke für eure Zeit. Vielen Dank, Mindy. Wir haben tatsächlich nur Zeit für eine Frage. Und wir wählen die Frage vom Signal Angel. Okay. Keine Fragen aus dem Internet? Dann fragen wir eine Frage am Mikrofon 1. Hast du dir angeschaut, was man mit Capability basierten Sprachen machen könnte? Es gibt da zum Beispiel eine Variante von OCaml, die mehr Isolation zwischen Prozessen bereitstellt. Man kann sich einfacher Gedanken darüber machen, welche Teile der Anwendung auf welchen Zustand Zugriff haben. Ich habe es nicht. Ich habe von Emily gehört, aber ich wusste nicht, dass es diese interessante Eigenschaft hat. Also, ja, muss ich mal angucken. Danke. Okay, danke. Das ist alle Zeit, die wir haben. Wenn ihr weitere Fragen hat, spricht Mindy außerhalb der Halle an. Und damit verabschieden sich dann auch aus der Übersetze Kabine Proplane und Florian.