🥇Die Zukunft ist bereits hier oder wir coden direkt im Browser

Ich werde von einer kuriosen Situation erzählen, die mir passiert ist, und wie man ein Mitwirkender in einem bekannten Projekt wird.

Vor nicht allzu langer Zeit habe ich mich mit einer Idee beschäftigt: Linux direkt über UEFI zu laden...
Die Idee ist nicht neu und es gibt einige Anleitungen zu diesem Thema. Eine davon kann man sich ansehen. hier

Meine langjährigen Versuche, dieses Problem zu lösen, haben sich zu einer durchaus strukturierten Lösung. Die Lösung funktioniert gut und ich nutze sie auf einem Teil meiner Heimcomputer. Etwas detaillierter ist diese Lösung beschrieben. hier.

Der Wesenszug des UEFI-Boots ist, dass die ESP (EFI System Partition) mit dem Verzeichnis /boot kombiniert wird. Das heißt, alle Kerne und die Initial-Boot-Images (initrd) befinden sich auf derselben Partition, von der UEFI ausführbare Dateien starten kann, insbesondere Systemloader. Aber der Linux-Kernel selbst wird bereits in vielen Distributionen mit der Option UEFISTUB kompiliert, die es dem Kernel erlaubt, direkt aus UEFI zu starten.

Bei dieser Lösung gibt es jedoch einen unangenehmen Punkt — der ESP ist im FAT32-Format und es ist nicht möglich, harte Links zu erstellen (die das System beim Aktualisieren von initrd regelmäßig erstellt). Und es ist nichts besonders Kriminelles daran, aber die Warnmeldungen des Systems bei der Aktualisierung von Kernelkomponenten sind nicht besonders erfreulich...

Es gibt auch einen anderen Weg.

Der UEFI-Boot-Manager (der genau der ist, wo man den Betriebssystemloader eintragen muss) kann neben den Linux-Loadern/Kernen auch Treiber laden. So kann man den Treiber für das Dateisystem laden, auf dem sich /boot befindet, und von dort das Kernel über UEFI starten. Der Treiber muss natürlich in die ESP-Partition gelegt werden. Genau das übernehmen Loader wie GRUB. Aber das Besondere ist, dass viele der häufig verwendeten Funktionen von GRUB bereits in UEFI vorhanden sind. Genauer gesagt, im Boot-Manager. Und um noch pedantischer zu sein, hat der UEFI-Boot-Manager in einigen Aspekten sogar mehr Möglichkeiten.

Es scheint eine schöne Lösung zu sein, aber es gibt ein "ABER" (bzw. gab es, aber dazu später mehr). Das Problem ist, dass das UEFI-Treibersystem ziemlich einfach strukturiert ist. Es gibt kein Konzept wie das Einbinden eines Dateisystems oder das Verknüpfen eines Treibers mit einem bestimmten Gerät. Es gibt einen Systemaufruf mit dem bedingten Namen Map (engl.) der nacheinander jeden Treiber aufnimmt und versucht, ihn mit allen mehr oder weniger passenden Geräten zu verbinden. Und wenn der Treiber erfolgreich ein Gerät verbinden konnte, wird ein Mapping — ein Verweis erstellt. Genau so sollte der neu geladene Treiber in der allgemeinen Anordnung mit all den anderen initialisiert werden. Und alles, was nötig ist — im Boot-Eintrag des Treibers ein Bit (LOAD_OPTION_FORCE_RECONNECT) auf 1 setzen, und UEFI wird nach seinem Ladevorgang dieses globale Remapping vornehmen.

Nur ist es nicht so einfach, dies zu tun. Das Standardwerkzeug efibootmgr (mit dem der UEFI-Entlade-Manager konfiguriert wird) kann (bzw. konnte nicht) dieses Bit setzen. Man musste es manuell über ein ziemlich kompliziertes und riskantes Verfahren setzen.

Und so habe ich es beim nächsten Versuch wieder manuell gemacht, bis ich nicht mehr widerstehen konnte und ein Issue auf GitHub erstellt habe, in dem ich die Entwickler bat, diese Möglichkeit hinzuzufügen.

Ein paar Tage sind vergangen, aber niemand hat auf meine Anfrage geachtet. Aus Neugier habe ich mir dann den Quellcode angesehen… geforkt und mir überlegt, wie ich dieses Feature "auf die Schnelle" hinzufügen kann… "Auf die Schnelle", weil ich nichts weiter installiert habe und den Quellcode direkt im Browser bearbeitet habe.

C (die Programmiersprache) kenne ich nur sehr oberflächlich, aber ich habe ungefähr eine Lösung skizziert (vor allem durch Kopieren und Einfügen)… dann dachte ich mir — obwohl ich bestimmt eine Menge Fehler hatte (meine früheren Versuche, den Code anderer zu bearbeiten, benötigten bis zum zehnten Mal), werde ich einen Pull Request erstellen. Und das habe ich getan..

Da stellte ich fest, dass Travis CI zur Überprüfung von Pull Requests integriert war. Und es hat mir sorgfältig alle meine Fehler angezeigt. Wenn die Fehler bekannt sind — warum nicht einfach beheben: wieder direkt im Browser, und beim vierten Versuch war der Code kompiliert (ein Erfolg für mich).

Und so habe ich, ohne den Browser zu verlassen, einen ziemlich realen Pull Request für das Tool erstellt, das praktisch in allen modernen Linux-Distributionen verwendet wird.

Ich war selbst überrascht, dass ich, ohne die Sprache wirklich zu kennen und ohne irgendwelche Einstellungen vorzunehmen (es gibt eine erhebliche Anzahl von Bibliotheken, die für den Build benötigt werden), und noch nie den Compiler gestartet zu haben, einfach im Browser eine ziemlich funktionale und nützliche Funktion "programmiert" habe.

Mein Antrag blieb jedoch seit dem 19. März 2019 ohne Reaktion, und ich begann bereits, ihn zu vergessen.

Aber gestern wurde dieser Antrag in den Master integriert.

Worüber erzähle ich also? Es geht darum, dass es innerhalb der modernen Technologien nun möglich ist, echten Code im Browser zu schreiben, ohne lokal irgendwelche Entwicklungswerkzeuge und Abhängigkeiten einzurichten.

Übrigens muss ich zugeben, dass dies bereits mein zweiter Pull-Request an eine bekannte (zumindest in engen Kreisen) Utility ist. Beim letzten Mal führte meine Bitte, die Anzeige einiger Felder im Web-Interface von SyncThing zu verbessern, zu einer buchstäblich einzeiligen Korrektur in einer Umgebung, die ich überhaupt nicht kenne.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte einloggen.