Pike: First, let me clear up a misstatement. I amnot a co-creator of Unix. I suppose I am described that way because Iam co-author (with Brian Kernighan) of a book about Unix, but neitherBrian nor I would want to take credit for creating Unix. Ken Thompsonand Dennis Ritchie created Unix and deserve all the credit, and more. Ijoined their group - the Computing Science Research Center of Bell Labs- after 7th Edition Unix had come out.
1) Innovation and patents - by Zocalo
Withso many of your ideas being used with such ubiquity in modern operatingsystems, what is your stance on the issue of patenting of software andother "intellectual property" concepts? Assuming that business isn'tgoing to let IP patents go away as they strive to build patentstockpiles reminiscent of the nuclear arms buildup during the cold war,how would you like to see the issue resolved? Pike: Comparing patents to nuclear weapons is a bit extreme.
2) Systems research - by asyncster Inyour paper, systems software research is irrelevant, you claim thatthere is little room for innovation in systems programming, and thatall energy is devoted to supporting existing standards. Do you stillfeel this way now that you're working at Google? Pike: Iwas very careful to define my terms in that talk (it was never apaper). I was speaking primarily about operating systems and most ofwhat I said then (early 2000) is still true.
Here at Googlethe issues are quite different. The scale of the problem we're tryingto solve is so vast there are always challenges. I find it interestingthat the slide in that talk about 'Things to Build' is a close match tothe stuff we're doing at Google, if you squint a bit. To summarize:
GUI:Google put the cleanest, prettiest UI on the internet and workcontinues to find new ways to present data and make it easy to explore.
Component architectures: We use a number of big (BIG!) pieceparts like the Google File System (GFS) and MapReduce (see the paper byJeff Dean and Sanjay Ghemawat in the upcoming OSDI
http://labs.google.com/papers/mapreduce.html)to build massive engines for processing data. Using those pieces we canharness zillions of machines with a few keystrokes to attack a problemlike indexing the entire internet. (OK, it's not quite that easy, butit's still amazing.) I have a daily test job I run to monitor thehealth of one of the systems I'm developing; it uses a week of CPU timebut runs for only a few minutes of real time.
Languages for distributed computing: I'm part of a team working on something along those lines that we hope to write up soon.
Bringingdata to the user instead of the other way around: Those damn browsersare still in the way, but other ways of connecting to data are startingto appear, things like the Google API. However, the surface is barelyscratched on this topic.
System administration: Google'sproduction people are phenomenal at keeping all those machines hummingand ready for your queries. They demonstrated that there was realprogress to be made in the field of system administration, and theycontinue to push forward.
3) Back in The Day - by Greyfox
Wereprogrammers treated as hot-pluggable resources as they are today? Thereseems to be a mystique to the programmer prior to about 1995.
Fromreading the various netnews posts and recollections of olderprogrammers, it seems like the programmer back then was viewed assomething of a wizard without whom all the computers he was responsiblefor would immediately collapse. Has anything really changed or was itthe same back then as it is now? I'm wondering how much of what I'veread is simply nostalgia. Pike: Isn'tit just that today there are a lot more computers, a lot moreprogrammers, and most people are familiar with what computers andprogrammers do? I'm not sure I understand your reference to 1995, buttwenty or thirty years ago, computers were big expensive temples ofmodernity and anyone who could control their power was almost bydefinition a wizard. Today, even musicians can use computers (hi gary).
4) What are you doing... - by Mark Wilkinson
Googleemployees are apparently allowed to work on their own projects 20% ofthe time. Given that you probably can't comment on what you're doingfor Google, what are you doing to fill the other 20%? Pike: Oneof the most interesting projects out there, one I am peripherally (butonly peripherally) involved with, is the Large Synoptic SurveyTelescope
http://www.lsst.org,which will scan the visible sky to very high angular precision, inmultiple colors, many times a year. It's got an 8.4 meter aperture and10 square degree field, taking an image every 20 seconds with its 3gigapixel (sic) camera. The resulting data set will be many petabytesof image and catalog data, a data miner's dream. The software for thetelescope is as big a challenge as the instrument itself; just thereal-time pixel pipeline on the mountain will make today's computeclusters look wimpy.
5) Database filesystems - by defile
Thebuzz around filesystems research nowadays is making the UNIX filesystemmore database-ish. The buzz around database research nowadays is makingthe relational database more OOP-ish.
This research to mesounds like the original designers growing tired of the limitations oftheir "creations" now that they're commodities and going back to thedrawing board to "do things right this time". I predict the reinventedversions will never catch on because they'll be too complex andinaccessible.
Of course, this second system syndrome isn'tjust limited to systems. It happens to bands, directors, probably inevery creative art.
I think what we've got in the modern filesystem and RDBMS is about as good as it gets and we should move on. What do you think? Pike: Thisis not the first time databases and file systems have collided, merged,argued, and split up, and it won't be the last. The specifics ofwhether you have a file system or a database is a rather dull semanticdispute, a contest to see who's got the best technology, rigged in away that neither side wins. Well, as with most technologies, thesolution depends on the problem; there is no single right answer.
What'sreally interesting is how you think about accessing your data. Filesystems and databases provide different ways of organizing data to helpfind structure and meaning in what you've stored, but they're not theonly approaches possible. Moreover, the structure they provide isreally for one purpose: to simplify accessing it. Once you realize it'sthe access, not the structure, that matters, the whole debate changescharacter.
One of the big insights in the last few years,through work by the internet search engines but also tools like UdiManber's glimpse, is that data with no meaningful structure can stillbe very powerful if the tools to help you search the data are good. Infact, structure can be bad if the structure you have doesn't fit theproblem you're trying to solve today, regardless of how well it fit theproblem you were solving yesterday. So I don't much care any more howmy data is stored; what matters is how to retrieve the relevant pieceswhen I need them.
Grep was the definitive Unix tool early on;now we have tools that could be characterized as `grep my machine' and`grep the Internet'. GMail, Google's mail product, takes that idea andapplies it to mail: don't bother organizing your mail messages; justput them away for searching later. It's quite liberating if you can letgo your old file-and-folder-oriented mentality. Expect more liberationas searching replaces structure as the way to handle data.
6) Thoughts on Bell Labs - by geeber
Plan9, Unix and so many other great things came out of Bell Labs. Since thecrash of the internet bubble, telecom companies have sufferedimmensely. One of the results of this is that Lucent has systematicallydismantled one of the world's greatest industrial research facilities.You spent a great part of your career at Bell Labs. What are yourthoughts about the history and future (if any) of Bell Labs, and howdid the culture of the Labs influence the growth of Unix? Pike: It'sunfair to say `systematically dismantled', as though it was adeliberate process and there's nothing left. A more honest assessmentmight be that changes in the market and in government regulation madeit harder to keep a freewheeling research lab thriving at the scale ofthe old Bell Labs. Bell Labs Research is much smaller these days, butthere are still some very bright people working there and they're doinggreat stuff. I hope one day to see Bell Labs restored to its formerglory, but the world has changed enough that that may never happen.
Icould go on for pages about the old Bell Labs culture, but I must bebrief. When I arrived, in 1980, the Computing Science Research Center,also known as 127 (later 1127; therein lies a tale) had recentlylaunched 7th Edition Unix and the Center, after a long period ofessentially zero growth, was just entering a period of rapid expansion.That expansion brought in a lot of new people with new ideas. I was agraphics guy then, and I hooked up with Bart Locanthi, another graphicsguy, and we brought graphics to Research Unix with the Blit. Otherfolks brought in new languages, novel hardware, networking; all kindsof stuff. That period in the early 80s generated a lot of ideas thatinfluenced Unix both within the Labs and in the outside community. Ibelieve the fact that the Center was growing was a big part of itssuccess. The growth not only provided new ideas, it also generated akind of enthusiasm that doesn't exist in the steady state or in ashrinking group. Universities harness a variant of that energy with thecontinuous flow of graduate students; in industrial research you needto create it in other ways.
One odd detail that I think wasvital to how the group functioned was a result of the first Unix beingrun on a clunky minicomputer with terminals in the machine room. Peopleworking on the system congregated in the room - to use the computer,you pretty much had to be there. (This idea didn't seem odd back then;it was a natural evolution of the old hour-at-a-time way of bookingmachines like the IBM 7090.) The folks liked working that way, so whenthe machine was moved to a different room from the terminals, even whenit was possible to connect from your private office, there was still a`Unix room' with a bunch of terminals where people would congregate,code, design, and just hang out. (The coffee machine was there too.)The Unix room still exists, and it may be the greatest cultural reasonfor the success of Unix as a technology. More groups could profit fromits lesson, but it's really hard to add a Unix-room-like space to anexisting organization. You need the culture to encourage people not tohide in their offices, you need a way of using systems that makes apublic machine a viable place to work - typically by storing the datasomewhere other than the 'desktop' - and you need people like Ken andDennis (and Brian Kernighan and Doug McIlroy and Mike Lesk and StuFeldman and Greg Chesson and ...) hanging out in the room, but if youcan make it work, it's magical.
When I first started at the Labs, I spent most of my time in the Unix room. The buzz was palpable; the education unparalleled.
(Andspeaking of Doug, he's the unsung hero of Unix. He was manager of thegroup that produced it and a huge creative force in the group, but he'salmost unknown in the Unix community. He invented a couple of thingsyou might have heard of: pipes and - get this - macros. Well, someonehad to do it and that someone was Doug. As Ken once said when we weretalking one day in the Unix room, "There's no one smarter than Doug.")
7) Languages - by btlzu2
Hello!
Maybethis is an overly-asked question, but I still often ponder it. Doesobject-oriented design negate or diminish the future prospects ofUnix's continuing popularity?
I've developed in C (which Istill love), but lately, I've been doing a lot of purelyobject-oriented development in Java. Using things like delegation andreusable classes have made life so much easier in many respects. Sincethe *nixes are so dependent upon C, I was wondering what future you seein C combined with Unix. Like I said, I love C and still enjoydeveloping in Unix, but there has to be a point where you build on yourprogress and the object-oriented languages, in my opinion, seem to bedoing that.
Thank you for all your contributions!!! Pike: Thefuture does indeed seem to have an OO hue. It may have bearing on Unix,but I doubt it; Unix in all its variants has become so important as theoperating system of the internet that whatever the Java applicationsand desktop dances may lead to, Unix will still be pushing the packetsaround for a quite a while.
On a related topic, let me saythat I'm not much of a fan of object-oriented design. I've seen somebeautiful stuff done with OO, and I've even done some OO stuff myself,but it's just one way to approach a problem. For some problems, it's anideal way; for others, it's not such a good fit.
Here's ananalogy. If you want to make some physical artifact, you might decideto build it purely in wood because you like the way the grain of thewood adds to the beauty of the object. In fact many of the mostbeautiful things in the world are made of wood. But wood is not idealfor everything. No amount of beauty of the grain can make wood conductelectricity, or support a skyscraper, or absorb huge amounts of energywithout breaking. Sometimes you need metal or plastic or syntheticmaterials; more often you need a wide range of materials to buildsomething of lasting value. Don't let the fact that you love wood blindyou to the problems wood has as a material, or to the possibilitiesoffered by other materials.
The promoters of object-orienteddesign sometimes sound like master woodworkers waiting for the beautyof the physical block of wood to reveal itself before they begin towork. "Oh, look; if I turn the wood this way, the grain flows along theangle of the seat at just the right angle, see?" Great, nice chair. Butwill you notice the grain when you're sitting on it? And what aboutnext time? Sometimes the thing that needs to be made is not hiding inany block of wood.
OO is great for problems where an interfaceapplies naturally to a wide range of types, not so good for managingpolymorphism (the machinations to get collections into OO languages areastounding to watch and can be hellish to work with), and remarkablyill-suited for network computing. That's why I reserve the right tomatch the language to the problem, and even - often - to coordinatesoftware written in several languages towards solving a single problem.
It's that last point - different languages for differentsubproblems - that sometimes seems lost to the OO crowd. In a typicalworking day I probably use a half dozen languages - C, C++, Java,Python, Awk, Shell - and many more little languages you don't usuallyeven think of as languages - regular expressions, Makefiles, shellwildcards, arithmetic, logic, statistics, calculus - the list goes on.
Doesobject-oriented design have much to say to Unix? Sure, but no more thanfunctions or concurrency or databases or pattern matching or littlelanguages or....
Regardless of what I think, though, OO designis the way people are taught to think about computing these days. Iguess that's OK - the work does seem to get done, after all - but Iwish the view was a little broader.
8) One tool for one job? - by sczimme
Giventhe nature of current operating systems and applications, do you thinkthe idea of "one tool doing one job well" has been abandoned? If so, doyou think a return to this model would help bring some innovation backto software development?
(It's easier to toss a small, single-purpose app and start over than it is to toss a large, feature-laden app and start over.) Pike: Those days are dead and gone and the eulogy was delivered by Perl.
9) Emacs or Vi? - by Neil Blender Pike: Neither.
WhenI was a lad, I hacked up the 6th Edition ed with Tom Duff, HughRedelmeier, and David Tilbrook to resuscitate qed, the editor KenThompson wrote for CTSS that was the inspiration for the much slimmered. (Children must learn these things for themselves.) Dennis Ritchiehas a nice history of qed at
http://cm.bell-labs.com/cm/cs/who/dmr/qed.html> .
Iliked qed for one key reason: it was really good at editing a number offiles simultaneously. Ed only handled one file at a time.
Edand qed were command-driven line editors designed for printingterminals, not full-screen displays. After I got to Bell Labs, I triedout vi but it could only handle one file at a time, which I found toolimiting. Then I tried emacs, which handled multiple files but muchmore clumsily than qed. But the thing that bothered me most about viand emacs was that they gave you a two-dimensional display of your filebut you had only a one-dimensional input device to talk to them. It waslike giving directions with a map on the table, but being forced to say"up a little, right, no back down, right there, yes turn there that'sthe spot" instead of just putting your finger on the map.
(Today,emacs and vi support the mouse, but back in 1980 the versions I hadaccess to had no support for mice. For that matter, there weren'treally many mice yet.)
So as soon as the Blit started to work,it was time to write an editor that used the mouse as an input device.I used qed (mostly) and emacs (a little) to write the first draft ofjim, a full-screen editor that showed you text you could point to witha mouse. Jim handled multiple files very smoothly, and was really easyto use, but it was not terribly powerful. (Similar editors had been atXerox PARC and other research labs but, well, children must learn thesethings for themselves.)
A few years later I took the basicinput idea of jim and put a new ed-like command language underneath itand called it sam, a locally popular editor that still has itsadherents today. To me, the proof of sam's success was that it was thefirst full screen editor Ken Thompson liked. (He's still using it.)Here's the SP&E paper about sam from 1987:
http://plan9.bell-labs.com/sys/doc/sam/sam.pdf.
Afew years later, I decided the pop-up menu model for commanding aneditor with a mouse was too restrictive, so I started over and builtthe much more radical Acme, which I'm using to write these answers.Here's the Acme paper:
http://plan9.bell-labs.com/sys/doc/acme/acme.pdf Idon't expect any Slashdot readers to switch editors after reading thesepapers (although the code is available for most major platforms), but Ithink it's worth reading about them to see that there are ways ofediting - and working - that span a much larger gamut than is capturedby the question, 'Emacs or vi?'
10) Biggest problem with Unix - by akaina
Recently on the Google Labs Aptitude Test there was a question: "What's broken with Unix? How would you fix it?"
What would you have put? Pike: KenThompson and I started Plan 9 as an answer to that question. The majorthings we saw wrong with Unix when we started talking about what wouldbecome Plan 9, back around 1985, all stemmed from the appearance of anetwork. As a stand-alone system, Unix was pretty good. But when younetworked Unix machines together, you got a network of stand-alonesystems instead of a seamless, integrated networked system. Instead ofone big file system, one user community, one secure setup uniting yournetwork of machines, you had a hodgepodge of workarounds to Unix'sfundamental design decision that each machine is self-sufficient.
Nothing'sreally changed today. The workarounds have become smoother and some ofthe things we can do with networks of Unix machines are prettyimpressive, but when ssh is the foundation of your securityarchitecture, you know things aren't working as they should.
Looking at things from a lower altitude:
Ididn't use Unix at all, really, from about 1990 until 2002, when Ijoined Google. (I worked entirely on Plan 9, which I still believe doesa pretty good job of solving those fundamental problems.) I wassurprised when I came back to Unix how many of even the little thingsthat were annoying in 1990 continue to annoy today. In 1975, when theargument vector had to live in a 512-byte-block, the 6th Edition systemwould often complain, 'arg list too long'. But today, when machineshave gigabytes of memory, I still see that silly message far too often.The argument list is now limited somewhere north of 100K on the Linuxmachines I use at work, but come on people, dynamic memory allocationis a done deal!
I started keeping a list of these annoyancesbut it got too long and depressing so I just learned to live with themagain. We really are using a 1970s era operating system well past itssell-by date. We get a lot done, and we have fun, but let's face it,the fundamental design of Unix is older than many of the readers ofSlashdot, while lots of different, great ideas about computing andnetworks have been developed in the last 30 years. Using Unix is thecomputing equivalent of listening only to music by David Cassidy.
11) Re: Plan9 - by Spyffe
Rob,
Rightnow, there are a large number of research kernels. Plan 9, Inferno,AtheOS, Syllable, K42, Mach, L4, etc. all have their own ideas aboutthe future of the kernel. But they all end up implementing a POSIXinterface because the UNIX userland is the default.
The kernelspace needs to be invigorated using a new userland that demands new andinnovative functionality from the underlying system. Suppose you wereto design a user environment for the next 30 years. What would thecentral abstractions be? What sort of applications would it support? Pike: Atthe risk of contradicting my last answer a little, let me ask you back:Does the kernel matter any more? I don't think it does. They're all thesame at some level. I don't care nearly as much as I used to about thewhat the kernel does; it's so easy to emulate your way back to afamiliar state.
Applications - web browsers, MP3 players,games, all that jazz - and networks are where the action is today, andaside from irritating little incompatibilities, the kernel has become acommodity. Almost all the programs I care about can run above Windows,Unix, Plan 9, and on PCs, Macs, palmtops and more. And that, of course,is why these all have a POSIX interface: so they can support thoseapplications.
And then there's the standard network protocols to glue things together. It's all a uniform sea of interoperability (and bugs).
Ithink the future lies in new hardware as much as in new software. Ageneration from now machines will be so much more portable than theyare now, so much more powerful, so much more interactive that wehaven't begun to think about the changes they will bring. This may bethe biggest threat to Microsoft: the PC, the desktop, the laptop, willall go the way of the slide rule. As one example, when flexible organicsemiconductor displays roll out in a few years, the transformation inhow and where people use computers and other devices will be amazing.It's going to be a wild ride.
