Posted on

Ancient Web: Beastie’s Official Home Explains Why the BSD Daemon Is Not Chuck

The BSD daemon is one of those computer mascots that escaped the operating system and became part of hacker culture. His official home still looks appropriately like something maintained by people who care more about provenance than redesigns.

The History of the BSD Daemon lives at McKusick.com.

The first thing the page clears up is the name. The daemon is not officially named Chuck. Marshall Kirk McKusick says that name came from an advertising myth associated with Walnut Creek. If you insist on calling the character something, the site suggests “beastie,” a play on the letters BSD.

From there the site becomes a surprisingly detailed history of Unix culture expressed through drawings, book covers, T-shirts, conference swag, legal permissions, and inside jokes.

The black-and-white 4.2BSD daemon appeared on the 4.2BSD manuals published by USENIX. Years later, a group at Kansas State University decided they wanted a UNIX shirt. They scanned the old artwork, edited it on a Sun workstation, printed copies, and sat around with colored pencils until they found a color scheme they liked. The initial run was only about forty shirts.

The 4.3BSD daemon has another famous connection: the artwork used on The Design and Implementation of the 4.3BSD UNIX Operating System was drawn by John Lasseter, long before his name became universally associated with Pixar.

The site also preserves the stranger administrative side of mascot history. McKusick has a page explaining how the daemon artwork may be used, why permissions matter, and why he became serious about protecting the figure after nearly losing control of it to a company. There are galleries covering FreeBSD, NetBSD, OpenBSD, USENIX, “!DOS,” Lego versions, cakes, shirts, and other mutations of the character.

This is where an old personal website can beat a modern summary page. It does not merely tell you that Beastie exists. It preserves who made which version, what it appeared on, why particular shirts were printed, and how the image moved through actual Unix communities.

The page is basically oral history with HTML around it.

You can still wander through the BSD daemon archive and follow the individual designs into their stories. CacheRat’s 1,967 Ancient Web Domains research list contains more sites where the people involved in computing history simply documented it themselves instead of waiting for somebody else to summarize it later.

Posted on

Ancient Web: The UUCP Project Mapped a Network Before the Internet Looked Like One

Before Internet routing became invisible infrastructure, one very practical problem was simply figuring out how to get from one Unix machine to another through a chain of dial-up connections.

Visit The UUCP Project, 1984

The Stargate Internet Museum’s page explains the problem neatly. Steve Bellovin had written pathalias, a program that could create routing information if it had a map of the network.

The problem was that no complete map existed.

UUCP networks were built from relationships between individual systems. One machine knew the machines it called directly. Those machines knew others. Mail and files could move hop by hop, but finding a good route across the larger network required knowledge that no single operator automatically possessed.

In January 1984, a birds-of-a-feather session at the USENIX conference in Washington, D.C. recruited more than thirty volunteers to build and maintain a map.

The resulting effort became known as the UUCP Project.

The network had human maintainers

The project divided responsibility among regional volunteers who supplied and maintained connectivity information. The maps were distributed through Usenet, eventually in the comp.mail.maps newsgroup, where other systems could collect them and generate routes.

Initial funding came from USENIX. When that funding ended, the work continued on a volunteer basis.

The museum page names Mark Horton as the person who ran the project, with major contributions from Mel Pleasant, Tim Thompson, Berry Kercheval, Steve Morenberg, Karen Summers-Horton, and a much larger collection of regional coordinators.

That structure is worth remembering because modern networking makes topology feel automatic.

In the UUCP world, the network map was partly a social artifact. Humans knew which systems existed, which links worked, who was responsible for which region, and how changes should be published so everyone else could calculate a path.

It was infrastructure maintained through cooperation and text files.

The Stargate Museum continues from this page into surviving 1984 map entries, which makes the exhibit more than a summary. It points directly at the kind of data that made the system work.

CacheRat’s 1,967 Ancient Web Domains research list includes pages like this because network history is easy to flatten into a straight line from ARPANET to today’s Internet.

The real history contains a lot more phone calls, volunteers, hand-maintained maps, and machines asking their neighbors for directions.

Explore the UUCP Project exhibit

Posted on

Ancient Web: psDooM Let Sysadmins Shoot Processes

Somebody looked at ps, renice, and kill and decided the obvious missing feature was a shotgun.

Visit the psDooM screenshots page

psDooM is a Unix process monitor built on Doom. Running processes appear inside the game as monsters labeled with a process ID and part of the process name.

The joke goes considerably further than a visual skin.

The program periodically checks the machine’s process table and spawns or removes monsters as processes appear and disappear. Damage to a process-monster corresponds to changing that process’s priority with renice. Killing the monster can kill the associated Unix process.

This is therefore one of those rare pieces of software where “shooting the runaway process” can be technically accurate documentation.

The project grew from the release of Doom’s source code in the late 1990s. The psDooM site traces its lineage through XDoom and a University of New Mexico proof of concept called “Doom as a tool for system administration.”

A GUI nobody asked for

A conventional process monitor turns machine state into rows, numbers, percentages, and sortable columns.

psDooM turns the same abstraction into physical space.

Processes occupy a level. They can be approached. Their labels float in front of them. Administrative actions become game actions. The metaphor is ridiculous, but it is also understandable almost immediately to anyone who has played Doom.

That is what makes the project more interesting than a one-line programming gag.

Interface design is largely the business of choosing metaphors for invisible state. Desktop systems use files and folders. Network tools use graphs. psDooM uses demons.

The screenshots page preserves the proof that this really existed, while the main project documentation explains the process-monitoring behavior, supported Doom versions, custom levels, user filtering, and other details.

It is also a snapshot of a specific open-source moment. Once id Software released Doom’s source, programmers did not merely preserve the game. They treated it as reusable infrastructure and started asking increasingly strange questions about what else its engine could represent.

CacheRat’s 1,967 Ancient Web Domains research list includes artifacts like this because software history gets much more interesting when you keep the experiments that were never supposed to become products.

Modern process managers are cleaner, safer, and more useful.

None of them let you circle-strafe Apache.

See psDooM in action

Posted on

Ancient Web: Greg Woods Built the Kind of UNIX Homepage That Never Really Ends

Greg A. Woods’s homepage is what a technical personal website looks like when nobody periodically arrives with a branding deck and orders the interesting parts removed.

Visit Greg A. Woods’s homepage

Woods describes himself through a long history of systems programming, UNIX work, consulting, and involvement with technical communities including USENIX and UNIX Unanimous. The page does not compress that history into a neat biography. Instead, it branches outward into years of software, arguments, reference tables, hardware notes, and strong opinions about how computers should behave.

There are pages about C programming, Git, Multics, Rdist, Smalltalk and Squeak, serial connectors, subnetting, old computers, public-key cryptography, spam, software distribution, and assorted utilities.

There are also pages with titles that do not pretend neutrality.

“SuDo is BAD.”

“SPF is BAD.”

Elsewhere Woods argues about tabs, dynamic linking, programming practices, and systems administration with the confidence of somebody who has already had the same argument on several mailing lists and is now giving the Web a permanent copy.

That is part of the site’s historical value.

Technical culture used to leave fingerprints

Modern technical documentation tends to split into official manuals, issue trackers, Stack Overflow answers, social posts, repositories, and ephemeral chat rooms. Personal context gets separated from technical content.

Older homepages often mixed all of it.

Woods’s old-computer material, for example, lists systems he owned or worked with, including PDP-11 hardware and AT&T 3B2 machines. Some entries acknowledge a less romantic side of collecting: equipment deteriorated, storage situations changed, and not everything survived.

The software pages similarly preserve more than code. They preserve a working programmer’s priorities. Which problems annoyed him enough to document? Which tools deserved maintenance? Which industry conventions deserved an essay explaining why they were wrong?

Even the page furniture matters.

The site rejects browser-specific design, quotes Tim Berners-Lee on universal access, carries old-style construction graphics and personal badges, and remains intentionally independent of the visual conventions that replaced the homepage era. The current page has continued to receive updates rather than being sealed as a museum reconstruction.

That continuity makes the site especially useful. The ancient and current layers occupy the same namespace.

A reader can move from old UNIX culture into newer Git notes without crossing a corporate migration boundary or discovering that the first fifteen years were deleted during a redesign.

CacheRat’s 1,967 Ancient Web Domains research list includes pages like this because technical history is not only preserved in standards documents and source trees. It survives in the stubborn personal pages where practitioners explained what they thought the standards documents got wrong.

Those arguments are part of the record too.

Explore Greg Woods’s UNIX-heavy personal Web

Posted on

Ancient Web: Tilde.club Put Personal Home Pages Back on a Shared Unix Box

Tilde.club is what happens when somebody remembers that a web page can just be a file in your home directory.

Visit Tilde.club

The service gives users accounts on a shared Unix machine where they can log in, write files, publish from ~/public_html, use shell tools, send mail, and generally treat the Internet like a computer instead of a content platform.

Paul Ford started the project in late September 2014. His own surviving page describes it as something he “set up accidentally,” then watched fill with hundreds of people who wanted a place to make low-stakes personal pages again.

That accidental quality is important.

A server instead of a platform

Tilde.club does not begin with profiles, feeds, engagement metrics, or monetization.

It begins with a Unix account.

The public site lists member homepages directly, highlights recently updated pages, publishes SSH fingerprints, and still exposes the community as a collection of people with directories rather than accounts inside a social product.

The model is old. Universities, ISPs, shell providers, and early hosting services routinely gave users web space under URLs containing a tilde before hosted site builders made that structure look primitive.

Tilde.club deliberately brought the primitive structure back.

The project also became part of a larger “tildeverse” of shared Unix communities. Its code and administration documentation remain public, and the machine is still being maintained; by 2026 the service had completed an upgrade to Fedora 43.

That combination makes the site more than retro styling. It is a functioning demonstration of a different social architecture for the web.

CacheRat’s 1,967 Ancient Web Domains research list contains many pages built before the web became synonymous with centralized platforms. Tilde.club is interesting because it consciously recreated some of those conditions after they had already become unfashionable.

You get a shell, a directory, some disk space, and a URL.

Then you decide what the page is for.

Return to Tilde.club

Posted on

Ancient Web: The Bastard Operator From Hell Is Still the Sysadmin Story Everyone Remembers

Long before “IT support” became a stock character in television, the Bastard Operator From Hell had already decided the users were the problem.

Read the BOFH archive

Simon Travaglia’s BOFH stories follow a system operator who is technically capable, deeply hostile, and willing to solve administrative problems with methods that would get a real employee escorted out by security.

The humor is built from very recognizable computing pain: backups, printers, overloaded systems, clueless management, helpdesk calls, network changes, audits, purchasing, passwords, email, cabling, users who absolutely must print one page immediately, and bosses who should never have been given access to anything.

The archive’s “Complete WWW Edition” collects the early stories, later columns, BOFH material from the 1990s and early 2000s, the PFY sidekick, quizzes, excuse generators and years of follow-on installments.

Sysadmin folklore in plain HTML

The first story opens on backup day, which is already enough to tell an old operator what kind of day this is going to be.

The technical details are exaggerated for comedy, but the cultural setting is real: shared Unix systems, operators with enormous privileges, tape backups, institutional computing, users calling the computer room directly, and a workplace where the person who understood the machines could hold terrifying amounts of informal power.

That world changed, but the archetype survived.

“BOFH” became shorthand far beyond the stories themselves. Administrators used the term jokingly for hostile operators, draconian policies, cynical support staff and the temptation to fix a human problem with root access.

The surviving web archive matters because internet folklore is surprisingly easy to detach from its source. People remember the acronym, the attitude and the jokes long after they forget where the original stories lived.

This site was found in CacheRat’s broader Ancient Web research corpus.

Explore the 1,967 Ancient Web Domains research list

The systems changed. The users are still calling.

Return to the complete BOFH archive

Posted on

Ancient Web: Multiplayer SimCity on X11

There was a multiplayer version of SimCity for X11 in the early 1990s. It ran on Unix workstations, could put several people into the same city over a network, and its surviving web page still has the product announcement to prove it.

Visit Don Hopkins’ SimCity archive

The page is maintained by Don Hopkins, who worked on Unix and multiplayer versions of SimCity. What survived is not a retrospective assembled thirty years later. It is a pile of primary material: screenshots, manuals, reviews, conference material, demo transcripts, interface discussions and the original announcement for Multi Player SimCity on X11.

That announcement is dated 1993 and reads like software distribution from another planet. A fully functional demo could be copied and played without a license, but there was a catch: the city melted every five minutes.

That is copy protection with personality.

SimCity escaped the beige box

The archive has screenshots of SimCity running on SGI Indigo hardware, Sun systems and NCD X terminals. There are transcripts from demos of both X11 SimCity and a HyperLook edition for the NeWS window system.

There is also a proposal for SimCityNet and material on user-interface design, including a summary of a Will Wright talk about interfaces for simulation games.

One line deserves to survive on its own: multiplayer SimCity went on tour with the Electric Carnival at Lollapalooza.

Today, networked games are ordinary enough that nobody thinks twice about the plumbing. These pages come from a period when putting a familiar simulation across networked Unix workstations was itself interesting enough to demonstrate at conferences and music festivals.

Why the page matters now

For game developers, this is source material. It shows not only what existed, but how it was described to users and other developers at the time. Product announcements list licensing models. Screenshots show actual interfaces. Transcripts preserve the way the software was demonstrated before streaming video became the default historical record.

For webmasters, the page is another good example of why boring HTML ages well. It is mostly a list of links with useful labels. Thirty years later, that is enough to reconstruct a little piece of game-development history.

This page came from the larger Ancient Web collection CacheRat is working through. The complete research list contains 1,967 sites for anyone who wants to do their own digging.

See the 1,967 Ancient Web Domains research list

The best part is that the old SimCity material is still sitting there waiting to be opened instead of summarized into oblivion.

Explore the SimCity archive and its original X11 material