Rik Farrow

The Short Version

Rik Farrow was born in Washington, DC, and attended Catholic grade school, and Good Counsel high school, graduating in 1968. He graduated with a BS in Psychology from the University of Maryland, with more than enough credits for a minor in Computer Science. He worked briefly for Altec in Silver Spring, and for North Star Computers in Berkeley, before beginning a long career as a consultant in 1980.

Rik wrote manuals for small computer system hardware, then moved on to writing about Unix. He wrote the Programmer’s Guide to UNIX, working as a ghostwriter, then Unix System Administrator’s Guide to System V (1989), and Unix System Security (1990). He began writing for UNIXWorld Magazine in 1986, and was their Technical Editor from 1989-1994. In 1994, Rik began teaching Internet Security (which was mostly Unix security with networking), something he did until Windows became the more popular choice around 2004. In 1998, Rik began editing one issue a year for USENIX ;login, and became the fulltime editor in 2006. As of December 2020, ;login: as a print magazine has been retired. He still assists with the digital version of ;login:.

Rik still consults, and occasionally speaks. He was the Tutorial Coordinator for USENIX from 2014 until 2018.

Ancient History

I began my computing career in 1968, when I took a FORTRAN course at the University of Maryland. The summer of 1969, I worked as a software librarian for GE in Bethesda, Maryland, where I first encountered a mainframe that could have been running MULTICS. To be honest, I didn’t understand the importance of MULTICS at the time, and was much more impressed with the analog speed gauge attached to the cabinet containing the dual CPUs of this GE645 computer. Typical speed maxed out around .65 million instructions per second. A Rasberry Pi2 does about 900 million instructions per second.

While I had long wondered if this mainframe ran MULTICS, Tom Van Vleck told me that no GE645 in the Bethesda area ever ran MULTICS, and this system was likely running GECOS-III. At least I finally knew where the old name for the comment field in UNIX password entries comes from.

While in college, I majored in Psychology, and worked as a lab assistant. I learned how to teach rats and pigeons, skills I used later in life, for example, to teach my cats to sit on command. I also wrote software for the group of professors I worked for.

When I graduated, the job market was tough–but then, when hasn’t it been tough? I wound up working for the USPS as a clerk, and later as a truck driver, learning how drive semi’s in the Washington DC area. While this job has little to do with my later career focuses, I did learn that people of average intelligence could memorize long lists of addresses or zipcodes, and the carrier or distribution center associated with each. I also got a lot stronger because working at that level for the USPS involved lots of physical activity. On my days off, I would bicycle 20 miles or cut cords of firewood, as I had become accustomed to working hard.

The USPS job eventually became just too boring to continue. I was fortunate that some friends re-introduced me to the world of computer science at that time.

First, Tom Mapp, a psychology grad student, had gone back to U Md to get his Masters in Computer Science. Tom brought me in to the lab, where there were two PDP11’s for the use of students taking the operating system class. Tom showed me the code for handling interrupts, a bit of concurrent programming that I had never heard of before, with the small amount of count needed to handle keystrokes.

My other influence was a bit more subtle. Madison Jones, ex-Marine Sargent, ex-President of the U Md student body (the only non-frat boy to be elected at that time), had asked me if he could store a box of books where I was living, while he traveled around the US. On top of this box of books was a Zilog Z80 manual. The Z80 was an early, eight bit, CPU that competed with Intel’s 8080 CPU. The Z80 ran at 4 MHz, making it a bit slower than the GE MULTICS mainframe I had encountered ten years earlier. With only 16 bits for addressing memory, the Z80 could only directly address 64k of memory, and an additional 256 IO ports, so it was puny in comparison to what the multiprocessor mainframe could do. But it was also cheap enough that people were building their own computers using the Z80.

My roommate, Steve Salzman, worked for ADP at the time, and he knew of some companies who were using the Z80. I visited LSD (Language, Systems, and Development), a company where one of the CS grad students I had met at U Md was working on developing systems software. The second company I visited, Altec, was using the Z80 in an embedded system. I was interviewed on the spot and offered a job, because I could explain how to build a counter out of two J-K flip-flops. I had been taking an computer architecture course and the operating systems course at U Md, which is how a postal employee would have a clue about using simple integrated circuits to count in binary.

Altec built digitizing tables, large plates of frosted glass with a grid of wires expoxied to the underside. The wires were attached to shift registers, and a clock would enable current to flow in several wires at-a-time. The operator of the table would place a photo or diagram on the table, and move a cursor that contained a coil over a spot of interest, press a button, sending a signal to the Z80. Then, a clever phase-lock loop (PLL) would determine which set of wires were under the cursor when the button was pressed, and software running in the Z80 would return X and Y coordinates. Modern digitizing tablets work the same way, as do touchscreens, although our little screens use capacitance instead of magnetism to do their magic.

Altec hired me as a programmer, the assistant to Grant Woods, but they soon had me working in the field, installing tablets and instructing new users. My first cross country trip brought me to Menlo Park, California, to install two tables for the USGS. I visited San Francisco, where Tom Mapp was living, and decided to leave Maryland, which alternated between steamy summers and ice-filled winters, for the more moderate climate of San Francisco.

North Star Computers

I eventually got a job in customer support (1979) at North Star Computers, working for Alan Bowker. Alan taught me about the physical circuitry in the Horizon, and encouraged me to build one from a kit. I bought a kit with my employee discount ($800), and built my own Horizon, which I used for many years. I later added an eight inch, Fujitsu, hard drive to the Horizon, and sold it to a commune who used the computer to run their grocery home-delivery business for many years. My initial intuition that simple CPUs like the Z80 would revolutionize the world seemed to be coming true.

Working in support for a company that sold both hardware and software, when the entire support team consists of five people, is unlikely to ever be easy. And given that anyone could buy a kit and call us with questions about their problems with the resulting system, it was a stressful job. We were lucky when the probelm was as simple as the computer not being plugged in. Many times, we would listen to the sounds the computer made over the phone, or ask the caller to describe the sounds to us, as the floppy disks were both noisy and slow, and we could diagnose a lot of problems just listening to the sounds during an attempt to boot.

I quit working at North Star before the end of 1979. They were moving the company to San Leandro, from Berkeley, and I would have wound up in a cube farm, instead of a room with a window (even though it faced the railroad tracks at the back of the building). The stress of dealing with an unending series of calls from desperate folks who had little clue about building or using computers had also taken their toll on me.

Self Employed

I began working as a consultant, doing simple programming jobs that involved Horizon computers at first. I helped people integrate other systems, like a gas chromatograph (for Chevron), or a machine-controlled vertical mill, because I understood the simple operating system CP/M, and could patch in other devices. That’s how I managed to add the Fujitsu hard drive to my homebuilt Horizon: I patched in device drivers to CP/M’s primitive file system, mapping the M: drive to the hard driver.

Finding work was hard at first, and I’ve always recommended that anyone who plans on switching to being self-employed both start consulting part-time first, as well as have a large amount of savings to tide them over for the slack times once they quit (or lose) their fulltime jobs.

I’ll be honest with you: working parttime suited me well. I had a difficult time sitting in an office everyday, because while somedays I would be really focused on working, other days I just wanted to be someplace else. I imagine that many people feel this way–but few actually are willing to take the risks that I did by not working fulltime.

I didn’t sit around and wait for people to call me with work. I called people at North Star and Morrow Designs, letting them know I was looking for work. Eventually, a call to Jean Morrow did result in my being asked to revise a manual for the Morrow floppy disk controller board. The current manual was written for the earlier version of the board, which, like North Star’s controller, was memory mapped. In 64K systems, giving up 8K bytes of your memory for a disk controller that only used about 256 bytes of memory was terribly wasteful. George Morrow had the brilliant idea that he could use the Z80’s IO ports instead of memory mapping for the disk controller, and he designed a board to do this. George’s design was also much more flexible than other controllers of the day. There were too many ‘standards’ for floppy disk formats, and George’s controller was flexible enough to handle most of them, including both 5 ¹⁄₄ and 8 inch floppy disks.

I received the old manual as a Wordstar file on a floppy disk (fortunately one my Horizon could read), a working IO-based controller (DJ-IO), and the schematics for the board. I quickly rewrote the manual, but ran into a problem while testing it’s ability to boot my North Star Horizon system. It really shouldn’t matter which disk controller I used, but booting kept failing. I discovered that George had flipped a low-order bit, so the first bytes of the bootstrapping code were written in one place in a ROM, but the hardware was reading a location 16 bytes away. When I showed this to George, he grumped at me, then removed the ROM from the board and burned in the three bytes needed at the address being referenced. A much more elegant solution than doing a hardware patch, changing the board layout, instead just burning in the address needed to jump to the bootstrap.

Morrow allowed me to keep the DJIO, and the 8 inch floppy drive I had been provided with for testing. I really needed the ability to read and write 8 inch floppy drives formatted for CP/M, and the controller in my Horizon was no help. CP/M was written in assembly, and I suppose I could have written the code to switch between controllers and drive types. Instead, I used a ‘new’ programming language, C, that I had discovered, and wrote the file system and device driver as a separate program. It took just two pages of C code, and I could copy files between my 5 ¹⁄₄ and the 8 inch drive, rename files, list the directory, and delete files. That took just two pages of C, which was really quite nice. Still, C was just a couple of steps above assembler, a programming language written by geniuses, [Dennis Ritchie and Ken Thompson](https://en.wikipedia.org/wiki/C_(programming_language), and really not suitable for everyday use by average programmers. C allows the programmer full access (my version had an extension for access to IO ports too), and has resulted in generations of programmers who write unstable and insecure programs.

Ritchie and Thompson had also been the creators of Unix, along with a handful of other Bell Labs employees. I was to learn about Unix shortly, after a short interlude with a group who want to build a little internet of sorts: Community Memory.

Community Memory

Community Memory had come and gone before I moved to the Bay Area. But I met a group of people attempting to revive the idea of an online, open access, free database for storing information, opinions, calendars, house and job openings, and other information. The original Community Memory had done all of these things, but used an inefficient computer, and had just three terminals at it’s peak. The group I worked with planned on using X.25, a networking protocol, to connect a much larger number of terminals across the Bay Area. I was hired to locate prospects that would license the X.25 implementation, written in C, and the money would be used to fund the project.

I did find one prospect, a vice president at a large company, and was quickly let go. But I had made a connection, Sandy Emerson, who would later play a small but important role in my career. And I learned that I really hated cold-calling, the process of calling people on the phone and trying to sell high-ranking corporate people software for handling a protocol few people understood. I only was asked to work at Community Memory because no one else wanted to do that job.

Dual Systems

In 1982, desktop PCs were just catching on, but so were small, multi-user systems. One of my connections contacted me, and asked me if I could write a systems manual. I had no idea what he was talking about, but he convinced me to drop by Dual Systems, another Bay Area microcomputer startup, one that has disappeared with hardly a trace left.

Dual Systems used a Motorola 68000, a 32 bit internal, 16 bit external, CPU that ran a version of Unix. This was the first I had heard of Unix, and I was really impressed with this operating system. I was accustomed to editing assembler, or poking bytes into memory locations, to change the workings of the systems I had used, while Unix had actual configuration files. Unix also supported multiple users simultaneously, something I hadn’t experience since my college experiences with mainframes.

I succeeded in writing a systems manual for Dual Systems, learning the basics of Unix system administration the hard way: no examples, no books, and of course, no Internet. I did talk to the people at Mt Xinu, but I would often get answers from people there like, “No one needs to know that, so just ignore it.” It was a frustrating time.

Morrow Micronix

Morrow Designs, George’s new company, was also experimenting with Unix. One of their programmers had written a Unix knock-off, which Morrow called Micronix. Micronix could run both CP/M and Unix-style programs on the same system. I was hired again to write a system’s manual, this time for Micronix.

Morrow later became a Unix licensee, and developed their own Motorola 68010 system. The system was a bit of a kludge, as it started life as a Z80 system, with an S100 8 bit bus, which was modified to be a 16 bit data bus and 24 bit address bus to support the Motorola CPU and one megabyte of DRAM. Unlike previous devices I had worked on, I had to buy parts of this system, as I wanted a Unix system for my own, and Morrow couldn’t just give it to me. Hard drives were still small in capacity and very expensive. I bought my own hard drive, at an OEM price of $1000 for 34 megabytes of capacity. My total system cost was around $2000, still a bargain for a Unix system in 1983.

I wrote yet another Unix system manual, this time starting with a fictional chapter, A Day in the Life of a Unix System Administrator. I had meant this part to be obviously fictional, and to help people understand their daily duties: booting, monitoring, user and printer management, backup, and shutdown. Some people thought I had actually video-taped a real person, so I guess I was more successful than I thought at writing my first published fiction.

I was facing another challenge around this time. While Morrow Designs was still flourishing, I could tell that things were not going well. IBM had entered the PC business years ago, and small manufacturers of competing desktop products were failing left and right.

I got my last consulting job for Morrow, writing a manual for a very cool hard drive controller, one that used a RISC processor and behaved like channel I/O. I had just returned from a three month sailing cruise, from San Francisco to the Panama Canal, and really needed the work. And I had fun writing this manual, as the designer, not George Morrow, had written the code for the RISC processor using his own programming language, and I used his source code as the basis for the manual. I later heard from people who had used the manual that it was the easiest manual to read and use they had experienced for writing a device driver, but I think the credit goes to the designer, not me. He had designed an elegant interface, where the programmer wrote values into an in-memory table, then sent a command telling the board where to find the table. Commands could be chained, so that as each command finished, the next would take over. And data was read-from or written directly to memory.

Becca Thomas

About this time, Sandy Emerson contacted me, and told me that she knew of another person I could work for, if I was interested in learning more about Unix. When I met with Sandy, she told me that there would be a problem if I decided to go ahead: these people were only interested in ghost writers. Anything I wrote would be published under their names. I could tell that Sandy was warning me about a somewhat unpleasant reality, but I was still interested. So far, everything I had written was essentially a work-for-hire, that is, I was already a ghost writer.

I arranged a meeting with Becca Thomas, and visited her at her house near Cole Vally (San Francisco). There I met an English professor, Joe Campbell, from the UC Berkeley, and discovered that I had to pass a writing test before I could go any further. I found this interesting, but not that far fetched, as these people were writing books, not manuals, and the bar for comprehensibility was going to be much higher, I supposed.

Joe had me write a description of the Unix file system for non-programmers. I had already attempted doing this several times, for my systems manuals and on my own, so I quickly turned in a couple of pages which Joe found acceptable.

I also met Becca’s partner, Jean Yates, in writing her first book, A User Guide to the Unix System. Sandy had told me that their first Unix book was a best-seller, and if I wanted to check that out, I should go to Stacy’s bookstore, on Market Street. When I went to the basement of Stacy’s, where their technical books were, I asked at the help desk about User’s Guide, and the man there pointed to stacks of her books piled in front of his desk. There were no other books stacked there, and I was impressed.

I soon began ghost writing A Programmer’s Guide to the Unix System. User’s Guide covered the 44 most popular Unix utilities, based on process accounting records for Unix system running at UC Berkeley. The book I was writing needed to cover programming tools, like the C compiler, linker, and debugger, along with the Unix system calls. And I had a Xenix system that I could play with.

Becca was a wonderful person to be working for, most of the time. One day, I moved the Xenix box out into the backyard, and sat in the shade of a tree playing with Xenix and drinking a beer. Jean Yates was not so nice, but she and Becca were splitting up around this time. So, I would write sections of the book, share them with Becca, who would mark them up (with red ink, on paper), and return them to me for revising. She would also run Writer’s Workbench, to provide more feedback. I got drilled on using more active voice many times.

While I did my research at Becca’s, I did my writing at home, in a flat near in the Western Addition. I would use my Morrow Design system, running Micronix, then use my C program to copy the output to 8 inch floppies for delivery to Becca. I wrote all of Programmer’s Guide, and the system administration appendix for a business user’s guide to Unix, during this period.

The books I had written were not nearly as successful as User’s Guide, perhaps because the market for Unix programmers was much smaller. When my ghost writing work dried up, Becca introduced me to another person who was using Unix, Tom Lubinsky.

Sherrill-Lubinski

Peter Sherrill and Tom Lubinski had a small office in Corte Madera, a few miles north of the Golden Gate Bridge. When Tom interviewed me, he questioned me on both graphics and SmallTalk, two topics I knew little about. I went to Stacy’s and bought a book by some of SmallTalk-80’s creators, like Alan Kay and Adele Goldberg, and started learning about object-oriented programming.

Tom was (and is) a talented programmer. He had already written an interpreter for Objective C, and was interested in building an object-oriented graphical modeling system. He already had a basic working system, and needed someone who could write documentation, using the source code for reference. While the system was object-oriented, the underlying language was C, and that was something I understood well enough to become immediately useful. I worked for Sherrill-Lubinski, later SL, on and off from 1985 until 1991.

System Administrator’s Guide to System V

It was at this time that I convinced Becca Thomas that the world needed a book on Unix system administration. As the already successful author, she negotiated a contract with Prentice-Hall. We had wanted to call this book _The Handbook, but when we suggested this title to our editor at Prentice Hall, he told us it was already taken. In other words, there was another group busy writing a Unix system administration book, and Prentice Hall also had a contract with them. Evi Nemeth and her students wrote the first edition of a vastly more popular system administration book.

Our book was finished first, although even though that took much too long. If you used System V, or needed to use Unix-to-Unix-Copy, UUCP, our book was the one for you. I had become an expert in serial communications, modems, and UUCP long before we finished out book. I had wired and configured the offices at SL and UnixWorld Magazine, and routinely used UUCP for email and file transfer. Also, early Linux looked a lot like System V Unix, and Linux users sometimes used our book. But we had picked the wrong operating system to spend four years writing about.

Evi Nemeth, working at the University of Colorado in Boulder, focused on Berkely Unix, BSD. Sun Microsystems used BSD for their workstations, as did other workstation vendors like DEC ULTRIX. Because of the difficulty in licensing Unix from AT&T, many students got their experience using BSD-related version of Unix at their universities, and that was, of course, what Evi and her students wrote about. They also had a much lighter style than we did, and covered TCP/IP networking, which we didn’t.

I also convinced Becca that if were were going to write a book about Unix system administration, we should try teaching. I thought that we would learn what worked and what didn’t when explaining system administration principles, and that would make the book better. We first taught a small class at a business, then were invited to teach at the USENIX Technical Conference in Atlanta, Georgia, in 1986. That class went well, and was my first USENIX conference as well.

Our next attempt at a USENIX tutorial, Winter USENIX in Washington, DC in 1987, didn't go so well. The Tutorial Director, whose name I will not mention, told use to write an advanced course. We told him we couldn't, but he went ahead and advertised our course as advanced anyway. That was a truly unpleasant and embarrassing event. I learned that I should never pretend to be advanced when I wasn't, and not to overbill myself when teaching.