Date Category Blog

I originally picked up this domain two years ago over drinks with one of my best friends, @grembo, but at the time wasn't even sure what to do with it.

After working a few days on a simple project at work, using daemontools by @hashbreaker to run a little report delivery system, a seed formed in my brain; that seed just sprouted with the arrival of my domain renewal.

For myself, I need a project. Something ambitious, but simple enough that I can envision it clearly and make reasonable progress on in my spare time. For the rest of the BSD community, the writing’s been on the wall for init for some time, now.

It’s not that I have a problem with BSD init: it's that everyone else keeps trying to replace sysvinit with worse results, possibly due to the failures of coding by committee. Hence event.d, systemd, launchd — these and other init replacements are clearly trying to solve a problem. One that adopting or rewriting BSD init clearly doesn't solve. In the case of systemd, it sounds like it may be trying to solve many problems all at once.

This is bound to fail.

Getting To It

The Unix philosophy is why it survives: for every program, do. One. Thing. Do that one thing well, and then build up lots of things that do one thing well, and which can opt to work together.

So I have a project in mind, direct in its goal and ambitious in scope: building on daemontools, I’ll fork FreeBSD, and work on a scheduler to replace init.

After that, maybe I'll have other changes: jail sandboxing for all new server software by default? Replace the default shell with something ridiculous? No one cares, least of all me. I have a goal now, and that’s my only plan. Replace init with something that solves the same problems these other, larger replacements already fix; replace BSD init with something equally as small in design and in code as we expect from any Unix utility. But replace it primarily with svscan, or something close to it.

Thankfully, I don't really feel a need to justify why I'm doing this beyond finding it an interesting problem.

Outline

  1. Research the hell out of this and gather a list of the actual problems that init faces and wasn't designed to handle. Expect links to arguments and my uninformed, (often off the mark) commentary.
  2. Poke and prod at the daemontools code base to see what might be tweaked, or learned from.
  3. Poke and prod at FreeBSD's kernel to see where init can be excised, and what the needs are first for replacing it.
  4. Rough idea, subject to revision: replacement can be svscan, with a modification to authenticate requests to run, and in the order defined by the requesting processes. Why? Because this smells right to me, based on some personal philosophical leanings.

Side notes

I’ll keep track of my progress here, point by point.

That’s all.