Unix was originally developed on a PDP-7 minicomputer, starting in 1969 at Bell Labs. They used this computer for two years.

Then in 1971 they got funding to upgrade to a PDP-11, and ported Unix to run on that. This machine was a 16-bit powerhouse with up to 56 kilobytes of ram, and cost 20,000$ in 1970. That's about 133k$ today!

It had a lot more storage. Bell Labs bought the PDP-11/20 with a RK11 controller (supporting up to EIGHT hard drives), and initially fitted it with two RK05 hard drives. Each of these drives had a MASSIVE 2.5 megabytes of storage!

So originally Unix was running on the PDP-7 with one hard drive. One big partition, containing all the files. It had directories /bin and /usr at least, and /usr was USER DIRECTORIES and not /home (which is user directories now, if you're not a unix-er). /home came later. Originally it was /usr.

And when they upgraded to two drives on the PDP-11, they thought: hey, let's split this up logically: disk 1 is root, disk 2 is users!

So disk 1 contained /bin and other files, and disk 2 was /usr. All the users now had NEARLY INFINITE SPACE and everything was great.

The Unix was under active development, and all sorts of tools were being added. And they were running out of space, quickly. RK05 hard drives were expensive, so just adding a third drive would be a pain... and /usr wasn't very full...

So they duplicated the layout of / onto disk 2: /usr/bin & /usr/lib were created. Some utilities and libraries were moved there. Which ones? Which ones would fit, mainly.

The only real limitation on what could be moved there and what couldn't is that they had to make sure not to put anything that was required for basic booting onto disk 2. (Because if /bin/mount got moved to /usr/bin/mount, they wouldn't be able to mount disk 2).

So that pseudo-rule exists because of the chicken-and-egg problem you'd get into if important early-boot tools were on disk 2. So less important stuff ended up on disk 2, important boot stuff on disk 1. Other than that, the only guideline for placing files was "where it'd fit".

That decision made sometime between 1971 and 1973, to reuse /usr as a second drive of /bin & /lib (and possibly /sbin, I can't recall when that started), still echoes into modern Linux.

Q&A with Ken Thompson, creator of UNIX.

Q: At what point in Unix's development did it become clear it was going to be something much bigger than you'd anticipated?

A: The actual magnitude, that no one could have guessed. I gather it's still growing now. I thought it would be useful to essentially anybody like me, because it wasn't built for someone else or some third party. That was a pejorative term then. It was written for Dennis and me, and our group to do its work, and I through it would be useful to anybody who did the kind of work that we did. And therefore, I always thought it was something really good that was going to take off. Especially the language [C]. The language grew up with one of the rewritings of the system and, as such, it became perfect for writing systems. We would change it daily as we ran into trouble building Unix out of the language, and we'd modify it for our needs.

Q: A symbiosis of sort.

A: Yeah. It became the perfect language for what it was designed to do. I always thought the language and the system were widely applicable.

Q: The presentation for the Japan Prize mentioned that Unix was open source. Was Unix open source from the beginning?

A: Well there was no such term as "open source" then.

Q: I was under the impression that Unix really became open source with the Berkeley distribution..

A: No, we charged $100, which was essentially the reproduction cost of the tape, and then sent it out. And we distributed, oh, probably close to 100 copies to universities and others.

Q: Skipping several decades of work, let's speak about Go. I was just at the Google I/O Conference, where it was announced the Go will be supported on the Google  App Engine. Does that presage a wider adoption of Go within Google, or is it still experimental?

A: It's expanding every day and not being forced down anybody's throat. It's hard to adopt it to a project inside of Google because of the learning curve. It's brand new, and there aren't good manuals for it, except what's on the Web. And then, of cource, it's labeled as being experimental, so people are a little afraid. In spite of that, it's growing very fast inside of Google.

Q: In the presentation, you were quoted on the distinction between research and development. [Thompson said research is directionless, whereas development has a specific goal.] So in that context, is Go experimental?

A: Yes, When we [Thompson, Rob Pike and Robert Griesemer] got started, it was pure research. The three of us got toether and decided that we hated C++. [Laughs]

Q: I think there's a lot of people who are with you on that.

A: It's too complex. And going back, if we'd thought of it, we'd have done an object-oriented version of C back in the old days.

Q: You're saying you would have?

A: Yes, but we were not evangelists of object orientation. [In developing Go,] we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into language fro any reason.

Q: It's a lean language, indeed. Returning to Unix, when you and Dennis worked together, how did that collaboration operate? Were you working side by side?

A: I did the first of two or three versions of Unix all alone. And Dennis became an evangelist. Then there was a rewrite in a higher-level language that would come to be called C. He worked mostly on the language and on the I/O system, and I worked on all the rest of operating system. That was for the PDP-11, which was serendipitous, because that was the computer that took aver academic community.

Q: Right.

A: We collaborated every day. There was a lunch that we went to. And we'd talk over lunch. Then, at night we each worked from our separate homes, but we were in constant communication. In those days, we had mail and writ [pronounced "write"], and writ would pop up on your screen and say there was a message from so-and-so.

Q: So, IM, essentially.

A: Yes, IM. There was no doubt about that! And we discussed things from home with writ. We worked very well together and didn't collaborate a lot except to decide who was going to do what. Then we'd run and very independently do separate things. Rarely did we ever work on the same thing.

Q: Was there any concept of looking at each others code or doing code reviews?

A: [Shaking head] We were all pretty good coders.

Q: I suspect you probably were. Did you use any kind of source code management product when working together?

A: No, those products really came latter; after Unix. We had something like it, which we called "the code motel", because you could check your code in, but you couldn't check it out! So, really, no we didn't.

Q: I bet you use source code management today, in your work on Go.

A: Oh, yes, Google makes us do that.

http://blogs.sun.com/video/entry/zfs_boot_in_s10u6

Details about a customized boot DVD for Solaris OS: http://sun.systemnews.com/articles/132/3/Solaris/21273

Ping, the UNIX utility, was written in 1983 by Mike Muuss to probe a target machine and see if the network path to it is functioning correctly. It is one of the most ubiquitous of programs, and has gifted the vernacular with a number of neologisms. Many, but not all, of the following pingterms are derived from Muuss's creation:

Ping storm: A flurry of ping requests sent either to test a server's response to high traffic or as a form of DOS attack.

Ping of death: A malformed ping sent in an attempt to crash a machine.

Ping pong door: A ping pong table that fits in a doorway, designed by Tobias Franzel. Players stand in different rooms as they play.

Ping server: Blogs notify a ping server when their content has been updated.

Ping spam (or sping): Misusing a ping server to lure traffic to a site that is not a recent blog post.

No Self Pings: A Wordpress plug-in to make Wordpress stop sending pings from your site to your site when you post.

Sonar pingtones: Yes, you can make your cell phone ping you like submarine sonar.

Ping Zine: An online magazine about Web hosting (recent story: "Netfirms Now Accepting Applications for New .me Domain Names".)

Ping Records: A doowop label that operated out of the back of a record store at 4648 South Cottage Grove in Chicago for a few months in 1956.

Ping attribute: In tags in HTML 5, gives the URIs of the resources that are interested in being notified if the user follows the hyperlink.

Ping tunnel: A covert connection between two remote computers using ICMP echo requests and reply packets.

The Story About Ping: A beloved book in which a duck has adventures on the Yangtze river; the book received a different kind of fame when reviewed on Slashdot as though it were documentation for the UNIX utility.

The Sultans of Ping are available on iTunes.