Home / Blogs

The Early History of Usenet, Part I: The Technological Setting

Usenet—Netnews—was conceived almost exactly 40 years ago this month. To understand where it came from and why certain decisions were made the way they were, it’s important to understand the technological constraints of the time.

Metanote: this is a personal history as I remember it. None of us were taking notes at the time; it’s entirely possible that errors have crept in, especially since my brain cells do not even have parity checking, let alone ECC. Please send any corrections.

In 1979, mainframes still walked the earth. In fact, they were the dominant form of computing. The IBM PC was about two years in the future; the microcomputers of the time, as they were known, had too little capability for more or less anything serious. For some purposes, especially in research labs and process control systems, so-called minicomputers—which were small, only the size of one or two full-size refrigerators—were used. So-called “super-minis,” which had the raw CPU power of a mainframe though not the I/O bandwidth, were starting to become available.

At the time, Unix ran on a popular line of minicomputers, the Digital Equipment Corporation (DEC) PDP-11. The PDP-11 had a 16-bit address space (though with the right OS, you could quasi-double that by using one 16-bit address space for instructions and a separate one for data); depending on the model, memory was limited to the 10s of kilobytes (yes, kilobytes) to a very few megabytes. No one program could access more than 64K at a time, but the extra physical memory meant that a context switch could often be done without swapping since other processes might still be memory-resident. (Note well: I said “swapping,” not “paging”; the Unix of the time did not implement paging. There was too little memory per process to make it worthwhile; it was easier to just write the whole thing out to disk…)

For most people, networking was non-existent. The ARPANET existed (and I had used it by then), but to be on it, you had to be a defense contractor or a university with a research contract from DARPA. IBM had assorted forms of networking based on leased synchronous communications lines (plus some older mechanisms for dial-up batch remote job entry), and there was at least one public packet-switched network, but very, very few places had connections to it. The only thing that was halfway common was the dial-up modem, which ran at 300 bps. The Bell 212A full-duplex, dial-up modem had just been introduced, but it was rare. Why? Because you more or less had to lease it from the phone company: Ma Bell, more formally known as AT&T. It was technically legal to buy your own modems, but to hardwire them to the phone network required going through a leased adapter known as a DAA (data access arrangement) to “protect the phone network.” (Explaining that would take a far deeper dive into telephony regulation than I have the energy for tonight.) Usenet originated in a slightly different regulatory environment, though: Duke University was served by Duke Telecom, a university entity (and Durham was GTE territory), while UNC Chapel Hill, where I was a student, was served by Chapel Hill Telephone—the university-owned the phone, power, water, and sewer systems, though around this time the state legislature ordered that the utilities be divested.

There was one more piece to the puzzle: the computing environments at UNC and Duke computer science. Duke had a PDP-11/70, then the high-end model, running Unix. We had a PDP-11/45 intended as a dedicated machine for molecular graphics modeling; it ran DOS, a minor DEC operating system. It had a few extra terminal ports, but these didn’t even have modem control lines, i.e., the ports couldn’t tell if the line had dropped. We hooked these to the university computer center’s Gandalf port selector. With assistance from Duke, I and a few others brought up 6th Edition Unix on our PDP-11, as a part-time OS. Some of the faculty were interested enough that they scrounged enough money to buy a better 8-port terminal adapter and some more RAM (which might have been core storage, though around that time semiconductor RAM was starting to become affordable). We got a pair of VAX-11/780s soon afterwards, but Usenet originated on this small, slow 11/45.

The immediate impetus for Usenet was the desire to upgrade to 7th Edition Unix. On 6th Edition Unix, Duke had used a modification they got from elsewhere to provide an announcement facility to send messages to users when they logged in. It wasn’t desirable to always send such messages; at 300 bps—30 characters a second—a five-line message took annoying long to print (and yes, I do mean “print” and not “display”; hardcopy terminals were still very, very common). This modification was not even vaguely compatible with the login command on 7th Edition; a completely new implementation was necessary. And 7th Edition had UUCP (Unix-to-Unix Copy), a dial-up networking facility. This set the stage for Usenet.

To be continued…

By Steven Bellovin, Professor of Computer Science at Columbia University

Bellovin is the co-author of Firewalls and Internet Security: Repelling the Wily Hacker, and holds several patents on cryptographic and network protocols. He has served on many National Research Council study committees, including those on information systems trustworthiness, the privacy implications of authentication technologies, and cybersecurity research needs.

Visit Page

Filed Under

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

Related

Topics

Cybersecurity

Sponsored byVerisign

Domain Names

Sponsored byVerisign

DNS

Sponsored byDNIB.com

Threat Intelligence

Sponsored byWhoisXML API

New TLDs

Sponsored byRadix

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC