Eight years in OS development is long enough for the work to stop feeling like a stunt. In the first few weeks of an OS project, everything is theatrical. Printing text is a milestone. Entering long mode is a milestone. Drawing one pixel to a framebuffer feels outrageous. The project survives mainly on the thrill of impossible things becoming barely possible. That phase matters, but it is not yet a systems project in the mature sense. It is still a spark.
What makes David Dull, better known as Coops, interesting is not simply that he started an OS. Plenty of people start OS projects. The part that deserves a blog post is that he stayed with the idea long enough for it to pick up real structural weight. MonkeOS stopped being a single technical curiosity and became an environment with its own runtime, its own filesystem story, its own shell behavior, its own desktop ambitions, and its own history of painful redesigns. By the time a person is still maintaining a project like that years later, the story is no longer "someone made a kernel." The story is "someone kept choosing ownership over shortcuts for almost a decade."
That is also why Loongue belongs in the same conversation. A LoongArch emulator is not the sort of side project someone stumbles into because they want a flashy screenshot for a README. It is the kind of thing that appears after years of repeated exposure to the exact kind of technical questions that operating systems force on a person: instruction decoding, state transitions, architecture assumptions, tooling mismatches, ABI edges, and the endless gap between what software says it targets and what the machine actually does. MonkeOS and Loongue are different projects, but they come from the same engineering temperament.
The clean version of an OS origin story says: a developer becomes interested in systems, reads the manuals, and calmly decides to build an operating system from first principles. The real version is usually more annoying. People end up in OS development because they are irritated by layers they do not own. They dislike invisible abstractions. They want to know what the machine is doing when nobody is hiding it. They become suspicious of software stacks that look complete only because a hundred details have been moved out of sight.
Coops's work has that flavor. MonkeOS is not organized like a project that wants to remain politely academic. It keeps drifting toward the places where polite abstraction breaks down: boot handoff, memory pressure, scheduler behavior, window management under load, font rendering details, VFS semantics, login before desktop, build-time asset normalization, and the ugly work of keeping a system coherent when every subsystem wants slightly different assumptions. The easiest way to explain that is not that the project wants to look impressive. The easier explanation is that the project comes from the kind of mind that gets annoyed when the plumbing is hidden.
That attitude is productive in OS development because operating systems are mostly plumbing plus consequences. The glossy parts of a computer system are downstream from a thousand small invariants. If someone stays in OSDev for eight years, it is usually because they learned to care about those invariants deeply enough that the work stopped feeling secondary. The kernel is not beneath the UI. The kernel is why the UI can exist at all.
Many hobby OS projects reach the first stable plateau very quickly. They boot through GRUB. They parse enough Multiboot data to find the framebuffer. They set up paging. They install a basic interrupt table. They print messages to serial and maybe VGA. At that point the project can absolutely claim that it is an operating system, and technically that is not wrong. But there is a huge difference between a system that can say hello from long mode and a system that keeps moving after the easy bragging rights are already collected.
MonkeOS crossed that line. It kept walking into the hard categories: memory allocation, VFS layout, bundled userspace, app launching, desktop composition, TTF-backed rendering, window focus, title metrics, audio backends, networking, and pre-desktop authentication. Once a project keeps adding layers like that, the development style changes. You stop writing isolated experiments and start writing decisions that will annoy you later if they are wrong. That is the real transition from "OS toy" to "system under construction."
The tree itself gives away that history. MonkeOS is not just one monolithic file plus a boot sector. It has
boot, interrupts, memory, drivers, vfs,
userspace, session, app_manager, stag_host,
desktop, login, terminal_app, kim, and more. That layout
only emerges after years of repeatedly learning that the first "good enough" source split was not good enough at
all.
A lot of writing about operating systems separates "the kernel" from "everything interesting." The kernel is treated like an austere foundation, while the user-facing experience is treated like the creative layer on top. MonkeOS rejects that split by accident if not by manifesto. The kernel decisions leak directly into what the user sees and feels. Timer frequency becomes compositor smoothness. Font table generation becomes layout correctness. Filesystem locking becomes whether login is a fake overlay or a real gate. Audio transport choice becomes whether the machine can play boot media without sounding broken. This is the kind of system where architecture and UX cannot stay politely separated.
That is one reason the project is worth discussing as a long journey rather than a checklist of features. The features are there, but the more interesting part is how often they had to be re-understood. Window titles being off-center sounds like a cosmetic bug until it leads back to inconsistent content-rect math. A settings card clipping text sounds like a UI bug until it exposes stale bitmap-era assumptions in a proportional text system. A black login background sounds cosmetic until it turns out to be a memory-budget problem in an early boot image decode path. The more complete the system became, the more often small failures turned out to be architectural.
MonkeOS is not monolithic because monolithic kernels are fashionable. It is monolithic because keeping the whole stack in one place is the fastest way to iterate on a young system that still does not know all of its permanent boundaries. That choice says a lot about Coops's development instincts. He has repeatedly favored direct control and refactorable ownership over premature theoretical elegance. That is a gamble. It means you will see roughness. It means the repo will show its internal arguments. It means you cannot hide behind imported subsystems nearly as easily. But it also means the project can change direction without asking five external layers for permission.
That trade-off is visible in the way MonkeOS evolves. A compositor timing bug can be fixed by touching timing, app scheduling, and presentation code in one sweep. Login can be moved in front of desktop session start because the tree owns both sides of the handoff. Fonts can be replaced deeply enough that shell, settings, and titlebars all benefit, because the project does not have to pretend the UI toolkit is somebody else's problem. A monolithic design can definitely magnify mistakes, but in a project like this it also magnifies learning.
One of the quiet realities of long-term OS development is that build tooling eventually stops being support work and starts being part of the system's identity. A young project can tolerate build steps that are ugly but understandable. An older project cannot survive long if the build is always half-broken, tied to one host setup, or dependent on dead workspace members and deleted dependencies. That is where a lot of projects rot.
MonkeOS has clearly been through that lesson. The repo has a proper mkiso path, GRUB-based BIOS and
UEFI handling, Windows and Linux wrappers, build-time asset generation, and a growing amount of explicit
normalization inside build.rs. That is not glamorous work, but it is what lets the rest of the
system be real instead of permanently "almost buildable." Eight years of OSDev teaches a harsh truth: if the
build lies, the runtime is usually lying too.
This also helps explain why the build script in MonkeOS does so much more than compile code. It pre-rasterizes fonts. It transcodes boot media. It bundles WebM-derived assets. It emits typed metadata into generated Rust source. That is the kind of build system a project grows after repeatedly discovering that runtime convenience is often just deferred instability. If the runtime can know a thing ahead of time, the build should probably do the work once instead of making the kernel rediscover it repeatedly under memory pressure.
A shell-only system can hide a lot of sins. Once a desktop exists, the machine becomes brutally honest. A drag path with the wrong present cadence is visible immediately. Text metrics become visible immediately. Mouse coupling to heavy app redraws becomes visible immediately. Compositor damage mistakes become visible immediately. Every place where the system assumed a fixed cell, a fake timing constant, or a lucky content size starts showing up as visible discomfort.
That is why it matters that MonkeOS did not stop at a framebuffer and a prompt. The desktop forced the system to confront questions that a lot of lower-level work can dodge for a long time: What counts as a window? Who owns a content rect? How are titles measured? When is a redraw local to one app and when does it force a full desktop compose? What does fullscreen mean in a native compositor instead of in a toolkit borrowed from somewhere else? Eight years of OSDev is enough time to learn that these are not soft questions at all. They are systems questions disguised as polish.
Coops keeping MonkeOS on that path matters because it shows a refusal to let the project remain safely unfinished. Desktop work is punishing precisely because it makes every low-level weakness legible. Continuing anyway is a statement of intent: the project is trying to own a user-facing system, not merely a bootable code artifact.
It sounds ridiculous at first, but one of the easiest ways to tell whether an OS project is still at the screenshot stage is to look at how it handles text. If everything still depends on one bitmap assumption from the earliest renderer, then the UI is often only pretending to be finished. Once a system grows a real TTF path, measured glyph widths, sane wrapping, multiple faces, and a consistent renderer shared by shell and desktop, the operating system has entered a much more demanding phase of adulthood.
MonkeOS has clearly been through that transition. The current tree includes TTF-backed loading and rasterization, multiple font families, UI helpers that measure rather than guess, and a long history of bugs that were exposed by moving away from fake fixed-width assumptions. That is exactly the sort of work that only appears after years of trying to make a system stop looking like a draft. It is not glamorous, but it is real progress.
At first glance, MonkeOS and Loongue can look like different kinds of projects. One is an operating system. The other is described here as a LoongArch emulator. But if you spend enough time around low-level systems work, the connection becomes obvious. Both projects live in the layer where instruction semantics, state transitions, architecture-specific behavior, and exactness matter more than broad application polish.
A person who spends years building operating-system infrastructure learns habits that transfer directly into emulator work:
- distrust undocumented assumptions
- model machine state explicitly
- care about alignment, calling conventions, and ABI shape
- accept that "mostly correct" is often just another way to say "debugging later"
- build tooling around the machine you have, not the machine you wish existedThat is why Loongue belongs in an eight-year retrospective. It is not merely another project in the same repo orbit. It is evidence that the skills acquired in OSDev have started to generalize outward. Once someone has spent enough time writing code that lives close to hardware truth, emulation stops looking like an unrelated field and starts looking like another form of the same argument.
People from outside low-level development often think persistence means working on the same exact idea for years without changing it. In OSDev the opposite is usually true. The projects that survive are the ones willing to destroy their own convenient lies. They rewrite initialization. They rewrite render paths. They rewrite login. They rewrite the build. They change how apps launch. They replace a fake feature with a smaller real one. They turn a supposedly finished subsystem back into active construction because the system finally learned enough to know that the old version was wrong.
MonkeOS has that survival pattern. The current shape of the tree only exists because earlier shortcuts were not allowed to remain sacred. There is a build-time font path because runtime placeholders were not enough. There is a real session layer because "boot straight into the desktop" stopped being structurally honest. There is a bundled media pipeline because arbitrary runtime import was too expensive or too unstable for the current system. There is a native app manager because vague launching semantics eventually stop scaling. None of that emerges from a project that is afraid to invalidate its own past work.
A lot of people build emulator-only operating systems and never quite realize how much that shapes their sense of correctness. Emulators are generous. They are stable in the ways that matter to developers. Their devices are familiar. Their timing is manageable. Their firmware path is less chaotic. Real hardware is impolite. It reveals the difference between "works in one known VM configuration" and "survives contact with a machine that does not care how hard you meant well."
MonkeOS being tested on real UEFI machines matters because it changes what kinds of lies the project is allowed to keep telling itself. Memory discipline becomes more serious. Firmware assumptions become more serious. Audio backend selection becomes more serious. Boot paths and display handoff become more serious. Eight years of OSDev is enough time to learn that hardware support is not a badge you collect after the architecture is done. Hardware is what teaches you whether the architecture was honest in the first place.
Any serious retrospective about almost a decade of OS development should admit something simpler: this kind of work is exhausting. It is not exhausting only because the problems are difficult. It is exhausting because success is lopsided. One week you spend hours on a bug that turns out to be one stale bound. Another week you fix five real issues and the visible result is merely that the system now feels less wrong. A lot of progress in OSDev is negative work. You remove glitches. You remove hidden assumptions. You remove dead dependencies. You remove the places where the machine could panic. That kind of progress is real, but it is rarely cinematic.
That is part of why sticking with an OS project for eight years says so much about the person behind it. It means they found a reason to keep showing up even when the wins were subtle, even when the architecture was arguing back, and even when every subsystem fixed just made the next subsystem's weaknesses more visible. Coops's journey reads like the work of someone who kept deciding that the system was still worth understanding better.
The personality of a long-running technical project usually becomes a compressed version of the developer's taste. MonkeOS does not read like a project chasing borrowed legitimacy. It reads like a project willing to be rough if roughness is the price of honesty. It chooses native paths instead of pretending that porting a mountain of other software would instantly make the system more itself. It chooses explicit kernel/runtime ownership even when that means more work. It chooses build-time normalization over pretending the runtime can afford arbitrary complexity. It chooses to keep a shell around because the shell is honest. It keeps desktop work around because the desktop exposes whether the rest of the system is honest too.
That is an unusual and, frankly, respectable personality for an OS project to develop. It is also the kind of personality that only emerges when one person stays close enough to the code for long enough that every subsystem begins to inherit the same priorities.
A retrospective like this needs at least one blunt summary. Here is the compact version:
1. Booting is easy compared to staying honest after boot.
2. UI polish eventually becomes architecture work.
3. Build systems are part of the runtime story.
4. README-only directories are not always fake; sometimes they are clean source boundaries.
5. Hardware pressure teaches better than aesthetic theory.
6. The hard part of OSDev is not starting. It is surviving enough rewrites to deserve the word "system".Coops's work on MonkeOS and Loongue makes sense through that lens. The impressive part is not just that the projects exist. The impressive part is that the underlying habits became stable enough to produce multiple low-level systems projects that each care about exactness in their own way.
A mature OS project leaves behind more than code. It leaves behind judgment. It teaches a developer what kinds of abstractions to trust, what kinds of bugs deserve immediate suspicion, what kinds of convenience become technical debt, and what kinds of "future work" statements are actually just avoidance. That is probably the most valuable thing eight years of OSDev gives a person. Not a bootable ISO. Not a screenshot. Not even a working compositor. It gives them a much sharper instinct for where software becomes real.
That is why David Dull, Coops, MonkeOS, and Loongue belong in the same story. The story is not merely that one person kept building systems. The story is that, over years, the work appears to have changed from isolated experiments into a stable way of thinking. Once that happens, the output is no longer random. Of course there is an operating system. Of course there is an emulator. The exact project names may differ, but the underlying craft has already decided what kind of problems it likes to solve.
There is a point in long-running technical work where the project stops being a demonstration and starts being a record of what its creator was willing to keep learning in public. MonkeOS feels like that kind of project now. Whatever shape it takes in another year or another five, it already says something valuable about its creator: David Dull, Coops, kept choosing to understand the machine more deeply instead of settling for the first layer that happened to work.
Eight years of OSDev is not merely a timeline. It is a pattern of refusal. Refusal to stop at boot. Refusal to accept fake smoothness. Refusal to confuse a marker file with a real runtime. Refusal to hide build complexity behind mystery. Refusal to let the desktop remain a screenshot. Refusal to let architecture stop at one machine when another architecture is interesting enough to emulate. That is the kind of refusal that eventually builds a body of work.