{"post":{"data":{"id":"21379","type":"post","attributes":{"title":"The Cuneiform Tablets of 2015","authors":"Long Tien Nguyen and Alan Kay","publisher":"","id":21379,"created_at":"2020-09-28T22:55:29.742Z","updated_at":"2020-10-02T05:21:13.345Z","plugins":"{}","slug":"viwjwq-the-cuneiform-tablets-of-2015","form_url":"/posts/viwjwq-the-cuneiform-tablets-of-2015","body":"

Abstract

We discuss the problem of running today’s software decades, centuries, or even millennia into the future.

1. Introduction

In the year 1086 AD, King William the Conqueror ordered a survey of each and every shire in England, determining, for each landowner, how much land he had, how much livestock he had, and how much money his property was worth [2]. The result of this survey, known as the Domesday Book, is the oldest public record in England and gives an extremely detailed glimpse into the sociopolitical structure of England in the 11th century, a time of great change and upheaval [8].

In the year 1984 AD, the BBC, to commemorate the 900th anniversary of the Domesday Book, commissioned the creation of the BBC Domesday Project, an interactive multimedia system intended to be a Domesday Book for the 20th century. Over 1 million people from all over the United Kingdom participated in creating this historical record for posterity. Each contributor was free to choose whatever he or she wished to record; the total sum of the contributions created a snapshot of everyday British life in 1980s. The data of the Domesday Project was stored onto two LVROM discs, a custom optical disc format based on the LaserDisc designed specifically for the Domesday Project. The LaserDisc format itself was cutting-edge at the time, as it was the first commercially-available optical disc technology. The Domesday Project’s software system was designed to run on an Acorn BBC Master computer, modified with custom hardware designed specifically for the BBC. The Domesday Project was completed and published in the year 1986 AD [10] [36].

In the year 2002 AD, 16 years after the BBC Domesday Project was completed, the LV-ROM technology and the BBC Master computer had long been obsolete. LV-ROM readers and BBC Masters had not been manufactured for many years, and most existing readers and computers had been broken, lost, or discarded. Though the LV-ROM discs containing the Domesday Project were (and still are, as of 2015 AD) intact and readable, the rapid disappearance of hardware that could read the LV-ROM discs and execute their contents jeopardized the survival of the Domesday Project [29]. To save the Domesday Project, the University of Michigan partnered with the University of Leeds to initiate the CAMiLEON Project¹ to develop strategies and techniques for digital preservation, and use them for preserving the Domesday Project [13]. The CAMiLEON staff obtained a broken Domesday Project device, repaired it, and used it to extract the contents of the LV-ROM discs. Then the CAMiLEON staff developed an emulator for the BBC Master computer and the LV-ROM disc reader that would execute the contents of the LV-ROM discs, enabling the user to experience the Domesday Project on a modern computer [28]. Most of the documentation and source code of the Domesday Project had been lost, and the CAMiLEON staff was forced to reverse engineer the hardware and the contents of the LVROM discs [9].

Though they successfully produced a prototype of a working emulator for Microsoft Windows that executed the Domesday Project, the CAMiLEON project folded after its funding ended; the CAMiLEON website ironically went offline not soon afterwards. The Domesday Project website also went offline after one of its key people, Adrian Pearce, suddenly passed away [12]. Most of the fruits of the CAMiLEON Project were not released to the public; the images from one of LV-ROM discs were uploaded to the BBC website and the papers from the website were successfully saved by the Internet Archive. However, an accurate emulation of the original multimedia experience is not available to the public, and lies somewhere in the decaying private hard drives of the former CAMiLEON staff; its future yet lies in jeopardy. By contrast, the Domesday Book of 1086 AD, stored in the National Archives of the United Kingdom in Kew, is in excellent condition and can be viewed by any visitor with special permission [29]. The full text (in Latin) and translation of the Domesday Book can be found online on several websites. Reproductions are widely available in print in countless libraries and bookstores. It may be that our descendants shall know more of England in 1086 AD than of England in 1986 AD. In this essay, we will try to explore the ways we can prevent our era from becoming, in the words of Vint Cerf, a Digital Dark Age.

2. Prehistory

The authors of this essay first met in October of 2011, when the first author attended a seminar led by the second author for the introductory computer science course for freshmen at UCLA. In this lecture, the second author gave a personal tour of the field of computer science and its history, and explored the relationship between computer science and mathematics, science, engineering, and art. We discussed the immature state of computer science today, comparable to the state of civil engineering during Ancient Egypt, when the pyramids were built. The second author opined that a significant barrier to progress in computer science was the fact that many practitioners were ignorant of the history of computer science: old accomplishments (and failures!) are forgotten, and consequently the industry reinvents itself every 5-10 years.

This interaction got us interested in preserving computing history for posterity, a problem that is catastrophically overlooked by the institutions that are supposed to be preserving today’s heritage. For example, the second author has repeatedly attempted to persuade, with little success, the Library of Congress to create a concerted and systematic effort to preserve computer software and a catalog of computer architectures (consisting of architecture specifications in English and “reference implementations”). The Computer History Museum, run by “hardware guys,” has an extensive and impressive collection of vintage hardware of all kinds and from all eras, but it sits there as a collection of lifeless beige boxes.

Our first experience at historical preservation took place in August of 2013. At the time, the Kleinrock Internet History Center (KIHC) at UCLA started work on the restoration of the systems that powered the very first ARPANET node at UCLA: the SDS Sigma 7 computer that served as the host and the Interface Message Processor (IMP) that served as the router for the host. However, the project ran into several difficulties: first, the 44-year old Sigma 7 and IMP were in poor condition, and it was difficult to determine what repairs were necessary to bring the machines back to life.

Secondly, and more importantly, the software for both the Sigma 7 and IMP was missing, and the 40-year old backup tapes that were found did not work (although later one of the original engineers on the IMP, Dave Walden, managed to find a complete copy of the IMP source code in his personal archive). The project was put on indefinite hiatus.

Our experiences show that more attention is given to hardware than to software, in spite of hardware being merely a “lifeless body” without the “immortal soul” of software to bring it to life. The “essence” of the ARPANET, and of many other systems, survives even if all the machines that ran the original software are gone, as long as the software still survives. After the KIHC project was shelved, we did some thinking about what it would take to allow a program to be usable in the far future, when the hardware “bodies” that the program once inhabited are long dead and gone.

3. Storage Media

The first problem we have to worry about is the deterioration of storage media. As we have mentioned earlier, the 40- year-old backup tapes for the Sigma 7 and IMP machines were no longer readable. All storage media currently in use have a fairly short lifespan, which varies widely depending on various factors, including storage conditions and usage patterns. For example, the National Media Laboratory reports that CD-Rs can last from 5 to an estimated 100 years, and magnetic tape can last from 10 to 50 years, depending on storage conditions [1]. Therefore, the preservation of digital data using existing storage media requires constant maintenance of the digital archive by transferring data from an old medium to a new medium every few years. This approach, in our opinion, is too risky, since it requires the institution doing the preservation to continuously exist and receive funding.

A better solution was developed by the Long Now Foundation in conjunction with the Los Alamos National Laboratory and Norsam Technologies. Microscopic text is etched onto a disk made out of nickel; the resulting “Rosetta disk” can be read with a microscope at 1000x magnification [24]. A Rosetta disk is estimated to last from 2,000 to 10,000 years; a 3-inch disk can contain about 350,000 pages of text [23]. Other institutions are also developing extremely long-term data storage media [14]. As we are computer scientists, we shall leave this “piece of the puzzle” to the materials scientists, and assume that they have developed such a “Rosetta disk” for us. Now we must figure out what to put on it.

4. The Simplest Approach

At first, the reader may think, why can’t we just put the program we want to send to the future on the disk, plus the documentation for the machine that the program runs on? The “archaeologist of the future” would read the documentation, write an emulator for the machine, and run the program. Unfortunately, this naive scheme makes the archaeologist of the future do a lot of work, because real computer architectures have a lot of complexity. Say, for example, we wanted to emulate a bog standard “Windows on Intel x86” computer. The Software Developer’s Manual [18] for the Intel x86 architecture has a total of 3603 (!) pages, and that’s just the CPU alone! Even 8-bit microcomputers from the 1980s have a lot of complexity. For example, the Commodore 64 Programmer’s Reference Guide [6] is 514 pages long. The archaeologist of the future would have to read and understand the whole document, and then write and debug an emulator, taking into account all the edge cases and quirks of the behavior of a real-world computer. Instead, we should do most of the “heavy lifting” ourselves, and design a scheme such that the archaeologist of the future can get the program working in a single afternoon. But what should we do today, so that the archaeologist of the future only needs to do a “fun afternoon’s hack?” We were inspired by several ideas.

5. Some Food for Thought

Guy Steele begins his keynote lecture Growing a Language [33] at OOPSLA 1998 with a very limited vocabulary. He adds more complex words to his vocabulary by defining them in terms of words that already exist in his vocabulary. These new words, in turn, can be used to define even more complex words down the line. This scheme vividly makes the case for programming languages that consist of small kernels that can be flexibly extended by their users.

The idea of building a language in this manner is not new. In the 1950s, Hans Freudenthal devised a universal language to communicate with aliens from outer space called LINCOS [11]. In his language, he tried to move from visual patterns to mathematics and then attempted to build everything from logic, like Russell and Whitehead attempted in their Principia Mathematica [31]. Freudenthal makes the assumption that any aliens that are sufficiently intelligent to be able to receive radio messages from space must also have discovered mathematics. Freudenthal starts with the concept of a natural number, which can be represented in a self-evident manner as a series of repeated radio “beeps” separated by periods of silence. 0 is represented as no beeps, 1 is represented as one beep, 2 is represented as two beeps, and so on. Thus, his “message to aliens” starts by defining the equals, less-than, greater-than, and arithmetic symbols for natural numbers. Each new concept is defined in terms of concepts previously defined; Freudenthal goes on to define real numbers, variables, propositional logic, and first-order logic. Then, he defines the concepts of time, behavior, and physics. Of course, we are not doing anything as ambitious as sending a message to aliens, so our design does not need to be so sophisticated.

While Freudenthal was designing LINCOS, another compelling example of a powerful universal language with a very compact explanation and bootstrap was Lisp by John McCarthy [27]. In the original formulation of Lisp, McCarthy showed how a powerful programming language could be built up starting from only 9 primitives: atom, car, cdr, cons, eq, quote, cond, lambda, and label. Using only these 9 primitives, a fully-functioning interpreter for Lisp could be written in Lisp itself. A thought the second author had back then was perhaps every piece of digital media should be prefaced by the simplest explanation possible of a virtual machine that could run the rest of the media, and that Lisp could be an excellent candidate.

Lisp, along with Simula [7], arguably the first truly objectoriented programming language, became the foundation of thinking about object-oriented programming, especially dynamic late-bound object-oriented programming, and the seeds of these ideas were incorporated into the Smalltalk systems [22] at Xerox PARC in the 1970s. A feature of the revolutionary Xerox Alto personal computer [34] was that it required a very powerful but very compact software system to make it into what would be considered a very early form of “modern interactive personal computing.” As further personal computers were developed at PARC, Smalltalk was made portable by having each “bag of bits,” called an “image,” that constituted an entire system also carry the microcode for each machine Smalltalk was to run on [22]. When an image was brought to a particular machine, the appropriate microcode was extracted and executed to create a Smalltalk virtual machine². All the rest of the “bag of bits” was completely machine independent. For example, the microcode needed for the Alto was 1024 instructions of 32 bit words: 4 kilobytes. One of the versions of Smalltalk done for the portable NoteTaker computer ran on an off-the-shelf chip (an early version of the 16-bit 8086) and the bootstrap was done with 6 kilobytes of 8086 machine code playing the role of the “microcode.” All other parts of the system were machine independent, and the system plus interesting media could all fit into less than 512 kilobytes [22].

This led to the somewhat interesting conclusion that one could store media as a “process” if the system that created it were carried along, and if the “microcode” for the system were also supplied.

Furthermore, if the “microcode” were thought through a little more carefully, it would be much more compact to describe what it did than to describe how to make a Lisp. The idea then would be to have a Lisp-like system, or in this case Smalltalk, in the rest of the bag, and the real beginning part of each bag should be the simplest description of the simplest machine that would bring the rest of the bag to life. An important motivation back in the 1970s, which carries through to the present essay, was that a good goal would be to entice the programmers of the future into revitalizing a piece of media by showing them that it could be “an afternoon’s hack.” Thus we wanted to avoid a lengthy description in the beginning, and we wanted to avoid requiring the archaeologist of the future to have to do a lot of work before seeing whether it would be worthwhile. The neat thing would be that the tools to modify, extend, and improve the system could be bundled along with the system as well.

It’s worth looking a little deeper into this approach, which is at least as “psychological” as it is technical. One question is whether any of the formal semantics techniques popular today will survive well enough so that they could be referred to. The second author began his computing career in 1961, and more than 50 years later, none of the formal semantics techniques from the 1960s has survived well enough to be used without reteaching. Teaching formal semantics to the archaeologist of the future using English and perhaps logic would be a hefty document, and for most programmers would not be regarded as a “fun afternoon’s hack,” or even a “fun month’s hack.” We fear that today’s favorite formal semantics techniques, such as denotational semantics, may not survive even 50 years hence. This is also, sadly, the case for Lisp (though it is still worth understanding deeply, just because it was so beautiful and powerful). But most programmers today don’t understand just how to bootstrap a Lispish kind of system.

Most programmers today haven’t written a machine code program and likely have a bit of a fuzzy idea of what machine code is like. However, universal machines can be both simple and tiny with respect to features, and it might be possible to explain the semantics in a single tempting page. The idea of values, labeling them, transforming them, looping, sequencing, and so forth, will probably hang on, and these could be viable contexts for a one-page description. Note that defining a simple machine with memory locations, simple operations, and a simple instruction format, is counter to perennial desires for abstraction and generality. However, our aim to be both very specific and very brief, and this is quite justifiable in part because the internals of our media document can be brought to full life from following just such a simple one-page description.

In summary, our “message to the future” should consist of two parts: a “one-page description” of a simple virtual machine, and a program that will run on the simple virtual machine.

6. Alternative Views

Now, we could also just describe how a NAND gate works and describe how the virtual machine works in terms of NAND gates! This could be a list of logic equations or a schematic diagram. An example of such a project is Brian Silverman’s Visual 6502 [20]. He depackaged a 6502 CPU, extracted the schematics from photographs of the die, and wrote a gate-level simulator for the schematics, resulting in a working virtual 6502. Though a NAND gate is easy to understand, a schematic of NAND gates would be harder to use, because the archaeologist of the future would have to transcribe the schematics, and either write a logic simulator or build a hardware circuit (using whatever technology she will have in the future) to run the program. However, a schematic diagram could serve as an alternative specification of the virtual machine.

Why would we need alternative specifications? To guarantee that a “message to the future” is still comprehensible to future generations, we should write it in several ways. Ancient Egyptian hieroglyphics were decoded thanks to the Rosetta Stone, which contained the same text written in three scripts: Ancient Egyptian hieroglyphics, Demotic script, and Ancient Greek. Because the Ancient Greek language was known to modern scholars, they were able to compare the Egyptian text and the Greek text to figure out the meaning of the hieroglyphs. Likewise, if we specify the simple virtual machine several different ways, it will increase the likelihood of the archaeologist of the future being able to understand how it works. Our first specification of the simple virtual machine uses English prose and diagrams. Our assumption is that basic mathematical and computational concepts, such as binary numbers, Boolean logic, arithmetic, and Turing machines will still be known. It seems to us that if knowledge of these concepts were lost then civilization has collapsed to the point where there would be no computers at all! We could then use the logic equations or schematic diagram, as described in the previous paragraph, as a second specification of our simple virtual machine. This could be used to verify the first specification. Figuring out other ways to describe the simple virtual machine is an open problem that we haven’t solved yet. Perhaps there is a more accessible formal semantics technique that is yet to be invented.

Currently, we only have one specification of the simple virtual machine, but we are working on figuring alternative specifications for the next version of our system.

7. The Cuneiform System

Inspired by the ideas above, we set out to build a system for software preservation, which we christened Cuneiform. It works as follows: in the present day, a preservationist using the Cuneiform tools preserves a software program for posterity. Once a program has been packaged with Cuneiform, an archaeologist of the future spends a fun afternoon “hacking” on an emulator that brings the packaged program back to life. The packaged programs will look and behave exactly as they did in the past. Furthermore, the archaeologist can do more than just execute the packaged program: the tools bundled with the program allow the archaeologist to view the program’s documentation, inspect the program’s behavior, and even modify or adapt the program.

A program packaged using Cuneiform consists of three parts: the label, the header, and the program itself. We describe the parts in the rest of this essay.

[There is more… i got lazy copying and pasting…]

","cable_url":"wss://jellypbc.com/cable","upload_url":null,"tags":[],"title_comments":[],"body_comments":[{"to":14037,"from":14036,"id":3854262647,"text":"Very much modeled after the hardware of the Burroughs B5000 computer [3], which introduced a HLL “machine-code” with bytecodes, descriptors (protected pointers), etc.","user":{"id":1,"avatar":"https://storage.googleapis.com/jellyposter-store/user/1/avatar/2d06aaeb01db8fbc93b39c6ddf62d5df.jpg","username":"cindy"}},{"to":2350,"from":2349,"id":179980978,"text":" Creative Archiving at Michigan and Leeds: Emulating the Old on the New","user":{"id":1,"avatar":"https://storage.googleapis.com/jellyposter-store/user/1/avatar/2d06aaeb01db8fbc93b39c6ddf62d5df.jpg","username":"cindy"}}],"contributors":"Cindy Wu","body_citations":[]},"relationships":{"uploads":{"data":[]},"citations":{"data":[]},"backlinks":{"data":[{"id":"20646","type":"backlink"}]},"figures":{"data":[]}}},"included":[{"id":"20646","type":"backlink","attributes":{"id":20646,"imprint_type":"","imprint_date":"","publisher":"","target":null,"post_id":20614,"generated_post_id":21379,"source_post_path":"/posts/mmsloc-local-first-software-you-own-your-data-in-spite-of-the-cloud","title":" Local-First Software: You Own Your Data, in spite of the Cloud ","authors":"Martin Kleppmann, Peter van Hardenberg, Adam Wiggins, Mark McGranaghan"}}]},"currentUser":{"data":{"attributes":{"name":"Anonymous","avatar_url":"/assets/avatar-bf489bd933e198667b26b776cbd7d0fc921ee585791fc68cca86a6187a8781f6.png"}}},"isProcessing":false,"editable":false}

The Cuneiform Tablets of 2015

Backlinks