QSOE 0.1 startet: Neues RISC-V-System bringt QNX-Ideen zurück

QSOE 0.1 ist als neues Open-Source-Betriebssystem für RISC-V gestartet. Das Projekt erinnert bewusst an QNX, setzt aber auf eine eigene freie Codebasis und eine ungewöhnliche Zwei-Kernel-Architektur. Damit wird QSOE für Entwickler interessant, die sich mit Microkerneln, Embedded-Systemen und alternativen Betriebssystemen beschäftigen. Für Linux ist der Start spannend, obwohl QSOE selbst kein Linux-System ist. Das Projekt liegt genau an der Schnittstelle aus freier Systemsoftware, RISC-V-Hardware und klassischer Betriebssystemforschung.

QSOE 0.1 bringt zwei Varianten mit. QSOE/N nutzt den eigens entwickelten Microkernel Skimmer. QSOE/L läuft auf dem formal verifizierten Microkernel seL4. Beide Varianten teilen sich denselben Userspace, dieselbe Shell und große Teile der C-Bibliothek. Der Kernel wird dadurch austauschbarer als bei klassischen monolithischen Systemen. Der Ansatz passt zu einer breiteren RISC-V-Entwicklung. Aktuelle Linux-Distributionen wie Fedora 44 zeigen, wie wichtig moderne Open-Source-Plattformen für Entwickler geworden sind. QSOE geht tiefer in die Systemschicht und fragt, wie ein QNX-ähnliches Betriebssystem auf offener RISC-V-Hardware aussehen kann.

Was QSOE 0.1 von Linux unterscheidet

QSOE ist kein weiterer Linux-Kernel und auch keine klassische Distribution. Das System folgt der Idee eines kleinen Microkernels. Treiber, Dienste, Dateisysteme und weitere Komponenten sollen möglichst im Userspace laufen. Die Kommunikation erfolgt über synchrone Nachrichten, ähnlich wie bei QNX Neutrino.

Dieser Unterschied ist wichtig. Linux bündelt sehr viele Funktionen im Kernel. QNX-ähnliche Systeme setzen dagegen stärker auf getrennte Dienste und klar definierte Nachrichtenwege. Das kann in Embedded- und Echtzeitumgebungen Vorteile bringen, weil Fehler besser isoliert werden können und einzelne Dienste kontrollierter arbeiten.

QSOE 0.1 ist aber noch kein produktives Echtzeitbetriebssystem für Autos, Medizingeräte oder Industrieanlagen. Dafür fehlen Zertifizierungen, breite Hardwareunterstützung und lange Stabilitätsnachweise. Der Vergleich mit QNX beschreibt vor allem die Architekturidee, nicht denselben Reifegrad.

Technisch besteht die erste öffentliche Version aus mehreren Bausteinen. QSOE/N bringt den Skimmer-Kernel, QSOE/L nutzt seL4, mr-bml dient als Bootloader, quser liefert die Nutzerumgebung mit einer mksh-basierten Shell, und libc stellt die C-Bibliothek bereit.

BausteinRolle in QSOE 0.1Einordnung
QSOE/NVariante mit eigenem MicrokernelZeigt den eigenen OS-Ansatz
QSOE/LVariante mit seL4-KernelBringt seL4 in die QSOE-Umgebung
SkimmerVon Grund auf entwickelter QSOE-KernelQNX-ähnlich und SMP-orientiert
seL4Formal verifizierter MicrokernelSicherheits- und Forschungsbezug
mr-bmlBootloader für mehrere KerneltypenWichtig für RISC-V-Bootpfade
quserUserspace mit qsh-ShellPraktischer Einstieg ins System
libcC-Bibliothek für beide VariantenTeilt große Teile des Codes
ZielhardwareSiFive HiFive Unmatched und QEMUNoch klar auf Entwicklerhardware begrenzt

Der gemeinsame Userspace ist der eigentliche Kern der Veröffentlichung. Anwendungen und Dienste sollen oberhalb der Kernel-Grenze möglichst gleich bleiben, egal ob Skimmer oder seL4 darunter läuft. Nur die stark kernelnahe Schicht unterscheidet sich. Das macht QSOE zu einem Experiment über Portabilität und Kernel-Abstraktion.

Die Version 0.1 erreicht nach Projektangaben auf der RISC-V-Plattform SiFive HiFive Unmatched eine interaktive Shell. Beide Varianten können auf echter Hardware starten. Für die tägliche Entwicklung bleibt QEMU wichtig, weil Experimente dort schneller und ohne spezielle RISC-V-Hardware möglich sind.

Warum RISC-V und QNX-Ideen zusammenpassen

RISC-V ist für solche Projekte attraktiv, weil die Architektur offen dokumentiert ist und in Forschung, Embedded-Systemen und Spezialhardware wächst. QSOE nutzt genau diese Offenheit, um ein Betriebssystem auf niedriger Ebene sichtbar und kontrollierbar zu halten.

Der Entwickler nennt QSOE als eigenständigen Plan nach dem Versuch, historische QNX-Neutrino-Quellen freizubekommen. Daraus entstand kein QNX-Fork, sondern ein neues Projekt mit ähnlicher Philosophie. Das ist wichtig für die Lizenzlage: QSOE wird als freies Projekt unter Apache 2.0 beschrieben.

Für Embedded-Entwickler ist vor allem die Kombination aus Microkernel, Message Passing und RISC-V interessant. Solche Systeme passen zu Steuerungen, spezialisierten Geräten, Forschungsboards und experimentellen Hardwareplattformen. Linux in der Avionik mit AvioNix zeigt, wie stark sichere und nachvollziehbare Betriebssystemgrundlagen in kritischen Bereichen diskutiert werden.

Auch die Hardwareseite wird wichtiger. Treiberarbeit rund um SteamOS und GeForce macht sichtbar, wie stark Betriebssysteme vom Zusammenspiel mit konkreter Hardware abhängen. Bei QSOE ist diese Abhängigkeit noch grundlegender, weil Bootloader, Kernel, Treiber und Userspace in einer sehr frühen Phase zusammenfinden müssen.

Der Blick auf aktuelle Linux-Arbeit zeigt dieselbe Richtung. Neue Kernel-Arbeit an Scheduling und sichererem Code zeigt, wie viel Aufwand moderne Betriebssysteme in Vorhersagbarkeit, Sicherheit und Nebenläufigkeit stecken. QSOE greift solche Fragen aus einer anderen Architekturtradition auf.

Für normale Nutzer ist QSOE 0.1 noch nicht relevant. Es gibt keinen Desktop, keine breite App-Landschaft und keine einfache Installationsroutine für Alltagsrechner. Wer das System testet, braucht Interesse an RISC-V, QEMU, Bootloadern, Microkerneln und Low-Level-Software.

Für Entwickler ist QSOE 0.1 dagegen ein bemerkenswerter Startpunkt. Das Projekt bringt nicht nur ein Kernel-Experiment, sondern ein komplettes kleines System mit Bootloader, Shell, Userspace und gemeinsamer Umgebung für zwei Kernelvarianten. Gerade diese Verbindung macht den Unterschied zu vielen Hobbykerneln.

Der nächste Maßstab wird nicht sein, ob QSOE Linux ersetzt. Das wird es absehbar nicht. Entscheidend wird, ob das Projekt Treiber, Dokumentation, weitere RISC-V-Boards, QNX-kompatiblere APIs und stabile Testpfade nachlegt. Dann könnte QSOE zu einem interessanten freien Labor für Microkernel-Systeme auf RISC-V werden.