Porting launchd to FreeBSD — and why FreeNAS Corral is next.
I've always been a software guy. Looking back, I think of my time with software as a series of phases. From 1994 to 2004, I learned to appreciate good software design. From 2004 to 2013, I learned to appreciate open source. From 2013 to 2022, I leveraged open source as a way to further my career.
From 2022 onward, AI empowered me to learn programming — and to understand what source code was actually doing — at a far faster rate, which gave me entirely new skill sets. I'd participated in projects and contributed to them before, but until now I'd never had the experience of being in the driver's seat.
It's as if I went from the 2nd or 3rd floor of development up to the 50th, with a team of engineers sitting at my keyboard. All of those ideas, all of those things I wanted to do but never could — now I could do them. It's a whole new level of freedom to make the result whatever I want it to be.
Until recently, I'd never gone all-in on vibe coding. I've always been diligent about learning what the code was doing, even when that meant reimplementing it from scratch. In my mind, I couldn't in good conscience contribute something I had no ability to follow up on and support.
Where I have vibe coded recently, I made every effort to let Claude commit the code itself, so that it would be obvious and transparent. I have no intention of contributing vibe-coded work anywhere, or of letting anyone think I'm capable of things I'm not. I simply want a solution to exist. I am not capable of writing a kernel module. I am capable of learning to understand what a kernel module is, and what its different components do at a high level. I can ask my team of engineers to write it for me and produce the result I want.
A few months back, in a GNUstep monthly meeting, someone raised the idea that GNUstep may have originally been intended as the desktop for the GNU operating system. That led me to recall that GNU Hurd — like Mac OS X — was also designed around a microkernel rather than a monolithic one. It re-invigorated my interest in Mach IPC for FreeBSD, which led me down a rabbit hole of watching old videos from 2014 of Jordan Hubbard discussing porting Mach IPC and launchd to FreeBSD. I've always thought history would have played out a lot differently had FreeBSD adopted launchd.
So I started with some Claude plans, and decided to put together a sockets version first. I thought, okay, this works well — but why let the experimenting stop there? I put together dozens of plans, and I have to admit it was absolutely thrilling to learn the inner workings of how things fit together, and to learn them fast.
Then I made a brand-new repo, built a Mach kernel module, and started a fresh port. What I ended up with is a standalone kernel module that in no way touches the kernel itself — which I think may set it apart from previous efforts. I was, however, inspired to build on some of the work that ravynOS started, a project that has always interested me, and which I believe inherited some of its lineage from NextBSD.
This whole time, I haven't only been thinking about what a Gershwin desktop environment image would feel like with launchd on FreeBSD. I've also been thinking about another project that once intended to use launchd: FreeNAS 10 "Corral."
Back to Jordan's video. I'm paraphrasing from memory here, but the idea that stuck with me was something like this:
Making your software open source means it doesn't have to die when you change jobs, or when the company folds.
So it's been on my mind, more and more, that maybe I should do something with Corral. I've created a "cowsurgery" organization — a tribute to the cow-surgery ASCII art from the CLI that I appreciated so much — and I'm also really interested in digging back into some of those task dispatching concepts.
Why am I doing this? It's fun. It's interesting. I think I can make something really good out of it, something that feels right. And it's exciting to finally be empowered enough to do it.