May 26, 2016
Faces of FreeBSD
Back by popular demand, we’re again sharing a story from someone involved in FreeBSD with our Faces of FreeBSD series. It may be a story from someone who’s received funding from us to work on development projects, run conferences, travel to conferences, or advocate for FreeBSD. Or, it may be from someone who gives back to FreeBSD financially or in another way. Regardless, it is always from someone who is making a positive difference in the FreeBSD world.
Here’s a chance to get to know your fellow FreeBSD enthusiasts. Sit back and enjoy the next 2016 Faces of FreeBSD story.
Michael’s Story
My name is Michael W Lucas. I’m originally from Rochester, Michigan, USA, a little farm town outside Detroit, Michigan. As a kid, I’d bike past the grain elevator and see the great big pallets of Purina Monkey Chow next to the train tracks. When I asked my dad about them, he sent me out into the woods and fields to find the monkey farm.
There really was a monkey farm. It was a mile east of town, inside one of the many buildings comprising the Parke-Davis pharmaceutical research lab. Inside a ten-foot fence, topped with tetanus-laced barbed wire. Armed guards patrolled the fence, presumably to keep the monkeys from seizing the lab and sparking the revolution.
Dad knew this perfectly well. But telling me would have spoiled his fun.
Naturally, I drifted into systems administration. It’s in my genes.
And I found FreeBSD because it let me sleep.
In 1995, the National Science Foundation handed the Internet over to commercial entities, and said “here–see if you can do something with this.” Internet backbones were hiring people as fast as they could find them. I gave up my secure but low-paying gig as a university library book cataloger to make something of myself in the exciting Internet industry.
Or maybe it was because I could work nights, and my friend Amanda insisted that nobody would bug me after 1 AM. I forget which.
Experienced systems administrators were hard to find in Detroit in 1995. So were inexperienced ones. My new employer, who provided backbone connectivity and transit to Internet Service Providers, took people with “potential” and threw them in the deep end, making them responsible for systems they weren’t really qualified to run.
You either swam, or you sank.
I lived in a flat on the border between Grosse Pointe Woods and Detroit. The people behind me drove BMWs. The front of the building had bullet scars. I had no idea how to get one of those fancy cars, but was very much aware of exactly what happened when you sank.
So I felt motivated to learn as fast as I could. I did well enough to become the backup DNS admin, and learned how to edit zone files and mangle named.boot.
I came in at 11 PM one night and was told “The DNS administrator just got walked out the door. You’re the new lead DNS administrator. Make those servers work. Good luck.”
Working nights has many things to recommend it. You get long stretches of time to focus on projects, like figuring out how the IP stack works or really mastering Minesweeper.
But when you’re the lead on a service, especially a vital service like DNS, people who work during those miserable hours when the Sun burns overhead have no problem calling you during the day.
The SCO UnixWare master DNS server kept randomly and unpredictably dying. The Solaris one screamed in agony every six hours, but that was easily fixed with a cron job to reboot it every three. And the caching nameservers, that ran everything from SunOS to Windows NT? Nothing could handle the load we put on the equipment.
And every time the phone rang at some obscene hour, like eleven AM, I grew more motivated to fix things. And a little more short on sleep.
One day, the Usenet administrator said “Here, I’m having good luck with this” and handed me a FreeBSD CD–either 2.0.5 or 2.1, I forget which. Hallucinatory from lack of uninterrupted sleep, I tried it on a client-facing DNS server in the office, figuring it couldn’t be any worse than the screaming nightmare it replaced. I ran through the default install, enabled a caching DNS server, and stumbled home, hoping it would hold together for a couple hours so I could get a nap.
The phone didn’t ring until almost three PM. The UnixWare box had soiled itself again.
But somehow, through some miracle, that experimental FreeBSD box had held together. I was pretty sure it had died and nobody had bothered to tell me, but when I got to work I saw it was still running, still answering queries.
“This can’t last,” I told myself. I decided to come back every hour or so to check on it, morbidly curious about exactly how it would scream and die. I expected that any server that could keep running this long would fail in a new and interesting manner.
At 7 AM, though, right before I was due to go home… the thing was still running. And answering queries.
Weird.
“Reboot it!” I thought. “It’s been over twenty-four hours, there’s no way FreeBSD can hold together for another day! No, wait–don’t touch it. Something magical is happening here, and if I even breathe on the system it’ll start crashing like everything else. No, you’re being silly, reboot it!”
I left the FreeBSD host running. Just to see what would happen.
The call came at ten AM. The Solaris box refused to boot, even after a right good kicking.
I put a FreeBSD server in its place.
And the rest, as they say, is history.
Eventually, I became a FreeBSD doc committer. I eventually let that access expire in favor of writing books. Lots of people can write and improve docs, but not so many want to write books. I’ve just completed a set of four FreeBSD storage books (two co-written with Allan Jude), and I’m happy with how they came out. The “FreeBSD Mastery: Advanced ZFS” tome is the most complicated, brain-stretching book I’ve ever written. My forthcoming PAM book certainly covers FreeBSD. And people keep telling me that “Absolute FreeBSD” is a classic. (As classics go, I’d vote for Joyce’s “Ulysses” or Pynchon’s “Gravity’s Rainbow” or something like that, but whatever.)
Book projects bring me into contact with a whole bunch of the FreeBSD community. Most everyone’s generous with their time, and happy to correct my work before it make it to print. Occasionally a developer even says “Wait–that’s what it does? Hold on, that’s not right, let me fix that before you publish!” Making other people work harder gives me a warm fuzzy feeling, so everybody wins.
The world has changed in the last 21 years. Rochester’s not much of a farm town any more–it’s grown five-star hotels and boutiques and great big houses. I’ve forgiven Amanda for getting me my first Internet job. And FreeBSD’s no longer a few guys releasing stuff on the Internet, either–it’s a whole bunch of people.
FreeBSD has had a whole bunch of different corporate backers over the years. But corporations have this distressing tendency to collapse, get sold, fold into other businesses, or change their core competency to hamster ranching. Now there’s a FreeBSD Foundation, specifically dedicated to soliciting support for the project and directing resources to developing badly-needed features.
When I published my first FreeBSD article in Sys Admin magazine back in the late 1990s, FreeBSD in the press was rare. Now, there’s a very successful FreeBSD Journal.
In the 1990s, there wasn’t much of a possibility that people would actually meet in person unless it was by coincidence, at USENIX or LISA or something like that. Today we have BSDCan in Ottawa, AsiaBSDCon in Tokyo, and EuroBSDCon in some random European city, plus an assortment of developer summits like BSDCam, all sponsored by the FreeBSD Foundation.
Weirdly, all these conferences welcome me.
Maybe because I don’t send anyone looking for the monkey farm. There’s one just outside Ottawa, in case you’re curious…