The 10,000 Year Clock

by Mike Shea on 20 October 2005

Slashdot and my friend Dave told me about the 10,000 year old clock built from the Long Now Foundation. I love the list of principles they have:

These are the principles that Danny Hillis used in the initial stages of designing a 10,000 Year Clock. We have found these are generally good principles for designing anything to last a long time.


With occasional maintenance, the clock should reasonably be expected to display the correct time for the next 10,000 years.


The clock should be maintainable with bronze-age technology.


It should be possible to determine operational principles of the clock by close inspection.


It should be possible to improve the clock with time.


It should be possible to build working models of the clock from table-top to monumental size using the same design.

Some rules that follow from the design principles:

Longevity: - Go slow - Avoid sliding friction (gears) - Avoid ticking - Stay clean - Stay dry - Expect bad weather - Expect earthquakes - Expect non-malicious human interaction - Don't tempt thieves

Maintainability and transparency: - Use familiar materials - Allow inspection - Rehearse motions - Make it easy to build spare parts - Expect restarts - Include the manual

Scalability and Evolvabilty: - Make all parts similar size - Separate functions - Provide simple interfaces

This is what's wrong with our world - we don't think about things like this very often and those that do are labeled as hacks and madmen. It's true that through religious manipulation the Egyptions enslaved tens of thousands but at least they had a plan for something that could and has outlived them.

We're doing all sorts of things with technology but very little effort is spent making technology last. Maybe that's because it isn't profitable to sell someone a 10,000 year iPod when you want to sell them another one in two years.

So here's your brain teaser for the day:

If you were going to build a computer that could last 10,000 years, how would you build it?

I decided that a single large xml file is the best way to archive my writing in a single file. I used to have a single ascii file as well but I thought that was a little redundant. The XML file, based upon RSS 2.0, is easily parsed and turned into database records if need be. It can be stripped of tags and turned into flat text with little effort. It can be transformed into HTML quite easily.

So now my Mike Shea CMS outputs files in three formats: single-article HTML, single-article ASCII text, and a single file XML format containing all articles. If stored on a damaged disc, more than likely people could recover every article from one of the three formats.

Now how will I get that XML file rendered with bronze age technology?