Mark Allen Code Mesh 2016 Interview
From OO to Clojure Workshop!
Watch my free workshop to help you learn Clojure faster and shift your paradigm to functional.
Mark Allen will be speaking at Code Mesh 2016.
PurelyFunctional.tv: Very briefly, what is your talk about?
Mark Allen: In this talk I will trace the origin and early history of time sharing systems before Unix. Almost everyone has some familiarity with the "origin story" of Unix because most of us touch a Unix system on a daily (or near daily) basis. I wanted to look at the systems that came before Unix.
PF.tv: What do you hope people will take away from the talk?
MA: I won't answer this question in the talk but it's worth thinking about: why is Unix the "winner" and these other systems dead, gone and mostly forgotten? I think its for three fundamental reasons.
Unix ran on "small" mid-range computers that small groups/departments could afford. Unix licenses from AT&T were reasonably "inexpensive" in their historical context.
It empowered people to write fast software in a language that was easy to comprehend (C) and for the most part made programs "portable" from one hardware system to another.
It was easy to modify and extend in ways that its creators never imagined or envisioned.
For various reasons, none of these earlier systems met all three of these criteria. Once Unix had been modified to handle networking via Ethernet, that was sort of the beginning of the end for these other systems.
That suggests the question - why even think about these systems?
I want people to know just how long the idea of "time sharing" has been around - like a lot of brilliant ideas, it came from John McCarthy in the early 60s. Some colleagues at MIT carried McCarthy's idea forward and built a system to enable it to be a reality.
Second, these older systems also have a lot to do with the artifacts of Unix from its earliest days - everything from file permission bits to hierarchical file systems to memory management.
Finally, I think the origin stories of these systems are pretty interesting. For example, the Dartmouth Time Sharing System (DTSS) begat the language BASIC. Kurtz wanted all students (not just engineering and math undergrads) to be able to interact with a computer and make it do useful work without having be a high priest of a card punch. They even installed teletypes in Hanover High School.
PF.tv: Your talks often have a historical theme. How did you get into the historical side of computing?
MA: The original idea was to do a series of talks on computing pioneers - half biography, half a summary of their significant professional works - papers, systems, books. I started with Grace Hopper because I think her story is totally fascinating. If you start with Grace Hopper, then inevitably you start to see how her work on compilers and compiling "languages" to talk to the machine kicked off everything that followed.
Once I got into the research, it was all over. There are so many incredible historical stories that deserve to be more widely known.
PF.tv: Does it take a lot of research to prepare for these talks?
MA: It really does. Every 1 minute of one of my historical topic talks represents between 2-3 hours of research, reading and note taking.
PF.tv: What concepts do you recommend people be familiar with to maximize their experience with the talk?
MA: For this particular talk on time sharing, it would be helpful — but certainly not required — to be familiar with the ideas of concurrency since that's the fundamental underpinning of how time-sharing works. I will sketch out a quick history of concurrency.
PF.tv: What resources are available for people who want to study up before the talk?
MA: Conveniently, I did a talk on "The Early History of Concurrency/Distributed Systems" last year that's on Youtube.
Another really fascinating document is a video from 1963 posted by the Computer History museum which features Fernando Corbato (one of the original researchers working on the problem space) demonstrating the MIT time sharing system from his office via a teletype.
There are some other contemporary videos out there with Robert Fano - another MIT professor who also worked on these systems but they're longer and less professionally produced.
PF.tv: Where can people follow you online?
MA: I'm @bytemeorg on the Twitters. I still own the domain name but the website hasn't been active for years. (Yeah, I oughta set up something. It's on my todo list.)
PF.tv: Are there any projects you'd like people to be aware of? How can people help out?
MA: Something that's been particularly fun - although I spend more time reading about these systems than playing with them - is a lot of these old historical systems (both hardware and software) have pretty good emulators that are open source or freely available. That means in most cases it's entirely possible to boot one of these historical systems (as it used to be) and take it for a spin on modern hardware. When I was doing my quick 10 minute history of Unix for bangbangcon this past May, I found a website that has AT&T System VI Unix running on a PDP-11/70 emulator in a web browser. Most teletype keyboards didn't have lower case when System VI came out.
I think it would be amazingly helpful for our profession/discipline if we were more open to historical work. I think we have a tendency to dismiss or ignore historical topics. I'd like to see more conferences open to accepting and encouraging historical talks.
PF.tv: With your historical perspective, where do you see the state of operating systems in 10 years?
MA: Oh wow. Let's see. Gazing into my crystal ball, what I see is that the things which are difficult now are still difficult in 10 years. Those tend to be the human factors of software development - not the technical ones. One theme that constantly reoccurs in my research is how gosh darn optimistic people are that these human problems will be solved with technology. Usually they aren't.
I don't want to close on a pessimistic note though, so I will say I find more and more developers getting excited about and interested in research (historical and current) - and that will only be a good thing for everyone. Writing robust systems in the face of failures is pretty hard and it's silly to think we can ignore 50 years of research on a lot of these topics.
MA: Thanks for the questions!