BSD | I Need An OS | Projects
I Need An OS – Part 3
In The Last Episode
- In Part 2, I laid out the battlefield. Picking a donor OS wasn’t about finding something perfect—it was about finding something usable, malleable, and not already tied down by assumptions or baggage. I wanted a clean slate without having to start at BIOS and claw my way up.
- So, I defined the criteria: small community (less noise, more clarity), no entrenched niche (I’m not fighting the design choices of a server OS or an IoT toy), and minimal cruft (I shouldn’t have to rip out half the filesystem just to get started). With that in mind, I ran through a shortlist of potential candidates: MidnightBSD, OpenIndiana, and even the wonderfully oddball Plan9. All worthy in their own ways—but each fell short for the kind of workstation OS I want to build.
- In the end, I picked DragonFlyBSD. It’s clean. It’s capable. It’s not trying to be everything to everyone. More importantly, it has the technical ceiling I need without the ideological floor I’d have to smash through. It’s an interesting system that feels like it’s waiting for someone to do something even more interesting with it.
- That something is this project!
Completing The Foundation
- Before any UI gets drawn, before a window system gets picked, and before you even think about clicking something—there’s groundwork. Serious groundwork. Remember, the goal of this project isn’t to create yet another *nix OS, it’s to create MY vision of an ideal workstation OS. DragonFlyBSD is just the core; there rest of the foundation still needs to be fleshed out, before the userland can be built upon it.
- To that end, there are three specific areas that I have identified as primary development targets before being able to start development on userspace components:
- Configuration
- Device Drivers
- Init System
Replacing /etc – Designing a Real Registry
- First up is something UNIX-like systems still stubbornly pretend isn’t a problem: configuration. Scattered text files in
/etc. Personal dotfiles mutated by a decade of one-liners. Environment variables duct-taped to shell scripts. It’s not a system—it’s a scavenger hunt. However, this isn’t a *nix-only problem, it’s been a prevalent issue across the OS spectrum with various platforms attacking the problem in various ways. - So far, the most successful GUI’d platforms are from Apple and Microsoft. And while I do have a strong appreciation for Mac OS X (not to be confused with the modern macOS), I’m going to take a page out of Microsoft’s book for this project. What I need is a registry. Yes, that registry. No –I don’t mean the exact same implementation, I mean the same basic premise. There are many ways to achieve this, and I have a few ideas of how to do it without massively disturbing the DFBSD core of this project. I’ll go into more detail in a future entry in this series. Suffice it to say that key goals include creating something that can be queried, cached, backed up, snapshotted—and doesn’t fall apart the moment a script forgets a space.
- A structured configuration service isn’t a luxury—it’s a prerequisite. Without it, there’s no reliable way to introspect the system, no foundation to build modern tooling on top of, and no clean interface between system layers. So I’m building it. From scratch. Spec, design, implementation. It has to happen before anything else can.
Drivers Without the Baggage
- With configuration locked down, the next foundational fracture is hardware abstraction. Drivers.
- DragonFlyBSD’s driver model is tidy compared to Linux’s sprawl—but it’s still stitched together with historical assumptions and ancient C macros. I’m not interested in dragging legacy scaffolding into the future.
- What I want is modularity. Discoverability. Composability. Drivers shouldn’t just exist—they should be described. Loadable on demand, matchable by metadata, configurable through the registry, hot-pluggable without hand-holding.
- Think less “dlopen a blob of kernel glue” and more “publish a capability graph.” Haiku is doing interesting things here. So did Apple’s IOKit, if you strip out the Objective-C and vendor lock-in. I’m pulling inspiration from both—and going a little further.
- This means rethinking the whole device model: how drivers announce themselves, how they negotiate resources, how they fail gracefully, and how userspace finds out any of this happened. No more sysctl spelunking just to figure out if your GPU showed up.
- The point is: a driver isn’t a file. It’s a contract. And I want a system that treats it like one.
Rethinking Boot – The Init System That Deserves This Stack
- Once the registry exists and the driver model’s sane, you need a conductor. Something that brings the system online. Something that understands how services start, how dependencies work, and how to say, “Stop, reset, and try again.”
- launchd, for all its quirks, had the right shape. It treated services as first-class citizens. It could be queried. It could express ordering, state, and readiness without fourteen shell scripts and a goat sacrifice. However, launchd is heavily dependent on features available in Darwin. It’s not my intention to spend years working on porting an init system to this project, so launchd would not be suitable here.
- Currently, OpenRC seems to be the best candidate available. It’s already been used in BSD projects, has a suitable license, and would not require an extensive amount of porting. However, there modifications WILL be required here. Since “/etc/rc*” won’t exist, OpenRC will require the ability to interact with the registry. I’m sure that there’ll be more details to worry about, but this is a great starting point.
Conclusion
- These are the parts that users never see. The foundation under the OS. The pieces that, when done right, nobody talks about—because they never break, they never confuse, and they make everything above them feel solid. Invisible, until they aren’t.
- UI comes later. But this is the real shape of the OS. It starts here.