Interview with Henry Spencer: On Usenet News and C News
 
   [Editor's Note: Henry Spencer is one of the early participants and
pioneers of Usenet News. Henry played a significant role in bringing Usenet
News into Canada and thus providing access to and participation in Usenet
beyond U.S. borders. In addition, Henry archived much of early Usenet, thus
helping preserve it. Along with Geoff Collyer, Henry wrote C news, the widely
used Usenet News software. Following is an interview with Henry conducted by
some of the editors of the Amateur Computerist in Toronto, Canada in August,
1992.]
 
 
   Ronda: Some of what we would be interested in knowing is where C news came
from, how it developed and what your efforts are to deal with it now. We
thought it would be helpful to ask a bit about your background with Usenet
News so that we have a sense of how C news grew out of your experience with
Usenet News and out of Usenet News itself. So our first question is, can you
say a bit about when you first became involved with Usenet News and then how
that involvement with Usenet led you to understand the need for the C news
program?
 
   Henry: Well, there was a Usenix Conference 10 years or so ago. I think it
was the Delaware Summer Usenix Conference, which was in the Summer of 1980.
The folks from Duke University made a presentation on a bit of 
networking software they had done. Version 7 UNIX, which was more
or less just out at the time, had some facilities for using auto 
dialing modems to pass mail and other things from machine to machine.
This wasn't terribly well understood by most people. But these folks 
had figured it out and made it work. They were using it as a sort
of distributed bulletin board system. The software they came up with is now
known as A news. It was actually the second or third version they did
internally, the first one that was circulated widely outside. Early on, Duke
was sort of the central point. The topology of the net sort of evolved from

there in random and confused ways. Partly, it was just a neat idea. There was
a lot of interest here in networking in general. A lot of the early traffic
was potentially very useful things like bug reports on version 7 and bug
fixes for version 7. There were some interesting and potentially useful
contacts available through it, like for example, you could send mail to
Dennis Ritchie and people like that at Bell Labs and sometimes they'd even
answer you. So it looked useful. There was a bit of delay in us getting
things in place. A lot of sites took a lot of time in switching to version 7.
But in the Spring of '81 we cut over to version 7. One of the first things we
did was to establish a Usenet hookup. In the early days, manually dialing at
300 baud was a bit of a hassle. Of course, the traffic was a lot smaller than
it is now. But it was valuable enough that we progressed from there. We got
a 1200 baud modem and the capabilities just kept on scaling up, more or less
keeping pace with the traffic. For a while, the phone bills were kind of
interesting to explain. I'm glad we're no longer in that business. But that's
how our involvement really got started.
 
   Eventually B news came out as an improved version of A news, better
performance, better ability to cope with heavier loads and some other useful
features. We were eventually bullied into adopting it. A news was working ok
for us for a long time, but some of our neighbors eventually bullied us into
switching. There were enough compatibility problems between the two that it
was better if everyone ran B news. Things ran quite satisfactorily that way
for quite a while. But the B news code was an awful mess inside. It just got
worse over time. It had started out as a heavily mutated A news and
progressed from there mostly downhill. So we first got involved with it when
B news "expire" just basically stopped working due to bugs.
 
   Ronda: Can you say what bugs?
 
   Henry: Probably, the way it looked was a memory leak, dynamically allo-
cated memory that wasn't being freed properly. This got more and more serious
as traffic grew and "expire" had to handle more and more stuff. Eventually,
it just broke entirely. This was a 16 bit machine, so there wasn't a whole
lot of memory available to begin with. I looked at the code and decided that
it wasn't really doing anything very complicated and it would probably be
quicker to just rewrite it than fix it as it had gotten to be quite a mess by
that point. I did and there are still remnants of that code in C news "ex-
pire" as it is today. But that's how things got started. Geoff Collyer and I
basically just progressed more and more in that direction as B news
limitations got to be more and more of a problem. The load on our machines
got worse and worse as the traffic grew. The bugs grew more and more
troublesome. So we eventually decided just to rewrite it for better
performance and better maintainability and over time did so. All along we had
the notion of distributing it in our minds. That's just the way we tend to
think about software development. There's always somebody else who could
benefit from something like this. Eventually, with some prodding from our
friends, we got everything together and produced an actual release. It's
needed some more work since, but that's how it got started.
 
   Ronda: So somehow from having redone "expire" you went on to redo the
whole program? Did rewriting the code for "expire" help you to realize there
was something more needed? How did you go from rewriting the code for
"expire" to deciding the whole Netnews program would benefit from being
rewritten?
 
   Henry: It was basically just sort of a logical progression. Doing "expire"
- something had to come first - and this demystified the stuff, not that it
was particularly mysterious to begin with for the most part, and got us
started in the right direction. And things progressed from there.
 
   Ronda: Can you say just a bit about what "expire" does in Usenet News?
 
   Henry: "Expire" is just responsible for getting rid of articles off your
system. Much of the rest of C news is devoted to getting them onto your
system from a remote site or from local postings. "Expire's" job is to get
rid of news that's been sitting around long enough, where the definition of
"long enough" has gotten shorter and shorter as volume has grown and disks
haven't grown to match. There was a time when it was fairly normal to keep a
month of news online. And while it's not impossible, today you have to spend
a lot of disk to do it.
 
   Ronda: The issue of the change in definition of "long enough" seems
important. With regard to "expire", when you did rewrite "expire", was that
when you were able to keep one month of news online?
 
   Henry: I think we had about a month online. Certainly it was of that
order. It was at least a couple of weeks and I wouldn't be surprised if it
was a month. I haven't really kept track. This all started quite a long time
ago and volume was pretty low then.
 
   Ronda: What do you mean by volume being low? How would you define the
number of news groups at the time?
 
   Henry: Low in just about every way. I don't know, maybe a hundred
newsgroups, with maybe a couple hundred sites I'm not sure. Just a wild
guess. The traffic at that point was low enough that if you wanted to spend
the time, you could realistically read everything that came over.
 
   Ronda: Were there people who read it all?
 
   Henry: A reasonable number of people actually read everything. It wasn't
till the volume started to become overwhelming that people just had to get
selective. There was always the possibility of something interesting cropping
up in an area you didn't normally read. The possibility is still there, but
it's no longer practical to do very much about it, short of having friends
alert you to something.
 
   Ronda: What year are we talking about when you started to see the problem
with "expire"? Was that around 1986?
 
   Henry: No that would be early 1980s. The development period for this stuff
was fairly protracted. It went through a lot of work of one kind or another
before we released it. And even that wasn't all that recent. Let me see here.
[Calls document up on his computer -ed] Well, our first patches were Summer
1989, so Spring 1989 must have been the production release. But that was a
year or more after an alpha release and stuff had been kicking around in
embryonic form for several years before that. We never did mount a systematic
campaign to do the whole thing. It just grew a bit at a time until we finally
decided it was complete enough to try and get something out the door. It
required a surprising amount of work to put everything together actually in
distributable form. And it involved some surprises in our beta testing,
portability hassles we hadn't been aware of, and systems differing in stupid
ways we hadn't realized.
 
   Ronda: You've said you were first interested in Usenet because of the bug
reports for UNIX that it carried. Can you explain a bit more about that?
 
   Henry: The Duke people originally thought that the bulk of the traffic on
Usenet was going to be things like version 7 bug reports. And that was a
noticeable fraction in the very early days.
 
   Ronda: Was Usenet different in the ways it dealt with bug reports from
other BBSs?
 
   Michael: Did it have other methods cause I guess a lot of companies have
various forms of support?
 
   Henry: Well, for one thing, Usenet predated a lot of company bbs's and the
like. It was basically a cheap way to hear about things fast and this was at
a time when practically every UNIX site had complete sources and so a bug
report often came with a fix. It was a way of finding out what people had
discovered and what fixes they'd worked out for it. Quickly and easily. And
for that matter, if you ran into something that you couldn't solve yourself,
putting out an inquiry to a bunch of fairly bright people who were fairly
familiar with the code, often got a response, "Oh Yeah. We solved that one"
or "You're right. There's a bug. Here's how to fix it" or sympathy even if no
one had a fix for it.
 
   Ronda: You mentioned something about noticing a particular bug in the
PDP-11 that was an obscure bug.
 
   Henry: This was something that was a problem in the long division routine
in the C compiler that came with v7 and it was obscure and difficult to spot
on the older PDP-11's. On the newer ones it was more conspicuous. One of our
users ran into it, pointed it out to me, and I ended up investigating it and
reporting it. On the new PDP-11's, it showed up a fair bit and you just had
to fix it. Even on the older PDP-11's, it turns out that 2 or 3 things that
were known as obscure problems in the stuff magically went away when the fix
was installed. What was happening was the code tried using the PDP-11's
divide instruction at one point. There was a possibility the result might
overflow because the PDP-11 instruction wasn't up to doing the whole job of
this particular requirement. If the overflow occurred, the code assumed that
the registers which had held the dividend were untouched. On older PDP-11's,
that was usually true but DEC had never promised it. On the newer PDP-11's,
it was often false. Any combination of operands that led into that particular
branch in the code produced grossly wrong answers. But it looks like some
boundary cases, even on old PDP-11's, didn't work quite right, because there
were a couple of things mentioned as very obscure known bugs in the division
stuff that I couldn't reproduce once I put the fix in. So it may have been
there all along and just nobody had analyzed it.
 
   Ronda: What's the process of analyzing a bug? You mentioned something
about documenting it.
 
   Henry: Oh, there were a couple of problems noted, as known defects in the
software. There is something the UNIX community has always been fairly strong
on, admitting things you know just don't work about the software. And this
was mentioned in the sources in bits of documentation accompanying them, that
there were a couple of cases that didn't work quite right. In this case, I
had a user of mine who had run into this. He had actually supplied a case
where the answer was just plain wrong. It was just a matter of digging in. I
think I ended up inserting some debugging printouts at various points in the
routine, and just finding out what was going on where the calculation was
going awry. Once I knew where to look, the problem was pretty obvious and the
fix, in fact, was about 4 lines of code. That was probably one of the first
things that started to make my reputation on the net because a lot of people
noticed when I posted that.
 
   Ronda: Why?
 
   Henry: Because it was a really obscure problem that had the potential to
make a lot of trouble for people. It was something in that it was subtle code
that was from the originators of UNIX themselves, something they'd missed.
 
   Ronda: That's interesting. So the reason people respected the bug you
found was because they understood the significance of the problem that had
been averted?
 
   Henry: Yes, it was a subtle problem that could have caused a lot of
trouble in code, coming from people who were normally pretty good.
 
   Ronda: So are you saying that one is encouraged to find what could be
problems that could cause trouble despite who it's coming from? And then to
suggest how to deal with it?
 
   Henry: Yes, it's diminished some in recent years because such a large
fraction of UNIX sites nowadays do not have sources for the code. But in
those days, it was reasonably normal when you hit some sort of problem to go
looking for what caused it and produce a fix for it. Partly, this has
declined because people no longer have sources and partly it's declined
because the community is a lot wider and many of the people using and even
running UNIX systems don't have the technical expertise to go hunting for
things like this. But, hey, it was very common at the time. This was in the
days when UNIX was still treated by the Bell system as, "Oh just something we
happen to do for our internal use. You can have a copy if you want, but if
you got problems, don't bother us." And the result was if you wanted UNIX
support, you did it yourself or it didn't happen.
 
   Ronda: It sounds then like people trained themselves to deal with prob-
lems.
 
   Henry: To a considerable extent, yes. The people got to know how to deal
with the things and the community. This is almost certainly one of the things
that got Usenet going in the beginning. Having quick access to a community of
experienced people was quite important in the days when you couldn't just
call the manufacturer for support. If you called Bell Labs or Western
Electric, as it was then, about it, they would hang up on you. If you could
manage to get through to Ken Thompson or Dennis Ritchie, they might thank you
for the bug report. But they certainly weren't going to promise anything like
support.
 
   Ronda: Do you miss that in any way?
 
   Henry: To some extent, yes. To some extent it's the community I'm still in
because we've been running obsolete versions of UNIX for a long time. And
still are. On our Sun, our main time sharing machine, we're running the last
stable version of Sun OS 3.5. Sun will hang up on you if you ask about it
now. And so we're still used to doing our own support, handling our own
problems. Unfortunately, because UNIX has grown so much and diversified so
much, there's less of a sense of community of others lending a hand now. Too
many people with too many different machines and too many different versions.
 
   Jay: But has the spirit and the sense of that somehow given form to the
Usenet community, the grander community?
 
   Henry: It's still there to some extent. But it's diffused considerably
from what it was.
 
   Ronda: Is there any way that the bug reports led to the other kinds of
discussions? Is there any connection between them? Or is it just that people
were interested in other areas?
 
   Henry: It [the bug report -ed] was incentive to get onto the network more
than anything else. So you could hear about things like this. People have
commented also that the Usenix conferences are in some ways less of a hotbed
of gossip than they used to be because the net has taken over some of that
function. You know it used to be - back in the very early days, when you went
to a Usenix conference, more often than not, you came back with a notebook
full of notes on known bugs and what to do about them. And new software
available and so forth. The bulk of that goes on via the net nowadays. Things
have changed, but originally getting onto the net, the big thing was getting
access to the community that knew about these things. And the rest of it was
a secondary issue originally. There was a group talking about science
fiction, for example. But this wasn't why system administrators were hot on
getting their machines connected. Well, not most them. And then, generally,
this was a way of doing networking on the cheap. It was a vigorous online
community that you could join without spending many dollars and jumping
through lots of bureaucratic hoops, to join something like the Arpanet. With
this, all you needed was an auto-dialing modem and someone who was willing to
be your connection point.
 
   Ronda: Somehow it seems that having the other discussions is important,
also, to the technical discussions. Do you agree? Is there a connection
between the technical and nontechnical discussions?
 
   Henry: They [the nontechnical discussions -ed] helped broaden support for
things. I don't think they really had very much of an effect on the technical
end. Then, as now, there are a lot of people who justify the net primarily in
terms of its technical benefits. People are heard to claim sometimes, "I like
the net for the tiny minority of technical stuff, but all this non-technical
trash I could do without." But in fact, it has been a standard misun-
derstanding from the early days, the theory that there's just a little bit of
technical stuff and a lot of garbage. This was as much of a misconception in
the days of 30 days of news as it is now. That there was a little bit of
technical stuff drowning in garbage. The fact was even then, the technical
stuff was quite a substantial slice of the traffic. It's just that individual
people [only -ed] notice the little bits of technical stuff that appeal to
them.
 
   Jay: And they call everything else garbage.
 
   Henry: Or they just don't think about the fact that there was a lot more
technical stuff.
 
   Michael: If you don't look for it you don't see it to some extent.
 
   Jay: But I thought Ronda's question was slightly deeper in the sense that
she was asking: Was there something almost as profound about the nontechnical
stuff in terms of the kinds of things people talked about that influenced
them to be better with the technical stuff?
 
   Henry: Maybe, in small ways. The nontechnical stuff was the first exposure
a lot of these people had to an online community. Bulletin board systems were
not particularly widespread at the time. They did exist, but they certainly
hadn't reached the current level of popularity. Networks like the Arpanet
were much spoken of by the people who belonged to them, but weren't
particularly widespread. And there may have been some positive effect in
helping to socialize people, so to speak.
 
   Ronda: You have talked a little bit about speed, a little bit about
performance. Maybe you can speak briefly about what the limits of B news were
that you were dealing with, and how that influenced your objectives with C
news.
 
   Henry: Well, our big problem, a contributing factor, was that B news was
messy and buggy. There were things you couldn't do with it. There were things
that didn't work well on it. It clearly was less and less able to cope with
the growing volume of traffic. Even just things like memory leaks. "Expire"
wasn't the only code that potentially had memory leaks. It was just getting
harder to deal with the stuff. The big thing though was that B news was very
inefficient at handling incoming traffic. It took a long time to process
incoming traffic. It beat on the machine pretty heavily, meanwhile. And there
didn't seem to be any simple way to fix this. There were fundamental struc-
tural problems that one really could not do anything about that limited the
ability to speed it up. We kicked around a bunch of ideas about improved ways
of storing news and so forth. Eventually, we concluded that there wasn't any
big improvement to be had. Nothing that would be worth the trouble of being
incompatible. The main thing we were after was just greater performance.
 
   Ronda: Can you say who we is? Or if this went on online as well.
 
   Henry: This is Geoff and me. [Geoff Collyer -ed] I've never been a big
believer in committee design. Our preference, me in particular, but I think
Geoff as well, our preference is to do something and then announce it, rather
than vice versa. Partly because we've got a higher opinion of our own sense
of good design than a whole lot of other people.
 
   Ronda: Can you explain what you mean by good design?
 
   Henry: We're big on writing simple clean software that does one thing and
does it well, which is not what you get out of a committee design. And in
fact, this is one of the things we have occasionally taken flack for. We make
our own decisions on what does and doesn't go into C news. So we don't
particularly care if this makes us popular or not. We've made a few mistakes
along the way as well. But, it was our own idea. We've modified our own ideas
of how things were going to work quite a bit along the way and stuff evolved
to a considerable extent as we wrote it. There were muddles that had never
adequately been cleaned up. As late as just before our alpha release, there
were still three different programs called "rnews" in various places in our
stuff. And when we were packaging things up to put together a release, I put
my foot down and insisted that there had to be one and only one "rnews". And
so we found other names for a couple of things in a hurry. But it evolved
along the way. We had ideas of where we were going. But it didn't come full
blown as a complete design. It couldn't really. That approach to doing things
just doesn't work in the real world. The stuff always evolves. Once you start
building up experience with the problem and with your tentative solutions,
the requirements always evolve. So you really do have to plan for getting
something working and having it evolve from there.
 
   Ronda: Interesting.
 
   Henry: We put a lot of thought over time into the performance issues and
also into the precise definitions for a lot of things. The B news stuff -
even its documentation - in crucial areas, just sort of waved its hands and
said, "well, you know what we mean." In some cases, we actually had to put
quite a bit of effort into deciding exactly what should be done in obscure
situations. [These are -ed] things you find out by doing it. It was not
something that really could be predicted from specification in advance.
 
   Ronda: That's interesting. Do you have a sense that the speed and the
performance have made possible the ability of C news compared to B news to
deal with volume?
 
   Henry: People have adopted our stuff for a variety of reasons. Par-
ticularly, after the word started getting out that it was generally better.
There have been a few specific features that won us a lot of converts.
Something that went into our version of "expire" sort of midway through its
development process and won us a lot of friends, was control over expiry
newsgroup by newsgroup. The B news "expire" basically just let you set expiry
rules for all the news put together. A lot of people, in fact, had different
opinions about the value of different newsgroups, and wanted to keep some
things longer than others. The fact that we could do that won us a lot of
friends very quickly. It probably wouldn't have been that hard to add to B
news, but nobody ever thought of it. There were things like this, but
ultimately, people switched to C news because B news was eating their ma-
chines alive, and they wanted some performance back. And for that matter,
because they could see the handwriting on the wall. There were machines,
including some of ours, where towards the end, B news was running essentially
nonstop from 5:00 in the evening till 9:00 in the morning, turned off during
the day because it had too much of an impact on performance when lots of
people were trying to get real work done. And it wasn't keeping up with the
incoming load. The backlog was growing. People who ran into that kind of
situation generally decided real fast that they needed to switch to something
else.
 
   Jay: I thought Ronda's question had another component. Can your careful
attention to speed and performance be pointed to as accounting for the
tremendous growth in Usenet that wouldn't have been possible with something
with less performance.
 
   Henry: The trend was very firmly established very early. But certainly
Usenet would have had a lot of trouble coping with growth if C news hadn't
come along when it did.
 
   Jay: What I am asking is if not as careful a version of C news, would that
have been a limit that would have...?
 
   Henry: Probably, because the care and effort we put into performance
basically accounted for a lot of the performance. We were a little disap-
pointed, initially, in fact, that fixing some of the basic structural
mistakes of B news didn't improve performance more. Yes, it was considerably
better than B news, but it wasn't as good as we expected. The way you make
stuff run really fast, it turns out, is to put a lot of attention into making
it run really fast. Avoiding basic mistakes is a crucial prerequisite, but
it's not enough by itself. To really make the stuff perform, you really do
have to put a lot of effort into understanding what things hurt performance,
where the time is going. You have to put a fair bit of time into thinking
about how things are being done and how they might be done better. We got a
certain amount of performance just by careful low level tuning, looking for
hot spots and finding ways to speed up the code there. But we also got an
awful lot by standing back and thinking - "What is this code doing and is
there a better way to do it?" "Are we repeating things that we could do just
once?" "Is there information we need that we're having to gather laboriously
that could just be stored centrally instead?" - and things like that, changes
in strategy. Changes in strategy are what win you the big performance
improvements on the whole. Not overall strategy in the sense of the mistakes
B news made versus the ones we didn't make. But sort of mid-level strategy -
how the code does what it does. The way you get big performance improvements
is not to make a bit of code run a little bit faster, but to take code out
entirely. To find ways of just not doing some things and still getting the
overall job done. Reducing the amount of time needed for something to 0 is
always better than reducing it to 10%, though the 10% can be useful too.
 
   Jay: But when the problems start building up now, will the next fix not be
a software fix?
 
   Henry: To some extent, we've had hardware fixes coming in all along.
Faster modems, bigger disks, faster machines. And that's certainly helped.
But it's going to be hard to beat C news performance a lot without drastic
revisions in something fundamental. There are things we know of and are doing
to make it faster yet. But huge performance improvements are going to have to
come from something more fundamental. One thing that turns out to be
relatively expensive is just looking up a file name in an operating system,
opening a file by name. The name look-ups are costly, even in versions of
UNIX that have put some attention into optimizing them. And we know where our
stuff is doing file name look-ups and we just don't do it any more than
necessary. Any major speed up in that area - that is still one of the major
bottlenecks - is going to have to come from major revisions to the operating
system. It's not something that can be greased up much more at the user
level.
 
   Ronda: You said earlier that you used to be able to get a month of Usenet
and now you're down to, I think you said, four days.
 
   Henry: In our case, we're storing 4 days, and using a great deal more disk
space for it, too.
 
   Ronda: Does that mean that in fact the size has gotten to a point where
there is a need to figure out how to make some change? Is it coming to that
somehow?
 
   Henry: People have been predicting the imminent death of the net for a
decade now, so I'm very reluctant to do that. But certainly, it's gotten to
the point where we store 4 days because that's basically enough to carry you
over a long weekend. If it drops much more than that it's going to be a
serious problem for maintaining continuity in a lot of discussions. You can
mitigate it somewhat by getting bigger disks or by being more selective about
what you get. Probably, the bulk of Usenet sites these days are somewhat
selective. We used to be a major redistribution point within Toronto. We're
still a minor one. Because of that we try to carry everything. But carrying
everything is steadily getting more expensive.
 
   Jay: But does that imply there's going to have to be very large central
distributing points?
 
   Henry: That's already happening to some extent. A lot of big universities
and things like that, for example, now have central news distribution
machines, just to keep the load from spreading everywhere. And, for example,
most of the news distribution within U of T now is handled by one of two
central machines.
 
   Jay: Yours not being one of them?
 
   Henry: Ours not being one of them anymore. We do some redistribution to
places outside campus. Not a lot compared to what we used to do. But that's
definitely happening. UUNET in the States is another example. Someone once
called it Usenet's main sewage pump. 
 
   Ronda: What is it? Can you say what UUNET is?
 
   Henry: It's a site which offers mail connections and news-feeds for money,
basically. It has done wonders for the connectivity of the net because a lot
of people who couldn't do this sort of thing on an informal basis are happy
to get a connection to UUNET which does cost money but is professionally
maintained. They're very much in the business of processing mail and news for
money. And they're a very central point now.
 
   Ronda: Isn't that also a little bit in contradiction with the way Usenet
originally started with it being available to people at a low cost or no
cost? But there's also Freenets growing up. For example, the Cleveland
Freenet and the Youngstown Freenet and Ottawa is supposed to be developing a
Freenet in Canada [National Capital Freenet in Ottawa and Victoria Freenet in
Victoria are now online -ed]. The Freenets is how I got access. I wouldn't
have been able to pay for access and other people I know wouldn't....
 
   Henry: There's always people willing to do a certain amount for free.
There's always going to be a considerable amount of that. The point is when
you are in it for a long period of time and the demand just seems to be
growing, sooner or later you burn out the supply of volunteer manpower. And
somebody has got to start paying for it.
 
   Ronda: And some of the contradiction is that it's public money.... In fact
the public is paying for it, so to then go and put a commercial person in and
charge back again, what we are already paying for in public funds, it's thru
the universities and it's thru the NSF....
 
   Henry: The real problem on all of this comes when you start talking about
unlimited growth. This is the problem Usenet has had all along, in fact,
which is, coping with continued growth. That shows up in a number of ways.
That's just one side of it. Eventually a university, for example, decides
that too much of its phone bill is being spent on shipping news around for
other people and its time to let somebody do this who is actually getting
paid for the job. Because NSF in its beneficence doesn't supply unlimited
amounts of money for such things, sooner or later the demands get large
enough that somebody's got to put up an appropriation specifically for it.
And at that point, universities have a tendency to bow out if they can't get
somebody nice to give them money for it.
 
   And Usenet has run into problems of growth in a lot of other forms. Like
the sort of social compact that regulates behavior to some extent on the net.
The problems of finding information when there are thousands of newsgroups.
All kinds of things like that. You regularly hear moans from people about how
Usenet isn't the way it used to be. And occasionally some inconsiderate old
timer will point out, "Well it never was. You're one of these beginners who
only joined in 1986. You don't know the way the net started out."
 
   Michael: The question of growth also brings out the connections through
the Internet because that has grown a lot more than it was initially.
 
   Henry: Again, that's been a saving grace to some extent because the
Internet has saved us from the pyramiding phone bills to a considerable
extent. The bandwidth that has been made available in recent years for the
growth of the Internet, a noticeable fraction of that is shipping Usenet
traffic around. I don't know about the Internet itself, but there was a link
between Toronto and Waterloo, the other prominent university in Ontario. Five
years ago or more, I saw a graph of traffic growth over time. Generally, of
course, it was upward. But there was this one huge step more or less, in the
traffic, and that was when we started shipping Usenet stuff back and forth,
that week. I expect that Usenet would have undergone some sort of collapse or
transformation by this point if we had to go on shipping it by phone, because
even with the modems getting better and better, they weren't getting better
that fast, by that much.
 
   Ronda: We have to end the interview soon. So we just want to ask a few
final questions. 
 
   Michael: I was wondering if there was anything - with you, with your
experiences of being on the net and being one of the writers, one of the
programmers of C news, and just your general knowledge - is there anything
that other people who were system administrators or who were on the Usenet
might find useful? Any insights?
 
   Henry: Nothing very dramatic. About all I have to say is that a lot of
this stuff is harder than it looks. I really don't know whether Geoff and I
would have gotten involved with C news if we had realized everything that was
going to be involved because there was a lot more programming than we thought
and a lot more ongoing hassle than we thought. If you decide to get into this
kind of thing, you have to think very, very carefully about the possible
implications.
 
   Ronda: Have there been rewards as well?
 
   Henry: For me, nothing enormously tangible. The occasional free dinner and
things like that. And Geoff is currently working full time on News software
support.
 
   Ronda: But what about the principles that you clarified in the papers that
you have written? Has that been something? For example, in "News Need Not Be
Slow," you and Geoff wrote, "In order to know how to get somewhere, you must
know where you are starting from." Are there principles like that that have
come out of doing the work that have been helpful?
 
   Henry: There's a lot of little things, things which can be useful to know
if you're doing something like performance enhancement. But the one general
principle I could distill out of it is that: If you want to write software
that's fast or portable or well structured, despite years of evolution, you
have to care about it and put effort into it. It's easy to be sloppy, but it
comes back to haunt you. The only way to make something fast is to care about
performance from the beginning and put real effort into getting it. The only
way to keep the code clean and maintainable is to constantly put effort into
that aspect of it. Resist the temptation to make quick fixes. Or if a quick
fix just has to be done for some reason, make a point of going back and doing
it right. These things do not happen automatically and they won't happen if
you don't care about them. The main reason why a lot of software today is
bloated and complicated and obscure and buggy is that people don't care. They
may care in the sense that if you ask them they say, "Yes, we care," but the
fact is they don't put any effort into it. They don't care enough to work on
it.
 
   Michael: Does what you just said help figure out how to keep Usenet
running? Everyone says it's loaded now with users and newsgroups and
messages? Is there any way to apply this?
 
   Henry: Not really very directly. It's a very different situation from
software. I can't think of any particularly direct application other than the
very general application you have to think about what the real underlying
problems are. And avoid the temptation to settle for quick fixes that don't
really solve the problem.

Reprinted from the Amateur Computerist vol. 5 no. 1/2
Winter/Spring 1993 Issue