OpenRC & Open Source

The shoulders of giants · April 14, 2020

I truly love working in the Open Source community. It is populated by such a motley crew of people, who bring their own unique perspectives to a shared goal. And there's always something to learn, be it from someone with more experience or less. I've had two wonderful examples of this happen over the last couple of days.

As I've alluded to this before, I'm the package maintainer for SBCL in Alpine Linux. What this means is that I spend a whole lot of time running build tests through CI for changes that look like pkgrel=2.0.3, at least that's what I'd like to say. The fact of the matter is that there's a whole lot of behind the scenes research, manual build testing, and code review that goes into it. Even with a project as large and well developed as SBCL, when you're porting to a non-glibc based OS your overhead goes up drastically. So much so, that I don't personally believe that I would be able to continue maintaining SBCL by myself, I'm not currently doing so as it stands.

Rather I feel like I'm standing on the shoulders of giants.

When I first took over maintenance of SBCL, it was failing to compile using CLISP. I was able to, after weeks of research, piece together a fix for it. I was proud, I raved about it to my friends, and I felt like the smartest guy in the world. Then it broke on the next release, and the next, eventually I couldn't get it to build at all. I was months behind the release cadence that SBCL keeps to, and the package was woefully out of date due to my own shortcomings. If you look in Alpine right now, we're on version 2.0.1 with a pending update to 2.0.3 this month. None of that would have been possible without the open source giants that I stand on.

The author of the patches that allow me to build SBCL currently for x86_64, armv7, and aarch64 come from Eric Timmons. MIT educated, working to get SBCL working on musl libc so that he can meet bandwidth constraints for used underwater robotics projects. Truly an impressive mind. His patches allow SBCL to build correctly using ECL on musl libc systems. For aarch64 Douglas Katzman (a Lisp dev with Google) has rewritten the FRLOCK handling in SBCL that has caused issues for years, and has provided detailed historical documentation resources, as well as in line source documentation, making the entire change accessible to anyone that wishes to understand it. While only a couple of examples, these are two earth shattering changes that would have been a hard stop for me. I'm still learning. I wouldn't consider myself green, but I'm not MIT educated, and I've never had so much as an interview with Google. These giants allow me their knowledge and consul freely and willingly. I've spoken with both of them when I've run into issues, and they've both taken time out of their work/lives to suggest fixes. While I might not be able to rewrite FRLOCK implementation, I can still contribute, because open source is a collaborative effort. We're all working towards a collective goal.

I take this attitude in all of the interactions I have within the open source community. When someone asks a question, even if I only know part of the answer, I offer them a suggestion. I might only be able to give them a direction, but I want to be the giant that helps raise a fellow developer to a new height. I want to help people learn, and grow, as others have helped me to do.

Just today for example I had someone in the Lapis discord ask about setting up OpenRC services, something I have plenty of experience doing thanks to the project I'm working on for KlockWork Systems, LLC. Despite trying to get my SBCL 2.0.3 merge approved, I took the time to make a suggestion, share some source code, and even help find a solution to their problem. I don't consider myself to be a "giant", but my knowledge is as freely his as Douglas or Eric have made theirs to me.

In that same vein of thought, I ended up learning something myself while helping. In OpenRC you can denote a directory to run a service from with a simple -d argument, this is the equivalent of SystemD's WorkingDirectory. The lapis server RC script we wrote together is:

#!/sbin/openrc-run
description="Lapis Server"

start () {
      ebegin "Starting $RC_SVCNAME"
      start-stop-daemon --start --make-pidfile --background --pidfile /run/$RC_SVCNAME.pid -d /var/www --exec lapis server production
      eend $?
}

stop () {
     ebegin "Stopping $RC_SVCNAME"
     start-stop-daemon --stop --pidfile /run/$RC_SVCNAME.pid
     eend $?
}
 

Chances are, this little script will become the basis of the RC script that ends up being pushed to Alpine when I package Lapis. In the end, you don't need to work at Google, or have an MIT education, to contribute freely and stand alongside the giants you admire. The egalitarianism afforded by the open source community means I can raise myself to those heights, so long as I'm willing to raise others alongside me.