I Need An OS – Part 2

In The Last Episode

I kicked off this journey with a simple realization: I need a workstation OS that doesn’t suck. More than that—I need one that actually works for me. I laid out the problem: most OS options out there are either too bloated, too fragile, or just don’t align with how I want to get things done. I’m not interested in rehashing another Linux distro or battling config files in the name of “freedom.” I want stability, usability, and zero nonsense between me and getting actual work done.

So, I outlined what this mythical OS would look like. It needs full hardware support out of the box, a sensible and polished desktop environment (Enlightenment or something like OS/2’s Workplace Shell came up), and no tolerance for config file hell—I’d rather have something like the Windows Registry than a graveyard of dotfiles or cfg files or dotconf files.

Since nothing quite like that exists in one package, I accepted the inevitable: I’ll have to build it. I don’t mean starting from bare metal—I’m not writing a kernel from scratch—but I’ll need to find a solid donor OS, tear it apart, and reshape it into something that fits. I’ll be leaning into LLVM over GCC, skipping Linux entirely, and keeping the scope focused: one desktop, one goal—get out of my way and let me work.

That was Part 1. Now, let’s dig into what happens next.

The Runner-Ups…

Before I tell you which OS I’m going to use, let me tell you more about what I was looking for. Afterwards, I’ll tell you which ones were contenders and why they weren’t chosen. So, here’s the list:

• Did not have a huge community.
• Did not already have an obvious target niche.
• Did not have an enormous amount of code and infrastructure that would have to be removed before I could start work in earnest.

First, I was looking for an OS that did not have a huge community behind it. What I’ve found is that if you ask a question about an OS that has a huge community, rather than actually answering your question, they tend to derail the conversation with questions about why you’re trying to do what you’re asking about. They never seem to understand that you’re on a fact-finding mission and that your question wasn’t a RFC. They seem to never be able to actually skip the BS and jump right to the part where they either give you the answer, direct you to someone else who knows the answer, or just refrain from saying anything because they don’t actually know the answer nor where to direct you to get it.

Next is OSes that don’t already have an obvious target niche. For those that do have an obvious, there’s usually a certain level of assumptions that’re made about how the system will be used and what types of environments they’ll be used in. These assumptions usually have a heavy impact on the system’s architecture, which can made development towards a different usecase extremely difficult because of the potential need for extremely invasive code changes.

Last, is really more of the case of me not wanting to sift through a code repository just to cut out a huge amount of prior work. It feels wasteful and extremely disrespectful the all of the developers that have worked on the project. I really just want to either improve or replace a few subsystems to form the base of my project.

The Criteria

I took a few weeks to consider whether or not I should even attempt such a project, before I created this site. During that time, I put a lot of thought into which OSes to even consider as potential donors. In the end, I landed on four contenders.

The first contender was MidnightBSD. If I’m being honest, I have a soft spot for MidnightBSD. Why? Because almost two decades ago, I went down the BSD rabbit hole looking for a BSD system that would be great as a desktop OS. Back then, MidnightBSD was attempting to provide a desktop experience with some basis on Étoilé, which itself is based on GNUstep. Since then, the project has moved on from Étoilé to XFCE and is still working towards providing a great desktop experience. Unfortunately, the installation process and post installation setup were not the most user friendly. In the end, I found it just a little bit rough to use as a starting point. I still consider it to be a great project that’s bound to be perfect for other prospects.

OpenIndiana was the next contender. I’ve used OpenIndiana a few times in the past and found it to be very comfortable. While being a foreign system, I found it to be incredibly consistent and orderly. Back then, I got the feeling that OpenIndiana was a bit too heavy for a standard desktop OS. However, it initially seemed to be a perfect fit as a donor OS. Well, great! Let’s clone the repository and get to work, right? Well, no. In making the transition from OpenSolaris to illumOS to OpenIndiana, the system was ported from the compilation toolchain used by Solaris to GCC. In addition, special tricks and tweaks were necessary to achieve compilation on GCC. Trying to repeat the process by transitioning this project to LLVM and Clang far exceeds the scope of my project.

The last contender was Plan9. I know that this one is an odd choice. The truth is that I’m always trying to find a way to use Plan9 in a project. Unfortunately, this project turned out to not be the one for Plan9. The biggest reason for the rejection is that I see Plan9 as a great OS for a distributed computing environment. In all honesty, I see Plan9 as potentially being the underpinnings of the type os computers envisioned in the Start Trek universe -massively parallel with heavy reliance on filesystem namespaces and user entitlements. In the end, that type of compute environment is simply far too broad for this project. In this particular case, I need to keep things narrowly focused on desktop usage.

And The Donor Is…

After all of that, I eventually chose DragonFlyBSD. The most obvious question is “why?” In short, DragonFlyBSD appears to be the better platform for targeting workstation performance and serious computing. It fits all of my criteria for this project and will be a great vehicle to build my idea of what a workstation OS should be. I’m also incredibly intrigued with the Hammer & Hammer2 filesystems. All in all, it feels light enough to not be a server OS, but heavy enough to do more than standard desktop work.

Conclusion

So, yeah—DragonFlyBSD it is. It doesn’t have the baggage, it doesn’t have the cult-like community behavior, and it doesn’t already have some fixed identity that I’d need to unravel. It’s just a solid, clean, capable OS with a strong foundation and room to grow. More importantly, it gives me the space to experiment without having to unbolt an entire philosophy just to start working.

That said, this is only the beginning. I haven’t even touched the layout restructuring, service model, or the beginnings of the UI layer. That’s all coming. Slowly. Painfully. But coming. The pieces are on the table now, and the board’s set—next step is turning DragonFly into something that’s not just functional, but frictionless. I have no illusions about the scale of what’s ahead, but at least now I know what I’m building on.

And if nothing else, I’ll have learned something. Hopefully something useful. Or at least something weird enough to make the struggle worth it.