BoringKernel
Its own x86_64 kernel provides memory management, scheduling, process address spaces, Ring 3, syscalls, ELF64 userspace, IPC and hardware-facing subsystems.
BoringKernel 0.0.62-dev · x86_64 · C · M68 PHYSICAL 1920×1080 DESKTOP
BoringOS
An independent x86_64 desktop operating system built from scratch in C — not Linux, not BSD and not a wrapper around another kernel. BoringOS has its own kernel, writable BoringFS filesystem, native Ring 3 userspace, display service and BoringWM desktop. The current M68 physical baseline boots that stack on the real Cthulhu workstation at 1920×1080 with real USB keyboard and mouse input, bounded display-damage presentation and the proven persistent 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 keyboard + mouse
- LIVE bounded display damage
- LIVE persistent BoringFS
- LIVE reboot + ACPI S5
The physically accepted M68 1920×1080 reference is commit 7a9594508bc02b6a5c8d5d13c2ed5c858c9cb54e. The earlier low-latency cursor/focus path is physically accepted at c5ded88e3d473162b94f963d9509394246ef782c. Development continues on main; physical checkpoints remain identifiable by commit history.
Built from scratch
What makes BoringOS an independent operating system?
BoringOS is not a Linux distribution, BSD variant or desktop shell on top of another OS. Limine boots it, but the kernel, userspace, filesystem and desktop stack are BoringOS components.
BoringFS
Its own writable filesystem has a formatter, validator, boringfsck, kernel mount support and a physically proven persistent USB-root lifecycle.
Native C userspace
boring-init, boring-display, the shell, PTYs and native applications run on BoringOS's own syscall and VFS layers rather than a Linux or BSD userspace.
BoringWM desktop
The native display service and BoringWM compose the desktop themselves. BoringTerminal, BoringEdit and BoringFiles run without X11 or Wayland underneath.
01 · Physical proof
The from-scratch desktop runs on real hardware at 1920×1080.
M68 physically boots the native BoringWM desktop on Cthulhu at 1920×1080. The earlier M66 USB/HID baseline remains intact, including real hub enumeration, keyboard and downstream mouse input.
Cthulhu
AMD Ryzen 7 5800X3D, Gigabyte B550 VISION D, 32 GiB installed memory detected through SMBIOS and 57 PCI devices reported by boringfetch.
1920×1080 physical desktop
M68 physically proved the firmware/Limine framebuffer request at 1920×1080×32 with BoringWM, keyboard and mouse working on the real machine.
Real keyboard + mouse path
The direct Holtek keyboard and the ROCCAT mouse behind a real Genesys hub reach BoringOS through its own xHCI/HID stack. Mouse movement drives the software cursor and pointer focus.
02 · Native desktop
Kernel, services, WM and applications are all BoringOS.
PID 1 starts the Ring3 display stack from BoringFS. There is no X11 or Wayland underneath it.
bootLimineUEFI bootstrap + firmware framebuffer.
kernelBoringKernelMemory, scheduling, processes and syscalls.
storageBoringFSWritable USB-root on the physical M63 image.
serviceboring-displayInput ownership and software composition.
policyBoringWMTiling, focus, close and persistent empty desktop.
appsTerminal · Edit · FilesNative Ring3 applications.
Physical shortcuts include Super+Return, Super+E, Super+F and Super+Q. M62 also physically proved seven terminals plus Edit and Files, full close-down and clean capacity reuse.
03 · USB
Multi-xHCI, the real hub and the real mouse now work physically.
M64 removed the single-controller assumption, M65 added bounded downstream hub topology and M66 proves the complete physical path on Cthulhu. M63 remains the separate durability baseline for USB Mass Storage and persistent BoringFS.
PROVENMulti-xHCIRelevant controllers are instance-owned with independent MMIO, command/event rings and device state.
PROVENGenesys hubReal hub-class descriptor, power, status and bounded asynchronous reset handling work on Cthulhu.
PROVENROCCAT mouseThe downstream physical mouse reaches HID Interrupt-IN and moves the existing BoringOS software cursor.
PROVENBoringWM focusWith two live windows, moving the pointer across them changes focus through real Ring3 pointer hit-testing.
04 · Graphics
1920×1080 is physically proven; rendering is still software-owned.
BoringOS composes the desktop on the CPU and presents into a firmware/Limine-provided framebuffer. M68 adds bounded client and layout damage while keeping the existing fast cursor/focus paths. There is still no native AMD/NVIDIA/Intel GPU driver.
PHYSICAL1920×1080×32The M68 boot entry is physically proven on Cthulhu at 1920×1080, with 800×600 retained as a selectable fallback.
LIVEBounded damageClient damage and changed window-layout regions can be composed and presented without always repainting the full framebuffer.
LIVEFast cursor + focusCursor movement and focus-border updates keep the earlier bounded low-latency presentation paths.
LATERNative GPU driverNative modesetting, VRAM/GTT and GPU command submission remain intentionally later work.
05 · Storage + BoringFS
The physical USB root now survives a full reboot cycle.
BoringFS is BoringOS's own filesystem. M63 physically proves mkdir/touch/write on the USB root, real reboot, a second successful mount and the original data still present afterwards.
BoringFS
Own codec, validator, formatter, boringfsck, kernel mount support and writable operation.
Physical root
xHCI USB Mass Storage, Bulk/BOT/SCSI and the fixed BoringFS slice are physically reached on Cthulhu.
Other path
Bounded synchronous AHCI/SATA read, write and flush support remains verified alongside VirtIO reference storage.
06 · After M68
Higher resolution and bounded display damage are proven. The next work broadens the system.
M61–M66 established the physical desktop, durability and USB/HID path. The cursor/focus latency fix made pointer interaction responsive, and M68 added a physically tested 1920×1080 desktop plus bounded client/layout damage.
M68current physical desktop milestone
1920×1080physically tested on Cthulhu
BOUNDED DAMAGEclient + layout presentation
M61–M63 · Desktop, capacity and persistence
Native Ring 3 desktop, dynamic process/task objects, writable USB-root persistence, real reboot and ACPI S5 shutdown.
M64–M66 · Multi-xHCI + hub + physical mouse
Independent USB controllers, real Genesys hub enumeration and downstream ROCCAT mouse input reaching BoringWM.
Cursor/focus latency · physical Cthulhu fix
Bounded cursor presents, input-first focus handling and deferred/coalesced border paints removed the observed pointer stalls.
M68 · 1920×1080 + bounded display damage
Higher firmware framebuffer resolution plus bounded client and layout composition/presentation, physically tested on Cthulhu.
Next · broader software graphics and memory use
Continue reducing avoidable full-frame work and make more practical use of Cthulhu's installed 32 GiB without weakening the proven desktop.
Parked input polish · typematic + DE layout
Held-key repeat and a proper German keyboard layout remain separate input-polish work rather than blockers for the current desktop baseline.
Later · networking, NVMe, audio, SMP and native GPU support
These larger system areas remain beyond the current physically proven desktop and storage foundation.
07 · Current limits
The remaining rough edges are visible — and useful.
The physical machine is now exposing exactly which bootstrap assumptions should be removed next.
Keyboard
Held USB keys do not typematically repeat yet, and the current keymap is effectively ENG/US rather than a finished German layout.
Graphics
1920×1080 is physically tested, but multiple windows at that resolution can still be demanding. Native 3440×1440 and GPU acceleration are not implemented.
Memory
Cthulhu has 32 GiB installed and BoringOS detects it through SMBIOS; making practical use of the full capacity remains future work.
System breadth
No networking, audio, NVMe or SMP runtime yet, and no native GPU driver. BoringOS still prefers truthful boundaries over pretend support.
FAQ · Independent OS
BoringOS in plain terms.
The short answers to the questions people usually ask when they see a hobby operating system with its own kernel and desktop.
Is BoringOS Linux?
No. BoringOS is not a Linux distribution and does not use the Linux kernel. It has its own x86_64 kernel, BoringKernel.
Is BoringOS based on BSD?
No. It is not BSD and is not a wrapper around another operating-system kernel.
What language is BoringOS written in?
BoringOS-developed system components are written primarily in C, with small isolated x86_64 assembly where the architecture requires it.
Does it have its own kernel and filesystem?
Yes. BoringKernel provides the kernel foundation and BoringFS is the writable native filesystem used by the physical USB-root system.
Does BoringOS run on real hardware?
Yes. It is physically tested on Cthulhu; M68 ran the native software-rendered desktop at 1920×1080 with real USB keyboard and mouse input.
Is it a Windows, Linux or macOS replacement?
Not today. BoringOS is an experimental independent operating-system project, not a claimed daily-driver replacement. Its missing areas are documented explicitly.
Source of truth
main is the active development line. Physically tested checkpoints are preserved by exact commit IDs in repository history, including the M68 1920×1080 reference.