How to Build an OS Without Being a Degenerate

This morning I published The Framebuffer People, about cloning every OS posted to r/osdev and finding a pile of QEMU-shaped Linux reskins with Patreon buttons. The thread had two kinds of replies. The loud kind called me a gatekeeper. The quiet kind asked a real question: “Another way to look at it. Give me a suggestion. What do I build?”

In the thread I answered that I can’t answer, and that is half true. Nobody can tell you which part of an OS will grab you. But there is a path that produces understanding and a path that produces a README with a roadmap hallucinated by a model. Here is the first path, written down properly.

Rule 1: Label the Tin¶

Before the first line of code, decide what you are actually doing and write it on the repo.

“This is a toy OS. I am using this purely to learn” is a complete defense. Nobody serious has ever attacked a project labeled like that, and nobody attacked the ones in the thread that said it. The problems start when a weekend of prompting ships with a feature list longer than the Star Wars intro, a Ko-fi link, and the word “revolutionary.”

Linus labeled his tin in 1991: “just a hobby, won’t be big and professional like gnu.” That sentence has outlived every project that claimed the opposite.

Rule 2: Do Surgery on a Real OS¶

The advice nobody wants to hear: don’t start from an empty folder.

Take an established OS. Delete a part of it. Now rebuild that part with the rest of the system watching you. The scheduler, the allocator, a filesystem, the pipe implementation. Anything.

This works because a real OS is a hostile reviewer that never gets tired. Your rebuilt component either survives contact with millions of lines of battle-tested assumptions or it doesn’t. There is no “works on my emulator.” And the outcomes are all wins:

• Your version is objectively better: congratulations, upstream it. You are now an OS developer by the only definition that matters.
• Your version is slower: you have a benchmark and a teacher, and you get to find out why theirs is faster. That “why” is worth more than a finished hobby kernel.

When you are the dictator of your own empty repo, every decision is correct by default. You learn nothing from a system that cannot push back. That is vibing with extra steps.

Rule 3: Read at the Speed of Paper¶

I finished FreeBSD Device Drivers a few days ago. It took around 200 days, which is what I estimated when I opened it. That number is the point.

Two hundred days of reading before touching a subsystem sounds insane to someone whose model finishes its turn in forty seconds. But the reading was never a tax on the work. The reading is the work. The typing at the end is a receipt.

Your stack: the hardware specs, the OSDev wiki including the Beginner Mistakes page that predicted this whole mess years ago, and at least one real book read cover to cover. If you cannot budget days of reading, budget zero days of announcing.

Rule 4: Buy the ThinkPad Before the Domain¶

The MOROS method, and it costs less than a year of your domain renewal.

The author of MOROS got things working in QEMU, then bought cheap old hardware to test against, then bought a few more cards specifically to make sure his code was generic instead of accidentally married to one device, then walked it across multiple generations of ThinkPads. Five years later, DOOM runs on his OS on real silicon.

A used ThinkPad is forty dollars. It will find bugs QEMU is structurally incapable of showing you: the timing quirks, the firmware lies, the device that violates its own spec. Every hour spent against real hardware is worth ten against the emulator, because the emulator was written to be reasonable and hardware was written to ship before Christmas.

Your OS should meet metal before it meets the public. The order of operations for the degenerate path is website, Discord, logo, QEMU screenshot, funding link. Reverse it entirely and delete the last one.

Rule 5: Write One Driver¶

Here is the open secret from the audit: what the hobby OS world is missing is drivers. Nobody writes them, because everyone lives in a framebuffer where the hard problems are pre-solved by the host.

So write one. A real NIC, a USB controller with actual EHCI or XHCI instead of “contributions welcome,” a WiFi chip. Not one OS posted to that subreddit has a WiFi or Bluetooth stack. The first hobbyist who ships one will have done something the ten thousand framebuffer shells combined have not.

And nobody is asking you to reverse-engineer an NVIDIA GPU from thermal noise. Vendors publish open source drivers. Take one, adapt it, credit it. Adapting a driver to your kernel is honest work and teaches you the bus, the interrupts, the DMA, the power states. Forking a whole kernel and renaming the variables teaches you find-and-replace.

A driver merged into Linux or a BSD outweighs any solo kernel, because your code now runs on machines you will never see, maintained by people who will read every line. That is the real multiplayer mode.

Rule 6: Say “Implemented,” Save “Invented”¶

exFAT written in Rust is still exFAT. It is Microsoft’s spec, and you implemented it, which is respectable engineering and most of what real engineering is. The degeneracy starts at the press release, when “I implemented a FAT driver” becomes “I authored a filesystem.”

The MOROS author says he “ported” DOOM. One word, exactly honest. Use his dictionary. You implement specs, you port software, you adapt drivers, and if one day you genuinely invent something, the word will be available because you didn’t spend it on a CRC32 function.

Rule 7: Treat AI Like a Senior You Don’t Trust¶

I am writing this next to an AI. The tool is fine. Here is the usage boundary.

Ask it to explain the difference between the PIC and the APIC. Ask it why your page fault handler double-faults. Argue with it about your VFS design. In every one of these, you are the one holding the model, and you verify against the spec, because it will hallucinate a register with total confidence.

What you do not do is type “make it perfect” and accept the todo list. I watched that produce roadmaps with PCMCIA support and Motorola modems, and an A20 line stub that tried three known methods and then started writing random words into the VGA buffer. Harmless in QEMU. On old real hardware, potentially permanent.

The rule in one line: AI can answer your questions, but it cannot do your confusion for you. The confusion was the curriculum.

A story from my own inventory. Back when GPT-4o was still around, I used it to sort my chip collection. It was 100% sure one of my chips had no USB capability. The chip has USB capability. And every time I re-swept the inventory, the model detected the same “problem” and helpfully removed the chip from the USB list again. My own database, corrected into being wrong, on a schedule. I wrote about this failure mode in 57 Is Actually 15: How LLMs Gaslight Their Own Tools. Now imagine that same confident wrongness deciding whether your hardware has an APIC.

Rule 8: No Begging¶

No Ko-fi. No Patreon. No sponsor button.

One exception: liberation stacks. Asahi Linux putting a real OS on locked Apple Silicon. The people cracking open the Switch, the PlayStation, the tractors. That work is a research lab: it burns retail hardware by the shelf, fights lawyers and lockdowns, and produces freedom that everyone downstream inherits. Fund those people generously.

Learning how to blink a pixel on a screen needs no funding. QEMU is free, the wiki is free, the ThinkPad is forty dollars. For perspective, ReactOS has been grinding since 1998 and Redox has a decade of serious Rust kernel work, and both barely fill the donation jar. GhostBSD ships a complete desktop operating system that people use daily, and it scrapes together about 1000 CAD a month. If they can’t, your roadmap won’t. Build because you want to build.

Rule 9: You Are Allowed to Keep It Private¶

My credentials for this entire sermon: I am a FreeBSD and DragonFly contributor, I have commits in the Linux kernel, and I use all of them daily. And I built an OS you will never see.

In 2024 I made GaslightOS, by Rule 2: I stripped the Android codebase down until it ran on exactly the hardware I own, a Fairphone 5 and a Samsung tablet. It never touched QEMU. It booted metal from day one, because the metal was the point. One user, two devices, no website, no Discord, no donation link. Deleting Android’s plumbing taught me more about why it exists than any tutorial could, which is the whole method: you learn what a subsystem does by watching what breaks when you remove it.

I never released it. Installing an alternative OS on those devices means blowing fuses. You unlock the bootloader, an efuse trips permanently, and there is no undo. The OS is fun. A tutorial that walks a kid into fusing their parents’ tablet is the opposite of fun. So it stays mine, and that decision is also part of OS development: knowing what your release would actually do once it leaves your hands.

Notice the inversion. The framebuffer people release everything and learned nothing. You can learn everything and release nothing. Of the two, only one needs a Discord server.

Rule 10: Get a Team, and Make Sure It Argues¶

An operating system takes years and a team. Every real kernel is a pile of arguments that reached a decision: mailing list fights, rejected patches, maintainers saying no to code that took someone months. That friction is the review process working. Linux is what disagreement looks like after thirty years of compounding.

So here is the diagnostic: if your team always agrees with you, you don’t have a team. You have an audience. The promotion circles in that subreddit, everyone upvoting everyone’s revolutionary OS like an MLM downline, are teams that always agree. And the model in your terminal is the most agreeable teammate ever built. “You’re absolutely right” is a compliment, and code review is the art of hearing the opposite.

One person who will tell you your VFS design is wrong, and can say why, is worth more than a Discord server of a thousand members. If nobody around your project has ever made you rewrite something, nobody around your project is looking at it.

Rule 11: Pick One Lane¶

The reason Rule 10 exists: you cannot be good at everything. Nobody is. In real OS teams, the person who lives in the storage stack does not write the WiFi driver, and the greybeard who scares everyone on the scheduler mailing list got that way by spending fifteen years on scheduling and almost nothing else. Filesystems, network stacks, graphics, memory management: each of these is a career, and the people who advanced them picked one.

The framebuffer people run the inversion. The feature list covers everything and the mastery covers nothing, because a model will happily generate all ten subsystems for you, badly, in one afternoon. Breadth is exactly what AI made free, which means breadth is now worthless as a signal. Depth is what it cannot fake for you, so depth is the entire remaining game.

So pick the lane that grabbed you during the Rule 2 surgery and stay in it until people start asking you the questions. One deeply understood subsystem makes you welcome on any kernel team on Earth. Ten shallow ones make you a README.

The Flowchart¶

flowchart TD
    A[I want to post my OS] --> B{Is the tin labeled honestly?}
    B -- No --> Z[Do not post. Fix the README first.]
    B -- Yes --> C{Does it boot on real hardware?}
    C -- Yes --> G[Post it. Include the hardware list.]
    C -- No --> D{Does the post say QEMU-only, clearly?}
    D -- No --> Z
    D -- Yes --> E{Is there a funding link?}
    E -- Yes --> Z
    E -- No --> F{Did you write the code you claim you wrote?}
    F -- Yes --> G
    F -- No --> Z

Four questions. The framebuffer people fail three of them, and the fourth one is the README.

The Short Version¶

Label the tin. Rebuild a piece of a real OS instead of ruling an empty repo. Read for months without apologizing for it. Put it on a forty dollar ThinkPad before you put it on the internet. Write one real driver. Use the word “implemented.” Keep the AI as an advisor with a fact-checking problem. No begging, unless you are liberating locked hardware. Find people who argue with you, and keep the one who makes you rewrite things. Go deep in one subsystem instead of shallow in ten. And when your OS has finished teaching you, you are allowed to keep it, quietly, for yourself.

Do all that and post your project anywhere you want, including under my posts. That is a thread I will read with pleasure, and metal will have already done the moderation.