Das läuft ja gerade richtig gut mit dem Podcast, ne?
Ja, finde ich auch. Aber was machen wir als nächstes?
Ich habe da von einem Forschungsgebiet gehört, wo sie im Grunde das Betriebssystem auf die Anwendung maßschneiden und zu ganz kleinen Systemen rauskommen.
Ach so, Juni-Könnels.
Ja genau die. Das klingt total spannend. Lass mal da drüber reden.
Ja, von dir aus.
Und ich meine, jetzt ist auch gerade die richtige Zeit dafür, ne?
Was meinst du?
Naja, also Juni-Könnels im Juni?
Äh, Stefan, es ist August.
Psst, sag das doch nicht, sonst muss ich die Folge noch in diesem Monat senden. Aber wir nehmen natürlich im Juni auf.
Nein, es ist August.
Ach man, Flo!
Der Systemcall heute mit folgenden Themen.
Die Betriebssystemfahrt am Organer.
Und die nächste Stufe der Linux-Dominanz.
Herzlich willkommen zum Systemcall, dem Podcast über Betriebssystemforschung.
Mein Name ist Stefan Naumann und bei mir wie immer ist der fabelhafte Florian Rommel. Moin Flo.
Hallo Stefan, in dieser Folge geht es um Juni-Könnels, aber vielleicht fangen wir einfach mal ganz von vorne an. Was sind die Juni-Könnels eigentlich?
Genau, das ist eine sehr gute Frage. Und vielleicht schauen wir uns mal das Gebiet an, wo die Juni-Könnels eigentlich eingesetzt werden.
Da geht es natürlich um die Cloud und die Virtualisierung. Also genau da, wo wir in der letzten Folge aufgehört haben.
Und ganz früher war es halt so, wir hatten für jede Anwendung im Grunde einen Host, also einen Rechner dastehen, der zum Beispiel seinen Webserver laufen ließ, vielleicht war dann eine Datenbank drauf und das war es im Grunde. Der hatte im Grunde eine Aufgabe. Dann wurden irgendwann die Rechner schneller, also die Server schneller, die Server größer mit mehr Prozessorkernen.
Also hat man angefangen diese Rechner zu nehmen, diese einzelne Rechner und die einzelne Anwendung zu nehmen, in eine virtuelle Maschine reinzupacken und dann mehrere virtuelle Maschinen auf einem Server zu haben.
Und warum hat man das gemacht?
Im Grunde ging es da um Kostenersparnis. Also man kann halt mit mehr virtuellen Maschinen die besseren Prozessoren, die schnelleren Prozessoren auch besser auslassen.
Also eine Anwendung lasst den Rechner nicht aus und dann wäre es Verschwendung, dann den ganzen Rechner zur Verfügung zu stellen alleine. Also nehmen wir zum Beispiel einen Webserver, da wird ja nicht ständig angefragt, vielleicht wird von dem einen Kunden gerade nicht angefragt, aber von dem anderen Kunden und sie werden quasi die Prozessoren trotzdem ausgelastet, obwohl der eine halt quasi nicht gebraucht wird gerade.
So aber man hat dann irgendwann festgestellt, die meisten dieser virtuellen Maschinen haben irgendwie nur eine Aufgabe und wir befinden uns auch gerade im Jahr 2013 oder 2012 eher noch, da war Hotplugging auch so eine schwierige Sache.
Ja, was bedeutet das?
Also wir konnten halt Prozessoren zur Laufzeit hinzufügen oder Speicher zur Laufzeit hinzufügen, das ging bei den Betriebssystemen damals noch nicht. Bei Linux zum Beispiel.
Ja, halberweise konnte es schon, aber Linux konnte damit nur nicht umgehen, wenn da ein neuer Prozessor hinzukommt oder weggeht.
Ganz genau. Und wenn wir uns das angucken, wir haben irgendwie keine Ahnung, sagen wir zehn virtuell Maschinen, darauf gibt es von irgendeinem Kunden eine Apache drauf, eine Datenbank drauf, da ist halt wahnsinnig viel Zeug, was nie gebraucht wird.
Also zum einen war jedes Mal ein kompletten Linux Kern und da sind zum Beispiel Dateisystem 3, die vielleicht nicht gebraucht werden, Codefile, die überhaupt nicht gebraucht werden. Und da ist vor allem auch ein ganzer User Space drauf, den wir nicht brauchen. Also warum brauche ich für meine Datenbank zum Beispiel irgendwelche Dienstprogramme oder so etwas irgendwie ein LS oder ein Editor oder so, mein Betriebssystem, der aber dann trotzdem ja mit der, mit der, in der virtuellen Maschine vorhanden ist.
Ja und im Zweifel sogar noch, wenn du, lass dich mal ein LS und Find oder so was brauchen, du hast dann wahnsinnig viele Optionen auch drin, die du überhaupt nicht brauchst. Und dann haben sich die Forscher halt die Frage gestellt, ok, was passiert denn jetzt, wenn wir nur das reinnehmen, was wir auch wirklich brauchen?
Und im Grunde sind sie da bei einer Idee gelandet, die es schon mal gab, nämlich die Library Betriebssysteme oder die Bibliotheksbetriebssysteme. Das weißt du, wie das Bibliotheksbetriebssystem ist, oder?
Ja, das ist eigentlich eine ganz alte Idee, nämlich eigentlich ein Schritt in der Entwicklung von Betriebssystemen. So sahen die ersten Betriebssysteme im Endeffekt aus, also als man noch große Mainframes hatte und dann war, und am Anfang hat man einfach Programme auf der, ja auf der wahren Haft ausgeführt und dann hat man angefangen Bibliotheken zu schreiben für I/O und so weiter und das waren quasi die ersten Betriebssysteme.
Genau, also das heißt, man hat im Grunde das Betriebssystem als Bibliothek entwickelt und an die Anwendung rangelegt. Also wir haben eine Bibliothek, die zum Beispiel Skytuning anbietet und Fertig anbietet. Oder ganz klassisch I/O. Oder ganz klassisch I/O, genau. Oder zum Beispiel Treiber, die werden einfach an die Anwendung gelingt und die Anwendung kann sie dann einfach benutzen. Also die ruft dann einfach Funktionen auf, statt eben jetzt Syscalls, die dann so einen, ja so einen Switch in eine andere Privileg-Ebene machen.
Genau, also diese Situation gab es halt einfach nicht. Es war keine Unterteilung zwischen Köln und UserSpace, das heißt es lief halt alles im Supervisor-Modus und genau, es gab halt keine Treibung zwischen Köln und UserSpace. Und diese Idee haben sie sich geschnappt und sind dann mal ein bisschen losgelaufen und haben sich überlegt, wie können wir jetzt eigentlich ein System bauen, wo wir nur das drin haben, was wir auch wirklich wollen.
Die haben sich also die aktuellen Anwendungen so angeguckt und die verlangen halt alle irgendwie Win32, also die API von Windows oder zum Beispiel die POSIX-API und die muss man doch erstmal erfüllen, da hängt schon viel dahinter. Also haben sie angefangen ein eigenes Blutsystem zu schreiben, man nennt das Clean Slate, also man fängt quasi mit einem blanken Tisch an. Und sie haben das in Okaml gemacht, das ist eine funktionale, imperative und OOP-Programmersprache. Im Grunde sie laufen da sehr, sehr stark auf dieses startende Typsystem hin. Also diese Sprache hat eine gewisse Typ-Sicherheit, garantiert sie. Das heißt, man kann Operationen nur auf Typen ausführen oder auf Daten ausführen, wo der Typ stimmt. Also nicht wie C oder so, genau, einfach stark typisiert.
In C kann ich halt im Grunde aus allem irgendwie einen Voltpointer machen und aus einem Voltpointer kann ich alles machen. Das Typsystem zwar schön, aber hilft mir halt nicht wirklich.
Aber das ist eigentlich nur so ein Implementierungsdetail von diesem Betriebssystem mehr oder weniger?
Nie, also ja, natürlich, gewisserweise schon, gewisserweise ist das ein Implementierungsdetail, was für eine Sprache das geschrieben ist. Hier machen sie aber so eine Whole System Optimization, also eine Optimierung über das System hinweg.
Und das geht besser, wenn man ein starkes Typsystem hat, weil dann der Compiler mehr Garantien hat, die er dann zur Optimierung auch nutzen kann.
Genau, also es ist zum Beispiel auch gar nicht so einfach in C rauszufinden, ob eine Funktion gebraucht wird oder nicht. Also man kann das machen, ob sie direkt gerufen wird, okay, aber dann gibt es noch Funktionspointer, da wird es schon schwieriger. Und wenn ich dann zur Laufzeit anfange irgendwelche Pointer zu brechen und dahin zu springen, dann wird es erst ganz kriminell.
Okay, aber jetzt haben Sie das in Orkammel geschrieben und jetzt wollen Sie aber gleichzeitig zum Beispiel sagen, wir haben eine POSIX API, also die Unix API bereitstellen und das ist ja eine C-Schnittstelle. Also machen Sie das wirklich oder ist das nur so was in der Art?
Das ist eine sehr gute Frage. Also da müssen wir noch einen kleinen Schritt vorwärts gehen. Im Grunde, diese Mirage OS zielt auf Xen. Also Xen ist so die Basisplattform von der Mirage OS.
Also um noch mal eine Ebene hoch zu gehen, also die Idee ist jetzt, ich habe meinen Hypervisor und da habe ich die virtuelle Maschine drin und in diesen virtuellen Maschinen soll dann jeweils nicht mehr ein ganzes Linux oder Windows oder sonst was laufen, sondern dann eben diese Unicurl, also diese Mirage OS, wo dann das dann spezifisch mit der Anwendung ja verbunden ist und auf die Anwendung abgestimmt ist.
Genau, also.
Genau, aber es soll für die Anwendung dann trotzdem die POSIX API oder Win230 API bereitstellen.
Nein, also das ist halt der Punkt. Im Grunde, sie legen gar nicht so wahnsinnig viele Werte drauf, diese ganzen Legacy Anwendungen zu haben.
Okay.
Das ist immer von, das ist so ein bisschen ein Zwiespalt in der Briefsystemforschung. Fange ich jetzt von vorne an, baue mein eigenes Briefsystem in der neuen Sprache, dann habe ich halt die ganzen Legacy Anwendungen. Das heißt, mein Briefsystem wird sich nie durchsetzen. Es kann sich nie durchsetzen.
Ja, also ist halt schwieriger. Aber klar, das ist dieser Clean-Slate-Ansatz.
Genau, das ist der Clean-Slate-Ansatz. Ohne natürlich weitere ich irgendwie existierendes Briefsystem, dann habe ich bestimmte Einschränkungen. Ich darf zum Beispiel den User-Space nicht kaputt machen, ich darf irgendwie bestimmte Systemcalls haben muss oder einschränken muss oder wo ich mir wahnsinnig viele Gedanken machen muss. Dann habe ich die Möglichkeit, dass meine Forschung im Grunde weiterlebt, wenn ich zum Beispiel in Linux Mainstreame, nein, Mainliner, mein Linux Mainliner. Aber ich habe natürlich die Einschränkung von diesem Briefsystem. Die Annahmen, die das Briefsystem mal getroffen hat, die werde ich nicht aufbrechen können in dieser Forschungsarbeit. Und die haben sich jetzt hier halt entschieden für eine Clean-Slate-Anwendung, wo sie im Grunde halt von vorne anfangen und aber ein eigenes Ökosystem aufbauen.
Okay, aber das heißt, sie stellen so etwas Ähnliches bereit wie die POSIX API? - Dazu komme ich gleich. Aber nochmal zu dieser whole system optimization zurück. Sie bauen jetzt quasi dieses Briefsystem, diese Bibliotheken für ein Briefsystem, also ein paar Treiber für das Xen zum Beispiel oder gewisse Buffer-Technologien, Buffer-Algorithmen für die Anwendungen. Und sie schreiben natürlich auch ein paar Anwendungen da drin. Zum Beispiel in den DNS Server. Und die meisten Anwendungen, wenn man jetzt auf den Linux guckt, so ein Apache zum Beispiel, der hat wahnsinnig viel an Konfiguration. Da kann man wahnsinnig viel einstellen, was dieser Apache tun soll und nicht tun soll und wo er jetzt drauf lauschen soll. Und diese Konfiguration sehen die als Quellcode im Biashow ist.
Das heißt, sie können das mit in die Optimierung hineinziehen sozusagen?
Genau das ist der Punkt. Sie ziehen das in die Optimierung mit rein. Das heißt auch, sie können zur Laufzeit das nicht mehr konfigurieren. Das heißt jedes Mal, wenn sie irgendeine Konfig, was man im Linux-Config erteilen würde, ändern wollen, müssen sie das Ding halt neu bauen und neu deployen.
Okay, aber dafür kann dann irgendwie meine Portnummer nicht mehr als Variable, sondern direkt als Konstante und dann darauf ob da mit mehr Optimierungen gemacht werden.
Genau, okay. - Ja, das ist natürlich eine elegante Idee.
Genau, genau so ist das. Und jetzt hast du mich ja gefragt, ob sie das POSIX eigentlich anbieten. Und ja, ja, ne, also sie haben im Grunde verschiedene Backends. Also du kannst deine Anwendung in OCaml oder für das Mirage OS auch auf dem Linux laufen lassen. Das ist quasi der Schritt, um deine Anwendung einmal zu bauen.
Also, um deine Entwicklung zu prototypen, ein bisschen umzuschreiben, auszuprobieren. Dann links du zum Beispiel gegen Unix Sockets, wenn du jetzt deine Anwendung im Netzwerk machen willst.
Und irgendwann kommt der Schritt, wo du sagst, okay, meine Anwendung läuft jetzt, ich hab jetzt genau das, was ich will, alles schön und gut. Jetzt wechsle ich das aus. Die Unix Sockets gegen, ich glaube mir net hieß das, also so eine Socket-Implementierung quasi von denen oder so eine Netzwerk-Implementierung von denen. Die stellt im Grunde das gleiche Interface bereit.
- Aber die läuft jetzt nur noch auf dem Garage aus. - Genau. Die läuft jetzt in diesem Garage aus und auf Xen.
Das heißt du brauchst dann kein Linux mehr. - Mhm.
Das ist im Grunde die Idee. Deine Anwendung bleibt effektiv unverändert, egal ob sie jetzt auf dem Linux läuft oder auf dem Xen läuft.
Deine Anwendung ist identisch und du baust halt quasi gegen eine andere Library. - Ok, ja gut. Mhm.
- Und dadurch, dass irgendwie alles zusammengelingt ist und von einer einzigen Sprache, gibt's auch kein dynamisches Nachladen von Code mehr.
Das heißt alles, was ich zur Compile-Zeit an Code nahe habe, ist auch der Code, der ausgeführt wird und nichts anderes. - Mhm.
- Und dadurch, dass wir das wissen, dann führen sie dieses Konzept des Sealing ein.
Können wir im Grunde dieses WriteX or Execute, also dieses Markieren von Speicherseiten als entweder schreibbar oder ausführbar, können wir eigentlich auch statisch machen. - Mhm. Also man kann das dann nicht mehr ändern, wenn die Maschine mal läuft.
- Genau, das ist die Idee. Also der Unicode wird dann gebootert, dann wissen wir ja, wo unser Code liegt, den markieren wir als executable, also ausführbar.
Und jetzt haben wir noch so diesen Heap-Bereich rumliegen, den machen wir natürlich als schreibbar.
Und dann können wir dem Xen sagen, jetzt möchte ich ab diesem Zeitpunkt meine PageStabs nicht mehr ändern können.
- Ok, und der ganze Heap ist sozusagen auch von vorne rein reserviert.
- Genau. Und dadurch, dass ich quasi in dem Moment meine PageStabs locken muss, muss ich den ganzen Heap allokieren. - Ja.
- Und damit quasi den Speicher mir holen. Und da wir uns im Cloud-Kontext befinden, also jeder Betriebssystem, jeder Student, der den ganzen Heap sich holt, den würde ich auf die Finger hauen und sagen, das macht man so nicht.
- Ja genau, das macht man ja on-demand, das nützt man ja den Heap.
- Aber das ist ja jetzt hier kein großes Problem, weil der Speicher ist sowieso bezahlt. Wir sind im Cloud-Kontext, ich hab für zwei Gigabyte Speicher bezahlt, also kann ich mir diesen zwei Gigabyte Speicher auch zuweisen lassen.
- Also das Anwendungsgebiet ist sozusagen, ich hab mir von einem Anbieter diese zwei Gigabyte Speicher und irgendeinen Prozessor geholt, also als Cloud-Rechner oder als Cloud-Virtuele-Maschine und dann kann ich die auch benutzen, wenn ich die bezahlt hab.
- Genau, also dadurch, dass wir diese Pageshaps dann locken, können wir sie auch gar nicht mehr ändern. Und damit haben wir quasi den gesamten Code, den wir in unserem Unicurl haben, executable und sonst nichts.
Es gibt keinen Code mehr, der irgendwie eingeschleust werden kann, der irgendwie ausführbar ist.
- Okay, also auch so ein Security-Vorteil dann gegenüber einem traditionellen Curl.
- Ganz genau, und das fahren sie halt wirklich sehr, sehr stark nach Hause, diesen Security-Vorteil, also auch diese Typ-Sicherheit von der Okamelsprache, da haben sie schon einen sehr, sehr großen Fokus drauf, dass das wirklich typ-sicher ist und dass es sicher ist und...
- Damit wird vielleicht auch ein bisschen mitigiert, dass das Ganze ja jetzt, also dass es keine Trennung zwischen Curl und User-Space mehr gibt?
- Ganz genau so.
- Das ist jetzt sowieso schon nicht mehr so schlimm, weil es ja sowieso noch eine Anwendung gibt, also die kann sich halt nur noch selber kaputt machen, aber unter so einem Safety-Aspekt, also dass aus Versehen irgendwas kaputt gehen kann, ist natürlich immer noch vorteilhaft, wenn die Sprache halt typ-sicher ist, weil dann nicht so viele Dinge aus Versehen kaputt gehen können.
- Ja gut, also du kannst natürlich deine Variablen zerstören, aber du kannst jetzt nicht einfach die den Stack zerstören, das kann ich.
Genau, eine Sache, also im Grunde so, der gesamte Rest von diesem Betriebssystem ist im Grunde basiert das auf einem Ring, einem Ringpuffer.
Also wir haben irgendwie noch, wenn wir jetzt Device-Triber z.B. nehmen, es gibt quasi einen Xen-Frontend-Triber in der VM selber, das wären quasi wir, und es gibt Backend-Triber in Xen, die nehmen Requests entgegen von der virtualen Maschine und arbeiten die ab, die nehmen die halt in den Ring entgegen, also im Producer-Consumer-Ring.
- Also Xen arbeitet schon auf die Weise.
- Genau.
- Also so werden ja, ja, so wird Performantaustausch zwischen dem Hypervisor und dann dem Betriebssystem oder jetzt eben dem Unikernel gemacht.
Genau, und jetzt schreibt quasi der Frontend-Triber aus der VM Request in diesen Ring rein, der Backend-Triber nimmt die, schafft die ins Gerät rein, irgendwann antwortet das Gerät und die Antwort schreibt dieser Backend-Triber wieder an diese gleiche Stelle, wo der Request entstand. Das heißt wir brauchen da keinen neuen Speicher. Also wir nehmen die Stelle, wo der Request entstand, da schreiben wir die Antwort rein, fertig ist der Lack. Und dann muss nur noch der Frontend-Triber irgendwann signalisiert bekommen, dass der letzte Antwort da ist.
- Genau, im Grunde basiert alles auf diesem Ring-Prinzip, wenn wir jetzt Protokoll.io betrachten, auf diesen Ring, wenn wir das Netzwerk betrachten, das betrachten wir auf diesen Ring und sehr sehr häufig legen die Autoren sehr großen Wert darauf, dass wir auch wirklich Zero-Copy haben, dass wir die Daten nicht kopieren müssen. Also im Gegensatz zu den zu vielen der klassischen Betriebssystem-Abstraktionen, die wir in Unix-Körnen oder sowas haben, also wo Dinge hin und her kopiert werden zwischen Köln und User-Space.
- Genau, weil man hat das halt irgendwann so gebaut und dann haben sich die Leute darauf verlassen, dass das irgendwie meine Pages sind, also kann ich da auch drauf schreiben und denen jetzt irgendwie die Pages wieder wegzunehmen, weil wir jetzt Zero-Copy machen, das ist schwierig, das ist wirklich schwierig.
- Eine Sache vielleicht noch, was auch ganz zu wissen ist, wenn man Netzwerk machen oder Kommunikation machen, gibt es zwei Möglichkeiten, einmal innerhalb des Computers quasi, auf diesem Computer, auf dieser virtuellen Maschine.
- Also zwischen zwei Unikörnis. - Zwischen zwei Unikörnis und zwischen zwei Hypervisor. - Zwischen zwei Unikörnis und zwischen zwei Hypervisor, genau, so wie wir das erzählen.
- Nennt sich V-Channel, also der virtuelle Kanal, virtuell Channel, ist ebenfalls wie so ein Ring und im Grunde läuft es darauf hinaus, dass wir wieder Zero-Copy machen und Seiten zwischen den VMS teilen, dann können wir sogar ohne, dass der Hypervisor aktiv werden muss, kommunizieren.
- Und ansonsten nach außen machen wir natürlich Ethernet und packen dann die ganzen Protokoll-Header und so davor und dran und weg.
- Ja, also ganz normale Kommunikation übers Netzwerk. Ja Stefan, klingt ja alles sehr schön, aber was bringt das denn oder hat es Vorteile gegenüber, wenn ich jetzt einfach Linux habe oder so was?
- Genau, die Frage haben sich die Autoren auch gestellt und haben eine relativ ausführliche Evaluation gemacht, sag ich mal. Sie haben erst ein paar Microwebschmarks gebaut, da so Zeug gemessen wie z.B. die Boot-Up-Times, da kommen sie so auf 50 Millisekunden für einen Reboot oder für einen Boot von einem Unikörner.
- Also schon mit irgendeiner Anwendung oder erst mal? - Genau, also mit einem Webstove, glaube ich. Jetzt haben sie das einmal getestet gegen einen Linux-Blank ohne alles, da haben sie im Grunde gemessen zwischen die Kiste geht an zu, ich glaube der erste Netzwerk, packiert geht raus, da waren das etwa eine Sekunde.
Und mit einem Apache-Webstove oben drauf waren es etwa 3 Sekunden, da haben sie gewartet bis der Apache da ist. Und da hingegen können sie 15 Millisekunden durchaus zeigen lassen, würde ich sagen.
Also da macht dann auch die Neukonfiguration eigentlich kein Problem mehr, weil ich konfigurieren neu und habe dann 50 Millisekunden, mein Service ist dann 50 Millisekunden mal nicht da oder mit weniger Workern, das glaube ich vernachlässigbar.
- Ja, in vielen Fällen schon. - Genau, da haben sie als zweiten Microwebschmark quasi Millionen von Threads erzeugen lassen, da sind sie etwa so bei 80% der Zeit von Linux gelandet, also schneller als Linux oder 20% schneller als Linux. Und da ist der limitierende Faktor des Garbage-Collections von OCaml gewesen.
- Ah, ok, also da steht jetzt die Sprache tatsächlich im Wege und das ist auch eine Sprache mit Garbage-Collection. - Genau, eine Sprache mit Garbage-Collection. Also was heißt im Weg, sie haben halt zwei so Heaps, im Grunde, es gibt einen Minor und einen Major Heap.
In dem Minor Heap leben die ganzen kurzlebigen Objekte, also wenn ich jetzt ein Objekt erstelle, dann lebt es erstmal da, das ist ja relativ klein, der Heap. Wenn er voll ist, scanne mal darüber, sortiert die ganzen lebenden Objekte raus, die werden in den Major Heap geschrieben und der Minor Heap wird platt gemacht.
Das ist im Grunde die Vorgehensweise. Jetzt kannst du den Minerheb natürlich vergrößern und kriegst eine bessere Performance raus.
Und wie oft erstellst du jetzt tatsächlich Millionen von Thwets und machst du damit nichts mehr.
Also im Grunde ist das halt eine ganze Menge Frasher gegen den Minerheb gewesen. Von daher, ja.
Ja aber wie sieht es denn jetzt mit Durchsatzmessungen aus von irgendwelchen Webservern?
Genau ja, zwei kleine Sachen noch. Sie haben die Warteoperationengenauigkeit mal gemessen. Also wie genau sind eigentlich diese Warteoperationen?
- Also was heißt das? - Wenn ihr jetzt einen Thwet habe, der eine gewisse Zeit warten soll.
- Ah, okay, also Timeout. - Genau, wie genau kommt eigentlich diese Zeit ran.
Sie messen einen geringeren Jitter und eine höhere Präzision.
Genau, Durchsatz. Da spricht man natürlich an. Sie haben nämlich auch einen DNS-Test gebaut. Da haben sie Bind9, das ist ein relativ alter DNS-Server gemessen. NSD ist ein Auf-Performance-Optimeter DNS-Server und MiWash halt.
- Also ihren eigenen OKMW geschriebenen DNS-Server, der als Unikandel dann läuft. - Genau.
Bind9 schafft 55.000 Requests pro Sekunde. NSD schafft 70.000 Requests pro Sekunde.
Und MiWash schafft etwa 75.000 bis 80.000 Requests pro Sekunde.
Okay, also so 10% schneller ungefähr.
Genau, ja und die sagen dann auch...
Oder 10% mehr Durchsatz ungefähr.
Ja, genau 10% mehr Durchsatz. Und sie sagen dann auch, sie haben dann eine kleine Algorithmusänderung gebaut.
Also erst mal, wenn ihr Durchsatz schlechter bleibt, dann sind die Algorithmusänderungen deutlich schneller geworden. Das ist im Grunde die Optimierung auf die Maschine, also diese mikroarchitekturale Optimierung, die man in C manchmal macht, im Grunde gar nicht zu verbringen gegen algorithmische Optimierungen.
Okay, aber Sie haben jetzt, dass ich das richtig verstehe, Sie wollten eigentlich Ihren Unikandel messen, aber haben jetzt gleichzeitig noch irgendwas anderes optimiert.
Ja, Sie haben jetzt gleichzeitig noch DNS-Server quasi noch optimiert.
Gut, aber das klingt jetzt schon so ein bisschen fishy, sag ich mal.
Also die Frage wäre dann, was ist, wenn ich diesen optimierten Algorithmus, was auch immer das genau ist, auch auf meinem Linux laufen lasse. Wäre der dann auch schneller oder?
Genau, der wäre dann sicherlich auch schneller. Also das nennt sich Memoization im Englischen.
Ich kann jetzt mit dem Begriff erstmal nichts anfangen. Und ohne diese Memoization sind bei 40.000 Requests gelandet pro Sekunde. Das heißt, auch noch deutlich unter diesen beiden Nein.
Okay, aber dann wäre es ja für mich tatsächlich interessant, dass auf dem, also so einen klassischen DNS-Server auch mal zu sehen, wie der dann abschneidet unter dem Linux.
Ja, Sie, also...
Also generell finde ich das ein bisschen schwierig hier, weil die Sache ist, Sie haben Unikandel, Sie haben aber auch noch eine andere Sprache, Sie haben ganz andere Software, die andere Algorithmen benutzt. Also die Vergleichbarkeit erscheint mir ja schon ein bisschen schwierig.
Mhm. Also Sie argumentieren halt dadurch, dass Sie Okaml benutzt haben, dass das eine funktionale Sprache ist. Ging jetzt halt deutlich schneller diesen Algorithmus zu optimieren. Es sind halt irgendwie 20 Zeilen von Code oder so, 20 Zeilen von Code.
Aber ich kann ja Okaml auch unter Niemens benutzen.
Genau, ja, das ist korrekt.
Also andere funktionale Sprachen.
Genau. Sie argumentieren auch noch weiter, in den letzten zehn Jahren gab es etwa 40 Schwachstellen in beiden Nein. Und Sie sagen halt, Sie sind, also im Grunde genommen sind das dann klassifiziert, 25 Prozent Speichermenschmerkfehler, 15 Prozent gab es irgendwie außergewöhnliche Zustände, die fehlerhaft abgefangen wurden und 10 Prozent so Paketparsing-Geschichten. Das heißt, gegen, oh das muss ich jetzt im Kopf machen, 50 Prozent dieser 40 Schwachstellen quasi wären Sie sicher dadurch, dass Sie typ-sicher sind.
Okay, aber das liegt jetzt auch irgendwie zum großen Teil an Okaml.
Das liegt an Okaml.
Also Sie argumentieren halt sehr, sehr häufig mit dieser Typ-sicherheit von Okaml und nicht unbedingt dadurch, dass Ihr, also das geht so ein bisschen Hand in Hand, ne. Also Sie haben eigentlich für beides, also für jetzt natürlich ja das Sprache in dem Fall Okaml und Unikonel, aber in dem Fall ist jetzt kein so starkes Argument jetzt für den Unikonel, wenn ich ehrlich bin, also in diesem Benchmark.
Ja, also die haben dann einen Größenvergleich gemacht. Miuage war bei 183 Kilo Byte.
Okay, also jetzt die Größe von dem, von der VM.
Von der VM, okay, ja klar.
Und Linux bei 462 Megabyte.
Okay, ja das, okay, das ist auch zu erwarten, weil klar, das ist leicht vorstellbar, das ist deutlich kleiner als wenn Du tatsächlich nur das mitliefst, was Du für die Anwendung brauchst.
Wobei wenn ich mir so angucke, 462 Megabyte, für den DNS ist das schon ganz schön viel oder, Linux? Ja, du bedenkst, dass da die ganzen Core-Utils, alle möglichen Dienstprogramme...
Ja, da hast Du wahrscheinlich nicht viel Zeit reingesteckt, das zu verkleinern oder? Also so ein Debian installiert und dann Dein DNS drauf.
Jaja, genau, also tatsächlich, also ich denke, wenn man sich da anstrengt oder was heißt anstrengt, wenn man darauf achte, dann kriegt man auch ein deutlich kleineres Linux.
Man könnte ja so ein hohes VR-Thema dagegen... Egal, das wird schon gerade ein bisschen zu weit.
Aber das ist interessant.
Das ist definitiv interessant, Sie haben dann noch ein bisschen, ich glaube jetzt gehst Du vielleicht durch die Decke, einen dynamischen Labservice gebaut.
Ah, okay.
Das war so twitterählich, also das mit einer In-Memory-Datenbank, was ich spannend finde, weil vorher haben Sie angekündigt, dass das quasi ein Netzwerk und Storage Benchmark ist, das ist irgendwie eine In-Memory-Datenbank, okay? Und der kann im Grunde zwei Sachen, der kann einen Postrequest entgegennehmen, das heißt etwas tweeten, und der kann einen Get-Request entgegennehmen, das sind einfach die letzten 100 Tweets.
Anzeigen, okay.
Und was Sie jetzt getestet haben, Sie haben im Grunde, Sie machen sogenannte Sessions auf, das sind neun Get-Request und ein Postrequest.
Okay.
Und Sie testen das gegen einen Nginx, da drauf ein Fast-DGI, da drauf ein Web-Py. Und Sie kommen dann raus, dass ein Linux mit diesem Web-Py 20 Sessions schafft, das heißt 200 Request quasi pro Sekunde zu bearbeiten, und das Miwage schafft 80 Sessions, also 800 Request pro Sekunde.
Okay, klingt jetzt beides ziemlich wenig, aber erwartungsgemäß ist jetzt natürlich der Python-Server deutlich langsamer, aber das ist jetzt nicht so verwunderlich gegen eine komplizierte Sprache, würde ich jetzt mal sagen.
Aber, also, wollen Sie jetzt damit irgendeine Aussage bezüglich des Unicons treffen, oder?
Ja, wahrscheinlich. Sie wollten natürlich Ihre Unicone damit benchmarken oder zeigen, dass der gut ist.
Also, warum haben Sie nicht einfach Ihren Service auf Linux ausgeführt? Das ist ja möglich, also, dass Sie Ihren in OCaml geschriebenen Service auf Linux laufen lassen.
Das ist eine sehr gute Frage.
Und dann dagegen gemessen.
Das ist eine sehr gute Frage. Entweder ich hab's falsch verstanden oder Sie haben halt zwei, fünf Sessions selber gebaut.
Also, wenn ich das jetzt richtig verstehe, wollen Sie nicht nur die Idee des Unicons hier promoten, sondern auch noch, dass eben hier in OCaml und einer typischeren Sprache und sowas zu schreiben. Aber ja, jetzt, dieses Benchmark ist ja auch jetzt sehr erwartungsgemäß mit einem Python-Service gegen einen in einer komplizierten Sprache geschriebenen Service.
Sie haben das dann nochmal anders gemessen, nämlich Statich-Lebseiten auszuliefern. Dann haben Sie dann den Apache genommen und gegen V
Okay, also hier sieht man wahrscheinlich jetzt am deutlichsten, wenn ich das einfach mal so sagen kann oder wage ich mal sozusagen den Unterschied zwischen Unicons und traditionellen Unicons vielleicht.
Auch wenn es hier ja immer noch um ganz andere Anwendungen handelt. Also man testet ja auch einen Apache gegen die selber entwickelte und wer weiß, also ein Apache hat ja vielleicht auch viel mehr Features als das, was Sie gebaut haben.
Ja, das ist auch der Punkt. Also es gibt eine ganze Menge Sachen, die der Apache kann. Der kann wahnsinnig viele Sachen. Und der HTTP Server auf Mirage, also egal wie Feature-complete der ist, der wird nicht den Apache ersetzen können.
Vermutlich nicht, also.
Ich lasse mich da gerne bessere belehren, aber ich glaube, die werde gewinnig.
Denke ich auch.
Okay, als letztes haben Sie dann noch mit den Codesize eine kleine Emulation gemacht. Der direkte Größenvergleich ist natürlich schwierig, wie viel Lines of Code eigentlich da drin steckt. Also haben Sie angefangen, Sachen, wo Sie kein richtiges Pandora's
und dann kommen Sie trotzdem noch bei 4-5 mal so viel Lines of Code in Linux raus wie in Mirage weißt. Also die da tatsächlich benutzt werden sozusagen. Genau, wo man sagen kann. Ich meine, wenn ich jetzt sehe, wie wenig ich in Haskell schreiben muss, ja auch eine funktionale Programmiersprache im Vergleich zu C oder C++, kann ich mir schon vorstellen. 4-5 mal wird vielleicht noch eher eine konservative Rechnung sein.
Ja, denke ich auch. Vor allem, wenn man jetzt, also ich weiß jetzt nicht genau, was Sie gemacht haben, aber wenn man jetzt bedenkt, dass ja normalerweise du ja keinen, also maßgeschneidenden Linux-Körnel einsetzt, sondern halt einfach den Distributionskörnel einsetzt, der einfach zumindest als modul nachladbar alles Mögliche beinhaltet, dann wird es ja deutlich, deutlich, deutlich, deutlich mehr sein, was da zumindest potentiell nachladbar ist in so einem Linux-Körnel gegenüber jetzt so einem Unicunnel, wo halt tatsächlich dann allein schon durch die dead-code-elimination während des Bauens halt nur das drin ist, was ich tatsächlich irgendwann auch mal benutzen könnte in meinem Programm.
Genau. Und deshalb auch der Punkt, das waren Sie auch noch ein bisschen nach Hause, dass Mirage OS noch nicht so featurereich ist wie das Linux oder die Anwendung da drauf, aber die meisten oder viele der hinzugefügten Features, die können halt oder werden halt einfach rausgeworfen, wenn sie nicht gebraucht werden. Und die Analyse ist auf Linux auch gar nicht so trivial. Gar nicht so. Also es ist im Grunde echt schwer zu treffen, was von Kot daraus muss, weil Function-Pointer in der Analyse schon...
Ja, also im Zweifel, es geht halt jetzt nicht so einfach.
Am Ende haben sie eine kleine Diskussion und da würde ich ganz gerne noch ein Teilgebiet davon besprechen, nämlich dem Legacy-Support, das habe ich ja oben schon mal angesprochen. Wenn man jetzt wirklich will, dass irgendwie viel der Legacy-Code übernommen wird, dann müsste man jetzt hier halt echt viel neu schreiben, also z.B. OpenSSL oder X2.
Alles in Okaml.
Alles in Okaml neu schreiben, schwierig. Das sollte man nicht einfach so machen. Aber sie sagen auch, eine höhere Abstattung wäre aber eigentlich auch wünschenswert, weil viel von diesen, gerade X2 ist halt die Dokumentation echt der Code. Da gibt es gar nicht so viele wirklich formale Dokumentationen, wie so eine X2 wohl aussieht.
Also die sagen dann, wenn es um Typ-Sicherheit gehen würde, das kann in C teilweise nachgerüstet werden, also C-Quality oder C-AL, wo man das könnte, aber es ist halt sehr schwer. Und sie sagen dann auch, wenn man das noch ein bisschen weiterführt, im Grunde haben sie ja auch sehr viel unsicheren Code als Basis, nämlich Xen.
Das ist ja auch der Grund, warum sie sagen, sie haben Xen als C-Plattform, um halt z.B. so viel die Treiberproblematik nicht zu haben. Die ganzen Bibliotheksbriefsysteme sind halt daran gescheitert, dass sie keine Treiber hatten, weil wenn die neue Grafikkarte rauskommt, dann würde ich vielleicht auch den Treiber dazu haben.
Und da sie jetzt Xen als C-Plattform haben, müssen sie halt nicht als mal eine Treiber schreiben, sondern sie haben halt schöne Geräte, die von Xen dargestellt werden. Nur, es ist halt unsicherer Code. Schreibt man jetzt neu? Wenn wir jetzt Bare Metal als Plattform haben, also es ist halt so ein bisschen schwierig. Und Sie kommen dann am Ende zur Schlussfolgerung, eigentlich wäre so ein Linux als Bibliotheksbriefsystem schon wünschenswert. Und da sind wir genau bei deinem Thema, Flo.
Ja, genau darum geht's. Nämlich, ich hab mir das Paper angeschaut, Unicornals, The Next Stage of Linux Dominance. Sie nehmen den Mund schon voll. Das ist auf der H.O.T. aus 19 erschienen, also da hatten wir schon mal ein Paper, Hot Topics in Operating Systems. Das war unsere allererste Folge über das Work.
Ja, was sagen die Leute hier? Zunächst stellen Sie fest, dass Linux ja momentan so das dominante Betriebssystem oder der dominante Kernel, das jetzt ja ein Kernel geworden ist. Also das wird auf Servern eingesetzt, auf Supercomputern, in so einer Art für uns eingebettete Geräte. Nur nicht auf dem Desktop. Nur nicht auf dem Desktop, ja. Bei mir schon, aber nicht so verbreitet, das gebe ich zu. Aber sonst wahrscheinlich das häufigste eingesetzte Betriebssystem, wenn man so will.
Genau, und im Prinzip startete Linux als klassischer Unix-Kernel. Aber mit der Zeit kamen immer weitere Funktionalitäten zu. Also irgendwie ist es in Echtzeit Kernel geworden, als Hypervisor kann man ihn benutzen. Genau, und die große Frage ist, kann jetzt ein einzelner Kernel, also Linux, diese ganzen verschiedenen Einsatzzwecke überhaupt gut erfüllen?
Und an manchen Stellen sieht man durchaus Probleme. Also zum Beispiel I/O. Da hatten wir die Folge über das Fachgruppentreffen mit XMap, also mit besseren Memory-Abstraktionen. Ja, also wo die momentanen Abstraktionen einfach nicht mehr gut genug sind für die aktuelle Hardware. Genau sowas gibt es auch für Netzwerk. Und da gibt es auch schon teilweise Lösungen, aber ja, so ganz gelöst ist das Problem nicht.
Wo man im Grunde auch am besten vorbeigeht und das direkt in User-Space reinschiebt.
Genau, das macht man jetzt teilweise. Und ja, in der Cloud ist es jetzt so, das haben wir erst festgestellt, also die Workloads laufen dann auf dedizierten, virtuellen Maschinen und eine Anwendung von Maschinen und das klassische Multiplex-Infotorsourcen wird eben nicht mehr benötigt. Deswegen hatten wir ja gerade schon besprochen, ist jetzt die Idee der Unikernel aufgekommen.
Und jetzt ist ja Linux momentan kein Unikernel und die Unikernel haben ja durchaus ihre Vorteile gezeigt. Also auch wenn wir das gerade beim Mirage an manchen Stellen hier und da ein bisschen angezweifelt haben.
Aber ja, also es gibt schon einige prinzipielle Vorteile, die so eine Verbindung, so eine Verschmelzung der Anwendung mit dem Betriebssystem mit sich bringt. Also die kann man einfach nicht leugnen. Und jetzt ist die Frage, wird jetzt Linux verschwinden? Also wird Linux jetzt ersetzt werden? Zumindest im Cloud-Bereich durch hier neue tolle Unikernelbetriebssysteme.
Die Autoren sagen dazu, dass Linux schon immer eigentlich hinterhergehängt ist hinter dem Stand der Forschung oder dem, was eigentlich aktuell war. Das hat sich schon, also das geht so nicht im Februar, hat sich schon eigentlich zu Beginn von Linux angedeutet.
Linux ist ja als klassischer, monolithischer Körnel gebaut worden und ist es ja immer noch. Klar hat ein Modul, aber es ist wesentlich immer noch. Und das war in der Zeit, als ja gerade Mikrokörnel die neue tolle Idee waren. Da gab es ja da schon sehr früh Kritik. Aber auch später ist Linux nicht so oft hinterhergehängt. Zum Beispiel Multiprozessor.
Oh ja, die waren echt lange wirklich ein Problem.
Ja genau, also als in den 2000ern das auf dem Consumer-Markt, die die Multiprozessoren, also Symmetric Multiprozessing Systems kamen, da hat Linux dann Support eingebaut, da hatten sie dann Big-Körnell-Lok und das war einfach nicht gut, das hat nicht skaliert.
Also Big-Körnell-Lok, das muss man vielleicht kurz erklären. Das ist im Grunde ein großes Lok, immer wenn irgendwer im Betriebssystem im Kern ist und Code ausführt, wird dieses Lok genommen. Das immer nur eins Wert im Betriebssystem quasi sein kann. Dieses Wert kann dann beliebige Objekte verändern, weil ihm gehört ja der Kern im Endeffekt an der Stelle. Aber es kann halt keins weiter rein. Und damit, damit mitteln wir quasi den Durchsatz von Systemcores.
Genau, also je höher dann natürlich die Anzahl an CPUs ist, desto schlechter skaliert das halt. Sehr gut vorstellbar, wenn ständig einer dieses Lok nimmt, dann können die anderen währenddessen nicht im Körnel irgendwas tun.
Ja, und genau, so da war Linux am Anfang, ist da so weiter dahergehängt und Leute haben gesagt, ja gut, das würde man in Linux nicht gut lösen können, aber ja, die Community hat dann angefangen, feinkranulare zu locken, Schritt für Schritt und inzwischen ist Linux auf dem Bereich quasi der Standard. Also wir haben sehr, sehr feinkranulare zu locken, sogar auf der Ebene von einzelnen Paged Tables oder sowas. Also im Prinzip sind wir jetzt da sehr gut bei Linux. Genau, und das Gleiche war ja auch mit Virtualisierung, also Prozess-Containment, also das war jetzt die ganzen Container-Sachen sind Docker und so weiter. Da war Linux am Anfang auch, oder hatte das einfach nicht, während irgendwie ein BSD meines Wissens sowas schon gab.
- Die hatten Jails, ne? - Genau. Und auch da hat Linux das eben eingebaut.
Und inzwischen ist es auch da wieder Standard. Also wir sehen, Linux hat irgendwie das Sachen am Anfang nicht gehabt.
Dann haben alle gesagt, ach ja, das ist schwierig da einzubauen. Da gibt es so viele Altklasse oder das Design eignet sich nicht dafür.
Aber die große Community hat das dann einfach eingebaut, und dann ist Linux da irgendwie zum Standard geworden.
In dem Bereich sogar, manchmal. Ja, und die Autoren prognostizieren im Prinzip das Gleiche für die Unicurnels.
Also die sagen, Okay, Linux wird einfach auch noch ein Unicurnel werden, zu dem ganzen anderen Zeug, was es schon ist.
Und man muss dazu sagen, für die ganzen... Linux löst das im Prinzip dadurch, dass es hochkonfigurierbar ist.
Also ich kann halt aus meinem Linux in Echtzeit Körner machen, bzw. ne, da glaub ich braucht man noch zusätzliche Patches.
Aber viele Dinge kann ich einfach konfigurieren und hab' es dann aus meiner upstream Linux Codebase aus.
Und genau das prognostizieren sie für Unicurnels auch.
Und da sie natürlich einfach nur reden wollen, haben sie das auch ausprobiert.
Und haben halt einfach mal versucht, aus dem existierenden Linux ein Unicurnel zu bauen und da halt eine Anwendung irgendwie laufen zu lassen.
Genau.
Also wie geht man jetzt vor, wenn man aus dem Linux in dem monolithischen Kern einen Unicurnel machen will?
Ja, also der Fall, dass es monolithisch ist, macht es wahrscheinlich sogar einfacher, würde ich sagen.
Es ist ja interessant, weil bis eigentlich vor nicht so langer Zeit Mikrokörne so, naja, die aktuelle gute Idee war.
Und jetzt sind es ja, werden sie ja momentan Unicurnels, so, dass das aktuell in der Forschung promoted wird.
Und eigentlich stehen sich die Ideen ein bisschen so, äh, also entgegen.
Tief entgegen, ne. Also im Mikrokern geht es darum, alles aus dem Kern rauszuhalten.
Im Unicurnel geht es darum, dass man alles im Kern drin zu haben.
Ja, eigentlich schon ziemlich entgegenstehende Ideen.
Na, jedenfalls, also weil du gerade gefragt hast, wie macht man das?
Also sie haben so ein paar Prinzipien, die finden einfach jede Anwendung.
Und das unterscheidet es jetzt zum Beispiel auch von GarageBase.
Es sollte einfach mit Linux als Unicurnel kompilierbar sein. Also wenn ich eine Anwendung hab, sagen wir mal, unser DNS Server irgendwie,
wenn der schon auf Linux laufen kann, dann sollte ich einfach noch mal kompilieren können mit Linux als Unicurnel.
Und dann habe ich ein Unicurnel Image mit der Anwendung drin.
Also nicht wie beim GarageBase, wo ich dann das nochmal neu schreiben muss in einer anderen Sprache.
Genau, und das machen sie, indem sie in GCC, zum Beispiel, das würde man dann natürlich auf Klänge usw. machen, eine neue Zielplattform einführen,
nämlich Linux Unicurnel. Es sollen außerdem keine Ringtransition stattfinden, also alles soll im Super-Baser-Modus laufen.
Klar, so ist es ja im Unicurnel. Und natürlich sollen auch diese Cross-Layer-Optimierungen möglich sein.
Also dass ich über Anwendungen und Betriebssystem hinweg optimieren kann.
Und natürlich sollen die Änderungen, die ich im Linux-Kone dafür machen muss, möglichst gering sein.
Und es soll eben auch der Fall sein, dass der Linux-Kone jetzt nicht geforkt werden muss, sondern dass ich einfach eine Option hinzufüge,
also dass ich mit der aktuellen Codebase einfach nicht mehr ein Unicurnel bauen kann.
Also eigentlich soll eine neue Konfigurationsoption für das Kconfig gebaut werden, erstellt werden, die dann sagt, ich möchte das Linux als Unicurnel bauen, dann kommt ein Unicurnel raus.
Genau, das haben sie auch gemacht. Also sie haben diese Konfigurationsoption hinzugefügt.
Sie haben dann irgendwie ein Symbol für die Main-Funktion der Anwendung hinzugefügt, die dann direkt nach der Initialisierung sozusagen das Ganze aufrufen wird.
Sie haben jetzt für die G-Libc Rapper für die System-Calls geschrieben, also dass diese Funktion jetzt nicht mehr tatsächliche System-Call-Aufrufe machen.
Also keine Ringtransition, sondern einfach einen Funktionsaufruf an die entsprechende Stelle.
Sie haben dann natürlich entsprechende Rapper im Kernel selber geschrieben dafür.
Und ja, das Linkerskript muss sie anpassen, solche technischen Sachen.
Genau, und etwas Initialisierungscode hinzufügen in den Kernel, der normalerweise in User-Space gemacht wird, irgendwelche Netzwerke, Interfaces einrichten.
Genau, und natürlich dann am Ende alles in eine Main repacken.
Und sie schreiben dann, das fand ich erstaunlich, dass die Änderungen im Kernel selber nur 11 Zeilen sind, die geändert wurden und 20, die hinzugefügt wurden.
Aber natürlich ist da nicht dabei die Änderungen im GCC und in der G-Libc. Die sind ja deutlich größer, also zumindest deutlich mehr Änderungen an Zeilen, denke ich.
Okay, aber 11 Zeilen, die geändert und 20 hinzugefügt, das ist jetzt...
Das gibt nicht viel.
Ich hätte jetzt 1000 erwartet, aber 11 und 20, das ist schon...
Ja, also ich weiß nicht, wie sie da gezählt haben. Ob sie das Linkerskript damit gezählt haben, glaube ich nicht.
Ja, gut, wahrscheinlich auch nicht jeder Stelle, wo sie diese Konflikte benutzt haben.
Weiß ich nicht, also...
Also dann hätten sie ja nur, keine Ahnung, 20 Stellen, wo sie Konflikte...
Er scheint mir auch ein bisschen komisch, aber gut, ich glaube ihnen, dass es gar nicht so viel ist. Sagen wir mal so, ob es jetzt wirklich genau so was ist. Genau, und das Ganze funktioniert. Es gab ein paar Probleme noch, also nämlich Konflikte bei Funktionsnamen.
Also im C werden irgendwelche Namen von globalen Variablen oder Funktionen einfach so immer, also im Winery landen. Also da gibt es keine Naming oder so, oder keine Scopes.
Und deswegen, natürlich wenn die Libc oder die Anwendung gleiche Namen verwendet, wie im Kernel irgendwie, dann gibt es da Probleme, die mussten sie irgendwie so lösen, temporär zumindest, also für diesen ersten Bluff-off-Konzept, dass sie die unbenannt haben.
Genau, und was sie auch gemacht haben, sie haben das Vm, also das Vmalloc im Kernel verwendet. Und das hat nicht alle Features, die so ein richtiges Malloc hat, aber ja, auch das ist prinzipiell was man lösen kann.
Und sie haben das ein bisschen evaluiert, wie gesagt, das ist nur so ein Proof-of-Concept-Papier, also da gab es keine große Evaluation, sie haben so einen Echo-Server geschrieben.
Und den gleichen Echo-Server, also einfach im User-Space eines normalen Linux laufen lassen und dann eben die Latenz gemessen. Und wir haben ungefähr die halbe Latenz im Unicurdle gegenüber einem normalen User-Space.
Ja klar, der meiste Teil davon wird natürlich irgendwo im System-Call sein, ne? Also bei einem Echo-Server ist da keine Computation, keine Rechnung, die in dem Server laufen, sondern das ist alles im System-Call oder im Briefsystem, was da die Arbeit passiert und ja, macht eine halbe Latenz natürlich auch Sinn.
Das ist keine große Evaluation, da kann man jetzt nicht allzu viel ableiten und das Ergebnis ist auch relativ verwahrtbar, weil klar, der Echo-Server wird sehr bestimmt sein von den System-Calls, also im User-Space.
Und wenn ich die eben durch normale Funktionsaufrufe jetzt ersetzt habe im Unicurdle, dann bin ich natürlich viel besser. Nicht so überraschend.
Aber trotzdem, was bemerkenswert ist, dass es laut den Autoren recht einfach war. Muss man dazu sagen, da waren jetzt auch viele Leute von Red Hat dabei.
Okay, die kennen sich da schon aus.
Ja, also auch bekannte, die im Linux-Kanal arbeiten, die kennen sich da aus und wundert mich sowieso, dass relativ viele Autoren sind, für die 11 Zeilen und die 20.
Die sind dann aufgeteilt worden, das sind typische Gruppenarbeiten, einer macht alles, der Rest schreibt seinen Namen auf dem Paper drauf.
Aber wie gesagt, hier ging es ja eher um sozusagen diese Meinung im Prinzip auch ein bisschen zu äußern, dass Linux das kann, dass Linux auch ein Unicurdle sein kann und wahrscheinlich wird.
Aber was haben die jetzt eigentlich so richtig gemacht? Okay, die haben das in eine Beine gepackt, okay?
Genau.
Aber im Großen und Ganzen, wenn ich das jetzt nicht komplett falsch verstehe, haben sie doch im Grunde die Systemcall-Transition, die Ringtransition, rausgeworfen, oder?
Ja, genau, genau. Und das Ganze natürlich in eine Beine wieder kompliziert, wie das halt so sich gehört für die Unicurdle.
Und auch da sind ja schon Optimierungen zwischen den, also zwischen den Ebenen möglich.
Da wäre natürlich wirklich spannend mal zu gucken, wie wirkt sich denn so DeadCode-Elimination tatsächlich aus in so einem, jetzt in diesem Linux-Kontext, wenn wir jetzt sagen, wir bauen jetzt gegen die Anwendung und keine Ahnung, ich mach da ein Printf und dann wird dann ein Socket jetzt komplett rausgeworfen?
Also fliegen da die anderen Systemcalls raus und dadurch dann auch alles, der ganze Rattenschwanz, der da...
Also wahnsinnig viele Ratten, sicherlich nicht, aber wenn ein Socket zum Beispiel rausgeworfen wird, weiß ich...
Also das wäre wirklich interessant.
So was schon out of the box jetzt funktioniert, ich vermute es eher nicht.
Weil du hast halt immer noch, also das wird ja sozusagen als, ja, das wird dann zusammen gelingt.
Ich glaube, das funktioniert so out of the box noch nicht. Da ist immer noch wahrscheinlich der ganze Kern irgendwie mit drin.
Siehst du, und da ist halt der Vorteil von Okame.
Ja, okay. Sieh ich ein, aber prinzipiell ist es nichts, was man nicht machen kann. Also Linktime-Optimization funktioniert an sich auch.
Vielleicht nicht ganz so gut, kann sein, wegen der nicht so starken Typisierung, aber sollte ja auch funktionieren.
Haben die jetzt hier nicht gemacht, also sonst hätten sie es geschrieben, nehme ich an, aber sollte auch funktionieren.
Ich bin gespannt, ob die Autoren recht behalten und wir in ein paar Jahren Linux als Unikonel haben werden.
Und sie sagen ja auch, dass das sogar das wichtigste Linux-Target wird.
Das Unikonel-Target, also...
Das kann ich natürlich über jedes Target sagen.
Stimmt.
Was mich jetzt noch interessiert, also wie findest du eigentlich, dass Mirage OS dieses, wir schreiben jetzt irgendwie neues Betriebssystem und es interessiert irgendwie die ganze alte Welt nicht?
Also du bist jetzt auf dieses Gleenslate, du wärst so, wir nehmen schon das Existierende hinaus.
Ja, also für mich spielt es jetzt so ein bisschen an wie der einfache Weg.
So wir bauen jetzt irgendwas und dann so wirklich interessiert uns die alte Welt nicht, aber also wir fangen nochmal von vorne an und also, verstehst du was ich meine?
Ja.
Ich meine, okay, wir prototypen jetzt gerade eine Idee, das ist die Unikonel-Idee, das ist alles in eine Beingrenzung, in so ein hohes System optimalisieren zu machen.
Aber das ist halt auch wirklich der einfache Weg und eigentlich sichert dir das doch, dass deine Idee irgendwie, oder die Wahrscheinlichkeit ist relativ hoch, dass deine Idee irgendwie in der Schublade wieder verschwindet, oder weil kein Menchstein Prototypen nutzen kann.
Das würde ich gar nicht sagen.
Bei Unikonels sehen wir jetzt, dass sich jetzt Leute in der Linux-Community und wie gesagt, das waren Leute von Red Hat unter anderem, die das gemacht haben jetzt ja Gedanken über Unikonels machen.
Und ich sehe da eher ein anderes Problem.
Und zwar hast du ja, wenn du so eine Clean Slate-Implementierung machst, und das haben wir ja, also meine ich jetzt zumindest bei Mirage erst gesehen, dass die Vergleichbarkeit einfach so wahnsinnig schwierig ist.
Weil du kannst dann sagen, ja ich habe jetzt hier ein neues System gebaut, da ist alles neu geschrieben und jetzt ist es viel schneller.
Aber liegt es jetzt daran, dass ich noch einfach viel, viel, viel weniger Features habe?
Liegt es daran, dass meine Idee tatsächlich so viel besser ist?
Also das finde ich in der Forschung so ein bisschen schwierig bei diesen Clean Slate-Implementierungen.
Ich sehe natürlich die Vorteile.
Also du kannst natürlich ein System so designen ohne Altlasten.
Es ist einfach, es geht schneller wahrscheinlich wie oder oft schneller.
Aber die Vergleichbarkeit ist sehr, sehr schwierig.
Ja, ja, das ist genau die Frage.
Also bin ich gerade schneller, weil ich weniger Features habe?
Oder bin ich gerade schneller, weil ich mich gegen diesen dicken Linux Kern vergleiche?
Oder bin ich gerade schneller, weil ich irgendwie alles statisch mache?
Ist das eine Sache, die aus meiner Idee kommt?
Oder ist das eine Sache, die eben daher kommt, dass ich mich gegen sowas großes...
Also der Linux Kern ist halt wirklich generisch.
Also wenn wir halt irgendwie auf dem Desktop laufen, auf Mobile-Forms laufen, auf Routern laufen.
Und dann komme ich irgendwie um die Ecke und ich habe was spezielles für die Cloud gebaut.
Also der Punkt ist, dass ich ja mit so einer Clean Slate-Implementierung ganz viele Variable oder alle Variable auf einmal ändere.
Und sowas ist ja eigentlich in der Wissenschaft immer ein bisschen schwierig.
Also wenn ich zwei Dinge vergleiche oder wenn ich eine Auswirkung von irgendwas feststellen will, zum Beispiel, dass ich jetzt die Anwendung mit dem Kern zusammenbinde und dann aber noch nebenbei ganz viele andere Variable ändere, wie ach ja, ich habe noch eine andere Sprache und was weiß ich, ein ganz anderes Programm, ein ganz anderes Algorithmus, dann ist die Vergleichbarkeit schwierig.
Also kannst du halt nur den gesamten Stack irgendwie messen und da müssen wir dir im Grunde glauben, dass du da wirklich irgendwie fair angegangen bist.
Also ich will jetzt nicht die Leistung dieser Mirage aus Leute hier in den Schatten, also irgendwie kleinreden, sicher nicht.
Und ich habe es auf das Papier nicht gelesen, aber an manchen Stellen ist es glaube ich tatsächlich die Vergleichbarkeit schwierig.
Ja, ich glaube du läufst halt relativ schnell in die Gefahr rein, weil du halt einmal von null anfängst und dann wirklich das Vertrauen aufzubauen, deinem Leser gegenüber quasi, dass du wirklich ehrlich arbeitest und ehrlich gearbeitet hast, das ist halt schwierig.
Also du kommst sehr schnell in die Situation, wo der Nutzer denkt, Moment, vorne habt ihr den 3,1 Kern gemessen, hier messt ihr den 2,6 und da messt ihr den, wo quasi jedes Krümelchen irgendwie interpretiert wird, also ja, aber hier haben wir es dir gerade nicht ganz fair.
Ja, aber selbst wenn es sozusagen irgendwie, also es ist ja nicht nur dieser Verdacht des Problems, sondern es ist ja auch tatsächlich, ändern sie ja alle Variable. Aber klar, das kommt natürlich auch noch dazu.
Wobei das ja, also auf der anderen Seite ist natürlich auch ein, nehmen wir die Idee an, wir hätten ein perfektes Cloud-Betriebssystem.
Ja, okay.
Das ist eigentlich das Maximum in Anstattung der Performance, was wir hier herausholen könnten.
Okay, ja, das sind mal die Punkte, den habe ich noch nicht so bedacht.
Ich meine, also natürlich der Punkt mit, wir ändern hier den Algorithmus, das deckt das natürlich nicht ab.
Man sollte natürlich trotzdem irgendwie fair messen und die Anwendung auf beiden Systeme identisch haben, wenn man das Betriebssystem messen will.
Aber im Grunde, im Kern finde ich die Idee eigentlich gar nicht schlecht zu sagen, wir haben jetzt hier ein Prototyp, der eigentlich das ideale Cloud-Betriebssystem darstellt.
Ja, ja, insofern und die Idee eines Unicorns ist ja jetzt nicht schlecht, das haben ja auch folgende Forschungen und so was und jetzt natürlich auch der Fakt, dass es so viel aufgegriffen wird, unter anderem jetzt auch von eben Linux-Entwicklern, das haben, also das effektiv ist, steht ja außer Frage, also.
Ganz genau. Und damit werden wir wieder am Ende der Sendung. Und wie immer am Ende der Sendung die Frage, was haben wir eigentlich gelernt?
Ja, ich habe gelernt, dass die alte Idee der Bibliotheksbetriebssysteme jetzt wieder benutzt wird, um effiziente und typ-sichere Single-Purpose-Betriebsmaschinen zu implementieren.
Und ich habe gelernt, dass die Idee der Unicorns, auch wenn sie im Clean-Slate-Betriebssystem erstmals implementiert wurde, jetzt auch in Linux Einfluss finden wird und Linux damit die ganze Welt aufrisst.
Und wenn ihr einmal in die Paperreihe schauen wollt, dann sind die entsprechend in den Show Notes verlinkt, ebenso wie die Website der Unicorns, wo ebenfalls ein paar interessante Paper zu dem Thema drinstehen und drin verlinkt sind und damit bleibt nur zu sagen, Florian Rommel, vielen Dank.
Vielen Dank, Stefan.
Und euch vielen Dank für die Aufmerksamkeit.
[Musik]