NiceBSD Dev Diary 2015-02-24

So this morning I found out that the NiceBSD.org domain was expiring. I had cancelled the auto-renew several months ago (with a bunch of other unused domains), at the time figuring the project to be too ‘out-there’ to get any interest. I like to bounce new ideas off folks, as I don’t want to spend time working on software that no one else will use, and also I find having a few cheerleaders at the start can help you through the moments of doubt that normally would snuff out a project. Fortunate for NiceBSD, I got some interest from my coworker Anthony yesterday. We had been talking about the need for simplicity and eliminating incidental complexity, and that’s when I surfaced NiceBSD to show.

I sat down with a cup of coffee, and started thinking about what Alan Kay had been talking about in Is it really “Complex”? Or did we just make it “Complicated” (Alan Kay) and wondered whether going to a ‘cleaner C’ like Go would necessarily address the problem that had prompted me to think up the NiceBSD technical goals in the first place.

So let’s review the needs that prompted the goals:

The size of modern “production-quality” operating systems has gotten to the point that few people have read the source code in entirely. Bugs like Heartbleed and the recent NTP vulns occur when the codebase becomes so large that manual code review is no longer possible (not to detract from automated bug-finding and the use of fuzzers).
Despite the earnest intentions of the GPL, because of its ‘viral’ nature (especially with GPL3), companies write their own alternatives to avoid GPL headaches. What a waste of human potential doing unnecessary re-writes.
I don’t want to create another toy. The internet is littered with toy operating systems (they might work, but are maintained by fewer than 20 people), and I’m not interested in an academic plaything. I want something I can do real work with, that I can reason about, and that won’t make me want to jab forks into my eyeballs.
I want to work with a system that has a rapid feedback loop.

Time has passed, I’ve had the benefit of several years of looking at various projects, and more time to let my mind stew on the subject.

Instead of Go, use Lisp. It’s simple, and will help with succinctness. I’m not overly concerned about the speed of the system at the start, just that it is correct and the LOC count is small.
And when I say Lisp, I mean Lisp everywhere. Not just the core userland, but the kernel level code as well. There are a few projects that have caught my eye, Mezzano being chief among them. Right now, there’s no ‘unified’ code base that pulls together everything needed for a modern system, and even then, there’s a great deal of modern OS functionality that will need to be built (e.g. security policy framework, firewall)
Code re-use will be primarily through the use of Quicklisp, the current ‘mainstream’ Lisp package manager. Wherever possible, userland should be thin application layer over robust libraries.
However, this doesn’t mean abandoning the work that FreeBSD/NetBSD/OpenBSD have done. There’s no shortage of valuable insights (and code to look at!) in these projects. As the culture guideline states: “Rather than see other OS’s and distributions as competitors, we see them as examples from which we can learn.”

So work on NiceBSD is actually starting to happen, though I don’t imagine fruits for another few months. I’ll keep up this dev diary so you’ll know if I’m still working on this or not, and I’ll try to have some sort of initial code tree up as soon as I have something beyond “I put these two projects in the same git repo”

I’ve started making a more-detailed milestone roadmap, based on my initial skimming of the Mezzano code base, and working on getting it building on my laptop. The first milestone is a build system that should ‘just work’ for newcomers. There’s already work on a patch in the Mezzano PR’s with a Makefile, though there’s a long road before the build system is nice and clean. I’m already questioning the need of using Make (everything else is Lisp, why stop here?), and I’m thinking of a better way of dealing with the build dependencies. After I’ve played with it a bit, I’ll also look into the possibility of separating out the graphical code in the build process, so that there’s an even smaller non-graphical ‘base’ that can be used for servers.

My timespan for this NiceBSD project is 10 years - if it’s still unusable by 2025, I’ll give up on computers and raise sheep.

A request for any readers - if you know of a Calgary Lisp user group, please send a note my way.