 Herzlich Willkommen zum ersten Tag der 21. Gulasch Programmiernacht hier zum Talk über das Serenity OS Betriebssystem und warum es euch interessieren sollte. Seit 2018 entwickelt der schwedische Entwickler Andreas Kling nach einer etwas dunkleren Zeit seines Lebens in seiner Freizeit an einem UNIX-artigen Betriebssystem namens Serenity OS, welches visuell den 90er Jahren entspricht. Dabei ist jede Komponente von Grund auf neu entwickelt vom Kernel bis zum Browser und heute wird das kleine Filmröhrchen, welches lange an dem Projekt mitarbeitet, ein wenig mehr darüber erzählen. Viel Spaß. Dankeschön. Wie schon angekündigt, ich rede heute über das Serenity OS Betriebssystem und warum es euch interessieren sollte. Zum warum es euch interessieren sollte, Teil kommen wir erst ganz am Ende. Erst mal reden wir über das Betriebssystem. Was bin ich? Ich studiere rein in der Theorie Informatik. Man findet mich auf Macedon und auf Matrix und ich mache alle sechs Monate etwa ein YouTube Video oder so und außerdem natürlich für diesen Talk wichtig. Ich entwickelt seit etwa zweieinhalb Jahren bei Serenity OS mit. Ich habe da über 500 Commits. Das heißt, ich würde schon behaupten, dass ich einige Dinge über dieses System sagen kann. Genau, was ist eigentlich Serenity OS? Ich habe schon mit vielen Leuten geredet, die haben es schon etwas davon gehört. Viele haben vielleicht noch nichts gehört. Hier habe ich mal so ein paar Deskriptoren aufgelistet, wie ich das System beschreiben würde und über all diese Dinge werden wir in mehr Details in der nächsten Stunde reden. Genau, ganz kurz noch zur Geschichte. Es wurde schon angekündigt. Andreas Kling, der das Projekt gestartet hat und immer noch so die wichtigste Person ist, würde ich behaupten. Der hat eben von seiner Drogenabhängigkeit einen Zug gemacht, 2018 und hat dann nach einem sinnvolleren Zeitvertreib gesucht und das wurde eben Serenity OS 2019. Hat er angefangen, seine Arbeit am Projekt auf YouTube zu veröffentlichen und da kommt auch so ein Hauptteil der Bekanntheit vom System her. Da kennst vielleicht einige schon und da wurde das Projekt auch mehr und mehr bekannter und dann 2020 würde ich sagen, ging es tatsächlich weg von so diesem ein-personen-Projekt, wo dann sehr viele Leute daran angefangen haben zu arbeiten. Inzwischen sind es über 700 Leute, die jemals schon einen Komet gemacht haben, regelmäßig so 100 Mitarbeiter im Monat. Genau, 2021 hat die Projektkommunikation von IRC auf Discord gewechselt und in dem Rahmen hat das Projekt einen riesen Schub an Aufmerksamkeit erhalten, habe ich hier Discord-Explosion betitelt und in dem Rahmen bin ich auch so zum Projekt gestoßen. 2022 war das Jahr des Browsers, da hat der Browser-Acid 3 bestanden und das Projekt Ladybird wurde ins Leben gerufen, auch die programmiersprache Jagd, zu der wir ganz am Ende noch kommen. Und 2023 ist bisher so das Jahr des Körners, denn wir haben 32 Bit rausgeschmissen und sind gerade an ARB64 am Arbeiten. Genau. Zunächst vielleicht die Frage auch, wenn jemand ein Laptop da hat, kann er ja mal versuchen, ob er während des Talks das Ding zum Laufen kriegt. Es gibt keine Isos und Binarys, das ist ein altes Meme. Hab nicht ich gemacht, kommt aus dem Serendint-US-Discord-Server und der Grund ist einfach, dass es uns zu viel auffand ist und vor allem, dass es auch nicht viel auffand ist, das System selber zu bauen. Das sind nämlich im Endeffekt alle Schritte. Ihr klont das Projekt, ihr installiert ein paar Packages beziehungsweise mit nix, könnt ihr einfach nix-shell und dann die nix-Datei halt machen, die wir dafür haben. Dann führt ihr dieses Shellscript mit dem Argument Run aus und dann je nachdem, wie viele schon gebaut hat, baut ihr die komplette Toolchain, baut ihr das ganze System und das öffnet sich in der virtuellen Maschine in QEMU und genau das ist, das ist alles, was man dafür tun muss. Also könnt ihr gerne ausprobieren, Serendint-US.org beziehungsweise, da findet man auch den GitHub Link dazu. Genau, noch mal von vorne, was ist es und wie funktioniert es. Hier ist mal ein Screenshot, der hat jetzt sehr, sehr widerliches Scaling, warum, das werdet ihr gleich noch sehen. Auf jeden Fall sieht man da schon die 90er UX, die schon angesprochen wurde und wir finden einfach, dass diese Art von User Interface extrem gut zu bedienen ist für Tastatur und Maus, für Desktop-Systeme und dass man eben nichts anderes braucht, so dass es sehr funktional, sehr power-userfreundlich. Man sieht hier links oben zum Beispiel ein normales Terminal mit normalen Unix Tools. Wir haben ein System Monitor, ein Spreadsheet-Programm, ein File Manager, links unten den Browser und dann habe ich hier einfach noch zwei Widget-Galleries aufgelegt, um euch so zu zeigen, wie verschiedene andere UI-Komponenten aussehen. Und wie man schon sieht, das ist alles sehr, sehr einheitlich. Das System ist aus einem Guss, wie nachher das in der Software aussieht, das guckt man uns noch an, aber schon allein visuell passen alle Programme zusammen und auch zum Window-Manager und es gibt auch verschiedene Themes und das Cool ist jetzt eben durch diese ganze Einheitlichkeit alles, was ich machen musste, um diese vier verschiedenen Screenshots zu erstellen, ist einmal ins Stadtmenü zu gehen und dann das Team zu ändern. Alle Programme empfangen die Änderung automatisch und ändern sich da und es funktioniert perfekt. Es gibt auch Themes, die eben verschiedene spezifische Systeme nachahmen. Zum Beispiel haben wir links oben was, was Windows 2000 nachahmt, das benutze ich persönlich ganz gern. Das rechts oben wäre das High-Contrast Team und dann eben unten die Standard-Dark- und Light-Teams. Genau und ansonsten auch, was so die Funktionalität vom ganzen System angeht, ist es glaube ich wesentlich mehr als ein 90er Vertriebssystem. Wir haben ein PDF-Viewer, wir haben ein Synthesizer-Programm, ein Email-Cline, ein SQL-Server, inklusive IDE. Wir haben ganz normale Utilities wie Text-Editors und Text-Editors, aber auch kompliziertere Programme wie ein Pixel-Mal-Programm, also ein Paint-Clone und Spreadsheet, also ein Kabellen-Kalkulation-Programm, das tatsächlich auch Formeln unterstützt. Dann haben wir, unterstützen wir so ziemlich jedes Bildformat, einige Audio-Formate und ein, zwei Video-Formate, dann nimmst du die Kurve immer ab, je komplizierter das Datei-Format wird, aber die lassen sich eben alle öffnen und teilweise auch bearbeiten. Von Spielen her haben wir auch einiges im System drin. Da gibt es so die Klassiker wie Solitaire und Snake, aber auch moderne Spiele wie Flood und Wirtle. Wir haben auch gute 3D-Unterstützungen, sehr, sehr guten OpenGL Software Renderer und ein 3D-Viewer und auch ein High-DPI-Mode. Und ansonsten gibt es noch so sonstige Systemverwaltungen, Unix-Posix-Tools, was man so alles kennt. Also ist eben auch ein Posix-System, was man Unix-System, was man mit üblichen Befehlen bedienen kann. Wie ihr vielleicht schon bemerkt hat, anhand dem beschissenen Scaling, diese ganze Präsentation läuft innerhalb von 7DOS. Wenn ich mal kurz Escape-Druck sehe, die hier, dass das ganze System da drin läuft. So und dann schalte ich euch auch mal wieder die Fußzeile an. Das muss der weg sein, damit die Illusion erhalten bleibt. Also was ich ganz kurz noch zeigen wollte, ist ja genau, das ist ein spezieller Bild. Wenn ihr auf das Report geht am Ende, dann wird da noch ein bisschen erklärt dazu, wie ihr genau dieses Ding auch auswählen könnt. Egal, genau hier haben wir eine Vision Information. So, weiter geht es. Hier unten nur noch mal eine Liste an Sachen, die alles in einem Repository implementiert werden müssen von einem Projekt, damit so was hier läuft. Genau. Also übrigens um fährt zu sein, das ist eine virtuelle Maschine zu Bear Metal, kommen wir nachher noch. Genau. Das letzte Programm, was ich schon ein bisschen erwähnt hatte, aber noch nicht drauf eingegangen bin, ist der Browser. Und der Browser ist halt eine der herausragendsten Merkmale von SerenityOS. Und der ist ziemlich gut. Der hat eine JavaScript Engine, der hat CSS, der hat einen sehr guten Layout und Renderer, der hat WebAssembly, der kann ganz, ganz viele moderne Standards. Hier ist zum Beispiel mal eine GPN Wiki Seite, also das GPN Wiki ist super zum Navigieren, nur der Fahrplan nicht so. Also dann merkt man halt so den Neuigkeitsunterschied zwischen, keine Ahnung, Media Wiki und Pre-Talks. Aber gut, diese Seite, also ich könnte mich mit dem SerenityOS Browser problemlos über die GPN informieren, sag mir mal so. Wenn wir zur Compliance kommen, JavaScript sind wir momentan insgesamt bei 85 Prozent der Test2.6.2-Tests. Die Test2.6.2-Tests sind die Standard-Spec-Test-Suit von JavaScript. Das heißt, es gibt nichts, keine offizielle Test-Suit. Hier seht ihr mal ein Vergleich mit ganz vielen anderen Engines, die übrigens dieser Vergleich wurde übrigens erstellt, weil ich mich beschwert habe, dass es aktuell keinen vernünftigen Vergleich im Internet gibt. Genau, wen es interessiert, V8 hat auch 85 Prozent und das sind die zwei besten Engines. Das bedeutet nicht, dass wir im Web besonders gut sind, das bedeutet nur, dass wir eigentlich ziemlich compliance sind. WebAssembly ist ein bisschen schlechter, da ist aber auch die Hälfte irgendwelche Simly-Tests. Und die Web-Driver-Tests, also die Vollintegrations-Tests, die auch für die WPT.fy-I-Seite, für die Web-Interoperability-Seite verwendet werden, diese Tests können wir noch nicht ganz durchführen, aber das sind gerade Leute dran. Das kommt, gehe ich davon aus, dass es in ein, zwei Monaten dann läuft. Genau, wenn ihr den Browser außerhalb von Serenity ausprobieren wollt, habe ich schon erwähnt, gibt es das Projekt Ladybird. Das ist einfach eine Cutie-Frontend, ein Cutie-Frontend für die genau die gleiche Engine, die auch im Browser selber verwendet wird. Und das findet man auch im EUA. Es gab auch mal ein Android-Bild, der tut mittlerweile nicht mehr ganz, aber da wird auch wieder dann gearbeitet, dass der wieder tut. Genau. Das heißt, wenn ihr das extern verwenden wollt, da ist es auch ein Stück schneller und schöner, dann könnt ihr das auch machen. Genau. Jetzt gibt es natürlich diese ganzen tollen Programme, aber ihr wollt doch garantiert eure Lieblingssoftware, WIM, E-Max, Bash, Half-Life, FFM-Pack, Python oder Klang verwenden. Naja, dafür gibt es über 300 Ports. Das Porting-System haben wir, wie man sehen kann, von den BSDs geklaut. Es gibt noch ein paar Sachen, die wir von den BSDs geklaut haben, die kommen nachher noch. Und die Ports funktionieren genauso wie bei einem BSD-System. Das heißt, ich habe da diesen unter dem Ports Verzeichnis, den Unterordner, der zu diesem Port gehört. Darin sind Patches für den Source Code von dem Port. Und wenn man dann dieses Packaging Script ausführt, dann wird der Source Code runtergeladen, gepatched und kompiliert für so eine TOS. Momentan nur außerhalb. Wir arbeiten aber daran, dass es auch demnächst innerhalb vom System funktioniert. Und wenn euch die Ports und die verfügbaren Ports interessieren und wie man so Porting durchführt, dann gibt es da diese zwei Seiten, die ich empfehlen kann. Also das Zweite ist ein Fahrt im Github repo, das erste wäre da die Website dazu. Die Recha gemacht hat, der hinten sitzt, wenn ich ihn mal erwähnen darf. Genau, kommen wir jetzt tatsächlich zum Software Stack, was wahrscheinlich viele noch viel mehr interessiert. Und das ist wirklich so unser wichtigster Punkt. Was macht jetzt mein Bildschirm? In SerenityOS gibt es keine einzige Zeile fremden Code, die von irgendwo anders her kommt, die reinkompiliert wird und keine Abhängigkeit, die wir irgendwie zur Bildzeit oder so runterladen. Das ist eine vertikale Integration, die man sonst, glaube ich, nur bei Apple findet. Also ich bezweifle, dass irgendein anderes Betriebssystem, Open Source Betriebssystem so stark vertikal integriert ist. Ja, okay, das, ja, Plan 9 war da der Kommentar. Das würde ich vielleicht noch glauben. Mit dem können wir aber auch reden. Es gibt auch ein Plan 9 Fallsystem. Genau, mit keine externen, keine externen Source Code Abhängigkeiten, meinen wir übrigens auch keine Standard Bibliothek. Und da kommt ebenso unser spezieller Stil von C++ her, den wir Serenity C++ nennen. Das ließ sich teilweise mehr als Rust als als C++. Und wogegen ich jetzt natürlich gar nichts hab? Die Compiler sind nur minimal modifiziert, hauptsächlich, dass sie die Plattform erkennen. Und die Standard Bibliothek wird eben ersetzt durch unsere eigene Standard Bibliothek mit den Namen AK. Darauf aufbauend gibt es so die ganzen wichtigen Bibliotheken, unsere eigene C Bibliothek, dann irgendwelche vernünftigeren C++ Bibliotheken wie Libcore und dann kommen schon so Sachen wie GUI und Web, die sich da so umdrauf stapeln. Die Utilities bauen direkt auf den Bibliotheken auf. Und da findet man so das ganz normale Postexzeug für die Command Line. Die Services sind unsere Demons, die irgendwelche Aufgaben ausführen, wie zum Beispiel am wichtigsten der Windows Server, der übrigens weder ex noch Wayland kompatibel ist, der hat sein eigenes Protokoll. Und die Anwendungen sind deshalb oder die GUI Anwendungen sind deshalb anders als die Utilities, weil sie mit den Services reden und so eine Utility redet im Normalfall mit nichts außer mit dem Kernel. Wenn die Prozesse jetzt tatsächlich miteinander reden, dann tun sie das über unser eigenes Interprozess Kommunikationsprotokoll. Das ist eigentlich ein Remote Procedure Call System, wo wir zwei C++-Objekte haben, die sich Nachrichten schicken und die werden dann als Funktionsaufrufe umgesetzt. Das könnte man auch anders implementieren. IPC kann man verwendet im System selber Unix Domain Sockets. Es haben aber auch schon Leute geschafft, das durch TCP zu tunneln und Remote Desktop und sowas zu bauen. Ist nicht im System drin selber leider, aber das haben schon Leute hingekriegt. Mit dem Kernel selber reden wir, wie es in jedem normalen Postexkernel oder in jedem Kernel hoffentlich funktioniert. Wir haben verschiedene System Calls und wir haben ein virtuelles Dateisystem. Das hier ist jetzt das Repository Layout wieder mit dem widerlichen Scaling, weil den Scaling Algorithmus haben wir selber gebaut. Da sieht man hier eben die Standardpibliothek AK, dann die Sachen, die standardmäßig ins ROOT Fallsystem reingeschoben werden unter Base, die externe Dokumentation, den kompletten Kernel. Ladybird eben so als extra Ding, weil es eben QT Code enthält, aber nicht so richtig eigentlich zu Serenity dazugehört. Wir haben ganz viel CI-Scripten und Blödsinn in Meter. Die Ports habe ich schon erklärt. Ganz viele Tests, die im System laufen und außerhalb die Toolchain Dateien, also Compiler Patches usw. Und zum Schluss das Userland, wo so der ganze Rest aus dem Userland hat, lebt und das sieht man hier zum Beispiel so wichtige Ordner wie die Services und die Utilities und die Applications. Genau. Gehen wir weiter zum Kernel. Über ein Kernel werde ich wahrscheinlich relativ viel reden oder ja werde ich viel reden, wenn ich so auf meine Zeit tucke, weil das glaube ich ganz interessant. Es ist ein monolithischer Kernel. Wir hatten mal Kernelmodule, die wurden dann aber irgendwann rausgeschmissen, weil es halt niemand braucht. Es ist eben ein POSIX-mäßiger Kernel, der auch sich von außen wie ein POSIX-Kernel verhält, aber auch von innen. Also auch der Kernel arbeitet z.B. intern mit so was wie File Descriptors usw. Er ist zunehmend Architektur unabhängig. Momentan die Hauptarchitektur ist logischerweise x8664. Wir haben mal angefangen mit x8632. Das wurde Anfang diesen Jahres entfernt, weil es keiner mehr braucht. Und RG64 sind wir gerade insbesondere auf dem Raspberry Pi, so am Bring Up dran. Das tut schon so halb. Das virtuelle Datei-System ist auch so wie man es üblicherweise kennt. Wir haben ein Proc-File-System, ein Assist-File-System, ein Device-Tree, der darunter lebt mit nur minimal anderen Namen, was man sieht, z.B. in Linus erwarten würde. Das große Problem ist, dass wir an konkreten Datei-System- implementierungen bisher eigentlich nichts außer EXT-2 haben, wenn man mal von CD-ROM und Plane 9 abzieht. Genau, aber unser EXT-2-Treiber, der ist gut abgehangen und der funktioniert. Genau. Wie sieht es denn mit Multi-Prozessenunterstützung aus? Das wollte ich euch demonstrieren. Da habe ich mal die Sven-PC-PUS auf 4 gesetzt und dann den Kernel-Script so ausgeführt, mit der eben Kernel-Command Line SMP gleich on, dass er eben Multi-Processing macht und dann habe ich direkt diesen Output gekriegt. Also wenn man das ganz hinten nicht lesen kann, hier oben steht Kernel Panic. Das heißt, der Kernel ist abgeschmiert. Der hat bemerkt, dass irgendein Zustand nicht vernünftig war. Ich glaube, in dem Fall hat er einfach ein Prozess, während er ein Interrupt-Disable hatte, er wurde ein Prozess auf einen anderen Kern geschoben. Das sollte nicht passieren bzw. damit können wir nicht umgehen, weil wir denken, okay, wir haben keine Interrupts, wir werden nicht rumgeschoben. Das stimmt nicht. Die Details sind eigentlich gar nicht so wichtig. Auf jeden Fall ist SMP so ein großes Problem von Serenity. Wir versuchen es. Wir haben verschiedene Mechanismen. Auch für Deadlocking ist auch immer ein großes Problem für Lock-Ranks. Wenn das jemandem was sagt, haben wir viel dran gearbeitet. Aber wir sind eben noch nicht zu weit und das wird sich hoffentlich in der Zukunft noch verbessern. Genau. Hardware-technisch sieht Serenity sehr gut aus. Wir können mit, wir buten nur auf Beers, nicht auf UEFI, das fehlt hier in der unteren Liste. Wir sprechen die VGA-Extensions, so dass wir können eigentlich überall ein Framebuffer hinkriegen. Wir haben PS2-Maus unter Satutreiber. Das ist auch das, was hier die virtuelle Maschine verwendet. In Sachen Festplatten können wir IDIs, SATA und NVMe insbesondere nicht ganz optimal, aber es tut. Wir haben tatsächlich USB 1.0 so halb unterstützt, eben zumindest in der Ebene vom UHCI-Treiber. Wir haben ein Ethernet-Stack und logischerweise, wie man sich denken kann, einen TCP-IP-Stack unseren eigenen. Wir können mit PCI-Geräten reden und können inzwischen tatsächlich auch Message-Signal-Interrupts. Das hat einige Zeit gebraucht. Das ist dann der neuere, bessere Interrupt-Mechanismus. Audio-Hardware-technisch tatsächlich, also von den Treibern her, sieht sehr gut aus. Mit AC97 und Intel-HD-Audio haben wir so gut wie alles an internen Soundkarten, die auch schon auf Bare Metal getestet wurden. Das heißt, da kann man viel Audio damit machen mit dem Audio-Stack, an dem ich so 90% des Codes beigetragen habe. Was halt fehlt, ist eben alles, was mit USB-Gerätetreibern zu tun hat. Also man kann ein USB-Gerät theoretisch initialisieren, da irgendwelche Functions ansprechen. Ich kenne mich nicht so genau aus, aber das scheint alles zu tun. Nur es gibt halt keine Treibern, nicht mal für so einfache Sachen wie Human-Device-Interfaces. Und eben alles, was über USB 1.0 rausgeht, ist noch nicht vorhanden. Grafikkartentreiber haben wir nur irgendwas für Intel und für Word.io, GPUs. Aber ansonsten ist Grafikkarten auch Fehl am Platz und vor allem auch irgendwelche Hardware-Beschleunigung fehlt noch komplett. Und ein WLAN-Stack gibt es auch nicht. Genau, aber wir können auf Bare Metal buchen, buchen, buten. Das ist jetzt von Linus Gro, einem der Hauptentwickler, so sein Laptop. Da butet er das regelmäßig und es funktioniert sehr gut. Wie man sieht an dem Dingens, der Framebuffer funktioniert, die Tastatur, die Maus funktionieren. Da gibt es ein kleines rotes Ding rechts unten in der Ecke hier. Das bedeutet, Netzwerk tut nicht. Das überrascht jetzt wahrscheinlich niemanden, aber jedenfalls ist das System ohne Internet sehr gut benutzbar. Auf Bare Metal, genau. Also, es ist nicht komplett ohne Probleme. Man muss immer ein bisschen rumprobieren, vielleicht auch noch mal eine serielle Konsole anschließen und dann debuggen. Aber wenn ihr daran Interesse habt, gibt es den Bare Metal Channel auf Discord, wo ich die Leute auf jeden Fall weiterhelfen, wenn ihr mal ein Bare Metal Boot ausprobieren wollt. Und es gibt auch schon so Halbwegsanleitungen dazu, wie man das grundsätzliche Setup macht. Genau. Dann mal die Demo zum Bare Metal Boot, genau. Jetzt gehen wir tatsächlich mal aus der WM raus und in irgendein Dingens, wo hoffentlich nichts Sensitives draufsteht. Genau, ich habe hier so ein, jetzt muss ich ein bisschen größer machen. Ich habe hier so ein minimales Hardware Setup. Das muss man auch nicht sehen, das ist nicht schlimm. Da ist ein Arduino Uno, der als serielle Konsole funktioniert und dann ein Raspberry Pi 3B komplett unmodifiziert vor einer SD Karte mit dem RH64 Image von etwa fünf Patches sind da drauf und das wurde mir heute Mittag noch schnell zugespielt, weil es jetzt noch hoffentlich ein bisschen weitergeht, als ich das bei der FSEC hatte. Das ist auch die Leute, die bei der FSEC schon da waren. Die sehen auch noch mal was. Genau, dann schließen wir das doch mal an und gucken mal, was auf der seriellen Konsole so rauskommt. Da hatten ein paar Sekunden. Perfekt. Genau, der hat jetzt gebooted, ist auch schon im Scheduling tatsächlich drin. Sieht mir hier oben, Scheduler iLoop Running. Jetzt versucht der Grad die SD Karte zu initialisieren. Das geht jetzt ein bisschen weiter, als es noch vor ein paar Tagen getan hat. Nur jetzt kriegen wir hier IO Fehler, weil was weiß ich, irgendwas ist halt falsch und dann gibt es irgendwann auf und ein Current Panic kommt. Allerdings in der virtuellen Maschine in QEMU tauchen diese Probleme nicht auf. Da buten wir bis ins Userland schon. Genau, das war die Metal Demo. Zurück zum Talk. Genau, zur Security. Unser Kernel und unser komplettes System ist nicht unbedingt primär fokussiert auf Sicherheit, aber wir nehmen Sicherheit extrem ernst. Dazu gehört, dass wir die Pledge und Wailmechanismen von OpenBSD geklaut haben. Es gab vor zwei Jahren oder vor drei Jahren, ich erinnere mich nicht mehr auf der GPN auch ein Talk zu OpenBSD, der so ein bisschen diesen Talk inspiriert hat. Und deshalb wollte ich jetzt auch noch mal über Pledge und Wail reden. Für die Linux Benutzer, die es noch nicht gesehen haben. Pledge ist ein Mechanismus, wo das Programm sagt, okay, ich benutze nur noch SysCalls aus diesen Gruppen. In diesem Fall sind die Gruppen Standard, Input, Output, Dateien lesen, R-Path, Unix Sockets, Prozesseverwaltung, Thread Verwaltung, auch allgemein Threads starten zum Beispiel. Und das sind relativ grobe Gruppen. Unsere Gruppen sind nicht genau gleich wie bei OpenBSD, wenn das schon jemand kennt. Wir haben dann paar Variationen drauf. Jedenfalls der Prozess gibt damit freiwillig Fähigkeiten ab, die er nicht braucht, zum Beispiel, wie dieser Prozess mit dem Internet reden. Das kann der nicht mehr und damit verhindern wir, wenn dieser Prozess nachher übernommen wird oder irgendwas Bösartiges tut, dass der dann nachher nicht eben irgendwas tun kann, weil sobald der ein Syscall ausführt, den er nicht gepludged hat, dann wird er sofort vom Kernel abgeschossen. Und man kann auch Pledge ist, die man schon weggeworfen hat, nicht mehr wiederkriegen. Man kann aber die, die man noch hat, dann durch einen neuen Pledge-Aufruf noch weiter reduzieren. Gerade zum Beispiel beim Startup braucht man manchmal ein paar mehr Permissions, um da Konfig-Dateien zu lesen und die kann man dann stückweise wegnehmen und dann mit ganz wenigen, im Hauptbetrieb mit ganz, ganz wenigen Permissionsarbeiten. Das gilt eben nicht nur für normale Befehlzeilenprogramme, sondern auch für GUI-Programme. So gut wie jedes Programm in Serenity ist über Pledge abgesichert. Dieser zweite, das zweite Argument damit ist IO nach dem Komma, ist für die Kindprozesse. Das heißt, man kann dann verhindern, dass Kindprozesse was für sich tun. Man kann den Kindprozessen eben auch weniger Permissions geben, als sie theoretisch haben könnten. Und hier ist einfach mal als Beispiel, das ist ein bisschen älter, aber so war dieses Präsentationsprogramm, das ich für diesen Talk ja geschrieben habe. So war das am Anfang abgesichert. Ihr seht auch hier schon spezielles Serenity-Main, das einfach mal ignorieren, was wir auf jeden Fall machen, ist den Pledge System Call mit den Permissions, die wir brauchen. Studio braucht eigentlich jedes Programm. Wir müssen die Präsentationsdateien und auch Bilder laden können. Wir brauchen Unix Send File Descriptor und Receive File Descriptor, um im Windows Server reden zu können und auch um Bilder zu dekulieren zu können. Warum das? Das erkläre ich gleich noch. Genau und dann geht man eben so im Geiste durch. Was braucht mein Programm und alles andere schaltet man aus. Im schlechtesten Fall wird man dann abgeschossen, da muss man halt eine Pledge wieder hinzufügen, aber das ist so ein Minimalprinzip eben. Genau, gehen wir weiter zu Unveil. Unveil ist ein ähnlicher Mechanismus, nur der ist tatsächlich aus Dateisystem gelegt ist, weil wenn man nur eben festlegen kann, Lesen, Schreiben, Dateien erstellen, das wäre ein bisschen ungenau. Das heißt Unveil bedeutet, ich kann bestimmte Ordner unter bestimmte Dateien mit bestimmten Permissions, in dem Fall eben Read and Write, freigeben. Und das kann ich auch mehrfach machen. Also Unveil ist nicht so wie Pledge, wo ich immer reduzieren muss, sondern Unveil kann ich erst mal beliebig machen und dann genau das eben freigeben, was ich brauche. Und dann mache ich ein Unveil No-Pointer, No-Pointer und dann ist der Unveil zu und dann kann ich nichts mehr am Unveil ändern. Und dann kann ich eben nur noch auf diese Dateien zugreifen, die dort angegeben sind. Alles andere gibt dann einen Innoent oder keine Ahnung, den Fehler für Dateien, die nicht existieren aus. Und wenn ich auf eine Dateizugreife, auf eine Art und Weise, die ich nicht darf, zum Beispiel den Downloadordner dürfte ich nicht erzeugen, weil ich keine Create Permission habe, dann kriege ich einen E-Perm, also einen normalen Permission Error. Und das bedeutet dann, dass ich das Dateisystem nochmal separat absichern kann und grad so was wie ein Browser, kann man darüber eben sagen, OK, du darfst nur Dateien runterladen und alles andere darfst du nicht. Damit es im OpenBSD Talk gab es dann tatsächlich eine Demo mit Chromium, was eben über auf OpenBSD mit Unveil abgesichert ist. Und wenn wir das eines Tages, wenn das eines Tages mal jemand porten will, was ich nicht empfehlen kann, dann könnt ihr einfach die OpenBSD Unveil Calls direkt drin lassen, die funktionieren bei uns genauso. Genau. Ansonsten haben wir noch quer durch System ein paar Mehr-Sicherheitsmechanismen. Der Kernel wird auf zufälligen Adressen geladen. Der Kernel hat bestimmte Speicherbereiche, die zum einen nach dem Init aus dem Page Table rausgeschwissen werden, weil es nur Initialisierungsroutinen sind oder Routinen, die Speicherbereiche, die nach dem Init nur noch lesbar sein sollen, damit man dann nicht darauf rumpfstampeln stampfen kann und dann dem Kernel irgendwas machen lässt. Hier gibt es ein paar schöne Befeßsein Argumente mit denen man sehr gute Garantien vom Compiler kriegt. Wir haben ähnlich wie OpenBSD keine Speicherseiten, die gleichzeitig schreib- und ausführbar sind. Beziehungsweise man kann ein Dateisystem speziell mit der Permission einhängen, dass ausführbare Programme in diesem Dateisystem das dürfen. Das brauchen wir für manche Ports, braucht OpenBSD für manche Ports. Deshalb existiert dieser Mechanismus. Aber im Allgemeinen Fall sind so schreib- und ausführbare Speicherseiten gleichzeitig ein Zeichen für ein Programm, das gerade Shellcode in sich injected bekommen hat. Und das wollen wir nicht. Und deshalb ist das auch ein Crash. System Calls dürfen nur außer Lipsy kommen. Das hat auch Linux. Prozessjails ist von FreeBSD oder DragonflyBSD geklaut. Weiß ich gerade nicht mehr. Auf jeden Fall sehen die Prozesse dann nur noch die Prozesse in ihrem in ihrem Jail und damit kann man eben eine Gruppe an verwandten Prozessen, die nur mit sich gegenseitig reden sollen, eben einsperren. Deshalb auch der Name Jail. Es gibt für alle komplizierten Decoding Vorgänge, insbesondere alles, was mit dem Web zu tun hat und alles, was mit Bilddekodierung zu tun hat, separate Prozesse, die eben zum Beispiel komplett keiner Zeitzugriff haben und eigentlich sonst auch gar nichts können, außer die die Daten nachher zurück schicken. Und das ist ja eben den Vorteil. Also zum Glück funktioniert so jeder moderne Browser. Aber das hat eben den großen Vorteil, dass man, dass man dann bösartige Dateien, dass sie nichts anrichten, außer die diesen Prozess abschießen. Und insbesondere sowas wie standardmäßige Out-of-Process-Image-Dekodierung, die wir überall drin haben. Das habe ich bei sich, bei nicht vielen Betriebssystem. Ich habe auch schon Windows mal kurz drei Minuten hängen lassen, weil ich irgendwie eine viel zu große PNG dem gegeben habe. Und das wird dann kurz in process dekuliert. Genau, das tun wir nicht. In allen User-Land-Programmen gilt generell das Fail-Fasten-Standard ist. Das heißt, wir haben überall Verify-Checks drin, insbesondere zum Beispiel für Arraygrößen. Und das heißt, wenn ein Programm bemerkt, dass irgendeine Vorbedingung, die es als gegeben annimmt, nicht stimmt, dann wird das Programm sofort getötet oder tötet das Programm sich selber durch Verify, was ein Assert oder ja, wie auch immer ist. Und auf der sozialeren Seite, wenn ihr eine Local Privilege Escalation, eine arbitrary Code Execution oder eine Remote Code Execution in Serenity findet, dann zahlt euch Andreas Kling 50 Dollar. Genau, also das ist, glaube ich, der Ansporn. Also ich sage jetzt einfach mal, diese Bounty wurde seit anderthalb zwei Jahren, glaube ich, nicht mehr geklämt. Deshalb würde ich jetzt mal einfach so sagen ins Internet, dass Serenity ist ein perfekt sicheres System ist. Es hat keine Sicherheitslücken und Gegenbeweise werden eben mit 50 Dollar bezahlt. Genau, bleiben wir jetzt auch bei der sozialen Seite sozusagen, der Projektphilosophie. Ich habe mal so ein bisschen versucht, zusammenzufassen, was das Serenity OS Projekt so auch als Community eben ausmacht. Und ich finde, es ist eine großartige Community. Das ist eben meine Meinung. Der ganze Talk ist meine Meinung, aber das insbesondere ist meine Meinung. Bei uns bedeutet Free Software wirklich, dass man alles damit machen kann. Kein Copy Left, kein TPL, wir ihr könnt mit unserem Code alles machen, solange ihr eine kleine Attribution irgendwo habt und deshalb eben auch BSD to Clause, das ist ähnlich zu MIT und ISC von der Lizenz her. Bei uns haben Entwickler grundsätzlich keine Aufgaben, die sie erfüllen müssen, nicht mal die Leute, die ganz oben sind, die irgendwie das Projekt maintainen. Alles, was sie machen, was wir machen müssen, ist theoretisch, okay, du hast da Code geschrieben und das hat irgendwas kaputt gemacht, bitte reparier es. Das will man in der Regel sowieso selber machen und meistens wird es auch von irgendjemand anderem schnell gefixt. Ansonsten setzt man sich selber dran. Ähnlich dazu eben gibt es keine große Roadmap, keine Ziele, keinen Plan. Wenn ihr irgendwie wollt, dass es irgendwas im System nachher geben soll, dann müsst ihr das einfach selber bauen. Es gibt nicht so, hey, ich mache jetzt mal Issue auf. Ich will dieses unienes Feature an diesem unienen Programm. Das wird generell als macht selber Issue geschlossen. Ganz einfach, weil wir niemanden da zu zwingen können, irgendwas zu tun. Das ist eine ganz praktische Grunde. Ihr könnt natürlich andere Leute von überzeugen, dass es toll wäre, wenn es es gäbe. Aber abgesehen davon gibt es irgendwie keine Richtlinien, was wir so an Features implementieren. Genau, es gibt natürlich kein Code, den wir nicht geschrieben haben. Das habe ich schon gesagt. Wir sind vollständig vertikal integriert, alles unser Zeug. Und fünftens, das ist ein dummer Witz, den ich auf dieses Leid gepackt habe. Ich hätte auch noch bessere Witze, einschließlich diesen Meme drauf tun können. Aber ich wollte einfach nur kurz demonstrieren, dass wir im System ein bisschen Spaß haben wollen, weil ich mein, wir machen das alle nur zum Spaß. Serenity ist bloß zum Spaß. Niemand braucht dieses System. Wir machen das alle bloß, weil es uns Spaß macht. Und deshalb können wir auch ein bisschen beim Entwickeln dann Spaß haben und eben ein paar Witze machen. Also den Witz versteht man vielleicht nicht. Also Propagate Errors. Okay, und der Wortwitz, aber Pro ist halt ein Programm, das Curl ersetzt und wir betiteln unsere Pull Requests immer mit dem Programmnamen zuerst. Das heißt, das ist ein standardisierter Programmname, der dann ein standardisiert Pull Requests Name, der noch ein Wortwitz ist. Und dann haben wir das so ein bisschen fortgeführt in Fred. Genau, wird es mir der Erklärung. Genau, warum soll es euch interessieren? Das ist jetzt die Frage, die ich ja schon auf der Titelslide hatte. Aber jetzt komme ich tatsächlich mal da dazu. Serenity ist zwar mit allem möglichen kompatibel oder versucht damit, kompatibel zu sein, aber Legacy interessiert uns nicht. Wir haben 32 Bit rausgeschmissen. Wir haben auch in Sound Blaster 16 Treiber Deforsion rausgeschmissen. Wir sind dabei zu versuchen, alles, was mit IDE zu tun hat, rauszuschmeißen, weil das auch groß und groß und harig ist und niemand will es anfassen und genau, also wir haben wirklich kein Bock, irgendwas drin zu lassen, nur weil es nur weil es da ein, zwei Use Cases dafür gibt, aber eben kompatibel mit allen möglichen Formaten und Geräten und so weiter versuchen wir schon zu sein. Wir sind in gewisser Weise ein Clean Slate Design, weil wir eben erst 2018 angefangen haben. Das heißt, wir können aus vielen vorherigen Fehlern anderer Systeme schon lernen. Und gleichzeitig gilt aber auch, dass wir natürlich auch Fehler machen und dann Refactern müssen und dafür haben wir keine Angst. Zum Beispiel ersetzen wir momentan unsere gesamte String Implementierung, weil die vorherige String Implementierung, der war UTF-8 und alles Mögliche so ziemlich egal. Und das heißt, wir ersetzen jetzt einmal komplett unsere kompletten mehreren 10.000, vielleicht sogar 100.000 Vorkommen von dieser Stringklasse. Dann kann man auf den Browser bezogen. Sind wir natürlich der Beweis, dass man einen mit dem modernen Web sehr, sehr hoch kompatibel im Browser wirklich in diesem Jahr oder auch in den letzten paar Jahren wirklich noch schreiben kann. Und das ist, glaube ich, immer das, wo behauptet wird, OK, man braucht man braucht das Budget von Google und 10 Millionen Entwickler. Und dann kann man vielleicht in 20 Jahren mal ein Browser, der so gut ist. Das stimmt nicht. Wir sind 300 Leute und und niemand macht zu wirklich irgendwas oder jeder macht nur so. OK, jeder macht nur so das, worauf er Lust hat. Aber das heißt halt, dass dann, dass dann irgendwie die JavaScript Engine dreimal weiter ist als die Rendering Engine, weil Layouting ist unterspezifiziert und harig im Web. Jedenfalls funktioniert das. Und unser Browser ist sehr weit und sehr gut. Die Engine habe ich ja schon gezeigt, wie gut sie ist. Browser könnt ihr euch auch selber nochmal angucken. Ähm, auf den Kernel bezogen. Unser Kernel enthält kein C. Das ist möglich. Unser Kernel hat sehr viel Objektorientierung mit mit Smart Pointers und hohen Abstraktionskonzepten. Das funktioniert alles ohne Problem. Also wer behauptet, man müsste einen Kernel in C schreiben. Der hat auch kein Recht. Und ja, OK, OK, wir haben wir haben Assembler Entry Points. Aber wir versuchen immer so schnell wie möglich irgendwie ein C plus plus zu kommen. Das ist ja klar. Und natürlich fehlt für euch jetzt, fehlt garantiert noch eure Lieblingssoftware entweder im System oder halt den Port, den ihr gerne machen würdet. Das heißt an Serenity kann man an allen Ecken und Enden hacken, weil es da überall noch Bereiche gibt, die verbessert und erweitert werden müssen. Damit kann ich nur sagen, geht raus und schreibt gewagte Software, weil diejenigen, die behaupten es sei unmöglich, die haben es nicht versucht oder zu früh aufgegeben. Genau. Und damit bin ich fast am Ende. Nur wollte ich ganz kurz noch mal noch mal ein bisschen über Jagd reden. Die Hintergrundgeschichte dazu ist, dass C plus plus eine Speicher und Typ unsichere Sprache ist. Das ist euch wahrscheinlich hoffentlich bekannt. Und das sorgt eben nicht nur in der Web Engine, aber auch vor allem in der Web Engine für Probleme. Und da geht es ja eben darum, dass wir sehr viel Antrusted Code ausführen und sehr viel Antrusted Websites ausführen, wenn man das so interpretiert. Und deshalb hat sich Andreas Kling entschlossen, dass er mal ausprobiert, eine neue Programmiersprache zu schreiben, die eben Speicher und Typ sicher ist und mit unseren Serenity Code Stil kooperiert, das heißt insbesondere auch objektorientiert ist. Und die Sprache heißt Jagd, weil das ist ein Wortwitz auf das schwedische Wort für Jagd und ein Wortwitz auf das Jagd, das sie die ganze Zeit in der Ecke gesehen hat. Und diese Sprache ist irgendwie so eine Mischung zwischen Swift und Rust, wenn ich sie mal spontan beschreibe. Hier sehen wir ein bisschen Code aus dem Compiler, der inzwischen schon, oder inzwischen schon, aber der seit so einem Dreivierteljahr oder so sehr hosting ist, wenn ich das richtig weiß. Und genau das ist eben eine eine ganz nette Sache. Also es ist momentan noch kein Serenity Code in Jagd geschrieben. Jagd ist interoperabel mit C++, weil es darin transpiliert wird. Und man kann theoretisch Serenity Teile in Jagd schreiben. Das wird aber momentan aktiv noch nicht gemacht, weil es immer noch so ein Experimentier Stadium ist. Das heißt, ich kann nicht garantieren, dass das nachher irgendwo landet oder dass wir das komplette System in Jagd neu schreiben. Aber das könnte theoretisch schon passieren. Und dann hätten wir nicht nur unseren eigenen Code, sondern auch unseren eigenen Compiler. Genau. Jetzt natürlich ganz zum Schluss. Was ist, wenn es euch mehr interessiert, da gibt es hier viele Links und auch meinen Serenity US Macedon Account, wo ich öfter mal Serenity spezifische Sachen poste, was ich so mache. Ihr könnt generell einfach mit uns reden. Wir weißen nicht. Es sind auch einige Leute anwesend, die sich mit dem System auskennen. Wenn ihr mal einen ersten Beitrag machen wollt, dann empfehlen wir in der Regel entweder ein Bug selber finden, nicht besonders schwer. Ja, klar. Die Good First Issue Liste auf GitHub ist ein guter Ansatzpunkt. Und ihr könnt beim Refactoring helfen, weil es ja auch sehr klar ist, was man tun muss. Gerade hier deprecated String nach String ist jetzt die große Sache, die noch ansteht, die ich schon angesprochen habe. Und ihr könnt auch auf Fixme Jagd gehen. Das heißt, wir haben ganz viele Fixmes im Code verteilt und da könnt ihr euch dann gucken, angucken, okay, das Ding sollte besser sein. Vielleicht behebe ich das ja. Da gibt es was weiß ich auf jeden Fall mindestens ein paar 10.000 Fixmes, die es so gibt. Genau. Und zum Schluss nicht vergessen Spaß haben. Habe ich schon mal gesagt. Danke fürs Zuhören. Ja, Fragen. Ja, gibt es noch Fragen? Ja, perfekt. Ich habe gleich mehrere. Falls das okay ist. Was? Mehrere Fragen. Ach so, ja, natürlich. Ja, okay. Also diese diese Funktion Pledge and Unveil, die du vorgestellt hast, sind das Library Funktion oder sind das tatsächlich dünne Cisco Rapper? Das sind System Calls. Also die, der genaue System Call Aufruf funktioniert ein bisschen anders. Aber die sind auch in der CB Buretik verfügbar theoretisch. Okay, was ist der Grund, dass ihr da so eine lustige String basierter API verwendet habt und keine Flags? Das ist eine gute Frage. Ich habe das Ding auch schon mal in Flags umgeschrieben. Das hat so lange gedauert und war so harig, dass ich es irgendwann aufgegeben habe. Der Grund ist erst mal, dass wir es von OpenBSD kopiert haben. OpenBSD hat genau dieses Verfahren. Du hast aber recht, das ist nicht das nicht das Idealste, insbesondere weil man eben erst mal ein User-Buffer in Kern kopieren muss. Das heißt auch performance technisch nicht so geil. Aber die Erklärung ist bisher halt, OpenBSD hat es so eingeführt und wir haben es versucht zu ändern und wir haben es nicht in den Zustand gekriegt, wo es wir es schöner fanden als so. Okay. Also ich sage dir das aus der Position der Person, die diesen, die das nicht schön fand und es tatsächlich versucht zu ändern. Da könnte man sich natürlich überlegen, ob man nicht, ob man die Funktionen so, wie sie sind, zu Library Funktionen umfunktioniert und die Cisco im Hintergrund anders macht. Aber okay, das stimmt. Nächste Frage. Du hattest erwähnt, dass Cisco es nur aus der LPC kommen dürfen und dass das in Linux auch so gemacht werden würde. Ich glaube, ich habe gelesen, dass das Linux Cisco Origin Verification hat. Es ist auf jeden Fall auch ein OpenBSD. Das ist klar. Ja, ich. Aber das keine LPC Events hat, die Cisco es direkt ausführt und seht, dass es auch nicht. Okay, also dann liege ich falsch, da wurde ich korrektiert. So ein Feature hat Linux tatsächlich nicht. Das scheint nur OpenBSD zu haben. Also Linux hat so ein Feature von der Art, was es nämlich verwenden kann, um mit Wine zusammen. Ach nee, stimmt nicht. Das war glaube ich andersrum. Nevermind. Aber vielleicht war es, vielleicht habe ich das doch gar nicht falsch in Erinnerung, aber ich weiß es nicht mehr ganz genau. Dritte Frage. Legacy Nein. Warum bootet ihr mit Legacy BIOS und nicht mit eFi? Das ist eine geniale Frage. Und das sicht einfach daran, dass bis ja noch niemand ein eFi Bootloader geschrieben hat. Beziehungsweise, dass einer geschrieben wurde. Da habe ich vor zwei, drei Wochen, was davon gehört, wurde es jetzt hingelaufen ist, weiß ich nicht. Auf jeden Fall gab es noch keine groß angelegten Bestrebungen, aber es könnte sein, dass sich das in nächster Zeit ändert. Und dann werden wir BIOS Boot vermutlich auch rausschmeißen, weil es Legacy ist. Wenn man jetzt an bei dem Projekt sich gerne beteiligen wollen würde, wie ist denn der Stand der Dokumentation der Libraries und sonst Architektur? Also es gibt es, es gibt sehr viel, sehr viel Dokumentation für Sachen, die man die man nicht durch grobes Code lesen rausfinden kann. Zum Beispiel, zum Beispiel Anwendungsarchitekturen, gerade von so komplizierten Anwendungen wie dem Browser. Und eben alles Mögliche, was es betrifft, das Development Environment einzurichten und sich zurechtzufinden und so. Aber tatsächlich sind die meisten Funktionen nicht nicht ausführlich dokumentiert, aber in der Regel sind entweder die Funktionsnahmen selbst sprechen. Wir haben oft sehr lange Funktionsnahmen, die sehr deutlich sind. Oder es gibt halt eine kurze Dokumentation in ein, zwei Sätzen. Aber in vielen Fällen ist es so, dass man Code lesen muss. Aber ich finde, das hilft einfach und das funktioniert in diesem System auch gut. Wenn man sich beim Code lesen, dann einfach mal kurz vom Browser bis zum Kernel durchgraben kann und alles herausfindet, wenn man zum Beispiel ein Back sucht oder so. Okay, vielen Dank. Das war es von dir. Weitere Fragen. Gibt es jenseits von Discord weitere Interaktions oder Organisationsmöglichkeiten, wenn man sich aktiv einbringen will? Ich glaube, Discord schreckt ein paar Leute ab. Ja, das stimmt. Aufgrund der Privacy-Unfeindlichkeit. Ich finde es auch nicht ultimativ schön. Momentan ist es so die einzige Echtzeitmöglichkeit. Man kann aber trotzdem auch über Github mit Leuten reden. Und grundsätzlich zum Beitragen braucht man nur das. Und ihr könnt natürlich mit Entwicklern persönlich reden. Viele haben Mastodon und Matrix-Accounts und so. Es gibt theoretisch auch ein Matrix-Server, aber den darf ich jetzt nicht sagen, ansonsten werde ich beworfen. Aber der wird nicht, der wird nicht wirklich verwendet. Deshalb ist Discord da die einzige Echtzeitmöglichkeit. Okay, danke. Auf welchen Hosts System kann man Serendants US gut entwickeln? Gut entwickeln eigentlich alles. Also, es haben schon Leute hingekriegt, Ladybird auf Solaris bauen zu lassen. Sportlich. Entwickeln geht auf jeden Fall auf allen BSDs, wenn ich das so gesehen habe. Und wenn nicht, setzt euch dann in Kontakt mit den Leuten, die da damals den Support dafür geschrieben haben. Was auf jeden Fall gut funktioniert, ist natürlich Windows Linux MacOS. Unter Windows muss man WSL2 verwenden. Aber das ist ja inzwischen relativ gechillt zum irgendwie irgendeinen Debian oder Ubuntu installieren und dann den ganzen Spaß im WSL machen. Und gerade, wenn man auf Windows eine normale IDE, wie z.B. C-Line oder WS-Code verwendet, die können sich reinremoten in WSL und dann ist es so, als würde man direkt auf dieser WSL-System entwickeln und so weiter. Noch jemand? Erst mal danke für den Talk, der war absolut super. Ich habe jede Menge gefragt. Ich glaube, ich werde auf den Discord-Zimmer euch ein bisschen nerven. Aber erst mal, wie euch ist euch ABI-Stabilität? Z.B. Linux will es unbedingt nicht brechen. Oft an der anderen Seite, wenn ihr legacy-Ratifikal ist. Ja, das siehst mich schon lachen. Also unsere ABI geht etwa alle zwei Tage kaputt. Okay, so schlimm ist es nicht. Aber wir ändern halt System-Calls ohne Vorwarnung und wir ändern auch die Reihenfolge ohne Vorwarnung. Das einzige Stabile ist unsere Lipsie. Also gegen unsere Lipsie immer bauen direkt. Das geht. Das war auch schon ein Problempunkt mit dem SIG-Port, weil die SIG-Leute gesagt haben, okay, wenn wir Serenity als Stage 2 Target hinzufügen wollen, dann brauchen wir eine stabile ABI. Da haben wir gesagt, nein, und mit ein bisschen Überzeugungsarbeit haben die sich dann auch hin und zu hin tun lassen, dass wir halt eine stabile Lipsie haben. Also eine stabile ABI-Garantie gibt es nicht. Okay, habt ihr dann auch elf als executable Format-Fan oder habt ihr aus eigenes Quartier zu schön merken? Nein, nein, wir haben elf. Die sind wahrscheinlich irgendwie speziell markiert, aber sie sind normale Elfs, die mit normalen Clang und GCC erzeugt werden. Wie ist es z.B. mit Confix? Habt ihr da ein eigenes Framework, mit dem alle Programme konfiguriert werden? Und folgt dem XG-Standard für normale Teilen? Ich weiß es nicht. Also die Config-Dateien werden alle als Innis gespeichert. Und einfach, weil Inni ein simples funktionierendes Format ist und bisher haben wir nicht mehr gebraucht. Zum Konfigurieren an sich, in der Regel zumindest die meisten GUI-Programme reden heutzutage mit dem Confix-Server, der eben Confix cached und dann speichert und eben diese ganze Verwaltung übernimmt und damit reden auch die Einstellungen. Das heißt, in der Einstellung kann dann ein Einstellungsprogramm, kann dann die Einstellung für irgendein anderes Programm ändern und es wird automatisch geupdatet über den Confix-Server. Man kann die Config-Dateien auch von Hand bearbeiten. Dann muss man aber in der Regel irgendwas neu starten. Das ist jetzt nicht so zu empfehlen. Da gibt es vielleicht auch noch Verbesserungsbedarf. Okay, da habe ich noch eine letzte Frage. Den Rest kommt dann auf Discord. Wenn man zum Beispiel mehrere Pfade unveilen will, zum Beispiel ich weiß jetzt nicht einen bei der Config und einem für dort, wo jetzt ein des Programme eigentlich arbeitet, kann man dann überhaupt unveil mehrmals draufrufen, weil wenn ja, dann zerstört es nicht irgendwie den Grund davon. Wenn das irgendwie ein arbitrary Code-Execution bekommt, kann ja dadurch sich sämtlichen Zugriff geben, die er braucht. Ja, genau, die Sache mit unveil ist, wenn ich nochmal auf die Slides zurückgehe, damit alle auch die Sintax vor sich haben. Das habe ich hier natürlich auf das Slide an sich ein bisschen vereinfacht. Mal der unveil hat zwei Zustände für ein Prozess offen und geschlossen. Und wenn er offen ist, dann kann ich beliebige Pfade zuhört sich unveilen, auch solche, die ich vorher noch nicht berührt habe. Und wenn ich dann dieses unveil No-Pointer, No-Pointer mache, also tatsächlich das System Call unveil mit zwei No-Pointer, dann merkt dadurch der Kernel, OK, der unveil muss jetzt geschlossen werden. Und ab dahin sind alle unveil Aufrufe entweder ein Prozesscrash oder halt einen invalider System Call, weiß ich grad gar nicht genau. Also auf jeden Fall ein Programm sollte, kann unveil nur vernünftig benutzen, wenn es den tatsächlich auch zu macht und zwar kurz nach dem Programm statt. OK, danke. Hat sonst noch jemand eine Frage? Ja, also wenn man bei OpenBSD ist es so, wenn man bei Anwähl die zwei No-Pointer reinpässt und dann nochmal aufruft, dann returned das minus eins, also es schlägt Fehl. Aber alternativ kann man Pletsch auch das Anwählprivileg einfach entfernen und dann gibt es einen Sickle. Manche Programmen machen beides. Ja, OK, ja genau das. Ich vermute, dass es bei uns ähnlich ist. Weiteres weitere Fragen sieht bisher nicht so aus. Hat dieses Betriebssystem SSH? Also es gibt garantierten SSH Port, weil also auf jeden Fall OpenSSL als Bibliothek ist auf jeden Fall geportet, auch wenn wir unsere eigenen TLS Implementierungen und so weiter haben. Und ansonsten soll das Programm einfach plus Networking benötigen. Und wir haben einen halbwegs funktionierenden TCP IP Stack. Deshalb glaube ich, dass schon Port existiert. Ansonsten einfach nochmal auf ports.rinitios.net nachgucken. Und falls nicht, dann gerne porten. Das ist auf jeden Fall cool. Wir haben aber keine eigene Implementierung. Das ist richtig. Ja, für ein bis zwei Fragen hätten wir noch Zeit. Also. Wer jetzt noch eine Frage hat. Könnte sich. Ja. Das ist jetzt ein bisschen auf Topik, aber das Logo ist sehr cute. Was war die Inspiration dahinter? Welche das der der der Ladybird Moment. Ich meine, diesen das das, wonach ihr auch die vorher mir Sprache benannt habt oder das das Jagd meinst. Ja, genau. Das ist nicht das Maskottchen. Das Maskottchen ist buggy. Da sieht man, wenn man auf die Webseite geht. Wir haben eigentlich drei Maskottchen. Buggy, Catdog und Moment, Catdog kann ich sogar demonstrieren. Hops. Demos, Catdog hier. Das ist so eine Katze, die sitzt einmal auf dem Desktop und das ist wie Klippi nur besser. Und man kann es auch. Man kann es auch anklicken. Und dann kommt irgendwie. It seems like you're trying to shave a Jagd. Would you like some help? Jetzt kommt natürlich nicht. Es schläfst natürlich ein. Nee, auf jeden Fall. In der. Also diese Jags zurück zum Thema. So diese Jags, das ist eigentlich das Bison Emoji von Tremoji, also Twitter, den Twitter Emoji set. Das hier ist nur ein. Ja, genau, super. Danke, Catdog. Also die haben wir halt nur, da haben wir halt nur verschiedene Modifikationen gemacht. Die Idee ist eben das Jagd Shaving. Das könnte vielleicht einigen Begriff sein, so dass man erst Dove Aufgaben beim Programmieren erledigen muss, bevor man dann die richtig coole, vernünftige Aufgabe machen muss. Also ein Jagd rasieren klingt so nach einer sinnlosen Aufgabe, aber muss halt manchmal sein. Und es hat sich so dazu entwickelt, dass eben alles, was man in Serenity macht, grundsätzlich ein Jagd ist, weil es gibt immer noch eine Aufgabe, noch eine nächste Aufgabe. Es geht immer noch einen Schritt tiefer und einen Schritt besser und so weiter. Und deshalb hat sich das so ein bisschen, so ein bisschen dazu entwickelt, dass es so Jagd Shaving, so das Standard-Meme ist, in der Serenity-S-Community. Und deshalb haben wir diese ganzen Jagd-Emoji, die so unser Hauptkommunikations-Pfad sind. Und was? Genau, Jagdsplaint.org. Da gibt es eine Erklärung zu jedem einzelnen Emoji, die hab ich auch geschrieben, weil ich so ein Deutscher bin. Witz mit Erklärung halt. Und da gibt es auch eine Erklärung zu jedem einzelnen Emoji, inklusive aller Emoji, die ich hier auf den Folien hatte. Cool, danke und danke für den sehr spannenden Tag. Du, vielleicht noch eine Frage? Ah. Hi. Du hast ja mehrfach erwähnt, dass ihr Features wieder rausgeschmissen habt und dass ihr eine gute Community seid. Wie kommt ihr dann zu dem Konstant, dass ihr jetzt dieses Feature wieder entfernt, wo sich irgendwie viel Mühe gemacht hat oder was irgendwie vielleicht wichtig war? Das ist eine gute Frage. Wir haben keinen formal festgeschriebenen Konsentprozess und Andreas Kling hat theoretisch als BFDL das letzte Wort. Bei 32-Bit war es tatsächlich so, dass sie geguckt haben, OK, welche Leute wollen damit noch rumspielen? Einzeler Leute haben gesagt, oh, wir würden es gern noch auf unseren uralten tollen Systemen noch gerne ausprobieren. Aber uns ist es jetzt nicht so wichtig und Andreas Kling hat auch gesagt, nehmen, lass mal und dann wurde es entfernt. Es war ein bisschen kritischer bei den Demos. Ich habe hier gerade schon die Hallo, genau, die Demos-Liste gezeigt. Die war auch schon wesentlich länger. Wir haben einfach ein paar Loeffer-Demos vor einiger Zeit rausgeschmissen. Es hat ein paar Leute nicht gefreut. Aber zum Glück ist es meistens dabei geblieben, dass es nur bei vereinzelten Leuten auf genau das nicht gefallen hat oder dass man dann ein bisschen diskutieren musste. Danke. Ganz zum Schloss vielleicht noch jemand. Ich war halt zu schnell. Ein alles gut. Drei, zwei, eins. Ach. Jo, dann noch mal einen großen Applaus für das kleine Filmröllchen.