How to Build an OS Without Being a Degenerate

There's a follow-up brewing after that earlier piece calling out r/osdev's wave of QEMU-only Linux reskins with Patreon links bolted on. Instead of just mocking the trend again, the author sat down and wrote the counter-manual: eleven rules for building an OS that actually teaches you something, aimed at the people who asked "okay, so what do I build instead?"

The rules aren't subtle. Label your project honestly instead of calling a weekend prompt session "revolutionary." Don't start from an empty folder — rip a piece out of an existing OS, like a scheduler or filesystem, and rebuild it while the rest of the system judges your work in real time. The author points to FreeBSD Device Drivers, a book that took roughly 200 days to finish, as proof that reading slowly is the actual work, not a delay before it. There's also a hardware argument: buy a used ThinkPad for forty dollars and test there, the way the MOROS OS creator did for five years before getting DOOM running on real silicon, because emulators are too polite to expose the bugs that real firmware throws at you.

Some of the sharpest rules are about drivers and language. Almost none of the OS clones flagged in the original audit had WiFi or Bluetooth support, because framebuffer-style hobby kernels let the host machine solve every hard problem already. Writing one real driver, even by adapting an existing open-source one, teaches interrupts and DMA in a way that forking a whole kernel never will. And there's a vocabulary correction buried in here too: implementing exFAT in Rust is still implementing Microsoft's spec, not inventing a filesystem, and the MOROS creator gets credit for saying he "ported" DOOM instead of claiming he built it.

The AI-skepticism thread runs through everything without being preachy about it. The author treats AI models as senior engineers with a lying problem — useful for explaining PIC versus APIC, dangerous the moment you ask one to generate a finished roadmap, because it'll happily invent PCMCIA support or write garbage into a VGA buffer with total confidence. There's a personal anecdote where GPT-4o kept insisting a chip in the author's own inventory lacked USB support and re-corrected the database back to wrong every time it was fixed. The same confident wrongness, the piece argues, is exactly what you don't want deciding whether your OS's APIC handling is correct.

The closing message is almost anti-viral by design: no donation links unless you're doing genuinely hardware-liberating work like Asahi Linux, keep a private OS if releasing it would be reckless, and pick one subsystem to actually master instead of shipping ten shallow ones. The author's own example is GaslightOS, a stripped-down Android build for a Fairphone 5 that never touched an emulator and never got released, because unlocking those bootloaders permanently blows a fuse. Depth, not a GitHub star count, is the entire point.