 Ja, hallo, guten Abend allerseits. Schön, dass ihr so zahlt euch zu meinem Vortrag erschienen seid. Mein Name ist Michael Stabelberg und das Thema, weswegen ihr hier seid, ist, dass Linungspackage-Manager zu langsam sind. Ich möchte mich im Vorfeld noch kurz entschuldigen, dass einige Fachbegriffe in diesem Vortrag auf Englisch bleiben und ich werde das dann einfach so dänglischmäßig hin und her mixen. Ich hoffe, ihr könnt mir das nachsehen, weil sonst wird es einfach sehr awkward, wenn man dann diese ganzen Begriffe in Deutsch übersetzt. Zunächst mal habe ich hier eine Demonstration, damit ihr gleich erst mal wisst, worum es wirklich geht. Auf der linken Seite ist jeweils Debian abgebildet, aber nur stellvertretend. Ich habe da auch gleich noch eine Folie zu und was hier passiert in diesem Video, was hier passieren sollte, ich habe das natürlich auch noch hier vorbereitet für den Fall, dass das Wähler nicht gehen sollte. Was ich hier gemacht habe ist, ich starte ein Docker-Container in Debian und dann installe ich das Programm ACK. Wie der Paketname ACK-CREP schon suggeriert ist ACK ein Ersatz für CREP und ACK ist einfach ein Tool stellvertretend hier für ein kleines Tool. Als Ersatz für CREP, ihr wisst alle, was CREP macht. Es gibt eine ganze Reihe an verschiedenen Ersatzprogrammen, sei es ACK, sei es Silversearcher, RIP, CREP, was auch immer. Da gibt es ganz viele verschiedene. Aber was ich hier illustrieren möchte ist, dass ein Paket, welches einfach nur ein paar Kilobyte groß ist, wenn ihr das unter Debian installiert, ich lasse es hier nochmal laufen, dass ihr wirklich einen Gefühl nochmal dafür bekommt. Was hier eben passiert ist, er lädt sich die Paketlisten runter, dann installiert ihr das Ganze, partipenden siehst ihr noch dabei, dann entpackt ihr das Ganze und das dauert insgesamt vier Sekunden, bis ich das ACK-Programm tatsächlich ausführen kann. So, wenn ich das jetzt vergleiche, wie schnell es eigentlich laufen könnte, indem ich das gleiche mache, aber mit meinem System seht ihr hier 0,5 Sekunden, also achtmal so schnell und das ist jetzt bei so einem kleinen Paket vielleicht nicht so beeindruckend, aber ich habe das Ganze auch mal mit QEMU nochmal gemacht unter Debian und wie ihr euch jetzt sicherlich schon ausmalen könnt, QEMU ist ein sehr großes Paket, hat viele, viele Megabytes, hat einige Bestandteile, hat auch ein paar Dependencies und sobald das jetzt hier mal tatsächlich auch anfängt, Paketlisten drunter laden, so weit so gut. So, und jetzt kommt QEMU und jetzt können wir uns erstmal zurücklehnen. Also erlädt das jetzt hier alles runter und ihr seht, das geht auch relativ flott. Das ist also eine Gigabit-Leitung mit einer sehr aktuellen Intel Workstation, fettangebunden, fett CPU, fett SSD mit irgendwie NVMe und trotzdem kann ich jetzt hier die ganze Zeit reden, während er dieses blöde Paket installiert. So, was macht denn in der die ganze Zeit, wieso dauert das so lange und was soll das überhaupt? Das waren jetzt 17 Sekunden, bis das Ganze installiert wurde und jetzt schauen wir uns mal das Gleiche an, wie das eigentlich aussehen sollte. Wenn wir das hier in diesem System machen, dann dauert das nur noch knappe drei bis sagen wir vier Sekunden, fertig, installiert und einsetzbar. So, das ist also die Prämisse von meinem Vortrag. Ich überspringe jetzt mal hier die nicht funktionierenden Videos und dann gehen wir in die Folien über. Fragen bitte erst am Ende, weil ich glaube, das ist wichtig, dass ihr erstmal alles versteht, was ich jetzt hier vorstellen möchte. So, ich habe hier tabellarisch nochmal aufgeführt, wie die Geschwindigkeiten sind der verschiedenen Distributionen und Paketmanager. Die Tabelle ist sortiert nach Wall Clock Time, also wie lange hat es tatsächlich gedauert insgesamt und die Zahlen, wenn ihr genau aufgepasst habt, sind auch nicht ganz reproduzierbar mit der Demo, die ich gerade gezeigt habe. Da muss man also noch ein bisschen Arbeit investieren, dass das ein sauberes Environment wird, was auch reproduzierbar ist. Aber das gibt euch einen groben Ansatz wert. Ich gehe kurz durch. Bei Fedora, wenn ich mit DNF das Arc-Programm installiere, dann muss ihr erstmal 100 Megabyte runterladen, bevor er mir die paar Kilobyte an Arc installieren kann. Das dauert insgesamt 25 Sekunden, was schon eine ganze Menge ist und die umgerechnet Datenrate, mit der das Programm also arbeitet, also mit der der Paketmanager installiert, sind knappe 4 Megabyte pro Sekunde. Dann, NixOS hat einige Grundsteine richtig gelegt, also die könnten eigentlich ziemlich flott sein. Aus mir unerklärlichen Gründen, wahrscheinlich irgendwie suboptimale Implementation, ich kann es ja nur mutmaßen, dauert es trotzdem 12 Sekunden, um knappe 15 Megabyte runterzuladen. Das entspricht einer streichlichen Datenrate von gerade mal 1 Megabyte pro Sekunde. Bei Debian sieht es nicht viel besser aus und wenn wir dann quasi in die kleineren Distributionen gehen oder die schlankeren oder die Nischendistributionen, wie Alpine zum Beispiel, was hauptsächlich im Dockerumfeld benutzt wird, dann sehen wir, okay, da geht es eigentlich auch besser. So, das ist also die Ausgangslage und jetzt stellen wir uns die Frage, okay, warum sind diese ganzen Packagemanager so langsam? Dafür müssen wir erstmal ein bisschen ausholen. Bei den weitverbreiteten Packagemanagern und Formaten, die die verwenden, gibt es 2 Stück. Die anderen sind eigentlich meist Abkömmlinge davon. Wenn man auf Wikipedia schaut, klar, es gibt noch ein paar andere, aber alle arbeiten in den Aspekten, die ich hier vorstelle, auf die gleiche Art und Weise. Bei Debian gibt es die DAP Packages, steht einfach für Debian Package und was die machen, ist ein TAR Archive eingepackt in dem Unix Archive, also quasi ein Archiv im Archiv, und das muss man dann eben erstmal entpacken. Beim RPM ursprünglich stand das für Red Hat Packagemanager, mittlerweile, das glaubt im background, hat man ein bisschen Metadaten um den CPIO Archive aus und rum gepackt. Und das Ziel von allen diesen Packagemanagern ist letztendlich einfach, die Paketinhalte zur Verfügung zu stellen. Also wenn ich zum Beispiel sage, ab Install Engine X, dann soll das letztendlich resultieren darin, dass ich Engine X auf meinem Computer ausführen kann. Soweit so gut. Traditionell bedeutet das also, dass die Packagemanager, wenn ich diesen Befehlein gebe, die Paketlisten drunterladen müssen, dann die Abhängigkeiten auflösen müssen, dann die entsprechenden Daten, die sie brauchen drunterladen, die Archive entpacken und die Software anschließend konfigurieren müssen. Das sind ja schon eine ganze Menge Anstritten. Und Annahmen, die die Packagemanager hier machen, sind, dass wir es mit einem mutable System, also einem veränderbaren System zu tun haben. Das heißt, die Packagemanager verändern einfach das installierte System. Am Beispiel jetzt gerade eben von Engine X, das landet in User Bin Engine X, sowie alle anderen Programme auch. Die landen alle irgendwie in User Bin. Gleichzeitig ist aber eine andere Annahme, dass Nutzer das System nicht verändern dürfen, im selben Ausmaß. Also wenn ich selber irgendwie Software nach User installiere, dann endet das meistens schrecklich. Manchmal reparierbar und manchmal einfach auch gar nicht mehr. Grundsätzlich ist es so, dass die Änderungen, die die Packagemanager durchführen im Normalbetrieb, also wenn ich einfach eine Installation oder ein Update mache, relativ gefährlich sind. Also wenn da irgendwas dabei schiefgeht, also angenommen ist es irgendwie ein Stromausfall oder euch geht der Akku-Layer oder der Kernel-Crash oder was auch immer, dann kann es sein, dass irgendwas kaputt gegangen ist und euer System hinterher einfach nicht mehr startet. Angenommen, ihr aktualisiert gerade die Lip-C und hinterher funktioniert kein Programm mehr, was hinzehengeschrieben wurde, das wäre schlecht. Was die deswegen alle machen, ist, dass sie den F-Sync-Systemcall benutzen, damit also die Puffer nicht nur im Arbeitsspeicher legen, sondern auch tatsächlich auf das Speichermedium rausgeflasht werden. Da kann man jetzt noch lange darüber diskutieren, so wie da die Norsen sind und ob das wirklich langt und so weiter. Aber das machen die eben alle und das ist einer der Gründe, warum das ein bisschen langsam geht. So, jetzt wissen wir also grob, was machen Packagemanager auf einem High-Level und jetzt können wir uns auch schon die Frage stellen, wie können Packagemanager eigentlich schneller werden? Die Kern-Contributions von diesem Vortrag sind folgende Ideen. Wir wollen ein Append-Only-Package-Store benutzen aus Immutable Images und hier konkret, wir müssen ein Image-Format benutzen, statt ein Archiv-Format. Ich habe gerade schon vorgestellt, Debian-Packages und RPM-Packages sind Archive, d.h. die müssen druntergeladen werden, verifiziert werden und ausgepackt werden. Wenn wir aber mit einem Image-Format arbeiten, z.B. ins Squashifest-Image, wie das ja auch schon andere Tools machen wie App-Image, dann können wir einfach dieses Image runterladen auf die Festplatte und direkt mounten, also direkt benutzen. Und bei App-Image und Snap und so, da wird das gemacht, aber eben nur für Anwendungsprogramm, also für so etwas wie Gimp oder Kiekheit oder was auch immer. Aber die These, die ich hier eben aufstelle, ist, dass man dieses grundlegende Vorgehen für eine komplette Distribution machen kann und dass das machbar ist. So, was machen wir jetzt mit diesen Images? Wenn wir die auf unsere Festplatte laden, dann stellen wir die in separaten Mountpoints zur Verfügung. Und das ist ein Konzept, was ich in diesem Vortrag Separate Hierarchies nenne. Das heißt konkret, wenn ich EngineX installiere auf meinem Computer, dann habe ich das unter slash RO slash EngineX und dann also der komplette Paketname inklusive Architektur und voller Versionsnummer. Und neben dran liegend, auf der gleichen Ebene in der Hierarchie, habe ich eben Z-Gel und unten drunter werden also die ganzen Dateien installiert. Also im Fall von EngineX habe ich da das User-bin-Enginex in diesem Unterordner. Ansonsten habe ich das System wie üblich aufgebaut. Das heißt, ganz normal irgendwie sein Slash-ETC für Konfigurationsdateien, sein Slash-Var-Lip, war Cash und so weiter und so weiter. Aber die Systemsopter wird halt nicht irgendwie in ein Verzeichnis so durcheinander zusammeninstalliert, sondern wird eben schön separat unter dieser Slash-RO für Read-Only-Hierarchie zur Verfügung gestellt. So, was sind jetzt die Vorteile davon? Gerade eben schon gesagt, wir müssen einfach nur noch Mountain statt zu entpacken. Und das macht zum einen die Paketinstallation enorm viel schneller. Und zum anderen, und das hatte ich am Anfang gar nicht realisiert, macht es auch Bildumgebungen viel, viel schneller. Wenn man an so einer Distribution arbeitet und ein neues Paket hinzufügt, dann baut man das üblicherweise in einer separaten Umgebung. Das macht man deswegen, damit man sich nicht auf seinem Host-System irgendwie ganz viele Pakete installieren muss, die man sonst eigentlich gar nicht braucht. Aber man kann das von dem Host-System irgendwelche Eigenheiten in den Paketen landen. Das heißt, bei normalen, oder bei herkömmlichen Distributionen ist das üblicherweise so gelöst, dass sie so einen separatis Changed-Root haben, also so ein separatis Base-Image, was irgendwie nächtlich oder wöchentlich oder vielleicht nie aktualisiert wird. Und dann mounted man das mit so einem Copy-on-write-Datei-System und installiert da einfach alle Build-Dependencies rein. Und je nachdem, um was für ein Paket das sich handelt, ich habe früher in Debian Free-Radius-Maintain zum Beispiel, das braucht irgendwie eine gute Minute oder so, bis da überhaupt der Changed-Root mal aufgebaut ist und dann dauert es noch mal ein paar Minuten, bis das durchgebaut ist. Das sind also superlange Iterationszyklen, wenn man da so ein Paket modifizieren will. Und hier ist es so, dass die Bildumgebung super schnell einfach zusammengesetzt werden kann. Dadurch, dass ich einfach unter Slash-RO meine ganzen Images mounte, kann ich in einem Bruchteil von der Sekunde das Build-Environment komplett fertig haben. Und nachher in der Fragerunde bzw. wenn wir noch ein bisschen Zeit haben für Demos, kann ich das auch gerne mal demonstrieren, wie das aussieht. Außerdem ist so ein Package Store grundlegend Append Only. Weil die Images ja unveränderlich sind, die werden nicht irgendwie editiert, ausgetauscht oder overlaid oder so, sondern die bleiben so, wie sie sind, können wir das Ganze Append Only aufziehen. Wir fügen immer nur neue Dateien hinzu und irgendwann machen wir mal eine Garbage Collection, aber das ist irrelevant für den Common Case. Das heißt, wir können Input-Output auch ohne F-Sync machen. Das ist vollkommen okay. Und das ist der Fall, dass wir das Package Store noch einmal installieren können. Darunter Paket-Installation, der Akku leer läuft, ist kein Problem. Entweder das Paket wurde, bevor der Akku leer gegangen ist, noch fertig installiert, dann ist es halt da, okay, gut. Oder es ist halt nicht da und dann ist aber auch nichts kaputtgegangen. Wir können einfach noch mal sagen, das Paket hat es offenbar nicht geschafft, dann installiere ich es jetzt einfach nochmal und dann wird das Paket noch mal installiert weil sie den Arbeitsspeicher auslasten können und viel schneller also diese Puffer füllen können. Und im Normalfall, in dem also die Pakete, die ihr installiert in euren Arbeitsspeicher passen, müsst ihr also überhaupt gar nicht auf die Festplatte schreiben, bis ihr das Paket nutzen könnt. Das macht es natürlich viel schneller. Außerdem, um das noch mal explizit herauszustellen, ihr kriegt also ein robustes System ohne Zerstörungsgefahr. Ihr könnt euch weder absichtlich noch bösartig irgendwie in User eure Installation kaputtmalen. Also schützt vielleicht auch gegen malware so ein bisschen. Aber es ist einfach ein gutes Gefühl, dass man weiß, okay, wenn irgendwas kaputt geht, dann kann es nicht das sein. Also dieser Teil des Systems ist einfach komplett abgeriegelt. So, jetzt tun sich da natürlich ein paar Fragen auf. Bei diesem Konzept von den Separate Hierarchies brauchen wir was, das nenne ich hier Exchange Direktories. Die gibt es in zwei Variationen, die gibt es einmal global und einmal per Package. In der globalen Variante ist die Beobachtung folgende. Pakete tauschen generell Daten über bekannte Verzeichnisse aus. Das heißt, mal hier ein paar Beispiele rausgegriffen das MAN-Programm, um euch die MAN-Pages anzuschauen. Kommuniziert mit EngineX oder mit ganz vielen anderen Paketen. Darüber, dass es in User-Share-MAN nach Dateien sucht, die die anderen Pakete dort hinterlegen. Ein anderes Beispiel der GCC, wenn ihr Software kompilieren wollt, kommuniziert mit der LibUSB über User-Include, indem ihr da einfach so ein Include-File findet, was die Library-File dort hinterlegt hat. So, jetzt könnte man sagen, okay, wenn also alle diese Programme an bestimmten Stellen nach diesen Dateien sucht, dann kann man dann einfach so ein Include-File finden. So, jetzt könnte man sagen, okay, wenn wir diese Programme an bestimmten Stellen nach diesen Dateien suchen, und wir haben diese Stellen nicht auf unserem System, dann können wir einfach die Programme patchen und anpassen, so dass sie unser Pfad-System akzeptieren und umsetzen. Das ist aber natürlich ein Riesenaufwand. Das ist nicht nur viel Aufwand im Moment, also um das Programm zum Laufen zu bekommen, sondern auch immer, wenn sich das Programm ändert, muss man das anpassen und so. Da kommt man ja gar nicht hinterher. Der bessere Ansatz ist, dass man diese bekannten Pfade emuliert. Wie ich das mache, ist, dass ich einfach in User-Include einen Sim-Link habe, sagen wir zum Beispiel User-Include-JPEG-Lip, und das ist dann ein Sim-Link auf den vollen Pfad, also in dem Fall wäre das die LibJPEG-Turbo-Paket, und dort ist dann die Include-JPEG-Lip drin. So, das ist jetzt die globale Variante gewesen, jetzt schauen wir uns die Per-Package an. Der Unterschied zwischen den beiden ist, dass die globale Variante lose gekoppelt ist und die Per-Package ist eng gekoppelt. Das heißt, das ist nützlich, wenn man Plug-in-Architekturen hat, bei denen das ABI einfach übereinstimmen muss. Bei Xorg ist es zum Beispiel so, dass die Autoren von Xorg sagen, wenn ihr einen Modul kompiliert für Xorg, wie einen Grafikkartentreiber oder sowas, oder einen Maustreiber oder was auch immer ihr habt, dann ist er nur kompatibel mit der Version, gegen die ihr auch kompiliert habt und nicht gegen irgendwelche anderen Versionen. Hier wollen wir also nicht mehr das globale Exchange Directory haben, sowas wie LibXorg-Modules, weil dann könnten wir nicht mehrere Versionen von dem Xorg nebeneinander installiert haben, sondern hier brauchen wir einen Per-Package Exchange Directory, sodass innerhalb von dem Slash-RO-Slash-Xorg-Server dann dort das LibXorg-Modules mit den Sim-Links auf die entsprechenden Plugins gefüllt wird. Okay, was sind die Vorteile davon, wenn wir Separate Hierarchies umsetzen? Das eine sehr wichtige ist, dass wir keine Konflikte mehr haben können zum Zeitpunkt der Paketinstallation, sondern erst beim Ausführen. Das heißt, Slash-bin ist auf meinem System eigentlich nur ein Convenience Directory. Ich erkläre gleich, warum das so ist. Aber erst wenn wir über Slash-bin in einem Programmausführen sagen, wir Slash-bin-Slash-Python, dann müssen wir uns entscheiden, okay, welches Python ist denn eigentlich gemeint? Also ist es jetzt 2.7 oder Version 3. Und das bedeutet also auch, dass der Package Manager an sich komplett versionsagnostisch sein kann. Und das ist ein sehr wichtiger Punkt hier, weil ein großer Teil der Berechnungen einfach komplett wegfällt. Bei normalen Installationen kann es sein, dass einfach ein paar Sekunden am Anfang von eurer Installationsoperation mit dem System aufgelöst hätte. Aber bei größeren Updates, ich weiß nicht, ob ihr das schon mal erlebt habt, wenn ihr in ein paar Wochen lang so ein Debian-System nicht aktualisiert, dann müsst ihr es auch einmal aktualisieren, weil ihr ein neues Stück Software braucht, was ihr vorher nicht hattet. Und dann wartet ihr erst mal irgendwie 1, 2, 3 Minuten, darauf, dass diese ganzen Dependencies resolved werden. Und das auf irgendeinem Intel i9, also aktuelles CPU, die man sich so für Geld kaufen kann und ein Sodom aufzieht, braucht man das gar nicht. Vorteil Nummer 2, die Pakete können immer nebeneinander installiert werden. Das heißt, wenn ich von der ZSH, also meine Lieblingsstelle ist, und ich habe die in Version 5.6.2 und ich mache ein Update auf die 5.6.3, und ich merke, oh, mein Konfig-Fall für die ZSH ist jetzt kaputt. Das benutze irgendwie ein Feature, wo ein Bug eingebaut wurde oder so. Dann kann ich mich entscheiden, okay, ich mache jetzt ein partielles und das bedeutet, dass ich sagen kann, okay, die neue Version von der ZSH die löscht ich einfach und dann nimmt er wieder die alte. Oder ich starte explizit die alte. Das heißt, die Programme sind immer nebeneinander installierbar und man kann immer einfach das ein oder das andere starten. Das gibt es jetzt in anderen Distributionen natürlich auch punktuell. Zum Beispiel in Debian kann man natürlich Python 2.7 und Python 3 nebeneinander installieren. Aber dort muss eben der Package Manager dafür aufwandtreiben. Also die Maintainer müssen sagen, okay, das ist Python 7 und 1, das ist Python 3. Wohingegen hier alle Pakete einfach immer in jeder beliebigen Versionskombination nebeneinander installiert werden können. So, dann kommen wir mal auf die Immutability zu sprechen. Die Paketinhalte, habe ich ja schon gesagt, sind Read-Only und die Exchange-Directories sind auch Read-Only. Die behindern einfach nur diese Symbolik-Links. Jetzt ist es aber so, dass manche Programme erwarten, dass das System beschreibbar ist. Bei GNOME kommt zum Beispiel G-Settings mit und das will ein Cache Directory ablegen. Das funktioniert natürlich nicht, wenn das Read-Only ist. Meiner Meinung nach ist das ein Floor im Design von dem Cache den G-Settings hier verwendet und ich finde, das sollte upstream verbessert werden. Das ist ein anderen Teil, der an diesem Projekt interessant ist, dass alle Verbesserungen, die ich machen muss, damit Zeug läuft, generell Verbesserungen sind, die auch für andere Use-Cases eigentlich gern gesehen sind. Ich stelle hier folgende Ideale auf für Caches. Gute Caches sollten optional sein. Das heißt, wenn ich den Cache nicht habe, dann sollte er transparent den Cache erstellen und ihn vielleicht nicht persistieren. Das ist mir doch egal, ob das Programm funktioniert. Bei G-Settings startet das Programm nicht, wenn der Cache nicht da ist. Meiner Meinung nach ist das kein Cache mehr. Gute Caches sollten transparent erstellt werden und Gute Caches sollten automatisch aktualisiert werden, wenn das nötig ist. Gerade der letzte Punkt ist manchmal schwierig. Wenn man den Spezialfall hat, dann muss man sich nicht umsetzen. Aber nach diesen Idealen sollte man streben, würde ich sagen. Ich hatte schon erwähnt, dass Pakete nebeneinander installiert werden können. Wie funktioniert das genau? Das Konzept hier nennt ich Hermetic Packages. Die Idee ist, dass Änderungen am System nie etwas am Programmverhalten ändern. Dass ein Paket quasi alles, was es braucht, hermetisch abgeregelt von der Außenwelt referenziert. Wie das konkret funktioniert, ist, dass wenn ich diese Bildumgebung aufbaue, dann sind dort nur die angegebenen Abhängigkeiten stehen nur die zur Verfügung mit den kompletten Versionsnamen im Paket. Das hatte ich ja schon gezeigt, dass in den Paketnamen quasi immer alles komplett spezifiziert ist. Beim Bauen wird am Ende ein Rapperscript für jedes Binary erstellt. In diesem Rapperscript gibt es jetzt so etwas wie Path, Perl5lib, Python Path, also alle diese Umgebungsvariablen, die einen Einfluss darauf haben, wo die Module zur Laufzeit nachgeladen werden können oder wo andere Programme zur Laufzeit gefunden werden können, die werden so gesetzt, als hätte das Programm eben nur die Bildabhängigkeiten zur Verfügung. Und dadurch bevorzugt das Programm also diese Fade und liest dann daraus die gleichen Sachen, wie damals alles kompelliert wurde. Da ändert sich dann also einfach nichts. Es ist so, dass ich am ganz am Anfang gesagt habe, okay, die Programme werden entpackt und dann werden sie konfiguriert. Was ich mit dem konfigurieren meine, da ist der Fachbegriff für Hux und es gibt noch ein ähnliches Konzept, das nennt sich Triggers. Ein Huck, auch genannt Maintenerscript oder Postinscript, oder da gibt es ganz viele verschiedene Namen dafür, ist einfach ein Stück Programmcode, der ausgeführt wird bei der Paketinstallation. Der wird bei dem Paket mitgeliefert und es üblicherweise unter kompletter Kontrolle ein Trigger hingegen ist auch einfach ein Stück Programmcode, was bei der Paketinstallation ausgeführt wird, aber bei der Paketinstallation von einem anderen Paket. Ein Beispiel dafür ist das Mann Paket, welches nen Trigger installiert, so dass wenn ein beliebiges anderes Paket, welches nen Mann Page enthält, also quasi alle Pakete die Anwendungen enthalten, dann wird nen Index aktualisiert für den Mann Page Viewer, so dass man die Volltextsuche über Mann Pages machen kann. Wer von euch hat schon mal die Volltextsuche über Mann Pages benutzt? Okay, zirka nen Viertel von den Leuten, wenn überhaupt. Für mich persönlich ich wusste das lange Zeit gar nicht, dass es das gibt. Ich hab das vielleicht einmal verwendet um zu schauen, ob's geht und ich mach das einfach General in Browser, da ist die Suche eh viel besser. Das heißt, für mich persönlich ergibt es gar keinen Sinn, dass das Mann Paket sagen kann, hey, ich mach dir die Installation von allen anderen Paketen langsamer, indem ich mich um den Feature kümmer, was du gar nicht willst. Außerdem ist es so, dass sowohl Hux als auch Trigger die parallele Installation von Programmen unmöglich machen, denn damals, als das Konzept so festgegossen wurde, gab's halt noch nicht so verbreitete Multicore-CPUs und üblicherweise und mir ist da auch kein Gegenbeispiel bekannt, sind diese ganzen Hux und Trigger einfach gar nicht Concurrency Safe. Also wenn ich das eine Paket gerade die Hux von dem ein Paket laufen lasse und gleichzeitig die Hux von dem anderen Paket laufen lassen würde, dann gibt's bestimmt super viele Bugs, wo die sich in die Quere kommen. Das heißt, die Paketmanager schaden die einfach alle sequenziell hintereinander. Außerdem ist es so, das ist beliebiger Code, der kann super langsam sein, der kann auch buggy sein und den hat einfach nur der Maintainer unter Kontrolle. Der ist üblicherweise auch schlecht getestet, weil üblicherweise der Maintainer halt einfach immer Updates macht und zwar immer von der letzten Version auf die neueste Version und so Szenarien wie, ah, ich hab irgendwie ein altes Debian Stable, hab eine Version ausgelassen und aktualisiere jetzt und wie dann der Huck überhaupt funktioniert so oder ob der überhaupt richtig funktioniert das steht auf einem anderen Blatt. Genau, ich hab schon gesagt, die Arbeit ist gegebenenfalls gar nicht bei der Paketinstallation nötig, also konkret, für Mann würde ich einfach vorschlagen, dass dieser Trigger halt nicht zur Paketinstallation laufen sollte, sondern dass der dann läuft, wenn ich tatsächlich auch eine Volltext-Suche starte. Das ist jetzt gegebenenfalls Geschmackssache für manche Leuten, die machen vielleicht so viel Volltext-Suchen, dass sie immer einen speziellen Index bevorzugen, aber generell ist es möglich, dass man diese Triggerhooks und so weiter quasi auf später verschiebt. Meine These ist noch weitreichender, nämlich soweit, dass man ein funktionierendes System komplett ohne Hooks und ohne Trigger einwandfrei umsetzen kann. Und wie gesagt, das Vehikel dafür ist, dass man die Arbeit von Paketinstallationszeit nach Programm Ausführungszeit verschiebt. An einem konkreten Beispiel bei SSH ist ja so, dass man einen Hostkey braucht auf dem Server, bevor man sich von dem Kleint aus darauf einloggen kann. Und was wir hier machen ist, dass es zur Paketinstallationszeit sagen, okay, dann erstelle ich halt ein Hostkey, haben wir in dem Rapperscript um SSHD, wird einfach gecheckt, ist der Hostkey da und wenn nein, dann wird er halt erstellt. Das hat den Vorteil, dass wenn ich das Paket erst mal nur installieren möchte, weil ich vielleicht nur an dem Kleint interessiert bin und nicht am Server, dann muss ich halt noch nicht diesen Hostkey erstellen, und erst dann wird die Arbeit gemacht, wenn sie auch tatsächlich benötigt wird. Es gibt sehr wenig Ausnahmen für diese These. Das Einzige, was mir wirklich eingefallen ist oder aufgefallen ist, sind Bootloader und Firmware. Also alles, wo irgendwie man ein Paket sich drunter lädt, aber die Idee eigentlich gar nicht ist, dass man die Daten in den Paket für das laufende System hat, sondern dass sie irgendwo anders hingeschrieben werden müssen. Also im Fall von irgendwie Firmware, so vielleicht in UEFI Update, das muss halt auf den Master Boot Record von der Festplatte oder so. Das ist natürlich außerhalb von dem System, und dann muss man natürlich irgendwie dann ein Special Case einbauen. Umsetzbarkeit. Wie praktikabel ist diese ganze Idee eigentlich? Ich habe einen Fuse-Datei-System implementiert, um diesen Slash-RO Mountpoint oder diesen Eintrags, ein Startpunkt in die Hierarchie zur Verfügung zu stellen. Ich habe am Anfang versucht, das einfach über Kernel Mounts und Overlays und Union-Datei-Systemen usw. umzusetzen. Es funktioniert einigermaßen, aber letztendlich ist es mehr Arbeit, diese ganzen Mounts zu benutzen, als das einfach alles selber Transparenz zu implementieren. Und insbesondere ist es viel, viel schneller, wenn man das selber macht, weil sich rausstellt, dass Kernel Mounts echt langsam sind. Sobald ich das verstehe, ist da einfach eine verkettete Liste als Datenstruktur verwendet, und je mehr Mounts man hat, das so langsamer wird das. Und die Mounts sind ohnehin irgendwie ziemlich langsam, wenn man so ein SquashFS-Image mountet. Und das resultiert dann halt mit dem puren Userspace-Ansatz einfach nicht hat. So, abgesehen von diesem Fuse-Datei-System muss man jetzt, wenn man die Pakete baut, den natürlich auch sagen, hey, pass mal auf, du landest nicht in User, sondern du landest in dieser Separate Hierarchy. Und das macht man mit dem Prefix-Argument beim Kompilieren. Also wenn man das Konfiguraufruf, dann sagt man minus, minus prefix equals RO-Enginex und so weiter. Und dann weiß das Paket Bescheid. Es gibt ein paar wenige Pakete, die gepatched werden müssen. In manchen Städten, wo man die Pakete verwendet wird, weil die Leute selten testen, ob das wirklich auch funktioniert, dass man quasi komplett andere Pfade als auf dem System üblich ist verwendet. Das heißt, es gibt ein paar Service-Files, zum Beispiel das Service-File für Getty, in dem steht Slash-Spin, Slash-Getty drin, das muss ich natürlich umbiegen, weil ich das koppeln will mit der konkreten Version, die halt zur Bauzeit vorhanden ist. Also Slash-Spin gibt es schon auch auf dem System, das hat auch irgendwie ein bisschen spezielles Path-Handling drin, G-Object, Automeg, also so ein paar gibt es, wo man da irgendwie noch ein bisschen nachtreten muss, aber das sind auch alles Patches, die upstream einwandfrei reinfließen sollten. Und dann gibt es noch irgendwie ganz wenige Pakete, da habe ich nur ein Beispiel dafür, die grundlegende Annahme über das System auf einem sehr niedrigen Level treffen, in dem Fall wer das DRACUT, welches In-It-RDs oder In-It-RAMFS Umgebung transparent von dem laufenden System abzuleiten sozusagen, schaut da also mit LDD wirklich in die Binaries, was haben die Abhängigkeiten, kopiere das dann alles rüber und da kommen diese Rapperscripts, die ich hier habe in die Quere, da muss man dem natürlich dann sagen, okay das ist jetzt das Rapperscript, aber das eigentliche Binary, welches das Rapperscript aufruft, brauchst du übrigens auch noch. Das ist aber wirklich der Ausnahmefall und abgesehen davon funktionieren die allermeisten Tricks, obwohl es machbar ist, vielleicht nicht für jeden geeignet ist. Einige Leute wollen vielleicht diese Konfigurationsfrontends wie Debcon oder Jast oder was es da sonst noch so gibt. Ich persönlich vertrete den Standpunkt, dass das Programm so einfach konfigurierbar sein sollte, dass man kein separates Frontend benötigen müsste für die Konfiguration, aber da gehen vielleicht die Meinungen auseinander. Ein Beispiel möchte ich noch nennen als ein interessantes Ding, was dabei rausfällt, wenn man ein System so vertreten kann und das ist das DebugFS. Ihr kennt das vielleicht, wenn ihr schon mal einen Core-Dump gehabt habt, den ihr in den Debug laden wolltet oder einfach einen laufenden Prozess in den Debug laden wolltet und dann macht ihr das in der Distribution und bemerkt ihr, hey Moment, ich hab zwar das Programm installiert, aber die Debuginformationen fehlen, die muss man üblicherweise nachinstallieren. Unter Debian ist das ziemlich schrecklich, da muss man dann selber rausfinden, welche Pakete brauche ich dafür und dann in Fedora ist es ein bisschen einfacher, weil die so einen Skripte haben, welches automatisch versucht euch zu sagen, welche Paketnahmen das sein könnten, dann installiert man die und dann klappt es meistens. Aber meiner Meinung nach ist dieses ganze Konzept, dass man die Debugsymbole aus einem Paket rausfrimmelt, ohne dass man das dann später transparent wieder zusammenfrimmelt, eine kaputte Abstraktion. Also da hat jemand was optimieren wollen und hat sich nicht durchgedacht so, wie man das folgende. Die Debugsymbole packt man automatisch aus allen Paketen raus im Package Manager, der hat genug Informationen über was da in dem Paket drin ist. Und dann mountet man das Fuse-Datei-System, welches wir für die Slash-RO-Hierarchie ohnehin schon brauchen, einfach nochmal in Slash-RO-DBG und zeigt das aber nicht auf quasi den Paketinhalt, sondern auf die Debug-Pakete und dann kann man Lazy-Loading über HTTPS aktivieren, was super einfach möglich ist, weil wir es nicht mehr so tiefen zu tun haben, die wir dann erstmal komplett runterladen müssen und verifizieren und ausparken und caching und so weiter, sondern wir können einfach sagen, okay, in dem Image da brauchen wir diesen Block und jeden Block, dann laden wir die einfach transparent und dann funktioniert das auch einigermaßen performant. Was man dann damit machen kann, ist in dem Split-Prozess, wenn man die Debugsymbole raus tut, kann man eben einen Pfad hinterlassen, bei dem dann der GDB nachschaut, also wo er dann die Debugsymbole sucht. Und wenn der GDB auf einem CoreDOM gestartet wird, dann greift er auf diese ganzen Dateien zu und das Fuse-Datei-System erkennt, ah, der will irgendwie die Debug-Information vom EngineX, dann lad ich die jetzt transparent über HTTPS in den GDB rein und dann hat man automatisch immer alle Debugsymbole quasi auf dem System verfügbar, ohne dass man sich jemals darum kümmern muss, dass die da sind und ohne, dass man sie alle im Vorhinein runterladen muss. Und das finde ich eben interessant, dass man solche Ideen relativ einfach umsetzen kann, wenn man einfach dann tweaked, wie das System aufgebaut ist. So, jetzt möchte ich einen Fazit ziehen und dann haben wir noch Zeit für eine Fragerunde. Das Fazit ist ein Append-Only-Package-Store ist viel eleganter, als in dem System rumzumalen. Man hat ein einfacheres Design und die Implementation ist deutlich schneller. Die Exchange-Directories simulieren ein normales System, insbesondere für Tritt-Software. Man kann also unpaketierte Software ganz einfach selbst kompellieren und ausführen, kein Problem, sie sei auf einem normalen System. Man kann close source binaries üblicherweise problemlos ausführen. Ich habe das am Beispiel von Steam gemacht, welches eben auch 32-Bit Libraries braucht, das heißt, ich habe auch Cross-Compilation implementiert und das funktioniert einwandfrei. Die Ideen sind alle umsetzbar und das liegt zum großen Teil daran, dass andere Konzepte, wie zum Beispiel Live CDs das Konzept von einem Read-Only-System schon gepreikt haben und das in Cross-Compilation ohnehin die Pfade alle umgebogen werden und abweichen und dadurch ist eigentlich Software, die es schon eine Weile gibt, die haben normalerweise Leute schon auf eine Live CD benutzen wollen und vielleicht schon mal Cross-Compilen wollen und dann ist die eigentlich in einem guten Zustand, dass man sie auch einfach so kompellieren kann. Noch kurz über das Projekt, weil die Frage garantiert aufkommt, das Ziel ist es hier nicht, jetzt eine neue Linux-Distribution vorzustellen und aufzubauen, sondern die Idee ist, dass ich euch jetzt hier Block-Posts genauer ausführen und dass dazu quasi eine Proof-of-Concept-Implementation kommt, damit Leute nicht sagen können, die Ideen sind ja schön und gut, aber in der Praxis würde das ja niemals funktionieren und die Hoffnung ist, dass andere Distributionen die Ideen vielleicht teilweise oder vollständig übernehmen könnten. Wenn ihr das Projekt verfolgen wollt, gibt es im Moment noch ein privates GitRepo, in den nächsten Wochen arbeite ich daran, dass das öffentlich wird, auch mit einer freien Lizenz natürlich. Wenn ihr euch sehr interessiert, dann könnt ihr per Mail gerne nach einer Einladung fragen, kein Problem. Es gibt auch eine Mailing-Liste, wenn ihr Feedback habt dazu, würde ich mich sehr freuen zu dem ganzen Projekt, wenn ihr mir einfach eine kurze Mail schreibt oder solange ich heute noch hier bin, einfach noch ansprechen, die Nacht ist ja noch jung. Ihr könnt auf freelists.org slash list slash distry euch da eintragen, aber postet das bitte noch nicht online vor meiner Veröffentlichung, sonst nehmt ihr mir ein bisschen den Wind aus den Segeln. Wenn man also die Distribution einmal komplett durchbaut, dann hat man da vielleicht irgendwie zwei, drei Stunden, die der Rechner anderweitig wenig benutzbar ist. Die Idee ist, dass man vielleicht einfach sich irgendwie 20 Cloudforms hoch startet und dann verteilt man den Bild da drüber und dann dauert es vielleicht nur noch zehn Minuten oder so. Das würde die Entwicklung nochmal deutlich einfacher machen und ich finde es ein interessantes Problem. Es gibt noch genug Detailverbesserungen, die man vornehmen kann. Ich habe während der Veranstaltung noch ein paar Ideen bekommen, die ich gerne umsetzen würde, und dann kann man sich da jetzt verkünsteln und quasi das Leben lang an diesem System trickeln. Aber wie gesagt, im Wesentlichen, die Blockartikel ist das, was dabei noch rauskommt. So, jetzt haben wir Zeit für Fragen und Feedback. Ich kann euch auch gerne noch eine Demo geben, aber da würde ich gerne von euch so ein bisschen angeleitet werden, was euch genau interessiert und ich sage an der Stelle schon mal vielen Dank für eure Aufmerksamkeit. Vielen Dank. Ich laufe mit den Mikros herum, vielen Dank. Um es ein bisschen ketzerisch zu formulieren, vielen Dank für den schönen NixOS Einführungsvortrag. Für mich als NixOS-Nutzer hast du da gerade eigentlich genau das beschrieben, was ich verwendet, zumindest so 80%. Der wesentliche Unterschied, den ich jetzt so gesehen habe, ist, dass du in deinem Slash-Ao oder Images zusammenfused mit deinem Fused-File-System während bei NixOS der Nix-Storen ein normales Filesystem ist, wo Dinge entpackt werden. Wo Archivien entpackt werden. Von daher ist das ein bisschen die Frage, ob das für dich nicht zeiteffizienter wäre, dich um Verbesserungen NixOS zum Beispiel zu bemühen. Zum Beispiel, wenn du jetzt sagst, du hast festgestellt, so ein Prozess ist da schneller, dann wäre es doch wahrscheinlich effizient, das alles umzusetzen in der bestehenden Institution, wo solche Probleme wie du beschrieben hast, mit dem GCC der Include-Fade finden mussten, so was alles schon mal gelöst wurde. Und vielleicht noch als konkrete Frage auf deiner Tabelle, die du ganz am Anfang hattest mit den Geschwindigkeiten, wo du sagst, dass NixOS war, und du hast in den letzten 10 Sekunden gedauert, was hast du da genau gemacht? Welchen hast du da genau ausgeführt? Weil ich habe eine Vermutung, dass du da NixOS Rebuild gemacht hast und NixOS Rebuild, da ist das teuerste eben nicht, irgendwie Pakete zu installieren, sondern da ist das teuerste, diese ganze Nix-Konfiguration auszuwerten, also diese Programmierspare zu interpretieren. Ja, das wäre auch meine Vermutung. Ich beantworte das umgedreht, dass da NixOS irgendwie erst teure Sachen evaluieren muss, weil sie sind auch die genauen Befehle zum Nachprobieren dabei. Da kannst du auch gerne noch mal mehr in eine Mail schreiben, was ich da eigentlich verwenden soll, dann können wir das gerne noch rausfinden. Du hast sicherlich recht, dass viele der Sachen in NixOS auf jeden Fall sehr ähnlich funktionieren oder tatsächlich genau so, aber die Grundidee, dass du eben diese Image hast, die du irgendwie so zusammenwürfelst, dass da irgendwie ein System bei rauskommt und das ist ein großer Unterschied zu NixOS, was auch Trittsoftware einfach frisst, und ich hatte auch NixOS eine ganze Weile lang selbst verwendet auf meinem Laptop. Ich bin aber an einige verschiedene Grenzen gestoßen, für mich persönlich, die das System nicht so angenehm gemacht haben, für mich. Und deswegen finde ich die Ausprägung unterschiedlich genug, als dass ich es interessant genug gefunden habe, das jetzt mal durchzuspielen. Was du vorgestellt hast, ist ja relativ weit weg von, was die Standarddistribution machen. Siehst du eine Chance, da inkrementell mehr in die Richtung zu kommen und wenn jetzt Debian sagen würde, oh, finden wir interessant, was wäre der erste Schritt. Weil ich kann mir jetzt schwer vorstellen, dass Debian so eine große Änderung mit einer neuen Version. Das ist natürlich so ein bisschen die Schwierigkeit an der Sache. Wo hast du jetzt quasi fruchtbaren Boden, als dass du zum einen genug Flexibilität hast, um so eine Änderung umzusetzen und ja, wie machst du sie schrittweise, weil du musst sie ja schrittweise machen, gerade bei Debian. Das ist das, was ich gerne machen würde. Ein bisschen der Andere an diesem Projekt ist ja auch, dass man quasi Greenfield einfach mal alles so ausprobieren kann, wie man es gerne hätte. Und dann kann man sich jetzt überlegen, so was sind die wichtigen Punkte davon. Womit ich wahrscheinlich anfangen würde, wenn ich das in Debian machen würde, ist einfach einmal das komplette Archiv neu zu bauen. Und zwar mit diesen Dash-Prefix-Optionen, also die Pfade aller einfach einmal umgebogen und dann versuchen die resultierenden Debian-Packages in Squashifest-Images zu konvertieren und dann zu schauen, wie man das zusammenwürfelt. Aber wie gesagt, das habe ich jetzt nicht ausprobiert. Das wäre nur mein erster Ansatz. Sicherlich muss man da noch ein bisschen genauer planen und das dann wirklich auch umzusetzen. Erfordert sehr viel Zeit und die Zeit habe ich eben einfach nicht. Deswegen ist meine Hoffnung, dass quasi hier so ein bisschen das Fundament gelegt werden kann und wenn Leute sich dann zusammentun könnten, um das tatsächlich umzusetzen, das wäre quasi das best possible Outcome. Als Prior Art war ja jetzt nichts so erst schon genannt. Hattest du sie ja auch schon mal so ältere Projekte wie Google, Linux oder Tiny Core angeguckt, die ähnlich arbeiten? Nein, die beiden habe ich mir jetzt nicht konkret angeschaut. Also ich habe schon davon gehört, aber nicht genau angeschaut, wie die funktionieren. Weil ich glaube, gerade Tiny Core benutzt auch so ein, dass erst SquashFS-Sachen eben mounted. Also ich habe kürzlich gesehen, dass in BOS da gibt es ja dieses Haiku und das hat in der aktuellen Version auch ein Package Manager, bei dem einfach Images gemountet werden. Das kann man auch so machen. Wenn jetzt das alles soweit verteilt ist, wie finden dann eigentlich die dynamische Linke, die ganzen Bibliotheken? Genau, wie das funktioniert, ist in einem Elf-Binary hast du ja den sogenannten Airpath. Abgesehen davon, wenn du den nicht hättest, könntest du auch den LD-Library-Path über die Umgebungsvariable setzen und bei mir ist das eben so, ich kann da jetzt auch mal kurz, gehen wir mal hier in den Demo-Teil über. Also wenn ich jetzt hier irgendwie in Git reinschaue, wenn ich hier bin in Git, und das ist eben dieses Script, ihr seht, da sind halt super lange Pfade drin, aber wenn wir uns out in Git anschauen, nicht mit Cut, dann sehen wir hier der dynamische Linke, findet die durchaus und, aha, okay, weiß gerade nicht, was da gerade passiert, wenn es jemand sieht, vielleicht Runpath? Nein, ich glaube es ist Airpath, aber ja, jedenfalls kann man das da auslesen und dann wird eben, also hier auf der Version von dem System wird er eben noch auf die ganzen Direktories gesetzt von den Abhängigkeiten, aber mittlerweile bin ich dazu übergegangen, dass ich einfach einen Lib Sub-Directory habe und darauf wird der Airpath gesetzt und darin sind Sim-Links auf die ganzen Bibliotheken in den korrekten Versionen. Also so wird das gefunden. Das war halt auch meine Frage, weil ein fixer Airpath heißt, dass jede Security-Update ein Rebuild von allen Abhängigkeiten mitzieht ist, also der erste Teil ist korrekt, beim zweiten Teil stimm ich nicht notwendigerweise zu. Leute werfen die Hände in die Höhe. Ne, was ich meine, ist, dass man in so einem System eben ohnehin ein automatisches Tool braucht um zu sagen, ich habe jetzt hier eine Änderung gemacht, folgende Reverse Dependencies müssen alle neu gebaut werden und dann baut man die einmal alle neu und dann muss man das halt verteilen. Da gibt es Downsides davon und da gibt es sehr erbitterte Diskussionen darüber. Ich kann mich erinnern, weil ich vor zehn Jahren angefangen habe Go Packaging in Debian zu machen und mich die Leute dafür sehr hassen, weil du dort genau das gleiche Problem hast und auch in Haskell, was eben auch statisch baut, soweit ich mich erinnere. Aber ich sage eben, für dieses System, das muss zum Beispiel ja auch nicht irgendwie auf den kleinsten Embedded Devices laufen. Also du musst ja nicht irgendwie alles in Shared Libraries packen von auf dem System vorhalten, sondern du kannst ja auch mehrere Versionen vorhalten und dann zum Beispiel, wenn du eine Sicherheitslöcke in OpenSSL hast, da musst du halt alle Software, die mit dem Rest der Welt spricht, schnell aktualisieren und den Rest vielleicht irgendwie langsam. Also ich finde, das ist nicht so schwarz-weiß und da gibt es schon so ein bisschen Spielraum und wenn man die Ressourcen hat, also wenn man groß genug System hat, als dass man sich diese ganzen Pakete eben einfach runterziehen kann und neu bauen kann und das kostet alles nix, dann ist das in der Praxis nicht notwendigerweise ein Problem. Aber ja, da kann man lange darüber diskutieren. Also zuerst mal Danke für den Vortrag. Bist du denn schon auf irgendwelche Probleme gestoßen, wo du noch nicht so genau weißt, wie du sie lösen sollst? Also immer mal wieder in der Laufzeit des Projekts, aber das waren üblicherweise Probleme, die einfach damit zusammenhängen, dass die Standardkonfiguration von vielen Paketen nicht quasi dementspricht, wie die Realität aussieht. Also oftmals ist es so, dass Distributionen eben Sachen anpassen müssen, müssen irgendwie Pfade umbiegen, oder gelinglich ist es auch so, um das mal als ein konkretes Beispiel zu machen. Für die längste Zeit war es so, dass wenn ich hier irgendwie in dem Network Manager Applet, man sieht es ja nicht aufpoppen, oder in allen möglichen Dialogen, wenn ich einen Pop-up Fenster hatte, dann war die Größe richtig, aber der Inhalt einfach grau. Und ich wusste einfach nicht, woran das lag. Und nach einer Weile habe ich dann rausgefunden, das liegt daran, dass wenn man Kyro kompiliert, aber die libx-Render nicht hat, dann ist das zwar eine legitime Konfigurationsoption zur Kombinationszeit, aber zur Laufzeit ist dann halt einfach alles leer. Und ich habe da auch einen Blog Post drüber geschrieben, dass eben Optional Dependencies generell eine schlechte Idee sind, aus genau diesem Grund, weil du halt super viel Bittrott hast. Und ja, da passiert eben viele so Sachen, die man dann debaggen muss und die man dann fixen muss, aber das sind die Kosten, eine neue Distribution von 0 auf hoch zu ziehen. Das hättest du glaube ich im gleichen Maße, wenn du so ein Linux from scratch dir bauen würdest. Und das liegt nicht inherent daran, dass die Konzepte flawed sind. Ich habe allerdings mehrfach die Konzepte ein bisschen angepasst, basierend auf den Erfahrungen, die ich gemacht habe. Also ein Beispiel dafür ist, dass mit dem R-Path und dem lib-Directory, ich bin deswegen vom R-Path auf ein lib-Sub-Directory umgestiegen, weil sich rausstellt, dass der Dynamic Linker einen Cash hat, der nur dann richtig aktiv werden kann, wenn du Einverzeichnungen hast, sonst quasi nie richtig warm werden kann. Und dann dauert es eben 10 Millisekunden, jeden Git-Aufruf zu starten, selbst wenn der Git-Aufruf an sich nur 3 Millisekunden dauert und wenn du dann irgendwie ein Editor-Plugin hast, welches Git-Aufruf ein paar Mal, dann wird das halt furchtbar langsam und bei so Sachen muss man halt nochmal irgendwie überlegen, okay, wie kann man das Geschick da lösen. Aber im Großen und Ganzen funktioniert es eigentlich erstaunlich smooth. Andere Frage, was passiert, wenn man das System rebooted? Kannst du genauer fragen? Ja. Und wenn nicht das System neu startet, dann muss ja irgendwas loslaufen, die alle wieder einbauen, oder nicht? Ah, genau, ja. Also das Fuse-Datei-System wird eben in der, also wenn du den Kernel startest und er den init-Adelaid, dann ist da als slash init einen Rapper drin, der das Fuse-Datei-System startet, welches dann eben automatisch die ganzen Images transparent mounted, bevor er das eigentliche init exakt. Hier vorne. Ich bin nicht ganz sicher, ob ich es richtig verstanden habe, aber... Entschuldigung. Ich bin nicht sicher, ob ich es richtig verstanden habe, aber du hast ein Fuse-Datei-System gebaut, wo du dann alles rein entpackst. Hast du da mal ein Feind drauf ausgeführt, wie schnell das im Vergleich zu einem aktuellen Debian im Betrieb ist? Das hat sicherlich einen Overhead, ja? Ja, weil... Genau, aber ich sage ja nicht, dass das Fuse-Datei-System die Lösung ist und dass alle Distributionen jetzt grundsätzlich Fuse-Datei-Systeme nutzen müssen, wenn man ein Proof-of-Concept ist. Und wenn man sich jetzt entscheidet und sagt, okay, das Konzept möchten wir jetzt umsetzen, dann kann man das ja auch noch schneller machen, indem man zum Beispiel ein Kernel-Datei-System macht, welches das virtuell zur Verfügung stellt. Weitere Fragen. Da waren vorhin noch ein paar Hände mehr oben. Hey, ich komme gleich zu dir. Noch mal zwei Fragen. Du hast dich vorher am Anfang drüber beschwert, bei einem normalen Packetmanager du entpackst das Paket, und du verifizierst es. Lässt du das einfach sein? Also Kompressionen scheiß ich drauf. Nee, also Kompressionen habe ich auch, aber halt Transport-Level-Compressionen. Also wenn du quasi über HTP-Lads, dann liefert halt der HTP-Server das G-SIP aus, was du halt auch schon auf der Platte vorhalten kannst und er end G-SIP, dann halt, werden er quasi runter schreibt und verifiziert dann natürlich das Resultat, aber mountet es dann halt einfach direkt. Ja, das könnte man auch in richtigen Packetmanagern einbauen. Ja, also viele der Sachen, die schief laufen in heutigen tatsächlichen Packetmanagern, sind einfach nur Implementationsprobleme. Also zum Beispiel, dass ich bei mir die Paketinstallation einfach grundsätzlich Concurrent mache und quasi maximal parallelisiere, dass da zum Beispiel ab nicht auch aggressiver ist, wenn es Pakete runter lädt zumindest, ist einfach ein Implementationsproblem. Aber deswegen fand ich es eben interessant, mal wirklich die Limits zu pushen und ich habe auch tatsächlich mal geschaut, wie kann man das auslasten. Also die Installationsspeeds, wenn ihr vorhin in der Demo aufgepasst habt, waren irgendwie ein bisschen über 100 MB diese Kunde. Das ist also eine Gigabit-Leitung, so eine typische Leitung eben. Aber interessanterweise skaliert das Konzept auch höher. Also ich habe mir dann mal so eine 40 Gigabit Ethernet-Karte in meine Rechner eingebaut und dann gesehen, dass man eben mit 12 Gigabit Pakete installieren kann und das schon nicht so schlecht, oder? Also das lang für die nächsten Jahre bestimmt. Hier hinten gab es noch eine Frage. Was ist dann die Pakete genauso wie Debian? Ne, das würde ich nicht sagen, sondern wenn ich... Das ist eine super Überleitung. Ich schaue mal schnell, ob ich hier gerade Internet habe. Ja okay, das sieht doch ganz gut aus. Ich habe kürzlich festgestellt, dass ich gerne das X-Hose-Programm benutzen würde. Das braucht man dafür, dass wenn man Docker startet und darin eine Anwendung startet, die X11 braucht, sagen wir zum Beispiel KiCut, weil man KiCut noch nicht paketiert hat in seinem System, dann muss man dem X-Hover zuerst sagen, dass es okay ist, wenn der Connections aus dem Docker-Container bekommt. Dafür brauchte man X-Hose und ich hatte kein X-Hose und ich kann jetzt hier mal stellvertretend zeigen, wie das hier funktioniert. Also ich habe hier diesen Scaffold-Befehl, der generiert quasi eine Paketbeschreibung und das ist dann die Paketbeschreibung, die ja rauspuckt. Also die URL, die ich ihm gegeben habe, die übernimmt er einfach direkt, den Hash, den die Datei hatte zum Zeitpunkt und das ist der C-Bilder, das ist einfach hier die Standard-Annahme, wenn ich jetzt irgendwie eine URL, die auf C-Pen zeigt, benutze, dann wird er sagen, okay, das ist jetzt ein Perl-Paket, da muss ich den Perl-Bilder benutzen und dann die Build-Dependency und hier sind halt noch keine drin. Wenn ich das jetzt versuche, durchzubauen, ihr seht, wie schnell hier das Configur startet, das ist in der komplett abgeregelten Umgebung. Also das Aufbauen dieser abgeregelten Umgebung, das ist irgendwie, hier passiert in einem Bruchteil von der Sekunde quasi die einzelnen Pakete, die wir jetzt zur Verfügung stellen, nachgeladen werden. So, jetzt funktioniert das noch nicht, weil das Configur sich beschwert so, hey, X Proto habe ich nicht, X Elf habe ich nicht und XMU habe ich nicht. Und jetzt kann ich hier in dieses Build-Proto reingehen und sagen, okay, Xorg Proto ist das Paket, in dem das Proto Ding drin ist, dann LibX Elf und hier LibXMU, dann schreibe ich das raus, mache das nochmal, das Configur läuft wieder los, die nötigen Pakete, die er gerade eben nicht gefunden hat, das sieht aber gut aus, dann kompiliert er das und jetzt habe ich das paketiert und jetzt habe ich hier dieses SquashFS Image, das kann ich hier an SquashFS draufmachen und sehe dann hier drin, ah, da sind jetzt die ganzen Pakete drin, unter anderem eben bin X Host und das war jetzt der komplette Prozess von Null auf, ich habe ein fertiges Paket. Und wie du siehst, also das hat jetzt hier nichts mit Debian zu tun, aber manchmal schaue ich durchaus nach, okay, bei jetzt diesem einen Paket, wie macht das eigentlich Debian, wie macht das Arch Linux, damit ich einfach sehe, was müssen die so üblicherweise angeben, damit das Zeug überhaupt läuft und dann übernehme ich das halt, aber das sind wirklich nur die Ausnahmen und eine andere Beobachtung ist, dass diese ganze Flexibilität, die Package Manager üblicherweise anbieten über Spec-Files und über Debian-Packaging-Files, ist heutzutage eigentlich im Normalfall nicht mehr nötig, weil die Welt einfach so sehr konvergiert ist auf, ah, das ist irgendwie wie man C-Programme baut, das ist wie man Python baut, dass man einfach sagen kann, in so einer deklarativen Beschreibungssprache, okay, das ist jetzt, was ich machen möchte und der Rest passiert einfach automatisch. Ja, das Ganze erinnert einem ziemlich fest an die Art und Weise, wie nichts der Package Manager das halt auch macht. Ja. Und da hat es ja auch sehr viele Pakete, die nicht einfach nur straightforward sind, ja, kann mal das Mess- und Bildsystem, das Paket baut, sondern halt noch Patches und alles Mögliche, das dann halt doch noch extra gemacht werden muss und wenn du Pakete für dein System paketieren möchtest, musst du ja all das auch wieder machen, hast du das Gefühl, du kannst das irgendwie besser machen als nix als, oder als nix? Nee, den Anspruch hab ich auch gar nicht, ich will es nur funktionierend genug machen, als dass Leute mir glauben, dass die Ideen funktionieren. Das war quasi der Milestone und den Milestone hatte ich dann erreicht, als ich auf diesem Laptop Videos in Chrome geschaut habe. Und dann dachte ich, ok, jetzt bin ich fertig, oder? Build and Chill, oder wie? Haben wir noch mehr Fragen, hier vorne ist noch. Wenn du das jetzt mit Fuse alles zusammen mountest, wie viele Pakete kannst du theoretisch installieren, bevor da irgendwo Fuse sagt, nee, ich mag kein Mount mehr. Das Gute ist, wenn ich hier jetzt Mount ausführe, seht ihr, dass das gar nicht so eine lange Tabelle ist, ich meine, sie ist lang, aber das ist einfach so, bei aktuellen Systemen, aber wenn wir hier mountgrab sagen, dann sehen wir hier, es gibt einen Mount, und das ist das Fuse-Datei-System. Und was ich sage, wenn ich sage, was ich meine, wenn ich sage, dass die Pakete innerhalb gemountet werden, ist einfach, dass das Fuse-Datei-System halt einen neuen Reader aufmacht, der eben das QoShFS lesen kann und transparent dann dieses Dispatching macht. Also auf Kernel-Ebene ist es einfach ein Mount, das ist aktuell im Fuse-Datei-System. Und das erklärt auch, was ich vorhin meinte, mit Kernel-Mounts sind langsam, und deswegen lasse ich die einfach außen vor für den Moment. Sonst doch Fragen. Ja. Ach, ich irgendwie habe ich ein Deja-Vue. Ich habe doch noch eine ketzerische Anmerkung gehabt. Du hast vorher das Beispiel mit der Mann-DB gemacht, die man wirklich sehr selten benutzt. Wie regelst du das? Ja, das habe ich aber mit deinem Knob-Startmenü. Willst du jedes Mal dein Startmenü neu bilden, wenn du dein Startmenü aufrufst? Nee, ich finde, da ist die Folie mit den Caches zutreffend. Da sollte nämlich dann irgendwie, wenn das Startmenü aufgebaut wird, müsste er halt schauen, gegebenenfalls macht er das halt nur so und so oft, ob da quasi neue Pakete dazu gekommen sind. Also im konkreten Fall von diesen Menu-Files, die sind ja an der wohldefinierten Stelle, und dann kannst du einfach schauen, okay, was ist irgendwie die End-Time der letzten Datei, hat sich das geändert, dann muss ich halt nochmal schauen, sind da neue dazu, meine internen Caches aktualisieren, und dann wird das eben angezeigt. Das heißt aber, ich muss jedes Mal durch den gesamten Datei-System baumsteigen? Nee, du musst ja nur einmal ein Retail machen und die letzten Datei finden, oder halt irgendwie ein End-Time oder so. Ja. Ich glaube auch, da war auch eben so eine Bemerkung, da haben die, ich weiß nicht genau, wie die Formulierung mehr war, aber die Paketmanager haben da falsch optimiert oder haben der Implementationsdefizit oder so was. Das würde ich nicht so sehen, sondern das ist einfach, dass sich über die Zeit Anforderungen ändert haben. Du meinst halt sowas, wie es soll irgendwie ein Bild durchlaufen in einem CI-System zum Beispiel, und das ist ja eine so gesehen eine relativ moderne Anforderung, dass sowas jetzt irgendwie nicht mehr einmal im Monat passiert, wenn irgendwie die neue Version gekattet wird, sondern jetzt halt irgendwie das CI-Prozess auch irgendwie optimieren, dass ich dann irgendwie das Image in 2,4,2,5 Minuten in die Produktion durchschieben kann anstatt 4 Minuten. Das ist ja auch alles legitim. Aber ich würde nicht sagen, dass das ein Problem ist von den Paketmanagern, dass sie da irgendwie vor 20 Jahren bei irgendwelchen anderem Scheiße gebaut haben, sondern das war halt einfach eine andere Welt damals. Und es wurde auf andere Dinge optimiert. Und wenn ich ein System, was ich sehr langfristig verwende, dann ist in 2,4,2 auch ziemlich egal, ob dann wie KDE eine Sekunde länger zum Installieren braucht, wenn KDE dafür jeden Tag eine Sekunde schneller startet. Klar, ja, das ist natürlich ein Trade-off, den man machen kann. Generell würde ich sagen, dass das nicht unvereinbar ist. Also ich würde nicht sagen, dass du jetzt einen Kontrast beschreibst mit dem KDE-Beispiel. Aber generell merke ich halt, dass mir jede Interaktion mit der Distribution sei es jetzt als Nutzer, wenn ich Pakete installiere oder updatee, oder als Entwickler, wenn ich neue Pakete hinzufügen möchte, keinen Spaß mehr macht, weil alles so langsam ist und weil ich weiß, dass alles so viel schneller sein könnte. Und das ist auch einer der Gründe, weswegen ich mit Debian aufgehört hatte. Manche Leute haben den Blockpost sicherlich gelesen. Was war der Anfang? Ach, genau, du hattest über die Debugoptimierung. Ja, das war ich. Die Debugoptimierung, ja, ich will auch nicht sagen, dass Sie das falsch gemacht haben, weil die Optimierung ist ja durchaus nachvollziehbar. Ja, du hast irgendwie ein Paket, das ist groß. Was kannst du rausnehmen? Die Debuginformation, die wenig Leute brauchen. Superlegitim. Aber das ist eben einfach nicht zu Ende gedacht, wenn du jetzt als Entwickler eben diese 5 Entwickler mitgelegt bekommst, bis du wieder an deine Debuginformation kommst. Das ist der Teil, den ich bemängelt. Dass Sie eine Optimierung umgesetzt haben, ohne auf die UX zu achten. Und gerade, dass man das eben heute viel, viel besser machen kann. Und ich will das auch denen gar nicht vorwerfen, dass Sie es damals nicht gemacht haben, aber dass Sie eben nicht auf den modernen Ansatz umsteigen in endlicher Zeit quasi, das ist das Problem, was ich eben sehe. Also Debian bewegt sich viel zu langsam. Ja, aber das einfachste Mittel wäre, dass du deine Optimierung in den System D mitgelegt bekommst. Entschuldigung. Zuerst mal, proposystem D, Pöttering hat dieses System vor einiger Zeit mal so vorgeschlagen, fast vollständig. Ich habe mir das durchgelesen. Es ist nicht so ähnlich, wie du das jetzt gerade darstellt, finde ich. Ja, ein anderes Ding. Aber was du als modern beschreibst, ist ganz, ganz massiv ein System, wie es einen Entwickler haben will. Für mich als Nutzer läuft mein Update morgens um fünf, wenn ich garantiert nicht am Rechner sitze. Ich will, dass mein System zur Laufzeit schnell ist. Ja, ich meine, das ist schön, dass du das in dein Leben so untergebracht hast, dass du das so machen kannst. Meine Realität ist es halt nicht. Und man sieht ja auch, wie das irgendwie bei Windows 10 so ist. Man muss ja nur mal auf Twitter schauen, wie die Videos ausgeführt werden, ihnen gerade irgendwie ihre Arbeit zu erschossen haben. Also ich finde, das ist generell so im Computing-Bereich noch kein gelöstes Problem, dass man Updates irgendwie quasi unobtrusive, also komplett im Hintergrund machen kann. Das Nächste, was ich finde, dass daran kommt, ist irgendwie Chrome OS, wo du halt einfach irgendwann so ein Pop-up bekommst und der sagt dann halt so, hey, da gibt es Updates, vielleicht wirst du neu starten, dann startest du neu, es dauert genauso lange wie sonst, aber du bist im neuen System. So, lass erstmal die anderen zu Wort kommen. Also es gibt ja insgesamt relativ wenig Gründe, warum dein System langsamer sein sollte als das halt bisherige System abgesehen von der Implementation, soweit ich das verstanden habe. Insbesondere dank der Komprimierung könnte es sowieso noch schneller sein, zumal ja Hard Disk langsamer ist als halt die CPU und das RAM, dass er dann das ganze zu runtime noch empacken kann und damit hast du ja ein Speed-Up, wenn du ein Programm startest. Ja, genau. Also im Moment... Das ist sogar das Gegenteil von dem, was hier alle kritisieren. Möglicherweise, ja, vielleicht müssen wir das vor der Tür fortsetzen. Dann können wir so zwei Fraktionen bilden. Ich bestehe auf einen Sitzkreis. Gibt es noch Wortmeldungen von Personen, die sich bis jetzt nicht zu Wort gemeldet haben, das wäre nämlich... Wir haben auch nur noch 4 Minuten. Wie baust du denn diese zentralen Verzeichnisse auf? Wenn du sagst, wir können beliebig viele Pakete parallel installieren, aber in dem Moment, wo du sagst, das kommt jetzt alles in mein Slash-User-Bin rein, dann fällst du ja genauso auf die Schnauze wie alle anderen auch. Genau. Ach so, genau. Ja, das hatte ich vielleicht nicht klar genug gesagt. Also der Punkt von dem BIN-Verzeichnis ist letztendlich nur für interaktive Nutzung also die ganzen Programme, die ich installiert habe, so zum Beispiel der EngineX, der schaut nie nach BIN, weil der weiß ja, der hat ja die konkreten vollständig spezifizierten Pfade. Aber ja, du hast natürlich recht, dass je mehr Zeug du so installierst, desto länger dauert es irgendwie die Pakete zu scannen, um zu finden, was soll nach BIN. Das Gute ist, dass es überhaupt gar nicht lange dauert im Moment, also irgendwie auch wieder ein Bruchteil von einer Sekunde, und da kann man auch noch optimieren, das ist noch nicht irgendwie am Ende angelangt. Und das installiert und das amortisiert sich sehr schnell. Also im Moment bin ich da nicht besorgt. Hier vorne noch mal. Wie machst du das? Simulinkst du das Zeug dann alles nach Slash-User-BIN oder wie schaut denn deine Bas-Variable in deiner lokalen Stelle aus? Lang. Ein Teil davon ist von mir, der Rest ist quasi der Bash-Path, ne, der Z ist Ha-Path, sorry. Aber im Wesentlichen langs auch, wenn Path einfach nur Slash-BIN enthält und so kann man das auch in der Bildumgebung machen. Ja, Slash-BIN, Slash-Git ist einfach ein Simulink, der ist auch einfach virtuell, also das Fuseday-System, erstellt den, also hält den vor quasi. Gut, dann würde ich vorschlagen, werden wir die weitere Diskussion, ein Gespräch auf Nachdenktalk verlegen. Ich sage nochmal einen großen Applaus und vielen herzlichen Dank, Michael. Danke.