An operating system learning lab
MakopaOS
A small operating system lab for studying how a computer boots, runs isolated programs and controls access to resources.
Educational kernel and boot examples. This is not a general-purpose desktop operating system.
nasm -Wall -Werror -f bin \
-o boot.bin boot.asm
python scripts/verify_boot.py boot.binLatest verified change · OS032 / PR #19 ↗ · Merged
From boot sector to explicit kernel authority
The retained BIOS example is now accompanied by a freestanding Rust kernel and thin UEFI loader. Fixed workloads exercise task isolation, capability-mediated IPC, a bounded approval broker, and a supervisor-readable effect journal.
Source checked . Documentation and retained evidence review, not a new runtime test.
Read change evidence ↗Documented example / 19 September 2026
Start with 512 bytes. Follow the boot boundary.
The retained BIOS example prints MAKOPA. The separate Rust and UEFI path explores memory ownership, isolated tasks and explicit permission to produce an effect.
What turns an assembly example into a boot image?
A tiny boot result is the entry point to a larger question: what should a running program be allowed to do?
Source-described boot behavior and build commands, not a screenshot or fresh machine boot. The BIOS example and Rust/UEFI kernel are separate paths.
In plain terms
Boot a small system and examine how a kernel limits what a running program is allowed to do.
Why it matters
An operating system must decide which program can use which resources. Small, fixed examples make those decisions easier to inspect.
Follow the example, step by step
Start the machine
A small loader starts the Rust kernel in the QEMU simulator.
Run a fixed example
Isolated tasks communicate using handles that grant specific permissions.
Inspect the record
Serial output records the permitted operations and contained faults.
Separate kernel mechanisms from workload policy
Documented approach
The architecture proposal places isolation, IPC and capability checks below replaceable policy and protocol services. The current README separately describes the implemented fixed workload profiles.
Alternative and scope
The proposal excludes model inference, natural-language intent and external agent protocols from the kernel. It also retains the BIOS diagnostic alongside the separate UEFI path rather than claiming a general-purpose OS replacement.
Cost of the choice
A deliberately small trusted core leaves broader services and gateways as future work. The initial model does not claim protection from hostile firmware, physical attacks, side channels or a compromised compiler.
What the evidence establishes
This source is explicitly marked Proposed. It explains direction and limits, not proof that all target services or gateway interfaces have been implemented. No new kernel execution is claimed here.
Read the decision source (opens in a new tab)Boot, isolation and explicit authority
The Rust/UEFI path contains separate fixed workload profiles for isolation, capability-mediated IPC, approval and journaling. The original BIOS boot sector is retained as a separate example; this map is not a claim of a general-purpose OS.
A complete path in one boot sector
The retained BIOS example is a 512-byte educational boot sector written in 16-bit real-mode x86 assembly. It uses BIOS interrupts for direct screen output and boots far enough to print its own MAKOPA message.
A kernel with bounded authority
The Rust/UEFI path validates an ELF kernel and memory-map handoff, owns physical frames and recovery address spaces, and contains a fixed ring-3 fault. Separate staged profiles demonstrate cooperative tasks, single-slot IPC, capability attenuation, and one explicitly approved synthetic in-memory effect.
Small by design
The documented evidence uses fixed workloads and deterministic serial records in QEMU. These bounded teaching profiles do not establish a general-purpose operating system, physical-hardware qualification, or an external workload gateway.
Related updates
Inspect the checked source
Evidence reviewed . Individual decisions and captured examples retain their own source revisions and limitations.
Read the checked README (opens in a new tab)