Irreal

There are lots of people who enjoy the opportunity to experience what it was like to work on early Unix systems. That’s been possible for a long time. Indeed, there’s a cottage industry of experimenters who have built PDP emulators, resurrected early Unix sources, and gotten the original systems running. If you’re interested in that sort of thing, take a look at the Unix Heritage Society and its news list.

The problem is that it’s a lot of work even if you’re using the software that others have already written. Much too much work for those of us with a merely casual interest in trying out one of the historical Unix systems. Fortunately, Russ Cox has solved that problem for us.

Cox has ported Unix v6 to Go, written a PDP-11 emulator, compiled the whole thing to Web Assembly and put up a site that allows you to run the emulator and Unix v6 in your browser. Just follow the link and try it out. You can log in as dmr, ken, or root. Be warned, though, it can suck up a lot of your time.

Cox has a Github repository with all the code for the emulator and ported v6 OS. The userland stuff is the original C versions from various Unix archives so you’re running the original Unix software. If you login as ken you will find the code for Thompson’s famous compiler hack that I wrote about previously. Presumably you can compile it as described in Cox’s post about the hack and try running it on the emulator.

It won’t be quite the same experience of those who have somehow acquired and restored an old PDP-11 and are running v6 on it but it will give you the flavor and, if nothing else, make you realize how easy us kids have it today.

Afterword

This is the third and final post in the Ken Thompson/Old Unix triptych. If, after yesterday’s post, you have an itch to try out ed, Cox’s V6 emulator is a great place because you’ll be working in the original environment and, in any case, it’s the only editor available.

After yesterday’s post on Thompson’s famous hack, I watched the video of Thompson’s talk at this year’s Southern California Linux Expo that Cox mentioned. That was pretty interesting as another example of Thompson’s curiosity and genius but the point for this post is that YouTube recommended a related video that turned out to be an Emacs Elements video on the ed editor. It covers most of what you need to know to use ed in real life. If you prefer a written tutorial, Brian Kernighan’s tutorial on ed is excellent and what I usually refer to when I forget something.

As I’ve written before, I use ed to edit my mbsync log file. I do this mainly to keep current on ed against the day I need it to recover a Unix or Linux box where nothing else works. With modern systems, that day probably won’t come but if it does, I’m prepared. In the meantime, I’m maintaining my connection with the old ways.

Emacs Elements says that he sometimes uses ed for short editing jobs and for scripts. You can see an example of scripting with ed in Cox’s post about the Thompson Hack. I like ed a lot but I can’t imagine using it as my regular—or even frequent—editor. Others disagree and do just that. It is, in any event, very useful for scripting and worth knowing for that alone. And for you Vi(m) users out there, almost everything in ed is available as a colon command so a knowledge of ed is especially useful for you.

Every year or so I revisit and write about Ken Thompson’s 1983 Turing Award lecture, Reflections on Trusting Trust. It’s one of those papers that should be read every year: it seems there’s always something new to learn. The paper is only 3 pages and—unlike the usual academic paper—very easy for any programmer to read.

The TL;DR is that Thompson modified the Unix C compiler so that when it compiled the login module it inserted code to accept a special password for any login. That may seem mundane but Thompson’s hack went one step further: he also modified the compiler to insert code to insert the login backdoor when the compiler itself was being compiled. He then recompiled the compiler, removed all the backdoor code from the compiler source, and recompiled it again with the backdoored compiler. From that point on the compiler would create backdoors for login and for the compiler but with no trace in the compiler source.

Thompson says only that the code he added recognized when login or the compiler was being compiled but offered no details. I’ve often wondered about the details and assumed he used the file name (login.c or cc.c) to decide which code to modify. It turns out that Thompson kept that code and recently Russ Cox obtained it and wrote a post with a complete exegesis of the code and how it worked.

The frightening thing is how simple it was. It operated on the source code and merely looked for the code it wanted to modify. When it found it, it simply inserted the back door code into the source and let the compiler compile it as normal.

The really clever part was how he inserted the backdoor code (that the binary was executing) back into the compiler. That explains his otherwise unexplained mention of what we now call quines in his paper.

Just about everybody in our field recognizes that Thompson is a programming genius and his Turning paper proves the accolades are deserved. Cox’s explanation of how the whole thing worked will leave you even more convinced. Believe me, you really, really want to read Thompson’s paper and Cox’s explanation of the exploit code.

Perhaps I’m just old fashioned and pining for the old days. Or perhaps I’m anticipating the time when I can finally wave my cane at all those pesky kids. Whatever the case, I do believe that avoiding the command line—or worse, disparaging it—is leaving a lot on the table.

Doug McIlroy’s original conception of hooking up programs as if there were a garden hose between them is a powerful and liberating idea and arguably one of the most important Unix innovations. You can see it in action in this video about Unix where Brian Kernighan pipes together some simple programs to build a spell checker or in the famous McIlroy rejoinder to Knuth on writing a word count program.

But you don’t even need the power of pipes to see the usefulness of the shell. Mirco has a short post that demonstrates 5 one line shell invocations to solve various problems. In a sense, they’re all trivial problems but try to imagine a better way of solving them—especially with a GUI program in your toolkit.

As far as I can see, these examples are semispecific to Bash and Linux. For example, the last example of negating a file specification doesn’t appear to work with the zshell (although I’m certain there’s an extension that makes it work) and the date example depends on the version of date you’re using. Still, they demonstrate how you can often use the shell to solve a simple problem quickly and easily.