Thanks to some good influences in college and shortly afterwards, I’ve written a number of technical articles and papers for various magazines and conferences. Most of the ones that are still relevant have been converted to HTML and are available here.
This paper was presented at the 1994 Applications Development Symposium, sponsored by the USENIX Association. The abstract reads:
In classic software design, little or no consideration is given to the issue of installing the resulting package on the customer machine(s). This is complicated by the rich variety of administrative policies and styles used in UNIX installations. This paper will not attempt to prescribe a specific method for software installation. Instead, it will focus on (a) issues which make a package installable into highly customized sites such that the package can be installed with minimal disruption to both the site and the package and (b) the reprogramming of system configurations in a style designed to minimize the impact of that reprogramming.
This paper has been reformatted for HTML and with minor grammatical and content fixes. No attempt has been made to do a full update.
One dark night I was reading a system administration newsgroup (this was in the pre-web days) and got fed up with hearing the same stupid suggestions over and over. About three hours later, the first draft of this article was posted. It’s changed surprisingly little over the years, but hey, shouldn’t natural laws be stable?
First written in 1992, with minor random updates since then. Decades later I’m still getting mail about it.
This paper is a rewrite and expansion of my very first system administration paper, originally presented in 1988 at the Second Large Installation Systems Administration (LISA) Workshop (it wasn’t a conference yet), sponsored by the USENIX Association. The updated version was presented at the 1991 Large Installation Systems Administration (LISA) Conference. The abstract reads:
As laser printers become smaller and cheaper, many sites are installing multiple conveniently located slow printers rather than one or two central fast printers. With an increase in numbers of printers and hosts supporting printers comes an increase in failures. This paper describes a naming and /etc/printcap convention for BSD-based spooling systems that makes it simple to relocate printers and redirect print jobs when failures or changes occur. As a side benefit, it makes /etc/printcap files and queues easier to manage.
It’s worth noting that although printer technology has advanced hugely since this paper was written, queuing and recovery technology has made comparatively little progress.
This paper was presented at the 1990 Large Installation Systems Administration (LISA) conference, sponsored by the USENIX Association. The abstract reads:
Often the people most qualified to perform certain system administration tasks are not necessarily qualified to have root access in general. This paper will discuss the rationale and methods for having non-root accounts do some types of systems administration. We will discuss two subsystems which we are currently administering without root and apply that experience to suggest some general rules.
This paper has been reformatted for HTML and with minor grammatical and content fixes. No attempt has been made to do a full update.
This paper was co-written with my long-time colleagues Elizabeth Zwicky and Ron Dalton. It was presented at the 1990 Large Installation Systems Administration (LISA) conference, sponsored by the USENIX Association. The abstract reads:
All decisions about how to manage a given system are made with
respect to local policy.
This is true even in the absence of such policy,
as the consistent actions of the system manager
become de facto policy.
This paper will discuss the interactions between
policy and systems management.
Using a series of case studies,
we will illustrate two points:
how proper policies can be used to ease the day-to-day tasks
of systems administration;
and how technical issues can and should be used
as one of the driving forces in policy decisions.
Converting it to HTML forced me to re-read it in detail.
I was surprised as how relevant it remains
and how much we continue to apply policy as a tool.
This paper was recently republished as part of Selected Papers in Network and System Administration, edited by Eric Anderson, Mark Burgess, and Alva Couch.
This piece was intended for Datamation, but for some reason they stopped answering their mail about the Readers Forum (see next two articles, below). Between one thing and another, it fell between the cracks until put up here November, 1997.
It was originally written in March of 1987, and felt eerily prophetic with all the thrashing involved in the Y2K “crisis.” It feels eerily prophetic again as Toyota slogs through all the fallout from possible bugs in the brake and throttle control systems.
Datamation once had a sense of humor. It usually showed up in a regular section called Reader’s Forum. That sense of humor began to disappear about the same time this article was published. One of the early indicators was when they changed the title of this article from “Fear and Loathing on the Benchmark Trail” to “More Benchmark Tales”. Two points off your personal benchmark if you don’t understand the original title, I’ve restored it here.
The particular details of these benchmarking “war stories” are out of date, but all the principles are the same - what to trust, what to verify, what can be different from system to system. Even using standard tools, there are a lot of pitfalls in benchmarking. This article will give you a few guidelines on avoiding them.
Another item from the Datamation feature Reader’s Forum. This paper was the cumulation of a 4-year running joke. One friend made few disgusting puns, another topped him, and a bunch of literate techies were off and running. For several years we told the basic storage story (included in the article) as a joke to friends. The joke started going around the lab when I was working at BNR (which, by the way, actually stands for Bell Northern Research). One day it hit me there was a way to put it all in a pseudo-scientific context, and the article was born. I sent it to Datamation and was shocked to find they actually paid for articles. Nothing motivates like getting paid for something you do for fun. :-)
When keying this into HTML format, I got a shock. Yes, the Dilbertesque joke precedes Dilbert by about 10 years. First published in Datamation as The Quark, Of Course in August 1984. No changes have been made from that publication except the title.
One curious co-incidence - I’d been spending large amounts of time trying to convince BNR that UNIX was a good thing. The cover story for this particular issue carried the caption UNIX: Hit or Myth.