BoringKernel
Der eigene x86_64-Kernel stellt Speicherverwaltung, Scheduling, Prozessadressräume, Ring 3, Syscalls, ELF64-Userspace, IPC und hardwarenahe Subsysteme bereit.
BoringKernel 0.0.62-dev · x86_64 · C · M68 PHYSICAL 1920×1080 DESKTOP
BoringOS
Ein eigenständiges x86_64-Desktop-Betriebssystem von Grund auf in C — kein Linux, kein BSD und kein Wrapper um einen fremden Kernel. BoringOS besitzt mit BoringKernel einen eigenen Kernel, das schreibbare BoringFS, einen nativen Ring-3-Userspace, einen eigenen Display-Service und BoringWM. Der aktuelle physische M68-Stand bootet diesen Stack auf Cthulhu mit 1920×1080, echter USB-Tastatur und Maus, begrenztem Display-Damage-Present und dem bewiesenen persistenten USB-Root-Lifecycle.boring is not a bug. it's the entire operating system now.
- PHYSICAL 1920×1080 Desktop
- PHYSICAL Multi-xHCI + USB-Hub
- PHYSICAL Tastatur + Maus
- LIVE begrenzter Display-Damage
- LIVE persistentes BoringFS
- LIVE Reboot + ACPI S5
Die physisch abgenommene M68-Referenz mit 1920×1080 ist Commit 7a9594508bc02b6a5c8d5d13c2ed5c858c9cb54e. Der frühere physisch abgenommene Low-Latency-Cursor-/Fokuspfad ist c5ded88e3d473162b94f963d9509394246ef782c. Die Entwicklung läuft auf main; physische Checkpoints bleiben über ihre exakten Commits nachvollziehbar.
Von Grund auf
Was macht BoringOS zu einem eigenständigen Betriebssystem?
BoringOS ist keine Linux-Distribution, keine BSD-Variante und keine Desktop-Shell auf einem fremden OS. Limine startet das System, aber Kernel, Userspace, Dateisystem und Desktop-Stack sind BoringOS-Komponenten.
BoringFS
Das eigene schreibbare Dateisystem besitzt Formatter, Validator, boringfsck, Kernel-Mount-Support und einen physisch bewiesenen persistenten USB-Root-Lifecycle.
Nativer C-Userspace
boring-init, boring-display, Shell, PTYs und native Anwendungen laufen auf BoringOS-eigenen Syscall- und VFS-Schichten statt auf einem Linux- oder BSD-Userspace.
BoringWM-Desktop
Display-Service und BoringWM komponieren den Desktop selbst. BoringTerminal, BoringEdit und BoringFiles laufen ohne X11 oder Wayland darunter.
01 · Physischer Beweis
Der von Grund auf gebaute Desktop läuft physisch mit 1920×1080.
M68 bootet den nativen BoringWM-Desktop auf Cthulhu physisch mit 1920×1080. Die frühere M66-USB/HID-Basis bleibt vollständig erhalten, einschließlich echtem Hub, Tastatur und Downstream-Maus.
Cthulhu
AMD Ryzen 7 5800X3D, Gigabyte B550 VISION D, 32 GiB installierter Speicher per SMBIOS erkannt und 57 PCI-Geräte in boringfetch.
1920×1080 physischer Desktop
M68 beweist die Firmware-/Limine-Framebuffer-Anforderung mit 1920×1080×32 auf der echten Maschine; BoringWM, Tastatur und Maus funktionieren dabei.
Direkter Maus-/Fokuspfad
Der physisch abgenommene Low-Latency-Pfad präsentiert kleine Cursor-/Fokusregionen, sodass kontinuierliche Mausbewegung auch beim Wechsel zwischen Fenstern direkt bleibt.
02 · Nativer Desktop
Kernel, Services, WM und Anwendungen sind BoringOS.
PID 1 startet den Ring3-Display-Stack aus BoringFS. Darunter gibt es weder X11 noch Wayland.
bootLimineUEFI-Bootstrap + Firmware-Framebuffer.
kernelBoringKernelMemory, Scheduling, Prozesse und Syscalls.
storageBoringFSSchreibbares USB-Root im physischen M63-Image.
serviceboring-displayInput-Ownership, Software-Komposition und begrenzte Region-Presents.
policyBoringWMTiling, Fokus, Close und persistenter leerer Desktop.
appsTerminal · Edit · FilesNative Ring3-Anwendungen.
Physisch bewiesen sind Super+Return, Super+E, Super+F und Super+Q. M62 bewies zusätzlich sieben Terminals plus Edit und Files, komplettes Schließen und saubere Capacity-Wiederverwendung. Der Pointer-Fokus zwischen mehreren Fenstern ist jetzt ebenfalls physisch als flüssiger Interaktionspfad abgenommen.
03 · USB
Multi-xHCI, echter Hub und echte Maus bleiben die stabile Basis.
M64 entfernt die Single-Controller-Annahme, M65 ergänzt begrenzte Downstream-Hub-Topologie und M66 beweist den vollständigen physischen Pfad auf Cthulhu. Die neue Cursor-/Fokus-Optimierung verändert USB/HID nicht.
BEWIESENMulti-xHCIRelevante Controller besitzen unabhängige MMIO-, Command-/Event-Ring- und Gerätezustände.
BEWIESENGenesys-HubEchte Hub-Class-Deskriptor-, Power-, Status- und begrenzte Reset-Pfade funktionieren auf Cthulhu.
BEWIESENROCCAT-MausDie physische Downstream-Maus erreicht HID Interrupt-IN und den bestehenden BoringOS-Inputpfad.
UNVERÄNDERTM66-BasisDer Performance-Fix liegt hinter HID: Input, BoringWM und Present-Pfad wurden gezielt optimiert, ohne USB neu zu öffnen.
04 · Grafik
1920×1080 ist physisch bewiesen; gerendert wird weiterhin vollständig in Software.
BoringOS komponiert den Desktop auf der CPU und präsentiert in einen Firmware-/Limine-Framebuffer. M68 ergänzt begrenzten Client- und Layout-Damage und behält die schnellen Cursor-/Fokuspfade. Einen nativen AMD/NVIDIA/Intel-GPU-Treiber gibt es weiterhin nicht.
PHYSICAL1920×1080×32Der M68-Boot-Eintrag ist auf Cthulhu physisch mit 1920×1080 bewiesen; 800×600 bleibt als auswählbarer Fallback erhalten.
LIVEBegrenzter DamageClient-Schäden und geänderte Fensterlayout-Regionen können komponiert und präsentiert werden, ohne immer den gesamten Framebuffer neu zu zeichnen.
LIVESchneller Cursor + FokusCursorbewegung und Fokusrahmen behalten die früher physisch bewiesenen begrenzten Low-Latency-Present-Pfade.
SPÄTERNativer GPU-TreiberNative Modesets, VRAM/GTT und GPU-Command-Submission bleiben bewusst spätere Arbeit.
05 · Storage + BoringFS
Das physische USB-Root überlebt einen vollständigen Reboot-Zyklus.
BoringFS ist das eigene Dateisystem von BoringOS. M63 beweist physisch mkdir/touch/write auf dem USB-Root, echten Reboot, erneuten erfolgreichen Mount und die ursprünglichen Daten danach weiterhin vorhanden.
BoringFS
Eigener Codec, Validator, Formatter, boringfsck, Kernel-Mount-Support und schreibbarer Betrieb.
Physisches Root
xHCI USB Mass Storage, Bulk/BOT/SCSI und die feste BoringFS-Slice werden auf Cthulhu physisch erreicht.
Lifecycle
Persistenz über Reboot sowie anschließender echter ACPI-S5-Shutdown bleiben die eingefrorene M63-Durability-/Power-Basis.
06 · Nach M68
Höhere Auflösung und begrenzter Display-Damage sind bewiesen. Jetzt wird das System breiter.
M61–M66 etablierten Desktop, Persistenz und USB/HID. Der Cursor-/Fokus-Fix machte den Pointer physisch direkt, und M68 ergänzt einen physisch getesteten 1920×1080-Desktop sowie begrenzten Client-/Layout-Damage.
M68aktueller physischer Desktop-Meilenstein
1920×1080physisch auf Cthulhu getestet
BOUNDED DAMAGEClient + Layout Present
M61–M63 · Desktop, Kapazität und Persistenz
Nativer Ring-3-Desktop, dynamische Prozess-/Task-Objekte, schreibbare USB-Root-Persistenz, echter Reboot und ACPI-S5-Shutdown.
M64–M66 · Multi-xHCI + Hub + physische Maus
Unabhängige USB-Controller, echte Genesys-Hub-Enumeration und Downstream-ROCCAT-Maus bis in BoringWM.
Cursor-/Fokus-Latenz · physischer Cthulhu-Fix
Begrenzte Cursor-Presents, input-first Fokusbehandlung und deferred/coalesced Border-Paints beseitigten die beobachteten Pointer-Stalls.
M68 · 1920×1080 + begrenzter Display-Damage
Höhere Firmware-Framebuffer-Auflösung plus begrenzte Client-/Layout-Komposition und -Präsentation, physisch auf Cthulhu getestet.
Nächstes · breitere Software-Grafik und Speichernutzung
Weitere vermeidbare Full-Frame-Arbeit reduzieren und Cthulhus installierte 32 GiB praktischer nutzen, ohne den bewiesenen Desktop zu schwächen.
Geparktes Input-Polish · Typematic + DE-Layout
Held-key repeat und ein richtiges deutsches Tastaturlayout bleiben separates Input-Polish statt Blocker der aktuellen Desktop-Basis.
Später · Netzwerk, NVMe, Audio, SMP und nativer GPU-Support
Diese größeren Systembereiche liegen weiterhin hinter der aktuell physisch bewiesenen Desktop- und Storage-Basis.
07 · Aktuelle Grenzen
Die verbliebenen Ecken sind klar abgegrenzt.
Die echte Maschine liefert inzwischen einen stabilen Desktop-Baseline-Test und macht die nächsten Baustellen sehr konkret.
Tastatur
Gehaltene USB-Tasten wiederholen noch nicht zuverlässig typematisch; außerdem ist die aktuelle Belegung praktisch ENG/US statt eines fertigen DE-Layouts.
Grafik
1920×1080 ist physisch getestet, mehrere Fenster können dort aber weiterhin spürbar fordernd sein. Native 3440×1440 und GPU-Beschleunigung sind nicht implementiert.
Speicher
Cthulhu besitzt 32 GiB RAM und BoringOS erkennt sie per SMBIOS; die vollständige praktische Nutzung dieser Kapazität ist noch zukünftige Arbeit.
Systembreite
Noch kein Netzwerk, Audio, NVMe oder SMP-Runtime und kein nativer GPU-Treiber. BoringOS behauptet nur Support, der tatsächlich implementiert und getestet ist.
FAQ · Eigenständiges OS
BoringOS ohne Umwege erklärt.
Die kurzen Antworten auf die Fragen, die bei einem Hobby-Betriebssystem mit eigenem Kernel und Desktop fast immer zuerst kommen.
Ist BoringOS Linux?
Nein. BoringOS ist keine Linux-Distribution und verwendet keinen Linux-Kernel. Es besitzt mit BoringKernel einen eigenen x86_64-Kernel.
Basiert BoringOS auf BSD?
Nein. Es ist weder BSD noch ein Wrapper um einen anderen Betriebssystem-Kernel.
In welcher Sprache ist BoringOS geschrieben?
Die BoringOS-eigenen Systemkomponenten sind hauptsächlich in C geschrieben; kleine isolierte Teile verwenden x86_64-Assembler, wenn die Architektur es erfordert.
Hat es einen eigenen Kernel und ein eigenes Dateisystem?
Ja. BoringKernel bildet die Kernel-Basis und BoringFS ist das schreibbare native Dateisystem des physischen USB-Root-Systems.
Läuft BoringOS auf echter Hardware?
Ja. Es wird physisch auf Cthulhu getestet; M68 lief dort mit nativem softwaregerendertem 1920×1080-Desktop sowie echter USB-Tastatur und Maus.
Ist es ein Ersatz für Windows, Linux oder macOS?
Heute nicht. BoringOS ist ein experimentelles eigenständiges Betriebssystemprojekt und kein behaupteter Daily-Driver-Ersatz. Fehlende Bereiche werden ausdrücklich dokumentiert.
Quelle der Wahrheit
main ist die aktive Entwicklungslinie. Physisch getestete Checkpoints bleiben über exakte Commit-IDs in der Repository-Historie erhalten, einschließlich der M68-1920×1080-Referenz.