Spannende Open-Source-Projekte auf der FOSDEM 2026
Hier kommt Teil zwei meines Erfahrungsberichtes von der FOSDEM, bei dem es um generell interessante Open-Source-Projekte geht, die ich dort entdeckt habe. Teil eins mit Fokus auf den Bildungsbereich findet ihr hier.
Amber
Amber ist eine Programmiersprache, nicht zu verwechseln mit der anderen, gleichnamigen Programmiersprache und dem Webframework für Crystal. (Die Favicons all dieser Seiten ähneln sich sehr, weil sie die gleiche Farbe haben, weil, naja, ihr wisst schon…)
Das Lustige an Amber ist, dass es eine moderne, ECMAScript-inspirierte Sprache ist, die *Trommelwirbel* zu Bash kompiliert. Die Idee scheint zu sein, den üblichen Bash-80er-Jank zu reduzieren, indem man in einer “normalen” Sprache schreibt, um funktionierende Bash-Scripte zu bekommen. Dazu zählt Type Safety, funktionierende Arrays und Runtime Safety, die einen kein Programm starten lässt, das potenziell unbehandelte Failures hat. Außerdem werden bei generierten Code perfekte Ergebnisse in Shellcheck (einem Linter für Bash-Skripte) angestrebt.
Ich habe ein bisschen mit Amber herumprobiert und das Prinzip ist schon ganz witzig - sich anzuschauen, wie ein Programm in “sauberes” Bash übersetzt wird, macht Spaß. Man merkt aber doch an vielen Ecken noch, dass die Sprache noch jung und nicht annähernd produktionsreif ist, einige Themenfelder sind noch nicht richtig behandelt und die Doku lässt auch noch zu Wünschen übrig.
Um schlussendlich auf den Elefanten im Raum einzugehen: warum braucht man sowas? Im Talk wurden ein paar bekannte Argumente für Bash benannt (funktioniert auf fast jedem System, ist meist schon vorinstalliert, benötigt keine Dependencies), aber schlussendlich finde ich, wenn man sowieso schon zu einer anderen Programmiersprach greift, kann man auch einfach eine nehmen, die nicht den Umweg über Bash mitsamt dessen Unzulänglichkeiten macht. Klar, vieles andere müsste man nachinstallieren, aber im ganzen Talk fiel kein Pro-Bash-Argument, das nicht auch auf ein Go-Programm zugetroffen hätte. Zum “Kickstarten” von Bash-Projekten, die dann ohne Amber weiter gepflegt werden können, eignet sich das Ganze auch nicht, weil sich zu viele Amber-spezifische Artefakte in den fertigen Skripten wiederfinden. Naja.
bin
An bin, einem “Binary Manager”, bin ich eher zufällig vorbei gekommen, als ich Amber installieren wollte, weil das einer der angebotenen Installationswege war. Grundsätzlich bin ich ja Fan von guten alten OS-nativen Softwarepaketen, die sich sauber ins Paketmanagement integrieren und damit auch geupdatet werden; aber inzwischen wird einfach wirklich viel Software nur als Binary verteilt. Bisher hatte ich da keine bessere Lösung, als sie nach ~/.local/bin zu dumpen und hin und wieder, wenn ich zufällig daran dachte, zu updaten. bin präsentiert sich als die Lösung dafür und verwaltet installierte Binärdateien, indem es per API der zu durchsuchenden Quellen (neben GitHub werden auch GitLab, Codeberg und ein paar weitere unterstützt) nach Updates sucht und sie herunterlädt. Das funktioniert, soweit ich das sehe, sehr gut, und ist eine echte Arbeitserleichterung. Cool!
eBPF-Tracing für kleinere Container-Images
Der Talk von Axel Stefanini hatte für mich eher den Charakter einer Tech-Demo, um eine bestimmte Idee rüberzubringen, als den einer einsatzfertigen Lösung; der Vortragende spricht im dazugehörigen GitHub-Repository selbst von einem “Experiment”. Spannend war es nichtsdestotrotz: in seinem Beispiel wurde eBPF eingesetzt, um in einem fertigen Container-Image die Syscalls abzufangen und zu prüfen, welche der vorhandenen Binaries tatsächlich aufgerufen wurden - implizit mit dem Ziel, die nicht genutzten entfernen zu können. Das ganze wird aufgerufen über OCI-Lifecycle-Hooks, die beim Start eines Containers ein entsprechendes Script ausführen. Die Idee dazu entstammt wohl diesem Projekt, welches einen ähnlichen Ansatz verwendet, um SecComp-Profile zu generieren.
Ob das Ganze sinnvoll ist, weiß ich noch nicht genau - dazu ist das Projekt zu weit weg von der Produktionsreife. Container-Images auf ihre minimale Größe zu schrumpfen, scheint mir eigentlich ein gelöstes Problem zu sein, indem man Container von Grund auf selbst baut. Aber so einen Hook auf ein fertiges Image anwenden zu können, das dann automagisch kleiner wird, ohne das im Buildprozess mitgedacht haben zu müssen, ist vielleicht gar nicht verkehrt.
CheckMK
