# BRUTAL: a capability micro-kernel OS in modern C, built to run Doom > BRUTAL is an operating system written from scratch in modern C on a capability based micro-kernel, targeting x86_64, i686, RISC-V and ARM. The project's stated main goal is running Doom, and the release history is organised as milestones rather than versions. **brutal-org/brutal** — 🏢 An operating system inspired by brutalist design that combines the ideals of UNIX from the 1970s with modern technology and engineering - Repository: https://github.com/brutal-org/brutal - Website: https://brutal.smnx.sh/ - Stars: 1,112 · Forks: 43 - Language: C - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/brutal-org-brutal ## The kernel's organising idea is capabilities, not processes BRUTAL is an operating system built from scratch in modern C, and it sits on a capability based micro-kernel. The topics attached to the repository list the terms that make the design legible: operating-system, osdev, kernel, microkernel, hobby-os, and modern-c. A capability system is the specific architectural commitment here. Rather than making the operating system enforce access through a global notion of user and supervisor, with every process holding authority over everything it can name, a capability system hands out unforgeable tokens that stand for authority. Access to a resource becomes a property of holding the right token, and the kernel never has to keep a global table of who may touch what. The consequences are practical, and they are why the project is interesting to read even if you never boot it. Privileges compose. A subsystem can be given a narrow capability to do one thing and denied everything else, and the check happens at the point of use rather than at every boundary. A service can be handed a capability to a single device and to nothing else, which is the kind of isolation that a hobby kernel can implement in a readable amount of code. The project describes itself as exposing its features to developers through clean APIs, which is a design goal stated in the README rather than a measured property, but it points in a consistent direction with the rest of the architecture: a small kernel with a deliberate interface, and a lot of engineering pushed upward into the library layer. ## Four architectures, and a C library that is the real deliverable BRUTAL targets x86_64, i686, RISC-V and ARM. Supporting four instruction sets is a deliberate breadth for a project of this size, and it forces the porting layer to be a real interface rather than a convenience, since the kernel has to speak to four different interrupt and memory models. The second headline feature is a rich and modern C library, described as complete with fibers, custom allocators, generic data structures, and more. This is the part of the project that carries the most weight in practice, because the kernel is the part everyone writes and the library is the part every application actually uses. Fibers in particular are the kind of feature that shows up in what a real operating system needs and that a minimal one usually omits, since they are awkward to provide without solid scheduler and context-switch machinery underneath. Custom allocators and generic data structures are the other two named capabilities, and they point the same way. A custom allocator is only useful if the allocator interface itself is first class, which implies the memory model exposes it. Generic data structures in C only work if the language surface provides what generics need, whether that is macros, a compiler extension, or a disciplined convention, and a project that claims modern C and generic data structures together is making a claim about the toolchain it expects. The library is what makes BRUTAL more than a kernel that boots. It is the layer where the capability model has to become something an application programmer can use without thinking about tokens. ## Milestones instead of versions, and the last one is from 2022 The release history is the most informative thing about the project's trajectory, and it is not a version list. The three tagged releases are named for what the system gained. Milestone 2, tagged on 2021-08-16, is Milestone 2: Userspace, IPC, and Syscalls. Milestone 3, tagged on 2021-11-21, is Milestone 3: Bootloader, PCIe, ACPI and IPCs. Milestone 4, tagged on 2022-03-27, is Milestone 4: Capabilities and Graphics. That progression is a readable narrative of the project moving outward from a kernel that can boot and call into userland, through real hardware support, to the capability model that now defines its architecture. Then the timeline stops. The newest tagged milestone is from 2022-03-27, and the last push to the repository was on 2026-08-26. So the code is being touched, but the named milestones stopped being cut more than four years ago. Nobody claims the project is abandoned, and the commits say otherwise, but the milestone list is a fair signal about what a new contributor should expect to find: an architecture that has been designed further than the milestones record, and a codebase that has moved on since. For a reader, that gap is a documentation opportunity. The design notes in `meta/` are where the current intent lives, and the milestone names give you the vocabulary the project uses to talk about its own progress. ## The build wants GNU Make, NASM and LLVM The build instructions are brief, and they point at a document rather than repeating the steps. The project states that BRUTAL is pretty easy to build from source using GNUMake, NASM and LLVM, and directs readers to `meta/building.md` for the details. If you are the kind of reader who wants the commands, that file is where they are, and the README deliberately keeps them out of the summary. The toolchain combination tells you what kind of code this is. NASM is the Netwide Assembler, and requiring it means the project writes assembly directly for at least part of the boot path or the low level entry points, which is normal for a kernel and for a bootloader. LLVM as the compiler means modern C with modern diagnostics rather than a legacy compiler, and the presence of a `compile_flags.txt` at the repository root, alongside a `.clang-format` and an `.editorconfig`, points to a project with enforced formatting on both the C and the editor side. The repository layout supports the same reading. There is a `makefile` at the root, a `brutal.sh` script next to it, a `build/` directory, a `sources/` directory, and a `sysroot/` directory. The sysroot is the interesting one. A sysroot is the set of headers and libraries visible to the compiler, and having one in a hobby OS means the project ships its own C standard library and its own system headers, so that userland code compiles against the project's own libc rather than the host's. That is a second confirmation that the rich and modern C library is a real deliverable and not a wrapper around the host toolchain. The CI badges in the project cover both Ubuntu and Darwin, so the build is exercised on the two platforms its developers actually use. ## Running Doom is the stated goal, and the roadmap is the design document The roadmap section says something that is easy to skim past and important to understand. Right now the main goal of brutal is to run doom, with the details in `meta/roadmap.md`, including how the project plans to get there and where you can contribute. This is the clearest statement of ambition in the repository, and it is worth reading as a specification of what an operating system needs rather than as a game demo. To run an existing game you need a filesystem, memory management that survives a real workload, timers, input, display output, and a process model capable of running something you did not write. Doom, specifically, needs the graphics milestone the project tagged as Milestone 4, which lines up exactly with where the tagged history stops. So the tagged milestones and the stated goal are consistent with each other. Capabilities and Graphics, the last named milestone, is the pair of things you need before a 1993 game becomes plausible. The unstated consequence is that everything between here and a running Doom, sound, files, a compiler toolchain for userland, and drivers for real input, is the remaining work, and that work is not captured in a release name. The contribution angle is worth noting too, since the roadmap says where you can contribute. A project with a documented gap list and a defined target is far easier to join than one that says it is building an operating system. ## Where BRUTAL is the wrong project The failure modes here are about expectations rather than defects. First, this is not a Linux replacement and does not aim to be one. There is no compatibility layer, no POSIX story in the documentation, and no package ecosystem. The design goal is stated as the ideals of UNIX from the 1970s combined with modern technology and engineering, which is a statement about philosophy rather than about running your existing software. If your goal is to run a distribution, this is the wrong repository. Second, the scope is enormous relative to the released state. A capability micro-kernel, four architectures, a full C library with fibers and custom allocators, graphics, and a plan to run Doom is a multi-year project. The milestone record shows the last named milestone in 2022. A person expecting a bootable desktop or a usable POSIX shell will not find one, and the project summary does not claim otherwise. Third, the build requires assembler and a modern LLVM toolchain, and the detailed steps live in a separate document. That is a small thing, but for someone who wants to skim the code without a toolchain, the sysroot and the library sources are the interesting part and the kernel is not. Fourth, the credits document matters for a different reason. The project says it takes inspirations from and reuses code from other projects, with the list in `meta/credits.md`. For a licence-conscious reader, MIT covers the project's own code, and reused code carries the terms of its origin, so that file is the place to check before copying code out of the tree. ## Conclusion BRUTAL suits a systems programmer who wants to read a complete operating system, from capability-based micro-kernel design through a userland C library, and who is willing to spend a long time on it, because the project publishes design documents alongside code and names its milestones in terms of what the kernel gained. It does not suit anyone looking for a usable daily driver, a Linux alternative, or a system with a maintained userland. Before starting, check three things: that your toolchain has GNU Make, NASM and LLVM as the build documentation requires, that the architecture you care about is one of x86_64, i686, RISC-V and ARM, and that you can accept a project whose newest tagged milestone is Milestone 4 from 2022 while the last push was on 2026-08-26. ## FAQ ### What is BRUTAL and what is its kernel architecture? BRUTAL is an operating system built from scratch in modern C, built on top of a capability based micro-kernel, and it targets x86_64, i686, RISC-V and ARM. The project describes it as combining the ideals of UNIX from the 1970s with modern technology and engineering. ### How do I build BRUTAL from source? The project states that BRUTAL is easy to build from source using GNUMake, NASM and LLVM, and points to `meta/building.md` for the detailed steps rather than listing them in the README. The repository includes a `makefile`, a `brutal.sh` script, a `build/` directory, a `sources/` directory, and a `sysroot/` directory. ### What is the current goal of the BRUTAL project? The stated main goal of brutal is to run Doom, with the plan described in `meta/roadmap.md`, which also covers where you can contribute. The tagged milestone history lines up with this, ending with Milestone 4: Capabilities and Graphics in 2022. ### What C library features does BRUTAL provide? The project describes a rich and modern C library complete with fibers, custom allocators, generic data structures, and more. The repository includes a `sysroot/` directory, which is where a project shipping its own headers and standard library would keep them. ### How often is BRUTAL released? Releases are cut as milestones rather than versions: Milestone 2 in August 2021, Milestone 3 in November 2021, and Milestone 4 in March 2022. The last push to the repository was on 2026-08-26, so commits continue even though no milestone has been tagged since 2022. ## Sources - [brutal-org/brutal on GitHub](https://github.com/brutal-org/brutal) - [License: MIT](https://github.com/brutal-org/brutal/blob/main/LICENSE) - [Project website](https://brutal.smnx.sh/) - [README](https://github.com/brutal-org/brutal/blob/main/README.md) - [Releases](https://github.com/brutal-org/brutal/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/brutal-org-brutal