The comp.* hierarchy

Long-form reference · 8,199 words · about a 36-minute read

From net.* to comp.*

The computing groups were the first thing anyone tidying Usenet in the mid-1980s had to deal with, because there were more of them than of anything else and they were named worst. Under the old scheme the shell scripts and programs people posted lived in net.sources, the picture-drawing discussion in net.graphics, the hard Unix questions in net.unix-wizards, and the arguments about the network itself in net.news. Nothing in those names said which was a subject, which a filing cabinet for code and which a piece of self-government, and nothing said what a site would pay to carry them. The Great Renaming — the B News changes of 1986 that made it technically possible, the new names in 1987 — sorted the whole namespace into seven topical trees, of which comp.* took everything about machines and the programs that ran on them. The general account of why the renaming happened, who made it stick and what B News 2.11 had to do with it belongs on the Usenet explainer and is not repeated here.

What is worth stating here is the comp.*-specific paperwork, because two pieces of it survive verbatim in the Usenet administrative record. When the Big-8 Management Board removed the two great source groups in 2006 it wrote their histories into the removal proposals, and those proposals are still on the Internet Systems Consortium’s archive. comp.sources.unix, they record, “was created in April 1987 to replace the moderated newsgroup mod.sources”; comp.sources.misc “was created in April 1987 to replace the unmoderated newsgroup net.sources”. That is the renaming in miniature: a moderated group losing the mod. prefix that B News had once forced on it, and an unmoderated one acquiring a department to sit in, both on the same month’s paperwork.

The tree that resulted is still the largest of the eight, though no longer by much. The ISC distributes two files from which any server can build its own group table — a master active file recording each group’s posting status, and a master newsgroups file pairing every name with a one-line description — and the edition consulted while this page was written, timestamped 26 August 2026, carries 45,003 names in all. Of those, 677 begin with comp. The rest of the Big Eight, on the same day, runs rec.* 659, soc.* 213, sci.* 185, misc.* 100, talk.* 31, news.* 26 and humanities.* 7. comp.* is thus a little over a third of the Big Eight by name count, and its lead over rec.* is now eighteen names. Most of the arithmetic behind that closeness is in one document: the 2011 cull described at the end of this page removed 149 comp.* groups against 29 rec.* ones.

Two cautions about that number. It counts names a hierarchy’s administrators still maintain, not groups anybody reads: 642 of the 677 are flagged y in the active file, meaning unmoderated and open to posting, and 35 are flagged m for moderated, and neither flag is a statement about traffic. And the article counters shipped beside each name in the active file are placeholders — the same pair appears against all 45,003 entries — so no figure on this page is a measure of how busy anything was.

How to read a comp.* name

A comp.* name is read left to right as a narrowing, and the second component is the department. That is the whole convention, and it is the reason a reader who had never heard of a group could often guess its address: comp.lang.python for the Python group, comp.os.minix for the MINIX group, comp.sys.mac.system for Macintosh system software. The guess worked because the second level was a small, stable vocabulary that hardly changed in twenty years. Counted in the current master file, the comp.* second level distributes like this:

• comp.sys.* (163 groups) — particular machines, named by manufacturer or model line: the Amiga, Atari, Apple II, Macintosh and IBM PC families and their many neighbours. The odd entry on that shelf is comp.sys.arm, which is named for an instruction set rather than a machine, because by the time it existed the machines running it were built by companies with nothing else in common; the architecture’s own history is told on that page.
• comp.os.* (98) — operating systems, one sub-branch per system, sized by how much argument the system generated: ms-windows 34 groups, os2 22, linux 16, msdos 7, and then a long tail of single rooms for QNX, VMS, RSTS, Plan 9, OS-9, LynxOS, CP/M, Coherent, Mach, Magic Cap, pSOS and, still listed today, comp.os.minix.
• comp.lang.* (87) — programming languages, one per language and sub-branches where a language grew a dialect problem: java 11 groups, pascal 7, perl 5, basic 5, c++ 4. comp.lang.ruby is the late arrival on that shelf, voted in only in 2000, years after the language itself.
• comp.unix.* (29) — Unix as a subject in its own right, split by vendor and by lineage, which is what the 1992 reorganisation described below was about.
• comp.databases.* (29) — database systems, almost all of them named after something you could buy. comp.databases.pick is one of the few named after a way of thinking about data rather than a product.
• comp.infosystems.* (22) — the network services themselves, from comp.infosystems.gopher, dating from the years when Gopher was the service in question, through to the comp.infosystems.www.* family that replaced it.
• comp.graphics.* (20) — divided, unusually, by role rather than by subject: comp.graphics.api.opengl for the interface, comp.graphics.apps.photoshop for the application.
• comp.dcom.* (20) — data communications, meaning the wires and the boxes: cabling, modems, Ethernet, SDH and SONET, VPNs, xDSL, voice over IP, and the vendor rooms comp.dcom.sys.cisco and comp.dcom.sys.nortel. comp.dcom.telecom, moderated, is the branch’s edited room.
• comp.soft-sys.* (16) — applications too large to be tools and too specific to be languages: SAS, SPSS, MATLAB, PowerBuilder, SAP, ESRI’s GIS, and the computer-algebra shelf comp.soft-sys.math.* holding Mathematica, Scilab and comp.soft-sys.math.maple.
• comp.text.* (7) — text processing and markup: FrameMaker, Interleaf, SGML, XML, PDF, and comp.text.tex, the working group of the TeX world.

Below those sit the branches that never needed depth. comp.arch is a bare two-component name for computer architecture, with comp.arch.arithmetic, comp.arch.embedded, comp.arch.fpga, comp.arch.hobbyist and comp.arch.storage hung off it later; comp.risks, comp.dsp, comp.fonts, comp.software-eng and comp.misc are single rooms with no children at all, which in this namespace is a statement that the subject is broad but not busy; comp.programming and comp.compilers grew three and two names apiece and stopped, and comp.theory grew exactly one, comp.theory.cell-automata. comp.std.* holds the standards groups, comp.org.* the professional societies — the ACM, the IEEE, USENIX, UniForum — and comp.society.* the groups that considered computing rather than did it.

Three further branches carry more weight than their names suggest. comp.protocols.* (13 groups) is where the internet itself was discussed group by protocol — TCP/IP and its domains, NFS, PPP, SNMP, Kerberos, BIND, SMB and network time; comp.mail.* (15) covers mail systems and their software, from sendmail and UUCP mail to Elm, MH, Pine, Mutt and MIME; and comp.security.* (7) holds firewalls, Unix security, SSH and a three-group shelf for PGP. comp.windows.* (7) is the windowing branch, with comp.windows.x at its centre and rooms for the X toolkit, Motif and KDE.

Two of this directory’s pages sit at the awkward edges of the scheme. comp.os.msdos.4dos is a fourth-level name for a single commercial product, about as far as the Big Eight was ever willing to follow a shareware utility; only one name in the whole DOS branch goes deeper, comp.os.msdos.programmer.turbovision. comp.publish.* is a branch address with no group at the top of it: the master file lists comp.publish.prepress, comp.publish.cdrom.hardware, comp.publish.cdrom.software and comp.publish.electronic.misc, and nothing called comp.publish or comp.publish.cdrom, so the branch exists only as the shared prefix of its children.

A subhierarchy earned its own level

The governing rule of the namespace was that depth had to be earned. A subject started as one group; if the traffic in that group became unreadable, its readers proposed a split, and the proposal succeeded or failed on whether enough of them wanted the extra rooms. Nobody built empty scaffolding in advance, and proposals that tried were told to wait. The best-documented statement of the principle is in the 1990 proposal to reorganise comp.sys.mac, where a list of suggested Macintosh groups for databases, communications, spreadsheets and word processing was set aside with the note that they “should be considered as sub-groups of the c.s.m.appl hierarchy and we should wait and see how traffic in that area works out before considering splitting it further”.

That proposal is worth following, because it shows the whole mechanism working at once. Chuq Von Rospach, then at Apple, opened a call for discussion on 19 February 1990 on the ground that comp.sys.mac was overloaded and that creating one more group beside it would need doing again in two or three months. His preliminary proposal renamed comp.sys.mac to comp.sys.mac.misc — explicitly to bring it “into the same standardized naming as other hierarchies” and to stop people posting to the parent group just in case — and created rooms for system software, applications and wanted requests. He also published his rejected proposals with reasons, and the reasons are a compact statement of comp.* taxonomy: fonts belonged in comp.fonts, desktop publishing in comp.text.desktop, viruses in comp.virus, none of them under comp.sys.mac, because those subjects were not Macintosh subjects that happened to involve fonts but font subjects that happened to involve a Macintosh.

Names changed under discussion, too, which is the point of having a discussion period at all. By the call for votes of March 1990 the proposed comp.sys.mac.appl had become comp.sys.mac.apps, the applications sub-hierarchy that had justified the shorter spelling had been dropped, comp.sys.mac.os had become comp.sys.mac.system, and three further groups had been added from the survey of readers’ suggestions: comp.sys.mac.games, comp.sys.mac.comm, and a moderated comp.sys.mac.announce for the low-volume notices. One proposal went the other way and was cancelled before the ballot: a Macintosh virus group, which the reorganiser had already argued belonged in comp.virus. The groups that emerged are the ones the master file still lists: comp.sys.mac.misc for general discussion, comp.sys.mac.system for system software, comp.sys.mac.apps for applications.

The comp.unix.* reorganisation of 1992 makes the same argument about a different fault. Chip Salzenberg’s request for discussion of 17 July 1992 proposed splitting System V by release, renaming comp.unix.msdos because its name misled readers into thinking it meant Unix on MS-DOS hardware, and abolishing comp.unix.sysv286 and comp.unix.sysv386 on a taxonomic complaint stated in one sentence: those names “mix together UNIX version and hardware platform”. As with the Macintosh proposal, the names on the ballot were not the names in the proposal — the System V groups arrived as comp.unix.sys5.* rather than the proposed comp.unix.usg.*, and the hardware group became a pair, comp.unix.pc-clone.16bit and comp.unix.pc-clone.32bit. The vote ran four weeks and closed on 14 September 1992 with 321 valid ballots, and every one of the nine proposals passed.

How a comp.* group came into existence

Almost every group named on this page that postdates the renaming was created by the same procedure, in one or another of its successive revisions, and that procedure is set out in full, with its own history, on the news.* page. In outline it ran: a Request for Discussion posted to the moderated group news.announce.newgroups and crossposted to news.groups, carrying a rationale and a charter for every group proposed; a discussion period of at least twenty-one days conducted in news.groups; a Call for Votes issued not by the proponent but by a neutral member of the Usenet Volunteer Votetakers; twenty-one days of voting by e-mail; a RESULT posting listing the name, a form of the e-mail address, and the vote of everyone who had voted; five days for objections; and only then the newgroup control message, which every news administrator on the network remained free to ignore.

The threshold is worth quoting exactly, because it is misremembered in two forms that are really one requirement stated twice. The guidelines in force while this gateway ran say that each separate proposed change passes if and only if it “received at least 100 more YES than NO votes and received at least twice as many YES as NO votes”. The hundred-vote margin stopped a handful of enthusiasts creating a group; the two-to-one ratio stopped a large and hostile electorate being outvoted by a slightly larger one. Both conditions had to hold, and in the comp.* votes reproduced on this page it is the ratio rather than the margin that does the killing.

The same guidelines constrain the names themselves, which is why the namespace is as tidy as it is. Each component of a proposed name had to consist solely of lowercase ASCII letters, digits, plus signs or dashes, had to contain at least one letter, and had to be no more than twenty characters long. That rule is why comp.lang.c++ is legal and why nothing in the hierarchy carries a capital, an underscore or a space.

A clean example of the machinery producing a group this directory holds: comp.lang.ruby went to a Big-8 ballot that closed on 20 April 2000 and carried on its first attempt, 200 votes to 16 — a margin of 184 and a ratio of more than twelve to one, which is what an uncontested proposal for an obviously missing group looked like.

The objections comp.* proposals actually met

Because comp.* proposals were about products and platforms rather than about nations or beliefs, they attracted a distinctive set of objections, and three of them recur across the decades.

The first was that a Big Eight group should not be a product’s support desk. The complaint was never that commercial software was off-topic — comp.databases.* reads like a trade-show floor plan and comp.soft-sys.* is a shelf of vendor names — but that a group named for one shipping product would live and die with it, leaving a name in the namespace after the product had gone. The argument was fought group by group, and the namespace it left behind suggests which way it mostly went, though no single vote settled it. Product-named groups did stay rare enough to be remarked on: comp.os.msdos.4dos, this directory’s example of a group named for one commercial utility, is discussed on its own page. The objectors were not wrong about the risk: comp.databases.revelation, comp.graphics.apps.freehand, comp.lang.lisp.mcl and comp.emulators.mac.executor all outlived any traffic about their subjects and were swept up in the 2011 removals.

The second was that vendors should run their own rooms rather than ask the Big Eight for one. That objection was answered, in the end, by the vendors themselves: rather than propose groups through news.groups, several large software companies stood up hierarchies on their own news servers and peered them widely, of which microsoft.public.* is the largest surviving example in the master file — 1,770 names, more than twice the whole of comp.*. That hierarchy’s administration and retirement are documented on its own page; Adobe ran the smaller adobe.* on the same principle, and this directory holds pages from both. The effect on comp.* was that vendor support traffic drained out of the Big Eight into namespaces where a company could create a group by editing a file.

The third, and the one that shaped the hierarchy most, was the split-versus-single-group argument. Splitting a busy group promises quieter rooms and delivers, immediately, a period in which every regular has to resubscribe, every crossposter guesses wrong and the FAQ has to be posted to four places. The case against a split was simply that readers who had been through one would vote against the next. The comp.os.linux vote of 1992 is the classic instance and is described below; the pattern it shows — an announcement group passing comfortably while the discussion groups fail on the ratio — repeats across the hierarchy.

The comp.os.linux vote, and what it proves

On 18 September 1992 Ian Jackson posted a request for discussion to news.announce.newgroups, crossposted to comp.os.linux, comp.os.mach and comp.os.minix, observing that comp.os.linux was “seeing a continual increase in traffic” and that the range of postings was broadening with the user base. His opening sketch proposed an announcements group, a design group and a bugs group, with the original group kept for everything else; on the question of directing newcomers elsewhere he was realistic in advance, noting that trying to get new users to ask their questions in a questions or help group “is probably futile”.

By the call for votes of 4 November 1992 the proposal had become four groups: comp.os.linux.announce, moderated, with named moderators; comp.os.linux.questions; comp.os.linux.bugs; and comp.os.linux.misc. The result was posted on 1 December 1992, and it is one of the most legible documents in the whole archive because the votetaker published the arithmetic beside the tallies:

.announce 479 yes, 131 no — PASS. .questions 380 yes, 217 no — FAIL (ratio). .bugs 390 yes, 212 no — FAIL (ratio). .misc 390 yes, 207 no — FAIL (ratio).

Six hundred and thirteen people voted. All four proposals cleared the hundred-vote margin with room to spare; three of them failed anyway, because a shade under two-thirds of the voters is not two-thirds. The moderated announcements group — the one nobody would have to read against their will — passed at better than three and a half to one. That is the split-versus-single argument in one table: a technical readership will readily vote for a low-volume moderated noticeboard and will not readily vote to be sorted.

The sorting happened later anyway, as traffic decided it should. The master file today lists sixteen comp.os.linux.* groups, among them the announce group that passed in 1992, comp.os.linux.misc, comp.os.linux.setup, comp.os.linux.hardware, comp.os.linux.networking, comp.os.linux.security and the development pair comp.os.linux.development.apps and comp.os.linux.development.system, plus rooms for the ports to Alpha, PowerPC, m68k and, inevitably, the Xbox.

Moderation in the technical hierarchy

Traffic in the technical groups fell into a small number of recurring genres, and knowing them is most of what a reader needed: the beginner’s question and the answer that corrected its premise, the bug report that turned into a diagnosis, the release announcement, the periodically posted FAQ, and the long argument over which of two designs was correct. The language groups argued indentation and undefined behaviour; the operating-system groups carried the Unix wars in real time; the database and application groups accumulated the unglamorous operational knowledge that keeps businesses running. The ordinary discussion groups were unmoderated, so all of it ran in one stream, and the moderated groups existed exactly where that stream would not do.

Moderation on Usenet is a mechanism rather than a policy: a reader’s posting to a moderated group is mailed to the moderator instead of being injected, and the moderator either discards it or reposts it carrying an Approved header, without which conforming servers will not propagate it. comp.* used that mechanism sparingly and for three specific purposes, and the proportions have barely moved: of the 677 comp.* names in the current master file, 35 are flagged moderated.

The first purpose was the announcement group — a low-volume noticeboard beside a noisy discussion group, which is what comp.os.linux.announce, comp.os.os2.announce, comp.sys.acorn.announce, comp.sys.atari.announce, comp.lang.perl.announce, comp.lang.python.announce, comp.unix.bsd.freebsd.announce and comp.unix.bsd.openbsd.announce all are. The second was the edited digest, discussed in the next section. The third, and the contentious one, was moderating a discussion group for quality.

comp.lang.c.moderated is the documented case. John William Chambless posted the request for discussion on 23 November 1994 with a rationale that any regular of a large language group would recognise: the noise level had become unbearable, various ways of keeping things reasonable had failed, and the main problem was newcomers who could not be expected to know that their question was a FAQ or that it was an operating-system question rather than a C question. The charter was blunt about scope — “For the discussion of C programming topics that are NOT system-specific and NOT covered by the c.l.c. FAQ”, with obvious homework off-topic — and the proposal named a volunteer moderator, Peter Seebach, and illustrated the charter with real subject lines from recent traffic, portability of TRUE and FALSE and the use of goto on the acceptable side, a kbdhit() function in Unix and how to write a getch() under Ultrix on the other.

What made it unusual was the moderation policy, stated in the proposal in a single sentence that no general-purpose forum would write today:

The moderator will reject off-topic messages, as well as incorrect answers to questions (within reason).

The vote was taken by Ron Dippold of the Usenet Volunteer Votetakers and the result posted on 7 March 1995: 330 yes, 14 no, 344 valid votes. comp.lang.c.moderated and comp.lang.c++.moderated are both still flagged moderated in the master file, sitting beside their unmoderated parents, which is the arrangement the Big Eight settled on wherever a language group grew too large to read.

The technical hierarchy also carried moderated groups that were really mailing lists wearing a newsgroup’s name. comp.society.privacy is the example this directory holds: a moderated group that was one face of the Computer Privacy Digest, distributed as numbered issues by e-mail and gatewayed into Usenet, and removed in January 2010 when the moderator’s address of record stopped accepting probe posts. Its page tells that story; what it illustrates for the hierarchy is that a comp.* moderated group could outlive the person who agreed to read every article, and that when it did, the removal machinery eventually noticed.

comp.risks: forty years of a moderated digest

The standing example of what moderation could achieve in this hierarchy is comp.risks, whose newsgroups-file description has never needed rewriting: “Risks to the public from computers & users. (Moderated)”. The group exists solely to carry the RISKS Digest, formally the Forum on Risks to the Public in Computers and Related Systems, published by the Association for Computing Machinery’s Committee on Computers and Public Policy and edited throughout by Peter G. Neumann.

Its origins are institutional rather than Usenet-native, which is exactly why it worked. Neumann established the forum in 1985 at the request of the ACM’s then president, Adele Goldberg, whose letter in the February 1985 Communications of the ACM the first issue cites as its inspiration. That first issue is dated Thursday 1 August 1985 and opens by defining the subject as whether critical requirements for human safety, reliability, fault tolerance, security, privacy, integrity and guaranteed service can be met, and what follows when they are not. It was, from the beginning, an edited periodical that happened to travel as news articles.

The publication record is complete and public, and it is a long one. Volume 1 ran from 1 August 1985 to 31 January 1986 across 45 issues. Volumes 2 to 33 followed on a frequent but irregular schedule, most of them running to between eighty and ninety-nine issues; volume 12 covers the second half of 1991, volume 20 the years 1998 to 2000, volume 30 the years 2016 to 2018. Volume 34 opened on 30 December 2023 and closed with issue 91 on Sunday 12 April 2026. Neumann died on 17 May 2026, and the digest has not appeared since. Thirty-four volumes over forty years and eight months is a publication run that very few peer-reviewed journals manage, achieved by one editor reading his inbox.

The digest form itself — a numbered issue with a masthead, a table of contents and several contributions concatenated into one article — is older than Usenet and was borrowed from the mailing lists. RFC 1153 of April 1990, which finally wrote the format down, dates the practice to the mid-1970s: high-volume lists had appeared, and their moderators developed a way to enclose several messages in one composite message for redistribution. It suited a moderated newsgroup perfectly: one article per issue instead of one per contribution, a stable citation for anything published in it, and a form in which the moderator’s editorial hand was visible rather than hidden. Several comp.* groups ran the same way, and comp.risks is simply the one that kept going longest.

Software distributed as postings

Before the web, and before anonymous FTP was something every reader could reach, one obvious way to obtain a program was to read it out of a newsgroup. The moderated comp.sources.* groups — comp.sources.unix, comp.sources.misc, comp.sources.games and their siblings for the Amiga, the Apple II, the Macintosh, Acorn machines, CP/M, MINIX, PostScript and the X Window System — carried complete working programs as ordinary articles, issued in numbered volumes. A submission went by mail to the group’s moderator; once it was approved and posted, every site carrying the group held the software, because the news system had already copied it there whether the site wanted it or not.

The division of labour between the two big groups was written down, and comp.sources.misc’s charter is the more entertaining half of it. Quoted in the 2006 removal proposal from the group’s own monthly informational posting, it reads:

This newsgroup is not for large programs which belong in other sources groups; it is for sources which do not fit elsewhere (for example, MS-DOS and VMS non-game sources) and for the small stuff -- for example, your favorite shell script to set your prompt or etc. -- the little stuff that just doesn't warrant submission to comp.sources.unix (formerly mod.sources), where it'd look a bit silly next to the latest version of Xterm....

The same charter routed argument away from the code: discussion went to comp.sources.d “rather than cluttering this newsgroup”, and programs with more than one source file were forwarded to comp.sources.unix. That is the whole editorial policy of a software repository, in two clauses, written before anyone had a word for the concept.

The container was the shell archive. A shar file — the first such utility is credited to James Gosling, in 1982 — is a plain-text Bourne shell script that recreates a set of files when it is run. Being text all the way through, it survived the mail and news gateways that mangled anything binary, and it needed no tool at the far end that the reader did not already have: saving the article and feeding it to the shell was the installation procedure. Improved shars were themselves distributed as sources postings, which is how the archive comes to contain both a program called cshar, described as an “improved version of shar”, and one called newshar, offered as “The Connoisseur’s Shar, version 2”.

Binary material, where it could not be avoided, was wrapped in uuencoding, the binary-to-text encoding that Mary Ann Horton had written at Berkeley in 1980 as uuencode and uudecode. It expanded a file by roughly a third and produced pages of dense unreadable text, and it was the only thing that reliably crossed a network of machines that agreed on nothing except seven-bit characters. Later versions of shar learned to call it.

Parts, patches and the archive that still holds them

Anything larger than a few hundred lines had to be split. A program went out as a numbered sequence of articles, and the reader saved each in turn and reassembled them by hand, in order, with the leading and trailing news headers stripped. This worked exactly as well as the propagation of the underlying network, which is to say that the characteristic message of the era was a request for the missing piece. The 1990 Macintosh reorganisation proposed a group for that traffic and described its contents in the reader’s own voice: a place for the “I’m missing part five of...” and “I need a program that does...” messages. comp.sources.wanted, still listed today with the description “Requests for software and fixes”, was the hierarchy-wide version of the same room.

Revising software distributed like that was the harder half of the problem. Reposting an entire program to correct three lines was intolerable on a network moving its articles over dial-up telephone links at night, so changes shipped as diffs — and the tool that made that practical came out of these same groups. Larry Wall’s patch was posted to mod.sources, which became comp.sources.unix, in May 1985: it applied a diff to a source tree and tolerated the line-number drift that accumulated as everyone’s copy diverged, which is the property that made distributed maintenance possible at all. The unified diff format arrived by the same route five years later, Wayne Davison’s unidiff appearing in volume 14 of comp.sources.misc in August 1990, a month before the format was added to GNU diff.

The archive of what the biggest of these groups actually carried is still online, and reading its index is a better description of the practice than any summary. The Internet Systems Consortium mirrors comp.sources.unix in twenty-nine volumes, and volume 1 — which carries material from the mod.sources years, its files timestamped 1986 — holds, among its contents: compress release 3.0; a public-domain getopt; a C cross-referencer; a contextual diff for Bell systems; the Bourne shell with history, tilde expansion and job control in nine parts; Terminfo and Curses in eleven; XLISP 1.4 in four; Sun RPC in ten; Larry Wall’s newsreader rn version 4.3 in nine kits, followed immediately by rn/patch01; and, sitting quietly in the alphabetical list, an entry reading simply “patch1.3    patch version 1.3”. The index even preserves the mail-server syntax a reader used to fetch a part they had missed.

The groups doubled as a release channel for new work. Larry Wall published the first version of Perl on Usenet in December 1987, version 1.0 carrying the date 18 December. NetHack’s first release, 1.3d of 28 July 1987, went out through comp.sources.games as a multipart posting in volume 2, and the archived parts are still cited as the release’s primary evidence. Taken together the comp.sources.* groups amounted to a package repository before package repositories — with a moderator in place of a maintainer, volume-and-part numbering in place of version tags, and a distribution network that pushed every release to every subscribing site whether it had asked for it or not.

How the sources and binaries groups ended

They ended slowly and then were tidied up in one afternoon. comp.sources.misc took its last approved posting in April 1995; comp.sources.unix took its last in December 1998. Nothing was announced at either point — a moderated group with no moderator simply stops producing articles — and the names sat in the master file until 2006.

In June 2006 Jim Riley proposed removing both, with a rationale of two sentences: the date of the last approved message, and the observation that there were now more suitable means of distributing program sources, so neither group was a candidate for conversion to an unmoderated one. The comment period produced, in the archive’s laconic phrase, no comments at all. The Big-8 Management Board voted on 11 and 12 July 2006 and both groups were removed on 17 July.

The binaries groups went in the same sweep, and their removal proposal is the clearest statement anyone in the Big Eight ever wrote about why distributing software as postings had stopped making sense. Of comp.binaries.ibm.pc — created in June 1987, unmoderated that November, moderated again in May 1988, and without an approved message since February 1996 — the proposal argued that the binaries groups had been created before widespread Internet access, when propagation by Usenet was a real alternative to posting floppies; that short expiry periods meant a reader had to watch a group constantly or hope somebody was archiving it, in which case FTP would have served better anyway; that large programs split across many parts lost parts; that Google archived the groups but not their binary content, which was the whole reason the groups existed; and that a moderator might be held responsible for whether the software was legal, functional and free of viruses. It closed the argument with a policy statement: “unmoderated binaries groups are not acceptable in the Big 8”.

The proposal said plainly that it was one of several intended to remove every comp.binaries.* group except comp.binaries.cbm, and the master file records that this is exactly what happened: comp.binaries.cbm, “For the transfer of 8bit Commodore binaries”, is the only name left under that branch. The surviving comp.sources.* groups are the four that never carried code — comp.sources.bugs, comp.sources.d, comp.sources.testers and comp.sources.wanted — four rooms for talking about source postings that no longer arrive.

August 1991, in comp.os.minix

The best-known posting in this hierarchy’s history was not a source release. comp.os.minix — still listed today, still described in five words as “Discussion of Tanenbaum’s MINIX system” — existed for the teaching Unix that Andrew S. Tanenbaum had released in 1987 to accompany his operating-systems textbook: source available, modification and redistribution restricted, and a sixteen-bit design increasingly at odds with the cheap 32-bit hardware its readers were buying.

A student at the University of Helsinki had already used the group for the unglamorous preliminaries. On 3 July 1991 Linus Torvalds posted there asking where he might obtain a digital copy of the POSIX standards documents, having decided to implement Unix system calls in a project of his own; he did not find them, and worked the calls out instead from the SunOS documentation his university held for its own server and from Tanenbaum’s MINIX text. On 25 August 1991, aged twenty-one, he posted again:

Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).

It is worth being exact about what the newsgroup did and did not carry, because the posting is quoted so often that the surrounding facts get compressed. The group carried the announcement, the requests for feedback, the argument and the early bug reports. It did not carry the kernel. Version 0.01 was released publicly on 17 September 1991 by upload to FTP, to the Finnish academic network’s server ftp.funet.fi — one of whose volunteer administrators, Ari Lemmke of Helsinki University of Technology, disliked the name Freax that Torvalds had been using and filed the directory under Linux instead, which is how the system acquired the name its author had thought too egotistical to use.

The most consequential thread the group ever carried opened on 29 January 1992, when Tanenbaum posted an article headed LINUX is obsolete, and the case for microkernels against monolithic kernels was worked through in public, at length, by the author of the textbook and the author of the kernel. Whatever it settled about operating-system design, it is a fair sample of what a comp.os.* group was for: two people who had written the code arguing about it in a room anyone could read, with the argument preserved because the medium preserved everything by default.

Linux then left. comp.os.linux was created, split unevenly by the 1992 vote described above, and grew into the sixteen-group branch the master file lists today. comp.os.minix remains a single line in that file, which is a reasonable epitaph for a teaching system whose newsgroup was, for one autumn, the most consequential room on the network.

FAQs, comp.answers and the archive at MIT

The other thing this hierarchy built and handed to the rest of the network was the FAQ as a document type. The invention of the form belongs to an ARPANET mailing list and is told on the Usenet explainer; what comp.* did was industrialise it. A group’s regulars wrote down the answers they were giving over and over, and the file was reposted on a schedule — monthly at first, weekly or daily in the busiest groups — so that a newcomer arriving inside the server’s expiry window met the answer before asking the question. Jef Poskanzer is credited with the first weekly FAQ, posted to net.graphics and comp.graphics; Eugene Miya tried the first daily one.

Volume created the need for somewhere to put them. comp.answers was created by control message on 12 January 1993, after a vote reported in news.announce.newgroups on 7 January had carried it 258 to 27, and the control message that created it is a compact statement of the whole system. It gives the newsgroups line still in use — “Repository for periodic USENET articles. (Moderated)” — and the working addresses, both at MIT: submissions to [email protected], moderator contact to [email protected], then Jonathan Kamens. It quotes the parent charter from the introduction to news.answers:

The news.answers newsgroup serves as a repository in which periodic informational postings (a.k.a "Frequently Asked Questions" postings, or "FAQs") from other newsgroups are posted.

And it adds the one rule that makes a per-hierarchy answers group different from the general one: each such group “will contain only periodic informational postings that are also posted to other newsgroups in the same hierarchy”, so that comp.answers holds only what appears in at least one other comp.* group. The same document offers, as its worked example of a qualifying posting, the comp.unix.questions FAQ under its real title, “Frequently Asked Questions about Unix - with Answers [Monthly posting]” — a document type announcing its own posting frequency in its subject line, which tells you most of what you need to know about how these files were meant to be read.

From the answers groups the files were collected into an archive at MIT, reachable by anonymous FTP at rtfm.mit.edu under directories for news.answers and for FAQs by subject, and later mirrored on the web. Those files outlived a great many of the groups that produced them and a good deal of the software they described. Reference works still cite them by their old FTP paths — encyclopaedia articles on 1980s video hardware and on 1990s Unix workstations both currently source claims to files at rtfm.mit.edu — which is a durability record most documentation formats would envy.

Netiquette, noise and the things comp.* readers did about them

The unmoderated majority of the hierarchy defended itself with conventions rather than machinery, and the conventions were written down often enough to become quotable. RFC 1855, the Netiquette Guidelines of October 1995, records both the crossposting rule as comp.* practised it — that an article of interest to several groups should be crossposted rather than posted separately, and that in general only five or six groups have interests similar enough to warrant it — and the sanction for ignoring the FAQ, in a sentence that is unusually candid for a document in the RFC series: asking a newsgroup where answers are readily available elsewhere “generates grumpy” replies telling the asker to read the manual, with a note that a more vulgar reading of the abbreviation is usually implied.

The reason those conventions were about disk and bandwidth as much as manners is visible in the design of the medium: crossposting stores one copy that appears in several groups, while multiposting stores several, and on a network where every participating server paid for its own storage that difference was the entire argument. The individual reader’s defence was the killfile, a private list of authors and subjects the newsreader would silently discard, which inverts the modern model by putting the filter at the reader rather than at the platform.

Against organised abuse the technical hierarchy had less to offer than the administrative one, and mostly borrowed. The measurement of spam by the Breidbart Index, the cancel-issuing volunteers, the net-abuse groups and the arguments about all three are the news.* hierarchy’s subject and are told on the news.* page. What comp.* contributed was the policy on binaries quoted earlier, arrived at group by group over twenty years and finally stated flatly in a removal proposal: the Big Eight would carry programs only where a moderator stood behind them, and when the moderators stopped, the groups went.

Where the traffic went

What dispersed the hierarchy was not one competitor but four, and they arrived in a sequence that can be dated.

Project mailing lists took the developer conversation first, and in several cases took it by gateway rather than by migration: a list and a newsgroup joined so that a message sent to either appeared in the other, after which the archive of record was the list’s. The comp.lang.ruby page documents one such gateway in detail, built in 2001, and the effect it had on where the group’s traffic can now be read. What took the releases and the patches, which had been the sources groups’ entire purpose, was at first nothing more modern than anonymous FTP: the argument that a reader who could fetch a program over the internet had no need of the Usenet copy is made in as many words in the 2006 binaries removal proposal quoted above. The sources groups’ last approved postings, in 1995 and 1998, come before the source-hosting sites existed; version-control hosting inherited a job that had already left.

Vendor forums took the support load. The move began inside Usenet’s own protocol, with company hierarchies on company news servers, and ended on company websites; the largest of those hierarchies survived in the master list long after the server that justified it was retired in 2010. Then the question-and-answer sites took the questions. Stack Overflow launched on 15 September 2008, and it inherited more than the traffic: the FAQ reflex, the demand for a minimal reproducible example, the insistence that the asker do the reading first, and the practice of editing a question until it is answerable are all comp.* habits with new interfaces.

The archives changed hands in parallel. Web-based archiving of Usenet began at Deja News in March 1995; Google acquired that database in February 2001 and folded it into Google Groups, which is why a comp.os.minix thread from 1991 or a comp.lang.c argument from 1994 can still be read in something close to its original form. On 22 February 2024 Google Groups stopped supporting new Usenet content — posting and subscribing were disallowed and new articles from Usenet peers stopped appearing — while viewing and searching the accumulated archive continued as before.

The Big Eight then tidied up, and comp.* supplied most of what was tidied. On 1 February 2011 the Big-8 Management Board opened a proposal called the Great Downsizing to remove 198 unmoderated newsgroups, on stated criteria that avoided any judgement of merit: no moderated groups, no names ending in .misc, and zero on-topic, non-crossposted threads in the previous eighteen months, with on-topic questions that received no answer not counting. The result of 24 April 2011 removed all 198. Of those, 149 were comp.* groups — against 29 in rec.*, twelve in misc.*, four in sci.*, three in soc.* and one in news.*. Three-quarters of the cull came out of a single hierarchy, which is what happens to a namespace organised by product when the products stop shipping.

The board recorded the objection honestly, which is more than most institutions manage while closing something down: the discussion, it noted, raised opposition to removals in principle and the notion that some groups have a function beyond mere traffic, but the claim that these particular groups had not been used for a long time “was not disputed”.

What still carries comp.*

The namespace has not been retired. As of the master files consulted on 26 August 2026, comp.* is 677 names — 642 open unmoderated groups and 35 moderated ones — and remains the largest branch of the Big Eight. Servers that carry text groups still carry it, and a reader with an NNTP client can still post to groups created by hundred-vote majorities thirty years ago.

The machinery still runs, and it now mostly declines to act. On 10 October 2025 Marco Moock put three removal proposals through news.announce.newgroups, aimed at comp.unix.* groups he judged no longer used well: comp.unix.sys5.misc and comp.unix.sys5.r4 in one, comp.unix.bsd.386bsd.misc and comp.unix.bsd.bsdi.misc in another, comp.unix.user-friendly in a third. The rationale proposed sending their readers to comp.unix.misc, and said plainly that if people declared an interest in the groups he suggested not deleting them. All three results were posted on 2 April 2026 and all three say the same thing: the groups will not be removed. The board’s tally on each was one vote in favour of deletion, one against, one abstaining and one member not voting. All five names are still in the master file.

What that list preserves is uneven in a way worth stating. Some entries are working rooms; some are names whose subjects have not been discussed in decades and which survived the 2011 cull only by ending in .misc or by being moderated; some describe software no longer sold by companies no longer trading. comp.software.year-2000, “Year 2000 compliance: projects and issues”, is still on the list a quarter of a century after the deadline it was named for; comp.lang.javascript is still described as “Netscape Communications Corp.’s JavaScript language”; and comp.databases.pick still carries the description its 1993 control message gave it. Nobody has troubled to rewrite any of them, which is itself a fact about how the namespace is maintained: by control message, only when someone proposes one.

The loss, when the comparison is made honestly, is structural rather than sentimental. comp.* offered one public room per subject, in a single namespace anyone could enumerate from a file, replicated to every participating server rather than held on one company’s, and archived in a form that could still be cited years later by a stable identifier. A modern answer lives in an issue tracker, a forum and a chat channel at once, and any of the three can be closed by its owner without notice or archive. The hierarchy’s own habit of writing everything down — every proposal, every tally, every removal, in a moderated group whose contents are still on a public FTP server — is why this page can quote thirty-year-old arguments exactly and why so much of what it says can be checked.

Scope and limits of this page

This site preserves no comp.* message archive. news2mail.com was a Usenet-to-e-mail gateway between 2000 and 2004, and what survives of it is a directory of the groups it served, not their articles. Nothing on this page is derived from message content held here; the group names, descriptions and moderation flags come from the Internet Systems Consortium’s master files, and the proposals, charters, tallies and removal notices quoted above come from the news.announce.newgroups and control-message archives on the same server, which anyone may read.

This page claims no traffic figures for any comp.* group and no readership estimates for the hierarchy. Vote tallies are quoted where the archive holds a RESULT posting and are the number of ballots cast, which is not the number of readers. Where a group’s own story belongs to a page in this directory — the ARM architecture, the Pick system, TeX, Maple, Ruby, 4DOS, the privacy digest, electronic prepress and CD-ROM publishing — it is named here as an example of a naming pattern and told there. The group list is a snapshot of what the gateway itself carried, taken in the years the namespace was already emptying, and it is a sample of comp.* rather than a census of it.