© Computec Media GmbH

Die FOSDEM feierte 2020 ihren zwanzigsten Geburtstag mit einem Feuerwerk an Vorträgen. Darin ging es um Kernel-Neuerungen, Open Source in der Lebensmittelindustrie, Live-Migrationen mit Webassembly und vieles andere mehr.

Die FOSDEM gilt als größte FOSS-Community-Veranstaltung in Europa. Zum Teil laufen hier mehr als 30 Tracks parallel – was Journalisten, die von dort berichten, regelmäßig in den Wahnsinn treibt. Dennoch gelang es dem Linux-Magazin, ein paar Eindrücke zu sammeln.

Den ersten lieferte c’t-Kernel-Log-Autor Thorsten Leemhuis. Er berichtete über die Geschichte des Linux-Kernels, ohne aus seinem über 200 Slides langen Eröffnungsvortrag eine Geschichtsstunde zu machen. Das gelang ihm, indem er aus den historischen Ereignissen einige typische Entwicklungsmuster der Kernel-Entwicklung herausfilterte.

Da wäre zum Beispiel der Umgang mit großen Projekten: Rund 15 Jahre habe es gedauert, Linux in einen Echtzeit-Kernel zu verwandeln. Am Ende sei es Thomas Gleixner und dessen Mitstreitern in vielen kleinen Schritten und dank sehr viel Beharrlichkeit gelungen, die Idee von einem echtzeitfähigen Kernel zu realisieren. Noch in diesem Jahr könnten die Kernel-Entwickler das Feature offiziell freigeben.

Auf dieser kleinschrittigen Reise passiert mitunter auch Unvorhergesehenes: Manchmal programmieren Entwickler Features in den Kernel, die dann in der freien Wildbahn erstaunliche Karrieren hinlegen. Basierend auf Namespaces und Cgroups machte beispielsweise die Firma dotCloud Anfang des vorigen Jahrzehnts Furore. Sie führte mit Docker eine Container-Technologie ein, die heute in vielen Rechenzentren zu Hause ist, unter anderem als Engine in Kubernetes. Dockers Idee und den Erfolg ihrer Umsetzung hatten nur wenige auf dem Plan. Die Docker-Entwickler bastelten aus der neuen Kernel-Technologie ein Open-Source-Produkt, das offenbar einen Nerv traf.

Sicher mittendrin

Auch ein anderes Projekt, nämlich den eBPF (Extended Berkeley Packet Filter) sollten Beobachter in dieser Hinsicht auf dem Schirm haben, empfahl Kernel-Beobachter Leemhuis. Dabei handelt es sich um eine im Linux-Kern angesiedelte VM-Variante, die System-Events parst und es erlaubt, sicher Code im Kernelspace auszuführen. Die Interaktionen mit dem Userspace laufen über sogenannte Maps (Key-Value-Stores), die Programme dürfen nicht Turing-komplett sein, und der Userspace darf nur lesend auf die vom eBPF generierten Werte zugreifen.

Tatsächlich gibt es bereits erste Nutzer dieser Technologie. Kris Nóva stellte in ihrem Vortrag “Fixing the Kubernetes clusterfuck” wenig später Falco vor, eine Runtime-Security-Engine für Kubernetes. Sie erkennt und blockiert zur Laufzeit eines Clusters unter anderem ungewöhnliche und ungewollte Systemaufrufe. Dazu durchforstet die Software mithilfe von eBPF unter anderem die Syscalls. Auch Containerkontexte sowie Meta- und Audit-Daten von Kubernetes klappert Falco auf bekannte Angriffsmuster ab. Das macht es zu einer Art Wireshark für den Kernel. Ergänzend ziehen Kubernetes-Admins noch andere Hilfsmittel heran, wie etwa den Open Policy Agent OPA, den Kubernetes unter dem Namen Gatekeeper implementiert.

Container isolieren

Mit Containersicherheit setzte sich auch der Talk von Mike Rapoport und James Bottomley auseinander, die beide für IBM arbeiten (siehe Titelbild). Sie suchen nach einem Weg, um Container sicher genug für den direkten Einsatz zu machen.

Ein zentrales Argument gegen den direkten Einsatz von Containern ist noch immer die fehlende Isolation im Speicher. Auch wenn die Angst oft übertrieben scheint, packen Nutzer und Unternehmen die Container mit Vorliebe zusätzlich in VMs, um sie voneinander zu isolieren. Bottomley und Rapoport suchen nun nach einer Möglichkeit, über den Kernel auch Adressräume voneinander zu isolieren. In ihrem Talk zeigten sie die verschiedenen Ansätze, die sie bereits probiert haben, um dann gleich auch die Probleme aufzulisten, die sich aus den jeweiligen Ansätzen ergeben.

Es scheint ein mühsamer Weg zu sein, auf dem Bottomley und Rapoport wohl nur in kleinen Schritten vorwärtskommen. Damit schließt sich dann auch der Kreis zum anfänglichen Vortrag: Bis zur Einsatzreife des Codes dürften noch ein paar Jahre ins Land ziehen, schätzen die Entwickler. Aber das ist in der Kernel-Entwicklung ja keine Seltenheit.

Offene Landwirtschaft

Doch auch FOSS-Entwickler leben nicht von Software allein. Unter anderem müssen sie schlafen und Nahrung zu sich nehmen, was auf der FOSDEM beides oft nur unzureichend gelingt. Immerhin widmeten sich einige der Vorträge dem Essen, konkret dessen Anbau und Qualität.

Sogenannte Lebensmittel-Ampeln sollen Käufern in Supermärkten durch Farbcodes schnell signalisieren, wie viel Zucker, Salz oder gesättigte Fette in bestimmten Nahrungsmitteln stecken. Denn nur wenige Verbraucher machen sich die Mühe, die Tabellen mit dem Nährwertgehalt auf den Produkten zu studieren. Selbst wenn sie es tun, bleibt oft die Frage offen, ob die angegebene Menge an Zucker oder gesättigten Fettsäuren nun der Norm entspricht oder besonders hoch ausfällt. Verschiedene Versuche, eine solche Lebensmittelampel [1] in Deutschland einzuführen, scheiterten bereits an Politik und Lebensmittelindustrie. Dabei betonen Ärzte den negativen Einfluss schlechter Ernährung auf die Gesundheit der Bevölkerung.

Seit Kurzem können europäische Hersteller immerhin freiwillig einen Nutriscore [2] auf ihren Produkten anbringen. Die fünfstufige Farb- und Buchstabenskala zeigt an, wie gesund ein Lebensmittel ist. Allerdings sehen viele Hersteller wenig Anreiz, diese Ampel zu verwenden: Meist wissen sie sehr genau, wie ungesund ihr Produkt eigentlich ist.

Offene Ampel

Hier kommen die Entwickler von Open Food Facts ins Spiel (Abbildung 1). Nach dem Motto “wenn die Industrie es nicht macht, tun wir es halt selbst” bieten sie Apps an, mit denen Käufer europaweit den Nutriscore von Produkten ermitteln können, selbst wenn er nicht auf der Verpackung steht. Die Daten sollen, wie bei Wikipedia und OpenStreetMap, von den Verbrauchern selbst kommen. Das Non-Profit will dabei neben Fett, Zucker oder Salz auch Zusätze in Produkten anzeigen. Zugleich unterstützt es Informationen der Nova-Ampel [3], die signalisiert, wie stark industriell verarbeitet ein Produkt ist.

Abbildung 1: Open Food Facts will mithilfe der Community eine Datenbank aufbauen, die über die Zusammensetzung von Lebensmitteln informiert.

In der Datenbank des in Frankreich gestarteten Open-Food-Facts-Projekts stecken bereits 1,1 Millionen Produkte, die Daten selbst stehen unter der Open Database License. Bislang 25 000 registrierte Benutzer in 182 Ländern haben dazu mithilfe der Projekt-Apps Produkte gescannt – aus Nordkorea würden aber noch Produktinformationen fehlen, witzelte einer der Entwickler. Es gibt Apps für Android, iOS und Windows 8 Mobile; beim Kategorisieren der Produkte hilft eine KI. Neben Open Food Facts entwickelt das Projekt bereits eine weitere App: Open Beauty Facts soll die kryptischen Inhaltsstoffe in Schönheitsprodukten entschlüsseln.

Essen auf Rädern

Gute Bewertungen in der Open-Food-Facts-Datenbank würden vermutlich die Produkte vieler Solawis erhalten. Die Idee hinter der solidarischen Landwirtschaft (englisch Community Supported Agriculture, CSA): Eine Community an Käufern legt zusammen und unterstützt Bauern mit festen monatlichen Beträgen. Das schützt die Landwirte vor finanziellen Schäden bei schlechten Ernten. Im Gegenzug erhalten die Mitglieder die angebauten Produkte, häufig Bio-Lebensmittel.

An solche Solawis, von denen es europaweit geschätzt 3000 gibt, richtet sich Open Olitor [4]. Der Name des Projekts entstammt dem lateinischen Wort für Gemüsegärtner. Das Tool steht unter der AGPLv3 und soll den Anbaugemeinschaften bei den organisatorischen Aufgaben helfen. Zum Einsatz kommen ein Scala-Server mit Maria-DB- und AWS-S3-Anbindung, als Frontend dient Angular.js.

Die 15 Entwickler rund um das Projekt streben eine Refinanzierung nach dem Solawi-Modell an. Sie haben verschiedene Organisationen und Stiftungen gegründet, um die Software-Entwicklung und den Ressourceneinsatz zu refinanzieren. Auch dieses Projekt steht Helfern offen, etwa zum Übersetzen von Texten.

Schräge Pflanzen

Auch der Vertical-Farming-Bereich war auf der FOSDEM vertreten. Dabei geht es darum, Gemüse und Kräuter in einer geschlossenen Umgebung effektiv anzubauen. Eine Pariser Firma namens Agricool [5] züchtet zum Beispiel Erdbeeren in Containern unter künstlichem Licht in einer Nährlösung, beobachtet von Kameras und Sensoren. Der Clou beim Vertical Farming: Die Anbauer sperren einerseits Schädlinge aus und kontrollieren andererseits die Anbaubedingungen wie Bewässerung, Benetzung, Dünger und so weiter. Das steigert die Effizienz, sodass Agricool nach eigenen Angaben jährlich 15 bis 20 Kilogramm Erdbeeren pro Quadratmeter erntet.

Die von Agricool verwendete Technologie liegt allerdings nicht offen, was das Unternehmen aber künftig ändern will. Zumindest einen Blick auf die verwendeten Werkzeuge erlaubten die Erdbeerbauern: Sie greifen unter Debian auf einen Controller zu, der Aktoren und Sensoren steuert. Dazu gehört zum Beispiel ein Drucksensor in den Wasserleitungen, der Lecks entdeckt. Die verwendeten Dienste setzen sie in einer Microservice-Architektur ein, das Monitoring erfolgt über Prometheus. Ansonsten kommen AWS, Grafana, Slack, InfluxDB und Redash zum Einsatz. Vieles sei aktuell noch handgemacht, betont Agricool. Man denkt daher darüber nach, künftig stärker auf KI-Prozesse zu setzen.

Ein anderes Projekt macht dies bereits: Der französische Forscher Alexis Duque betreibt Indoor-Farming mithilfe von OpenCV und Tensorflow Lite auf einem Raspberry Pi (siehe Artikel in dieser Ausgabe). Seine Arbeit mit dem vertikalen Gemüse dient allerdings vornehmlich der wissenschaftlichen Erkundung von Möglichkeiten, in diesem Bereich KI einzusetzen. OpenCV überwacht die Größe des Gemüses; die Daten landen dann in der Cloud, um sie mit Tensorflow Lite auszuwerten. Das Setup soll einen hochautomatisierten vertikalen Anbau ermöglichen, wobei sich aus den Daten Erkenntnisse über weitere Optimierungen ziehen lassen. In seinem Vortrag zeigte Duque auch eine kurze Demo mit Tensorflow Lite [6].

Am Gate

Der finnische Entwickler Timo Savola hat auf der FOSDEM sein Gate-Projekt [7] vorgestellt. Es erlaubt mittels Webassembly Live-Migrationen von Anwendungen zwischen verschiedenen Plattformen und unterstützt aktuell Linux, ARM64 und Android. Gate soll portable Anwendungen ausführen und es auch ermöglichen, Code aus unsicheren Quellen sicher auszuführen. Savola arbeitet seit fünf Jahren an dem Programm und ging damit auf der FOSDEM erstmals an die Öffentlichkeit (Abbildung 2). Er sucht nun Mitstreiter, um das Projekt weiter auszubauen. Gate arbeitet Programmiersprachen-agnostisch und setzt mit Wag auf einen Webassembly-Compiler.

Abbildung 2: Mit modernsten Programmiertechniken will der Finne Timo Savola Apps portabel und sicher machen.

Das Projekt schien bei der Vorführung schon in einem recht guten Zustand zu sein. Zur Demonstration seiner Software spielte der Entwickler eine Linux-Version von Doom und erzeugte an einer Stelle im Spiel einen Snapshot. Die dabei entstandene Datei transferierte er auf eine ARM-Plattform, führte sie dort aus und setzte das Spiel fort. Für sein Projekt verwendet Savola Go und einen Webassembly-Compiler, die Runtime für Webassembly ist in C und Assembler geschrieben.

Zum sicheren Ausführen potenziell unsicheren Codes definiert Gate via Webassembly logische Sandboxes: Jedes Programm läuft in einem eigenen OS-Prozess. Die Interprozesskommunikation erfolgt über Pipes, Seccomp schützt die Syscalls von Linux. Zusätzlich nutzt Savolas Lösung sämtliche Namespaces, um das System zu schützen. Mehr Informationen zu Gate liefert ein Blogpost von Savola [7], der Code wartet auf Github [8].