Asterinas – ein neues Linux-kompatibles Kernelprojekt

 (lwn.net)
8 Punkte von GN⁺ 2025-06-23 | 2 Kommentare | Auf WhatsApp teilen
  • Ein in Rust geschriebener Linux-ABI-kompatibler Kernel, der mit einer „Framekernel“-Architektur die Vorteile von monolithischen Kerneln und Mikrokerneln kombinieren will
  • Entworfen, um Speichersicherheit und eine einfache Shared-Memory-Struktur zugleich zu erreichen, indem sämtlicher unsafe-Code in begrenzten Bibliotheken gekapselt wird und die übrigen Kernel-Services mit sicheren Rust-Abstraktionen entwickelt werden können
  • Abgrenzung zu bestehenden Rust-OS wie RedLeaf, Tock und Rust for Linux durch Unterstützung für Hardware-Isolation, allgemeinen Einsatzzweck, Linux-kompatible ABI und die Ausführung von User-Space in verschiedenen Sprachen
  • Fokus auf Minimierung der TCB (Trusted Computing Base) und formale Verifikation (mit Verus), Unterstützung für Hardware vertrauenswürdiger Ausführungsumgebungen wie Intel TDX sowie separate Bereitstellung von OS-Entwicklungs-Frameworks wie OSTD/OSDK
  • Noch in einer frühen Entwicklungsphase: Unterstützung für x86/RISC-V und 206 implementierte Systemaufrufe; Fokus auf Docker-/Container-/Cloud-Umgebungen, zugleich aber auch Versuche mit Desktop-Erweiterungen wie X11/Xfce

Was ist Asterinas?

  • Asterinas ist ein neues, in Rust entwickeltes Linux-ABI-kompatibles Kernelprojekt
  • Die „Framekernel“-Architektur bedeutet, dass Code, der unsafe Rust benötigt (also speicherunsichere Bereiche), auf Framework-Bibliotheken beschränkt und durch sichere APIs gekapselt wird, während alle übrigen Kernel-Services in sicherem Rust entwickelt werden
  • Ziel ist es, die einfache, leistungsstarke Struktur monolithischer Kernel und die minimierte TCB (Trusted Computing Base) bzw. Sicherheit von Mikrokerneln zugleich zu verfolgen
  • Innerhalb des Kernels laufen Services getrennt im selben Adressraum, wobei jeder Service nur die Ressourcen nutzen kann, die ihm von der Core-Bibliothek zugewiesen wurden

Erklärung der Framekernel-Architektur

  • Das Framekernel-Konzept wurde erstmals in dem Paper „Framekernel: A Safe and Efficient Kernel Architecture via Rust-based Intra-kernel Privilege Separation“ vorgeschlagen
  • Ein monolithischer Kernel ist eine Struktur, bei der sämtlicher Code in einem einzigen Kernel-Mode-Adressraum enthalten ist, während ein Mikrokernel nur einer minimalen TCB Kernel-Speicher zuweist und die meisten Funktionen an User-Mode-Services delegiert
  • Ein Framekernel kapselt Code, der Rust-unsafe benötigt, in Bibliotheken, während die übrigen Kernel-Services mit speichersicheren Rust-Abstraktionen entwickelt werden
  • Jeder Service läuft zwar im Kernel-Adressraum, ist aber auf den Zugriff auf jene Ressourcen beschränkt, die die Bibliothek explizit bereitstellt
  • Wenn die TCB klein gehalten wird, wird formale Verifikation (mathematischer Beweis) deutlich praktikabler, was die Vertrauenswürdigkeit und Stabilität des Gesamtsystems erhöhen kann
  • Es handelt sich um einen Ansatz, der Shared Memory als Basis (hohe Leistung wie bei monolithischen Kerneln) mit interner Privilegientrennung/Sicherheit (Vorteil von Mikrokerneln) kombiniert

Vergleich mit bestehenden Rust-OS und Framekernel-Ansätzen

  • RedLeaf: Rust-basierter Mikrokernel, nutzt keine Hardware-Isolation
  • Asterinas: allgemeines OS, nutzt Hardware-Isolation, Linux-ABI-kompatibel, unterstützt die Ausführung von User-Space in verschiedenen Sprachen
  • Tock: zielt auf Embedded-SoCs, trennt Kernel (unsafe erlaubt) und Capsules (sicherer Code), unterstützt keine Hardware-Isolation
  • Auch das Projekt Rust for Linux verfolgt das Ziel, Kernel-Schnittstellen durch sichere Abstraktionen zu kapseln, damit sich Kernel-Treiber in Rust sicher schreiben lassen

Formale Verifikation und Sicherheit

  • Das Hauptziel der Reduzierung der TCB ist, formale Verifikation praktisch realisierbar zu machen
  • Asterinas ist ein einzigartiger Fall, der wie seL4 zugleich auf eine kleine, verifizierbare TCB, Linux-ABI-Kompatibilität und eine Shared-Memory-Struktur abzielt
  • In Zusammenarbeit mit dem auf Security Audits spezialisierten Unternehmen CertiK wird an formaler Verifikation auf Basis von Verus gearbeitet
    • Im Security-Assessment-Bericht von CertiK werden Prüfbereiche und gefundene Probleme des Projekts offengelegt

Bibliotheken und Entwicklungswerkzeuge

  • Neben dem Kernel selbst werden OSTD (Rust-OS-Framework) und OSDK (Cargo-basiertes Entwicklungswerkzeug) bereitgestellt
  • Hauptziele von OSTD:
    • die Einstiegshürde für OS-Entwicklung senken und eine Grundlage für Innovation schaffen
    • die Speichersicherheit von Rust-Betriebssystemen stärken und Low-Level-APIs abstrahieren
    • die Wiederverwendung von Code zwischen Rust-OS-Projekten fördern
    • neue Codes im User-Mode testen können (höhere Entwicklungsproduktivität)
  • OSD- und OSTD-basierte Kernel müssen nicht Linux-kompatibel sein und bieten High-Level-Speichersicherheits-APIs für x86-Hardwaresteuerung, virtuellen Speicher, Multiprocessing (SMP), Timer usw.
  • Intel ist als Sponsor beteiligt; besonders passend sind dabei Trust Domain Extensions (TDX) und Technologien rund um VM-Isolation

Entwicklungsstand und wichtigste Sponsoren

  • Anfang 2024 erstmals als Open Source (MPL-Lizenz) veröffentlicht; derzeit 45 Mitwirkende, wichtige Beitragsleistende stammen von der chinesischen SUSTech, der Peking-Universität, der Fudan-Universität sowie von Ant Group
  • Unterstützung für x86 und RISC-V, 206 Linux-Systemaufrufe implementiert (von insgesamt 368)
  • Anwendungen können noch nicht ausgeführt werden; Ziel sind eine frühe Distribution in Entwicklung und Unterstützung für Container (Docker), daneben Versuche mit Nix-basierten Distributionen
  • Das Laden von Linux-Kernelmodulen wird nicht unterstützt und ist auch dauerhaft nicht geplant

Weitere Pläne

  • Kurzfristige Prioritäten sind mehr CPU-Architekturen, breitere Hardware-Unterstützung und praktische Einsetzbarkeit in Cloud-Umgebungen
  • Unterstützung für Linux-virtio-Geräte ist abgeschlossen; als wichtiges Ziel gilt der chinesische Cloud-Markt (Alibaba Cloud, Aliyun)
  • Das Kernziel ist die Entwicklung eines Host-OS für Container mit sicherer, verkleinerter TCB und Unterstützung für Intel-Funktionen im Bereich Trusted Computing
  • Auch wenn das Ziel ähnlich ist wie bei Rust for Linux, beschränkt sich Rust for Linux auf Rust-basierte Treiber im bestehenden Kernel, während Asterinas auf einen vollständigen Kernel-Neuentwurf und eine minimale TCB abzielt
  • Derzeit wird auch mit verschiedenen Richtungen experimentiert, etwa mit Unterstützung für X11 und Xfce; auch OSTD selbst könnte bei allgemeinen OS-Entwicklern Aufmerksamkeit finden

Unterschiede zu Rust for Linux

  • Rust for Linux: führt nur sichere, in Rust geschriebene Treiber in den bestehenden Linux-Kernel ein; der gesamte Kernel bleibt C-basiert
  • Asterinas: implementiert einen neuen Kernel von Grund auf in Rust, begrenzt unsafe strikt, verfolgt formale Verifikation und konzentriert sich auf Cloud-/Container-Umgebungen

Gesamtbild und Ausblick

  • Asterinas versucht einen innovativen Ansatz in den Bereichen Speichersicherheit, formale Verifikation und Praxistauglichkeit für Cloud-Umgebungen
  • Es gibt noch keine Praxisbeispiele im breiten Einsatz und keine breite Validierung durch die Community, aber das Projekt stößt in den Bereichen OS-Forschung, Cloud und Security auf Interesse
  • Frameworks wie OSTD könnten künftig im Rust-OS-Ökosystem nutzbar werden

Zusammenfassung zentraler Punkte aus den LWN-Kommentaren zu Asterinas

  • Debatte über Singularity OS und sprachbasierte Sicherheitsgrenzen
    • Der Framekernel von Asterinas ähnelt Microsofts Singularity OS, erhöht aber mit dem Rust-Borrow-Checker die Speichersicherheit
    • Beim Ansatz, Systeme durch Sicherheitsgrenzen der Sprache selbst (z. B. Rust, Java, WASM/JS) zu schützen, stehen sich Kritik wie „vollständiges Vertrauen ist unmöglich, in der Praxis wird es zusammen mit Sandboxing auf Hardware-/OS-Ebene verwendet“ und die Ansicht „es bietet Vorteile bei Fehlervermeidung und formaler Verifikation“ gegenüber
    • Auch bei WASM, JS und Java gibt es Sicherheitsdebatten; in realen Diensten gelten Sprach-Sandboxes allein in der Regel nicht als ausreichend vertrauenswürdig, sodass Hardware- oder OS-Sandboxes meist zusätzlich eingesetzt werden
  • Trends in der Betriebssystementwicklung und geopolitischer Hintergrund
    • In den vergangenen Jahren sind verschiedene neue OS-Projekte entstanden, und die Stimmung für OS-Innovationen nimmt zu
    • China treibt als Reaktion auf US-Technologiesanktionen und Risiken in der Lieferkette die Entwicklung alternativer Betriebssysteme zu Linux voran
    • Es gibt heftige politische Debatten über US-Sanktionen, GPL und die globale Governance von Open Source sowie darüber, dass China, Europa und andere Regionen unabhängige Technologie-Ökosysteme anstreben sollten
    • Auch die Schwierigkeit, Linux-Forks zu pflegen oder einen völlig neuen Kernel zu entwickeln, die Abhängigkeit von Community-Wissen/-Know-how und Sprachbarrieren sind Streitpunkte
  • Debatte über Linux-Kompatibilität und die Zahl der Systemaufrufe
    • Viele meinen, dass die Anzahl der Linux-Systemaufrufe kein geeigneter Maßstab für Kompatibilität ist
    • Ein einzelner Systemaufruf wie ioctl umfasst zahlreiche Detail-APIs; für echte Kompatibilität sei deshalb die Ausführung realer Anwendungen mithilfe von Kernel-Testsuiten wichtiger
    • Mit Verweis auf die Linux-Geschichte, in der anfangs zur POSIX-Kompatibilität Systemaufrufe einzeln implementiert wurden, wird auch die pragmatische Sicht vertreten, dass schon 99 % der wichtigen Syscalls für viel Software ausreichen könnten
  • Lizenzierung und das Rust-Ökosystem
    • Diskussionen darüber, dass Asterinas MPL gewählt hat: Es gibt positive Einschätzungen, dass MPL gut zum Crate-Ökosystem und zu modularen Lizenzen in Rust passt
    • GPL sei nicht immer optimal; mit Unternehmensförderung könne auch eine unternehmensfreundlichere Lizenz wie MPL sinnvoll sein
  • Projektabhängigkeiten und Sicherheit
    • Es werden Zweifel geäußert, ob die Verwendung vieler externer Crates in einem Rust-basierten OS sicher ist; gefordert wird mehr Automatisierung bei Supply-Chain-Sicherheit und Audits über cargo deny/cargo vet
    • Erwähnt wird auch, dass sich allein anhand der Lockfile die tatsächliche Angriffsfläche der Abhängigkeiten schwer erfassen lässt, auch wegen transitive Abhängigkeiten und plattformspezifischer Unterschiede im Rust-Ökosystem
  • Technische Inspiration und ähnliche Architekturen
    • Es wird darauf hingewiesen, dass das Framekernel-Konzept der SPIN-OS-Architektur der University of Washington aus den 1990er-Jahren ähnelt
    • Auch SPIN betonte starke Modularität und vom Compiler durchgesetzte Schnittstellen- bzw. Zugriffskontrolle
  • Kontroverse um die Zusammensetzung der Committer
    • Es wird erwähnt, dass sich unter den 45 Mitwirkenden viele Commits auf eine kleine Zahl von Doktoranden konzentrieren
    • Zugleich wird dem Missverständnis widersprochen, von PhD-Studierenden getragene Beiträge hätten als echte Committer weniger Wert; als forschungsgetriebenes Innovationsprojekt habe das dennoch Bedeutung
  • Politik-/Geschichtsdebatten und Hinweise auf Offtopic
    • Die OS-Diskussion weitete sich auf geopolitische, politische und historische Debatten über die USA, Europa und China aus; von der Redaktion wurden mehrfach „Offtopic“-Warnungen ausgesprochen
    • Einige Nutzer betonen, dass auch das Open-Source-/FOSS-Ökosystem von geopolitischen Veränderungen beeinflusst werden kann
  • Sonstiges
    • Es wurden wissenschaftliche Arbeiten zur Sicherheit von WASM geteilt
    • Die Einschätzungen zum Entwicklungsstand des Kernels fallen teils positiv, teils kritisch aus

Verwandte Beiträge

2 Kommentare

 
eususu 2025-06-24

Solche Versuche gefallen mir sehr.
Vielleicht gibt es schon bald einen Kernel, der nicht abstürzt.
 
GN⁺ 2025-06-23
Hacker-News-Kommentare

  • Ich finde den Ansatz interessant und hoffe, dass er erfolgreich ist. Trotzdem bleiben bei mir Zweifel. Ich erinnere mich noch an etwas, das Linus Ende der 90er oder Anfang der 2000er in einem TV-Interview über Konkurrenten gesagt hat. Sinngemäß meinte Linus: „Niemand schreibt gern Treiber; sicher sind wir, bis irgendein junger, hungriger Mensch als exzellenter Treiberentwickler auftaucht.“ Schon damals war ihm bewusst, dass eine instabile Treiber-Schnittstelle eine Art Verteidigung sein kann. 25 Jahre später sind Kernel, die auf virtualisierter Hardware laufen, völlig alltäglich, aber wirklich praktische und nutzbare Betriebssysteme, die auf echter Hardware und mit ihrer Abstraktion erfolgreich sind, gibt es immer noch nur eine Handvoll

    • Zu dem Punkt, dass „eine instabile Treiber-Schnittstelle eine Verteidigung“ sei: Künftig könnte es gut sein, dass ein junger, hungriger Systemforscher oder eine KI auftaucht und KI-Agenten Linux-Treiber in C in sichere Asterinas-Treiber in Rust übersetzen. Ein anderer realistischer Ansatz wäre, den Linux-Kernel selbst in irgendeiner isolierten Umgebung weiterzuverwenden. Der HongMeng-Kernel nutzt zum Beispiel User-Mode Linux zur Wiederverwendung von Treibern. Asterinas könnte eine ähnliche Strategie anwenden. Referenz: https://www.usenix.org/conference/osdi24/presentation/chen-haibo

    • Ich bezweifle, dass Linus wirklich so eine „Schutzmauer“ wollte oder beabsichtigt hat. Er ist kein Gründer eines Tech-Startups, sondern ursprünglich einfach ein Kernel-Hacker und längst finanziell auf Lebenszeit abgesichert. Die Deutung, die Instabilität der Treiber-Schnittstellen im Kernel sei eine absichtliche Strategie zur Abwehr von Konkurrenz, ist eine überzogene Projektion

    • Es gab auch früher schon Präzedenzfälle wie SPIN OS (Modula 3), JX OS (Java), House OS (Haskell) und Verve. Sie alle implementierten Kernel-Funktionalität in typ- und speichersicheren Sprachen. Üblicherweise war das so aufgebaut, dass Gefahren hinter geprüften Funktionsaufrufen verborgen wurden, teils unter Nutzung einer VM. Wenn man Performance- oder Adoptionsprobleme ausklammert, liegen die Hauptschwachstellen in Lücken der Abstraktion, in Umgehungen über unsafe-Code, im Zusammenbruch des Sicherheitsmodells durch Compiler/JIT sowie in allgemeinen Hardwarefehlern, etwa kosmischer Strahlung im Weltraum. Trotzdem ist das deutlich sicherer als Kernel/Apps in unsafe-Sprachen. Um noch weiterzugehen, könnte man unsafe-Code statisch analysieren, sicherstellen, dass alle unsafe-Funktionen typ- und speichersichere Schnittstellen einhalten, beim Integrieren einen Compiler verwenden, der Abstraktionssicherheit erhält, und auch zertifizierte Compiler pro Komponente einsetzen. Die meisten Produktivitäts-Tools existieren bereits; nur „vollständig sicher abstrahierendes Kompilieren“ fehlt noch, daran wird aber geforscht, und eine manuelle Prüfung ist ebenfalls möglich

    • Dass es nur eine Handvoll praktisch nutzbarer Betriebssysteme gibt, hat einen Grund. In der Hardware-Welt gibt es zwar jede Menge Schnittstellen-„Standards“, aber echte Hardware verhält sich fast nie sauber nach Standard. Wenn niemand Zeit investiert, Treiber so zu schreiben, dass sie alle möglichen Besonderheiten und nicht behebbaren Fehler (Errata) abfangen, ist es in der Praxis extrem schwer, auf realer physischer Hardware Leistung und Support zu bieten

    • Andererseits laufen 98 % des Linux, mit dem ich tatsächlich zu tun habe, in virtualisierten Umgebungen. Auf Desktop/Laptop nutze ich VirtualBox im Vollbild, Windows-Treiber nur dann, wenn ich sie wirklich brauche, und auf dem Mac eine von Docker.app verwaltete headless VM. Alle produktiven Workloads in der Firma laufen in AWS-VMs. Die einzige Linux-Hardware, die ich zu Hause nutze, ist ein Homeserver, und selbst den will ich bald durch eine bei eBay gekaufte Mac-mini-VM ersetzen. Wenn also ein zu Linux kompatibler Kernel käme, der sicherer ist und ähnliche Performance bietet, dann wäre eine schwächere Treiber-Unterstützung heutzutage für mich kein großes Hindernis mehr

  • Ich habe gehört, dass Mikrokernel die IPC-Performance-Probleme zuletzt stark verbessert haben. Ich erinnere mich nicht mehr genau, wie stark, aber das Branchen-Trauma durch Mach war wohl groß. Auf der Projektseite wirkt es eher so, dass nur das Framework (privilegierter Modus) unsafe in Rust verwenden darf und Services (nicht privilegiert) nur sicheres Rust nutzen. Das fühlt sich irgendwie merkwürdig an: Wenn nicht privilegierter Code unsafe ist, ist er dann nicht trotzdem gefährlich, auch wenn er nicht privilegiert ist? Und umgekehrt darf gerade der unsafe-Code, der wirklich verifiziert werden müsste, unbegrenzt verwendet werden? Laut Lizenz verwendet Asterinas hauptsächlich die Mozilla Public License (MPL) 2.0, einige Komponenten aber permissivere Lizenzen. Das wirkt wie ein Mittelweg, weder GPL noch BSD

    • Auf die Frage „Nicht privilegiert ist doch auch gefährlich, wenn es unsafe ist, und wirklich überprüfungsbedürftiger Code wird auf die privilegierte Seite konzentriert?“: Diese Struktur muss im Kontext eines Framekernels verstanden werden. Der gesamte Rust-basierte Framekernel läuft im Kernel-Space, ist logisch aber in zwei Teile gegliedert: ein privilegiertes OS-Framework und nicht privilegierte OS-Services. Der privilegierte Teil umfasst sowohl sicheren als auch unsafe Rust-Kernel-Code, der nicht privilegierte Teil nur sicheren Rust-Kernel-Code. Diese Richtlinie bezieht sich vollständig auf Kernel-Code. Bei Framekernels gibt es keine Sprachbeschränkungen für User-Programme

    • Soweit ich weiß, haben die meisten neueren Mikrokernel die IPC-Performance drastisch verbessert. SeL4 hat IPC zum Beispiel sehr aggressiv optimiert, sodass IPC dort deutlich schneller ist als ein gewöhnlicher Syscall unter Linux. Viele Programme könnten auf seL4 wahrscheinlich sogar schneller laufen. Mich würden konkrete Performance-Vergleichsdaten interessieren

    • Ja, moderne Mikrokernel haben die IPC-Probleme verbessert. Das grundlegendere Problem ist eigentlich, dass auf moderner Hardware selbst Syscalls in monolithischen Kerneln sehr langsam sind. Deshalb liefern Schnittstellen wie io_uring oder virtio gute Performance: Sie verarbeiten Requests und Responses zwischen System und App (oder Hypervisor und Gast) über Queues und vermeiden dadurch Address-Space-Wechsel. Die Betriebssysteme der Zukunft werden unabhängig von ihrer Architektur zwingend Queue-basierte Syscall-Mechanismen brauchen. Und wenn man diesen Ansatz wählt, gibt es performance-seitig keinen großen Unterschied mehr, ob das OS monolithisch, als Mikrokernel oder in einer anderen Struktur gebaut ist

    • Die Trennung privileged/unprivileged im Framekernel bedeutet nicht Kernel- vs. User-Space. Das gesamte OS läuft auf Kernel-Privilege-Level. Logisch wird aber unterschieden zwischen Core-Library-Code (privileged, unsafe erlaubt) und den übrigen Kernel-Komponenten (nutzen die Bibliotheken, dürfen unsafe nicht direkt verwenden, unprivileged). Wahrscheinlich wird das über Linter oder ähnliche statische Checks erzwungen. Wegen der mehrfachen Bedeutung der Begriffe ist das leicht verwirrend

    • Auch nicht privilegierte Tasks laufen im selben Speicherraum wie der Kernel-Core, daher gibt es zur Laufzeit keine Möglichkeit, unsicheres Verhalten zu verhindern. Um Privilegien zur Laufzeit wirklich zu trennen, bräuchte man eine Mikrokernel-Struktur. Hier wird Privilegierung also nicht zur Laufzeit, sondern statisch umgesetzt, indem unsafe-Code verboten wird

  • Ich frage mich, ob das Konzept, einen Kernel in einen kleinen unsafe-Core und große sichere Module zu trennen, ein neuer Ansatz ist. Dass man den Hardware-Overhead eines Mikrokernels vermeidet, zugleich die Sicherheitsprobleme eines monolithischen Kernels umgeht und dabei die Safe/Unsafe-Trennung einer Systemsprache gut ausnutzt, macht das Projekt sehr interessant und weckt hohe Erwartungen

  • Mich erinnert das an Drew DeVaults Review zu Rust in Linux. Die HN-Diskussion dazu lässt sich ebenfalls verknüpfen: https://news.ycombinator.com/item?id=41404733

  • Ich halte das für einen wirklich großartigen Versuch, und dass der Autor selbst in diesem Thread ist, beeindruckt mich ebenfalls. Ich frage mich, bis zu welchem Grad das schon usable ist; ich würde gern zumindest in einer eingeschränkten Umgebung ein Server-Image bauen und damit experimentieren

    • Asterinas ist noch ein relativ neuer Kernel und für den allgemeinen Einsatz noch nicht ganz ausgereift. Aber wenn das Ziel ein tatsächlich effizienter und zuverlässiger Betrieb in realen Services ist, dann ist die verbleibende Lücke nicht besonders groß, und es ist gut möglich, dass dieses Ziel innerhalb eines Jahres erreicht wird. Derzeit wird an wichtigen Funktionen wie Linux-Namespaces und cgroups gearbeitet sowie an der ersten auf Asterinas basierenden Distribution. Das erste Ziel ist, Asterinas als Gast-OS für Confidential VMs einzusetzen; dank Speichersicherheit und kleiner TCB hat es in puncto Sicherheit klare Vorteile gegenüber Linux

  • Wenn ich lese, Mikrokernel-IPC sei langsam und deshalb unpopulär, beruhigt mich das fast, weil selbst technisch sehr starke Leute bei den Gründen realer Adoption und den Missverständnissen im Prozess danebenliegen können

    • Dann wäre es hilfreich, genau zu erklären, was daran falsch interpretiert wird, damit alle etwas davon haben

  • Die Lizenz ist MPL; persönlich finde ich, dass es auch bessere Lizenzen gibt, etwa GPLv3

    • In der Dokumentation wird direkt erklärt, warum MPL gewählt wurde. Es ist nicht meine bevorzugte Wahl, aber die Begründung ist nachvollziehbar

  • Ich halte das für eine wirklich gute Idee. Es gibt bereits viel aufgebaute Software, und eine alternative Grundlage kann auch aus nichttechnischen Gründen große Vorteile oder Wahlmöglichkeiten schaffen. Das erinnert mich an kFreeBSD und GNU/Hurd

  • Ich frage mich, wie man solche Kernel nennen sollte. *nux?