Posted on

Ancient Web: A 2004 Monk Fruit Page Became a Citation That Wouldn’t Die

A plain 2004 web article about a Chinese fruit managed to become something the modern Web is surprisingly bad at producing: a stable reference people kept citing for years.

Visit the original ITM Online Luo Han Guo page

The article, Luo Han Guo: Sweet Fruit Used as Sugar Substitute and Medicinal Herb, was written by Subhuti Dharmananda, Ph.D., then director of the Institute for Traditional Medicine in Portland, Oregon. It discusses Siraitia grosvenorii, the fruit now widely known in English as monk fruit or luo han guo.

The page covers the plant’s older botanical naming, its place in the gourd family, the intensely sweet compounds associated with the fruit, cultivation and processing, and its historical use in Chinese herbal practice. Those traditional medicinal uses are part of the article’s subject, not a recommendation from CacheRat; the interesting thing here is the document’s life on the Web.

The page kept getting cited.

Later reviews discussing natural sweeteners reference Dharmananda’s article. Scientific papers on monk-fruit compounds list the old ITM Online URL in their references. A 2026 paper indexed by PubMed still cites the 2004 page while discussing the metabolism of siamenoside I and monk-fruit extract.

That is a twenty-two-year citation trail attached to an ordinary .htm page.

A URL can become infrastructure if it stays put

Early specialist websites often published material that lived somewhere between a formal journal paper and an informal blog post. The author had subject expertise, the piece included references and terminology, and the URL was public enough for other researchers to cite. No DOI was required for the page to become useful.

That model has obvious weaknesses. A personal or institutional site can disappear. Pages can be edited without versioning. Older material may mix historical claims, secondary sources, and medical traditions in ways a modern scientific review would handle differently.

But the strengths are just as obvious: access was immediate, search engines could index the text, anybody could link directly to it, and the reference did not require an account or subscription.

The ITM page is especially interesting because monk fruit later became a much more familiar commercial sweetener. The old article therefore sits near the beginning of an English-language web trail for a subject that became increasingly common in food science and consumer products.

Even when the original server is temperamental, citations to the URL survive across newer literature. That is another lesson of Internet archaeology: the page itself is only one layer of preservation. References, quotations, bibliographies, and later documents can keep pointing back to a piece long after its original technical environment starts wobbling.

CacheRat’s larger 1,967 Ancient Web Domains research list contains many specialist pages like this. Their value is often easiest to see by asking a simple question: did anybody else rely on it?

In this case, they did. For decades.

Open the original Luo Han Guo reference page

Posted on

Ancient Web: MS Word Sucks Turned Software Frustration Into a Manifesto

Before software complaints became app-store reviews, angry tweets, and one-star screenshots, somebody had to buy a domain, write several thousand words, and explain exactly why the program deserved to be thrown into the sea.

Read MS Word Sucks

The page known as MS Word Sucks is a fine specimen of that older Internet tradition. It is not a tidy product review. It is a sustained grievance against Microsoft Word, written with the energy of someone who has been interrupted by AutoCorrect one time too many.

By 2004 the essay was circulating widely enough to become the subject of a Slashdot discussion, where readers quoted some of its more volcanic passages and immediately began arguing about Word, OpenOffice, LaTeX, document formats, user interfaces, and whether the author’s suffering was self-inflicted.

That reaction is almost as historically useful as the rant itself.

Software used to inspire manifestos

The complaints are recognizable even now: unwanted formatting, preferences that refuse to stay put, automatic features that feel less like assistance than sabotage, document behavior the user did not request, and the suspicion that increasingly complicated software had stopped serving the person sitting in front of it.

What makes the page feel old is not the subject. People still hate software.

It is the form.

A frustrated user did not need to compress the complaint into 280 characters or optimize it for a video. He could publish a plain HTML page, swear at Microsoft for as long as necessary, and leave it sitting on the public Web where search engines, mailing lists, forums, and friends would eventually find it.

The Web was full of pages like this: personal essays that were too opinionated for documentation, too specific for journalism, and too long for anyone except the author and the exact stranger who desperately needed to know that somebody else had noticed the same stupid behavior.

That is why these pages matter as artifacts. They preserve the emotional history of computing, not merely the release history.

Microsoft Word can be documented through version numbers, file formats, screenshots, and feature lists. A rant tells you what using the software felt like to at least one technically literate person while those design decisions were still current annoyances rather than historical curiosities.

CacheRat’s 1,967 Ancient Web Domains research list includes pages like this because old software culture was partly built from documentation and partly built from people yelling at the documentation.

Sometimes the rant ages badly.

Sometimes, twenty years later, you read it and immediately recognize the exact argument.

Revisit the original MS Word Sucks page

Posted on

Ancient Web: DeepCave Froze a Cave Diver’s Final Project in Place

DeepCave is difficult to read now because the site does not know how its story ends.

Visit DeepCave

The website belonged to David John Shaw, an Australian airline pilot and technical cave diver who documented extremely deep dives, equipment, photographs, video, records, and the preparations surrounding a planned recovery dive at Bushman’s Hole in South Africa.

In 2004, during a dive to roughly 270 metres, Shaw encountered the remains of Deon Dreyer, a diver who had died there a decade earlier. Shaw subsequently became involved in an attempt to recover Dreyer’s body.

DeepCave recorded that project while it was still in progress.

Its pages discuss deep-diving operations, rebreather equipment, training, logistics, record dives, and the planned return to the cave. Some surviving updates tell readers to stay tuned for news from the recovery effort.

On January 8, 2005, Shaw died during that recovery dive.

That fact changes the meaning of every unfinished sentence on the site.

A primary source can survive without receiving an ending

It would be easy to treat DeepCave as a piece of macabre Internet trivia. That would miss most of what makes the site historically valuable.

The important artifact is the contemporaneous perspective.

DeepCave shows what Shaw chose to document before the outcome was known: the equipment, objectives, previous dives, preparation, photographs, and technical context surrounding work at extraordinary depths. It is not a retrospective assembled years later from news reports. The project is described from inside the project.

That also means the site deserves careful reading.

Extreme cave diving carries severe risks, and the existence of detailed reports should not be mistaken for an invitation to imitate the activity. Technical diving at such depths involves specialized equipment, training, planning, decompression, gas management, and failure modes with very little room for correction.

The surviving website is valuable precisely because it shows how serious the undertaking was.

Personal websites often become unusually powerful historical sources after something goes wrong. A polished biography written later tends to impose an ending on everything that came before it. A frozen homepage does not. It preserves uncertainty.

DeepCave still contains the forward-looking language of somebody expecting to return and write the next update.

That is uncomfortable, but historically important.

It also demonstrates why old personal sites belong in Internet archaeology alongside famous corporate pages. A person’s Web directory may contain photographs, technical explanations, dates, intentions, and observations that later reporting can quote but cannot reproduce from the same point of view.

CacheRat’s 1,967 Ancient Web Domains research list includes surviving personal sites because sometimes the Web itself becomes part of the primary record.

DeepCave is one of those cases.

Read the surviving DeepCave pages

Posted on

Ancient Web: Rowan Crowe’s MoonRock BASIC Compiler Was Proudly Half Finished

Rowan Crowe released version 0.50 of his MoonRock BASIC compiler with a wonderfully honest explanation for the number: the project was probably nearing its final major release, and 0.50 was a joke because the compiler was about half finished.

Visit Rowan Crowe’s original site address

MoonRock was a hobby compiler for DOS developed through the 1990s. It accepted a BASIC-like language and generated assembly that could be turned into compact DOS executables using assemblers such as MASM, TASM, A86, or the included ArrowSoft assembler. Contemporary compiler archives describe it as an alternative to QuickBASIC and preserve version 0.50 as a roughly 1994–1998 project.

The surviving README is better than any polished product history could be.

Crowe explains that the six BASIC source files making up MoonRock had grown to roughly 280 KB and 10,000 lines. Its assembly-language library was around 100 KB and 7,200 lines even after comments and other material were stripped. He calls the compiler a monster full of kludges and exceptions and admits that returning to a hobby project after a month could mean figuring out how his own code worked again.

That is not failure. That is software development with the marketing department safely removed.

By the final release period, Crowe was running his own Internet service provider and moving much of his programming attention from DOS toward Unix. His main workstation still ran DOS, but he says it was increasingly being used to telnet into Unix servers. The paragraph captures a specific moment in computing history better than a timeline does: DOS was still the machine under his hands while the work had already moved through the network.

The compiler survives as an entire little ecosystem

Copies of MoonRock still include far more than MRC.EXE. There are .MOO example programs, configuration files, an interactive help utility, linker tools, reference documentation, bug and error lists, headers, source directories, and assembler support.

The changelog shows a surprisingly ambitious language growing in public: arrays, pointers, structures, software interrupts, file operations, FOSSIL serial functions, 386 code generation, DPMI protected-mode support, conditional compilation, inline assembly, memory management, and switches for optimizing either size or speed.

The filenames are part of the charm. HELLO.MOO, LIFE.MOO, STARS.MOO, CALC.MOO, and the compiler’s other samples make this feel less like an abstract programming-language project and more like a disk somebody genuinely used.

Crowe’s original personal site is no longer as dependable as the surviving software copies, but the address remains embedded in the documentation along with his FidoNet address and email. That is why preserving old software with its README matters. The file carries the author, the context, the limitations, the jokes, and the reason development slowed down.

MoonRock did not need to become the next C compiler to be worth remembering. Somebody wrote a 10,000-line compiler for DOS, used it, distributed it, documented it, and then openly admitted where the monster had gotten away from him.

Try the original Rowan Crowe site address

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: Adam Schneider Turned Wildflower Photos Into a Searchable Field Archive

Adam Schneider has been doing something increasingly unusual with his wildflower photographs: putting them on his own website in a structure that remains useful after the day they were posted.

Visit Adam Schneider’s Wildflower Photography archive

The collection is mostly plants from Oregon and Washington, with trips extending into California and other parts of the western United States. Albums are arranged more or less chronologically, and the main page provides a map, a timeline, and text search instead of asking you to scroll backward through somebody’s life one screen at a time.

That sounds mundane until you compare it with how personal photography usually gets published now.

A social feed is organized around when the audience saw it. Schneider’s archive is organized around what the photograph is. Individual images can carry common and scientific plant names, locations, dates, coordinates, filenames, image dimensions, and photographic details. Species can be searched across different trips and years. If the same plant appears in several locations, the collection starts behaving more like a field notebook than a gallery.

The archive is also still growing. The index contains recent trips alongside material stretching back through many years of hikes and photography. New pages sit comfortably beside old ones because a chronological directory does not require a redesign every time somebody invents a new engagement metric.

Personal data becomes a reference when you keep the metadata

The useful lesson here is not that every photographer needs to become a botanist or database designer. It is that long-running personal collections become dramatically more valuable when the owner preserves context.

A picture of a flower is pleasant. A picture tied to a species name, place, date, and trip is evidence. Hundreds or thousands of those records form a body of observations that can be searched, compared, cited, and revisited.

Schneider also handles image ownership in the straightforward old-Web way. The displayed photographs are visibly watermarked, and the site asks people who want to reuse them to contact him for permission or licensing; larger unwatermarked versions may be available. No mysterious platform rights layer is required to understand the arrangement.

For webmasters, the archive is another example of information architecture beating fashion. Albums, maps, timelines, text search, stable links, and descriptive pages are not exciting technologies. They are simply the tools that make a collection remain navigable after it grows beyond a few dozen items.

The larger 1,967 Ancient Web Domains research list is full of personal sites whose real value only became obvious after their owners kept adding to them for years. Schneider’s photo archive belongs in that tradition.

The Web is very good at preserving an obsession when the owner gives the obsession an index.

Browse Adam Schneider’s wildflower albums

Posted on

Ancient Web: Didik.com Is What Happens When an Inventor Never Stops Adding Pages

Didik.com feels less like a website than the contents of an inventor’s workshop after somebody taught the workbench how to make HTML pages.

Visit Frank Didik’s site

Frank Didik has used the site to document an unusually broad collection of designs, prototypes, modifications, experiments, and proposals. The subjects jump from electric and solar vehicles to giant lenses, inflatable structures, three-dimensional imaging, bicycles, architectural ideas, and whatever else happened to be occupying his attention.

The vehicle material alone could support a small archive.

Pages describe projects such as the Sun Shark solar-electric vehicle, the Long Ranger electric-car modification based on a CitiCar, a human-powered vehicle called the Muscle Car, and concepts for hybrid or ultra-efficient transportation. Other sections discuss practical electric-car conversion work and the engineering compromises behind range, batteries, motors, weight, and aerodynamics.

Then the site wanders somewhere else entirely.

There are experiments with large Fresnel lenses, lenticular three-dimensional imagery, lightweight structures, solar energy, inflatable buildings, and various machines and proposals that look as if they began with the sentence, “I wonder if this would work.”

That does not mean every claim on the site deserves equal weight. Didik also publishes personal opinions and speculative arguments on subjects well outside the strongest engineering material. Some of those pages make claims that should be evaluated independently rather than accepted because they share a domain with a clever vehicle prototype.

The useful part is the distinction the Web lets us preserve: an interesting builder’s archive does not have to become an endorsement of everything the builder believes.

The personal Web did not require a lane

Modern publishing strongly encourages specialization.

If you build electric vehicles, the advice is to make an electric-vehicle site. If you experiment with optics, make an optics channel. If you have a strange architectural proposal, perhaps feed it to a different audience entirely.

Didik.com comes from the opposite tradition.

One person gets one domain. Everything goes there.

That makes the site messy, but the mess is informative. The connections between subjects remain visible. Vehicle design leads into energy storage. Energy leads into solar collection. Solar collection leads into optics. Materials lead into structures. One experiment creates the question that produces the next page.

The site therefore preserves something that polished project portfolios often remove: the path between ideas.

Its copyright lines reach back decades, and the collection has accumulated rather than being periodically redesigned into a clean selection of “best work.” Old projects remain beside newer ones. Failed directions are not necessarily hidden. The archive is allowed to look like a long-running obsession.

That makes it useful in 2026 even when individual claims need skepticism. Historical technical work is easier to understand when photographs, explanations, prototypes, and neighboring experiments remain together instead of being reduced to one résumé bullet.

CacheRat’s 1,967 Ancient Web Domains research list includes personal technical sites like this because useful Web history often survives inside pages that no modern information architect would permit to remain in one navigation tree.

Sometimes that is exactly why they are worth keeping.

Explore the sprawling Didik project archive

Posted on

Ancient Web: IvyJoy Built a Kids Search Page Before Safe Search Became a Setting

There was a period when “search the Internet safely with a child” was not a browser preference. Somebody had to make you a page of places to search.

Visit IvyJoy

IvyJoy became one of those places.

Its best-known resource, Ivy’s Search Engine Resources for Kids, gathered child-oriented search engines, Web guides, specialized search forms, filtered general search tools, and directories intended to reduce the odds that a school research assignment wandered somewhere it absolutely did not need to go.

That sounds ordinary now because filtering and child-safety controls have been pushed downward into operating systems, search engines, school networks, browsers, and managed devices.

It was not ordinary when the Web was a looser pile of directories, independent engines, hand-built guides, and completely unfiltered pages sitting one typo away from each other.

IvyJoy’s usefulness is visible in the trail it left outside itself.

School districts, classroom resource pages, teacher directories, and educational publications repeatedly linked students to the kids-search page. A 2003 Surfnetkids guide listed Ivy’s Search Engine Resources for Kids among its honorable mentions. Years later, Berkeley Unified School District resource pages still pointed elementary students toward it. Teacher pages described it as a way to give children fewer accidental surprises while searching.

Even academic work on information retrieval for children used IvyJoy’s specialized coloring-page search as an example of a narrowly focused search collection.

A directory could be a safety device

Older Web directories are easy to dismiss because Google made manually curated lists feel obsolete.

For children, curation solved a different problem.

The objective was not merely to locate something. It was to constrain the neighborhood being searched. A librarian-created index, a children’s directory, a specialized encyclopedia, and a filtered search engine each represented a different boundary around the open Web.

IvyJoy collected those boundaries in one place.

That approach also taught a useful lesson that modern interfaces tend to hide: there is more than one way to search the Internet. Different engines and directories contain different material, use different selection rules, and produce different results.

A child clicking through a page of specialized tools could see that fact directly.

In 2026, many of the services once linked from old kids-search pages are gone, renamed, absorbed, or replaced. That decay makes the directory historically useful even where individual outbound links have failed. It is a snapshot of what adults once considered the safer, more educational side of the public Web.

CacheRat’s 1,967 Ancient Web Domains research list includes directories like IvyJoy because a link list can preserve something larger than its destinations. It preserves how people once organized the Internet in their heads.

For teachers and parents, that organization sometimes doubled as the firewall.

Explore the surviving IvyJoy site

Posted on

Ancient Web: Bagdad, Arkansas Is a Straight-Faced Fake Tourism Site

BagdadArkansas.org looks like a tiny-town tourism website until you notice that one of the dining options is Crazy Andy’s Cow Petting Zoo and Burger Store. At that point the chamber of commerce begins to lose credibility.

Visit Bagdad, Arkansas

The page introduces Bagdad as a family-friendly mountain town near the Buffalo River and provides the sort of directory a legitimate visitor site would have: lodging, food, activities, a visitor center, jobs, and contact information.

Then the names start accumulating.

Visitors can supposedly stay at Crazy Andy’s Memorial Hotel, eat at Crazy Andy’s Hot Doggery, visit the Buffalo River Aquarium, gamble at the Bagdad International Gas Station and Casino, shop at Bochsberger Town Mall, visit a local standoff memorial, and celebrate Johann Day every September 28.

The contact number is (870) 555-0121.

That 555 number, the increasingly ridiculous businesses, and the site’s complete commitment to its own municipal fiction strongly suggest that this is a deliberately fabricated tourism site rather than a factual guide to an Arkansas town. I could not find anything on the page itself announcing the joke, which is exactly why it works.

It does not wink. It issues directions.

The Web used to have more room for this kind of nonsense

A fake chamber-of-commerce site is a very old Internet joke format. Build the website an institution would have, populate it with increasingly questionable details, and let the visitor discover the premise by reading.

Bagdad does this with almost no technical spectacle. There is no game engine, no interactive reveal, no account, and no giant explanation of the lore. It is basically a directory site for a place whose local economy appears dangerously dependent on a man named Crazy Andy.

The footer simply says 2019 - Bagdad AR Chamber of Commerce. The page even supplies a visitor-center address: 251 Main Street, Room 103, Bagdad, Arkansas 72658. That bureaucratic specificity is part of the comedy. Fake things get much funnier when someone has bothered to invent Room 103.

For webmasters, it is also a good reminder that a site can have a strong identity without much machinery. The whole gag is carried by structure, copy, naming, and restraint. A modern version would probably explain itself with a modal, six social accounts, a cinematic loading screen, and merchandise before you reached the cow petting zoo.

This one just behaves as if Bagdad needs your tourism dollars.

The larger 1,967 Ancient Web Domains research list contains plenty of useful technical and historical resources, but pages like this are part of the excavation too. The old Web was also full of people building elaborate jokes because owning a domain was enough reason to do something stupid with it.

Explore the attractions of Bagdad, Arkansas

Posted on

Ancient Web: The QBasic Games Directory Came Back From the Dead

The QBasic Games Directory already died once, which makes its continued existence considerably more interesting than another retro-gaming list somebody assembled last Tuesday.

Visit the QBasic Games Directory

The directory was created and maintained by Lachie Dazdarian as a database of games written in QBasic, the beginner-friendly BASIC environment bundled with MS-DOS-era Microsoft systems.

For a generation of hobby programmers, QBasic was less a language choice than a door somebody had accidentally left unlocked.

It was already there. It had an editor. It could run code immediately. A teenager could type a few lines, make something move on the screen, and then lose the next several years of his life.

The resulting community produced platform games, shooters, role-playing experiments, puzzle games, graphics demos, engines, libraries, tutorials, and an impressive quantity of software created because somebody wanted to know whether it could be done.

The QBasic Games Directory cataloged that scene.

Then its old home at qbasic.com disappeared.

In 2017, Phat Code announced that the massive database had returned. Dazdarian publicly thanked Plasma for restoring it and said he did not expect to make major changes. The point was preservation.

That is a small but important distinction.

A database can outlive the scene that needed it

When an active hobby community is healthy, everybody knows where the files are. People recognize author names. Forums link to current releases. Someone remembers which engine a particular game used.

Twenty years later, all of that assumed knowledge becomes archaeology.

A directory suddenly matters more.

The QBasic scene is particularly vulnerable because so much of its output came from individual hobbyists rather than commercial publishers. Programs moved between personal pages, FTP servers, free hosts, community portals, magazine disks, and forum attachments. Many of those distribution paths vanished.

A surviving catalog gives the software context. It can connect a title to an author, screenshot, description, review, release period, or neighboring projects. Even when an individual file needs to be hunted elsewhere, the index tells you that the thing existed.

Phat Code itself wears its persistence proudly. After almost nine years without an official update, the site returned in 2016 with the message that “old school never dies.” The following year the QBasic Games Directory was restored there.

That is about as appropriate a hosting arrangement as one could ask for.

CacheRat’s 1,967 Ancient Web Domains research list includes programming-community survivors because obscure software rarely disappears all at once. First the community quiets down. Then the hosting goes. Then the filenames become meaningless.

A directory interrupts that process.

Sometimes the best preservation project is simply putting the old index back online.

Browse the resurrected QBasic Games Directory