Slashdot Mirror
Rob Pike Responds
He starts by clearing up my error in saying he was a Unix co-creator in the original Call For Questions. From there he goes on to answer your questions both completely and lucidly. A refreshing change from the politicians and executives we've talked to so much recently, no doubt about it.
Pike:
First, let me clear up a misstatement. I am not a co-creator of Unix. I suppose I am described that way because I am co-author (with Brian Kernighan) of a book about Unix, but neither Brian nor I would want to take credit for creating Unix. Ken Thompson and Dennis Ritchie created Unix and deserve all the credit, and more. I joined their group - the Computing Science Research Center of Bell Labs - after 7th Edition Unix had come out.
1) Innovation and patents - by Zocalo
With so many of your ideas being used with such ubiquity in modern operating systems, what is your stance on the issue of patenting of software and other "intellectual property" concepts? Assuming that business isn't going to let IP patents go away as they strive to build patent stockpiles 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
In your paper, systems software research is irrelevant, you claim that there is little room for innovation in systems programming, and that all energy is devoted to supporting existing standards. Do you still feel this way now that you're working at Google?
Pike:
I was very careful to define my terms in that talk (it was never a paper). I was speaking primarily about operating systems and most of what I said then (early 2000) is still true.
Here at Google the issues are quite different. The scale of the problem we're trying to solve is so vast there are always challenges. I find it interesting that the slide in that talk about 'Things to Build' is a close match to the stuff we're doing at Google, if you squint a bit. To summarize:
GUI: Google put the cleanest, prettiest UI on the internet and work continues to find new ways to present data and make it easy to explore.
Component architectures: We use a number of big (BIG!) piece parts like the Google File System (GFS) and MapReduce (see the paper by Jeff 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 can harness zillions of machines with a few keystrokes to attack a problem like indexing the entire internet. (OK, it's not quite that easy, but it's still amazing.) I have a daily test job I run to monitor the health of one of the systems I'm developing; it uses a week of CPU time but 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.
Bringing data to the user instead of the other way around: Those damn browsers are still in the way, but other ways of connecting to data are starting to appear, things like the Google API. However, the surface is barely scratched on this topic.
System administration: Google's production people are phenomenal at keeping all those machines humming and ready for your queries. They demonstrated that there was real progress to be made in the field of system administration, and they continue to push forward.
3) Back in The Day - by Greyfox
Were programmers treated as hot-pluggable resources as they are today? There seems to be a mystique to the programmer prior to about 1995.
From reading the various netnews posts and recollections of older programmers, it seems like the programmer back then was viewed as something of a wizard without whom all the computers he was responsible for would immediately collapse. Has anything really changed or was it the same back then as it is now? I'm wondering how much of what I've read is simply nostalgia.
Pike:
Isn't it just that today there are a lot more computers, a lot more programmers, and most people are familiar with what computers and programmers do? I'm not sure I understand your reference to 1995, but twenty or thirty years ago, computers were big expensive temples of modernity and anyone who could control their power was almost by definition a wizard. Today, even musicians can use computers (hi gary).
4) What are you doing... - by Mark Wilkinson
Google employees are apparently allowed to work on their own projects 20% of the time. Given that you probably can't comment on what you're doing for Google, what are you doing to fill the other 20%?
Pike:
One of the most interesting projects out there, one I am peripherally (but only peripherally) involved with, is the Large Synoptic Survey Telescope http://www.lsst.org, which will scan the visible sky to very high angular precision, in multiple colors, many times a year. It's got an 8.4 meter aperture and 10 square degree field, taking an image every 20 seconds with its 3 gigapixel (sic) camera. The resulting data set will be many petabytes of image and catalog data, a data miner's dream. The software for the telescope is as big a challenge as the instrument itself; just the real-time pixel pipeline on the mountain will make today's compute clusters look wimpy.
5) Database filesystems - by defile
The buzz around filesystems research nowadays is making the UNIX filesystem more database-ish. The buzz around database research nowadays is making the relational database more OOP-ish.
This research to me sounds like the original designers growing tired of the limitations of their "creations" now that they're commodities and going back to the drawing board to "do things right this time". I predict the reinvented versions will never catch on because they'll be too complex and inaccessible.
Of course, this second system syndrome isn't just limited to systems. It happens to bands, directors, probably in every 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:
This is not the first time databases and file systems have collided, merged, argued, and split up, and it won't be the last. The specifics of whether you have a file system or a database is a rather dull semantic dispute, a contest to see who's got the best technology, rigged in a way that neither side wins. Well, as with most technologies, the solution depends on the problem; there is no single right answer.
What's really interesting is how you think about accessing your data. File systems and databases provide different ways of organizing data to help find structure and meaning in what you've stored, but they're not the only approaches possible. Moreover, the structure they provide is really for one purpose: to simplify accessing it. Once you realize it's the access, not the structure, that matters, the whole debate changes character.
One of the big insights in the last few years, through work by the internet search engines but also tools like Udi Manber's glimpse, is that data with no meaningful structure can still be very powerful if the tools to help you search the data are good. In fact, structure can be bad if the structure you have doesn't fit the problem you're trying to solve today, regardless of how well it fit the problem you were solving yesterday. So I don't much care any more how my data is stored; what matters is how to retrieve the relevant pieces when 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 and applies it to mail: don't bother organizing your mail messages; just put them away for searching later. It's quite liberating if you can let go your old file-and-folder-oriented mentality. Expect more liberation as searching replaces structure as the way to handle data.
6) Thoughts on Bell Labs - by geeber
Plan 9, Unix and so many other great things came out of Bell Labs. Since the crash of the internet bubble, telecom companies have suffered immensely. One of the results of this is that Lucent has systematically dismantled one of the world's greatest industrial research facilities. You spent a great part of your career at Bell Labs. What are your thoughts about the history and future (if any) of Bell Labs, and how did the culture of the Labs influence the growth of Unix?
Pike:
It's unfair to say `systematically dismantled', as though it was a deliberate process and there's nothing left. A more honest assessment might be that changes in the market and in government regulation made it harder to keep a freewheeling research lab thriving at the scale of the old Bell Labs. Bell Labs Research is much smaller these days, but there are still some very bright people working there and they're doing great stuff. I hope one day to see Bell Labs restored to its former glory, but the world has changed enough that that may never happen.
I could go on for pages about the old Bell Labs culture, but I must be brief. When I arrived, in 1980, the Computing Science Research Center, also known as 127 (later 1127; therein lies a tale) had recently launched 7th Edition Unix and the Center, after a long period of essentially zero growth, was just entering a period of rapid expansion. That expansion brought in a lot of new people with new ideas. I was a graphics guy then, and I hooked up with Bart Locanthi, another graphics guy, and we brought graphics to Research Unix with the Blit. Other folks brought in new languages, novel hardware, networking; all kinds of stuff. That period in the early 80s generated a lot of ideas that influenced Unix both within the Labs and in the outside community. I believe the fact that the Center was growing was a big part of its success. The growth not only provided new ideas, it also generated a kind of enthusiasm that doesn't exist in the steady state or in a shrinking group. Universities harness a variant of that energy with the continuous flow of graduate students; in industrial research you need to create it in other ways.
One odd detail that I think was vital to how the group functioned was a result of the first Unix being run on a clunky minicomputer with terminals in the machine room. People working 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 booking machines like the IBM 7090.) The folks liked working that way, so when the machine was moved to a different room from the terminals, even when it 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 reason for the success of Unix as a technology. More groups could profit from its lesson, but it's really hard to add a Unix-room-like space to an existing organization. You need the culture to encourage people not to hide in their offices, you need a way of using systems that makes a public machine a viable place to work - typically by storing the data somewhere other than the 'desktop' - and you need people like Ken and Dennis (and Brian Kernighan and Doug McIlroy and Mike Lesk and Stu Feldman and Greg Chesson and ...) hanging out in the room, but if you can 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.
(And speaking of Doug, he's the unsung hero of Unix. He was manager of the group that produced it and a huge creative force in the group, but he's almost unknown in the Unix community. He invented a couple of things you might have heard of: pipes and - get this - macros. Well, someone had to do it and that someone was Doug. As Ken once said when we were talking one day in the Unix room, "There's no one smarter than Doug.")
7) Languages - by btlzu2
Hello!
Maybe this is an overly-asked question, but I still often ponder it. Does object-oriented design negate or diminish the future prospects of Unix's continuing popularity?
I've developed in C (which I still love), but lately, I've been doing a lot of purely object-oriented development in Java. Using things like delegation and reusable classes have made life so much easier in many respects. Since the *nixes are so dependent upon C, I was wondering what future you see in C combined with Unix. Like I said, I love C and still enjoy developing in Unix, but there has to be a point where you build on your progress and the object-oriented languages, in my opinion, seem to be doing that.
Thank you for all your contributions!!!
Pike:
The future 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 the operating system of the internet that whatever the Java applications and desktop dances may lead to, Unix will still be pushing the packets around for a quite a while.
On a related topic, let me say that I'm not much of a fan of object-oriented design. I've seen some beautiful 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 an ideal way; for others, it's not such a good fit.
Here's an analogy. If you want to make some physical artifact, you might decide to build it purely in wood because you like the way the grain of the wood adds to the beauty of the object. In fact many of the most beautiful things in the world are made of wood. But wood is not ideal for everything. No amount of beauty of the grain can make wood conduct electricity, or support a skyscraper, or absorb huge amounts of energy without breaking. Sometimes you need metal or plastic or synthetic materials; more often you need a wide range of materials to build something of lasting value. Don't let the fact that you love wood blind you to the problems wood has as a material, or to the possibilities offered by other materials.
The promoters of object-oriented design sometimes sound like master woodworkers waiting for the beauty of the physical block of wood to reveal itself before they begin to work. "Oh, look; if I turn the wood this way, the grain flows along the angle of the seat at just the right angle, see?" Great, nice chair. But will you notice the grain when you're sitting on it? And what about next time? Sometimes the thing that needs to be made is not hiding in any block of wood.
OO is great for problems where an interface applies naturally to a wide range of types, not so good for managing polymorphism (the machinations to get collections into OO languages are astounding to watch and can be hellish to work with), and remarkably ill-suited for network computing. That's why I reserve the right to match the language to the problem, and even - often - to coordinate software written in several languages towards solving a single problem.
It's that last point - different languages for different subproblems - that sometimes seems lost to the OO crowd. In a typical working day I probably use a half dozen languages - C, C++, Java, Python, Awk, Shell - and many more little languages you don't usually even think of as languages - regular expressions, Makefiles, shell wildcards, arithmetic, logic, statistics, calculus - the list goes on.
Does object-oriented design have much to say to Unix? Sure, but no more than functions or concurrency or databases or pattern matching or little languages or....
Regardless of what I think, though, OO design is the way people are taught to think about computing these days. I guess that's OK - the work does seem to get done, after all - but I wish the view was a little broader.
8) One tool for one job? - by sczimme
Given the nature of current operating systems and applications, do you think the idea of "one tool doing one job well" has been abandoned? If so, do you think a return to this model would help bring some innovation back to 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.
When I was a lad, I hacked up the 6th Edition ed with Tom Duff, Hugh Redelmeier, and David Tilbrook to resuscitate qed, the editor Ken Thompson wrote for CTSS that was the inspiration for the much slimmer ed. (Children must learn these things for themselves.) Dennis Ritchie has a nice history of qed at http://cm.bell-labs.com/cm/cs/who/dmr/qed.html> .
I liked qed for one key reason: it was really good at editing a number of files simultaneously. Ed only handled one file at a time.
Ed and qed were command-driven line editors designed for printing terminals, not full-screen displays. After I got to Bell Labs, I tried out vi but it could only handle one file at a time, which I found too limiting. Then I tried emacs, which handled multiple files but much more clumsily than qed. But the thing that bothered me most about vi and emacs was that they gave you a two-dimensional display of your file but you had only a one-dimensional input device to talk to them. It was like 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's the spot" instead of just putting your finger on the map.
(Today, emacs and vi support the mouse, but back in 1980 the versions I had access to had no support for mice. For that matter, there weren't really 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 of jim, a full-screen editor that showed you text you could point to with a mouse. Jim handled multiple files very smoothly, and was really easy to use, but it was not terribly powerful. (Similar editors had been at Xerox PARC and other research labs but, well, children must learn these things for themselves.)
A few years later I took the basic input idea of jim and put a new ed-like command language underneath it and called it sam, a locally popular editor that still has its adherents today. To me, the proof of sam's success was that it was the first 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.
A few years later, I decided the pop-up menu model for commanding an editor with a mouse was too restrictive, so I started over and built the 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
I don't expect any Slashdot readers to switch editors after reading these papers (although the code is available for most major platforms), but I think it's worth reading about them to see that there are ways of editing - and working - that span a much larger gamut than is captured by 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:
Ken Thompson and I started Plan 9 as an answer to that question. The major things we saw wrong with Unix when we started talking about what would become Plan 9, back around 1985, all stemmed from the appearance of a network. As a stand-alone system, Unix was pretty good. But when you networked Unix machines together, you got a network of stand-alone systems instead of a seamless, integrated networked system. Instead of one big file system, one user community, one secure setup uniting your network of machines, you had a hodgepodge of workarounds to Unix's fundamental design decision that each machine is self-sufficient.
Nothing's really changed today. The workarounds have become smoother and some of the things we can do with networks of Unix machines are pretty impressive, but when ssh is the foundation of your security architecture, you know things aren't working as they should.
Looking at things from a lower altitude:
I didn't use Unix at all, really, from about 1990 until 2002, when I joined Google. (I worked entirely on Plan 9, which I still believe does a pretty good job of solving those fundamental problems.) I was surprised when I came back to Unix how many of even the little things that were annoying in 1990 continue to annoy today. In 1975, when the argument vector had to live in a 512-byte-block, the 6th Edition system would often complain, 'arg list too long'. But today, when machines have gigabytes of memory, I still see that silly message far too often. The argument list is now limited somewhere north of 100K on the Linux machines I use at work, but come on people, dynamic memory allocation is a done deal!
I started keeping a list of these annoyances but it got too long and depressing so I just learned to live with them again. We really are using a 1970s era operating system well past its sell-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 of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.
11) Re: Plan9 - by Spyffe
Rob,
Right now, there are a large number of research kernels. Plan 9, Inferno, AtheOS, Syllable, K42, Mach, L4, etc. all have their own ideas about the future of the kernel. But they all end up implementing a POSIX interface because the UNIX userland is the default.
The kernel space needs to be invigorated using a new userland that demands new and innovative functionality from the underlying system. Suppose you were to design a user environment for the next 30 years. What would the central abstractions be? What sort of applications would it support?
Pike:
At the 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 the same at some level. I don't care nearly as much as I used to about the what the kernel does; it's so easy to emulate your way back to a familiar state.
Applications - web browsers, MP3 players, games, all that jazz - and networks are where the action is today, and aside from irritating little incompatibilities, the kernel has become a commodity. 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 those applications.
And then there's the standard network protocols to glue things together. It's all a uniform sea of interoperability (and bugs).
I think the future lies in new hardware as much as in new software. A generation from now machines will be so much more portable than they are now, so much more powerful, so much more interactive that we haven't begun to think about the changes they will bring. This may be the biggest threat to Microsoft: the PC, the desktop, the laptop, will all go the way of the slide rule. As one example, when flexible organic semiconductor displays roll out in a few years, the transformation in how and where people use computers and other devices will be amazing. It's going to be a wild ride.
===============
Pike:
First, let me clear up a misstatement. I am not a co-creator of Unix. I suppose I am described that way because I am co-author (with Brian Kernighan) of a book about Unix, but neither Brian nor I would want to take credit for creating Unix. Ken Thompson and Dennis Ritchie created Unix and deserve all the credit, and more. I joined their group - the Computing Science Research Center of Bell Labs - after 7th Edition Unix had come out.
1) Innovation and patents - by Zocalo
With so many of your ideas being used with such ubiquity in modern operating systems, what is your stance on the issue of patenting of software and other "intellectual property" concepts? Assuming that business isn't going to let IP patents go away as they strive to build patent stockpiles 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
In your paper, systems software research is irrelevant, you claim that there is little room for innovation in systems programming, and that all energy is devoted to supporting existing standards. Do you still feel this way now that you're working at Google?
Pike:
I was very careful to define my terms in that talk (it was never a paper). I was speaking primarily about operating systems and most of what I said then (early 2000) is still true.
Here at Google the issues are quite different. The scale of the problem we're trying to solve is so vast there are always challenges. I find it interesting that the slide in that talk about 'Things to Build' is a close match to the stuff we're doing at Google, if you squint a bit. To summarize:
GUI: Google put the cleanest, prettiest UI on the internet and work continues to find new ways to present data and make it easy to explore.
Component architectures: We use a number of big (BIG!) piece parts like the Google File System (GFS) and MapReduce (see the paper by Jeff 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 can harness zillions of machines with a few keystrokes to attack a problem like indexing the entire internet. (OK, it's not quite that easy, but it's still amazing.) I have a daily test job I run to monitor the health of one of the systems I'm developing; it uses a week of CPU time but 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.
Bringing data to the user instead of the other way around: Those damn browsers are still in the way, but other ways of connecting to data are starting to appear, things like the Google API. However, the surface is barely scratched on this topic.
System administration: Google's production people are phenomenal at keeping all those machines humming and ready for your queries. They demonstrated that there was real progress to be made in the field of system administration, and they continue to push forward.
3) Back in The Day - by Greyfox
Were programmers treated as hot-pluggable resources as they are today? There seems to be a mystique to the programmer prior to about 1995.
From reading the various netnews posts and recollections of older programmers, it seems like the programmer back then was viewed as something of a wizard without whom all the computers he was responsible for would immediately collapse. Has anything really changed or was it the same back then as it is now? I'm wondering how much of what I've read is simply nostalgia.
Pike:
Isn't it just that today there are a lot more computers, a lot more programmers, and most people are familiar with what computers and programmers do? I'm not sure I understand your reference to 1995, but twenty or thirty years ago, computers were big expensive temples of modernity and anyone who could control their power was almost by definition a wizard. Today, even musicians can use computers (hi gary).
4) What are you doing... - by Mark Wilkinson
Google employees are apparently allowed to work on their own projects 20% of the time. Given that you probably can't comment on what you're doing for Google, what are you doing to fill the other 20%?
Pike:
One of the most interesting projects out there, one I am peripherally (but only peripherally) involved with, is the Large Synoptic Survey Telescope http://www.lsst.org, which will scan the visible sky to very high angular precision, in multiple colors, many times a year. It's got an 8.4 meter aperture and 10 square degree field, taking an image every 20 seconds with its 3 gigapixel (sic) camera. The resulting data set will be many petabytes of image and catalog data, a data miner's dream. The software for the telescope is as big a challenge as the instrument itself; just the real-time pixel pipeline on the mountain will make today's compute clusters look wimpy.
5) Database filesystems - by defile
The buzz around filesystems research nowadays is making the UNIX filesystem more database-ish. The buzz around database research nowadays is making the relational database more OOP-ish.
This research to me sounds like the original designers growing tired of the limitations of their "creations" now that they're commodities and going back to the drawing board to "do things right this time". I predict the reinvented versions will never catch on because they'll be too complex and inaccessible.
Of course, this second system syndrome isn't just limited to systems. It happens to bands, directors, probably in every 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:
This is not the first time databases and file systems have collided, merged, argued, and split up, and it won't be the last. The specifics of whether you have a file system or a database is a rather dull semantic dispute, a contest to see who's got the best technology, rigged in a way that neither side wins. Well, as with most technologies, the solution depends on the problem; there is no single right answer.
What's really interesting is how you think about accessing your data. File systems and databases provide different ways of organizing data to help find structure and meaning in what you've stored, but they're not the only approaches possible. Moreover, the structure they provide is really for one purpose: to simplify accessing it. Once you realize it's the access, not the structure, that matters, the whole debate changes character.
One of the big insights in the last few years, through work by the internet search engines but also tools like Udi Manber's glimpse, is that data with no meaningful structure can still be very powerful if the tools to help you search the data are good. In fact, structure can be bad if the structure you have doesn't fit the problem you're trying to solve today, regardless of how well it fit the problem you were solving yesterday. So I don't much care any more how my data is stored; what matters is how to retrieve the relevant pieces when 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 and applies it to mail: don't bother organizing your mail messages; just put them away for searching later. It's quite liberating if you can let go your old file-and-folder-oriented mentality. Expect more liberation as searching replaces structure as the way to handle data.
6) Thoughts on Bell Labs - by geeber
Plan 9, Unix and so many other great things came out of Bell Labs. Since the crash of the internet bubble, telecom companies have suffered immensely. One of the results of this is that Lucent has systematically dismantled one of the world's greatest industrial research facilities. You spent a great part of your career at Bell Labs. What are your thoughts about the history and future (if any) of Bell Labs, and how did the culture of the Labs influence the growth of Unix?
Pike:
It's unfair to say `systematically dismantled', as though it was a deliberate process and there's nothing left. A more honest assessment might be that changes in the market and in government regulation made it harder to keep a freewheeling research lab thriving at the scale of the old Bell Labs. Bell Labs Research is much smaller these days, but there are still some very bright people working there and they're doing great stuff. I hope one day to see Bell Labs restored to its former glory, but the world has changed enough that that may never happen.
I could go on for pages about the old Bell Labs culture, but I must be brief. When I arrived, in 1980, the Computing Science Research Center, also known as 127 (later 1127; therein lies a tale) had recently launched 7th Edition Unix and the Center, after a long period of essentially zero growth, was just entering a period of rapid expansion. That expansion brought in a lot of new people with new ideas. I was a graphics guy then, and I hooked up with Bart Locanthi, another graphics guy, and we brought graphics to Research Unix with the Blit. Other folks brought in new languages, novel hardware, networking; all kinds of stuff. That period in the early 80s generated a lot of ideas that influenced Unix both within the Labs and in the outside community. I believe the fact that the Center was growing was a big part of its success. The growth not only provided new ideas, it also generated a kind of enthusiasm that doesn't exist in the steady state or in a shrinking group. Universities harness a variant of that energy with the continuous flow of graduate students; in industrial research you need to create it in other ways.
One odd detail that I think was vital to how the group functioned was a result of the first Unix being run on a clunky minicomputer with terminals in the machine room. People working 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 booking machines like the IBM 7090.) The folks liked working that way, so when the machine was moved to a different room from the terminals, even when it 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 reason for the success of Unix as a technology. More groups could profit from its lesson, but it's really hard to add a Unix-room-like space to an existing organization. You need the culture to encourage people not to hide in their offices, you need a way of using systems that makes a public machine a viable place to work - typically by storing the data somewhere other than the 'desktop' - and you need people like Ken and Dennis (and Brian Kernighan and Doug McIlroy and Mike Lesk and Stu Feldman and Greg Chesson and ...) hanging out in the room, but if you can 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.
(And speaking of Doug, he's the unsung hero of Unix. He was manager of the group that produced it and a huge creative force in the group, but he's almost unknown in the Unix community. He invented a couple of things you might have heard of: pipes and - get this - macros. Well, someone had to do it and that someone was Doug. As Ken once said when we were talking one day in the Unix room, "There's no one smarter than Doug.")
7) Languages - by btlzu2
Hello!
Maybe this is an overly-asked question, but I still often ponder it. Does object-oriented design negate or diminish the future prospects of Unix's continuing popularity?
I've developed in C (which I still love), but lately, I've been doing a lot of purely object-oriented development in Java. Using things like delegation and reusable classes have made life so much easier in many respects. Since the *nixes are so dependent upon C, I was wondering what future you see in C combined with Unix. Like I said, I love C and still enjoy developing in Unix, but there has to be a point where you build on your progress and the object-oriented languages, in my opinion, seem to be doing that.
Thank you for all your contributions!!!
Pike:
The future 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 the operating system of the internet that whatever the Java applications and desktop dances may lead to, Unix will still be pushing the packets around for a quite a while.
On a related topic, let me say that I'm not much of a fan of object-oriented design. I've seen some beautiful 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 an ideal way; for others, it's not such a good fit.
Here's an analogy. If you want to make some physical artifact, you might decide to build it purely in wood because you like the way the grain of the wood adds to the beauty of the object. In fact many of the most beautiful things in the world are made of wood. But wood is not ideal for everything. No amount of beauty of the grain can make wood conduct electricity, or support a skyscraper, or absorb huge amounts of energy without breaking. Sometimes you need metal or plastic or synthetic materials; more often you need a wide range of materials to build something of lasting value. Don't let the fact that you love wood blind you to the problems wood has as a material, or to the possibilities offered by other materials.
The promoters of object-oriented design sometimes sound like master woodworkers waiting for the beauty of the physical block of wood to reveal itself before they begin to work. "Oh, look; if I turn the wood this way, the grain flows along the angle of the seat at just the right angle, see?" Great, nice chair. But will you notice the grain when you're sitting on it? And what about next time? Sometimes the thing that needs to be made is not hiding in any block of wood.
OO is great for problems where an interface applies naturally to a wide range of types, not so good for managing polymorphism (the machinations to get collections into OO languages are astounding to watch and can be hellish to work with), and remarkably ill-suited for network computing. That's why I reserve the right to match the language to the problem, and even - often - to coordinate software written in several languages towards solving a single problem.
It's that last point - different languages for different subproblems - that sometimes seems lost to the OO crowd. In a typical working day I probably use a half dozen languages - C, C++, Java, Python, Awk, Shell - and many more little languages you don't usually even think of as languages - regular expressions, Makefiles, shell wildcards, arithmetic, logic, statistics, calculus - the list goes on.
Does object-oriented design have much to say to Unix? Sure, but no more than functions or concurrency or databases or pattern matching or little languages or....
Regardless of what I think, though, OO design is the way people are taught to think about computing these days. I guess that's OK - the work does seem to get done, after all - but I wish the view was a little broader.
8) One tool for one job? - by sczimme
Given the nature of current operating systems and applications, do you think the idea of "one tool doing one job well" has been abandoned? If so, do you think a return to this model would help bring some innovation back to 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.
When I was a lad, I hacked up the 6th Edition ed with Tom Duff, Hugh Redelmeier, and David Tilbrook to resuscitate qed, the editor Ken Thompson wrote for CTSS that was the inspiration for the much slimmer ed. (Children must learn these things for themselves.) Dennis Ritchie has a nice history of qed at http://cm.bell-labs.com/cm/cs/who/dmr/qed.html> .
I liked qed for one key reason: it was really good at editing a number of files simultaneously. Ed only handled one file at a time.
Ed and qed were command-driven line editors designed for printing terminals, not full-screen displays. After I got to Bell Labs, I tried out vi but it could only handle one file at a time, which I found too limiting. Then I tried emacs, which handled multiple files but much more clumsily than qed. But the thing that bothered me most about vi and emacs was that they gave you a two-dimensional display of your file but you had only a one-dimensional input device to talk to them. It was like 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's the spot" instead of just putting your finger on the map.
(Today, emacs and vi support the mouse, but back in 1980 the versions I had access to had no support for mice. For that matter, there weren't really 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 of jim, a full-screen editor that showed you text you could point to with a mouse. Jim handled multiple files very smoothly, and was really easy to use, but it was not terribly powerful. (Similar editors had been at Xerox PARC and other research labs but, well, children must learn these things for themselves.)
A few years later I took the basic input idea of jim and put a new ed-like command language underneath it and called it sam, a locally popular editor that still has its adherents today. To me, the proof of sam's success was that it was the first 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.
A few years later, I decided the pop-up menu model for commanding an editor with a mouse was too restrictive, so I started over and built the 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
I don't expect any Slashdot readers to switch editors after reading these papers (although the code is available for most major platforms), but I think it's worth reading about them to see that there are ways of editing - and working - that span a much larger gamut than is captured by 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:
Ken Thompson and I started Plan 9 as an answer to that question. The major things we saw wrong with Unix when we started talking about what would become Plan 9, back around 1985, all stemmed from the appearance of a network. As a stand-alone system, Unix was pretty good. But when you networked Unix machines together, you got a network of stand-alone systems instead of a seamless, integrated networked system. Instead of one big file system, one user community, one secure setup uniting your network of machines, you had a hodgepodge of workarounds to Unix's fundamental design decision that each machine is self-sufficient.
Nothing's really changed today. The workarounds have become smoother and some of the things we can do with networks of Unix machines are pretty impressive, but when ssh is the foundation of your security architecture, you know things aren't working as they should.
Looking at things from a lower altitude:
I didn't use Unix at all, really, from about 1990 until 2002, when I joined Google. (I worked entirely on Plan 9, which I still believe does a pretty good job of solving those fundamental problems.) I was surprised when I came back to Unix how many of even the little things that were annoying in 1990 continue to annoy today. In 1975, when the argument vector had to live in a 512-byte-block, the 6th Edition system would often complain, 'arg list too long'. But today, when machines have gigabytes of memory, I still see that silly message far too often. The argument list is now limited somewhere north of 100K on the Linux machines I use at work, but come on people, dynamic memory allocation is a done deal!
I started keeping a list of these annoyances but it got too long and depressing so I just learned to live with them again. We really are using a 1970s era operating system well past its sell-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 of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.
11) Re: Plan9 - by Spyffe
Rob,
Right now, there are a large number of research kernels. Plan 9, Inferno, AtheOS, Syllable, K42, Mach, L4, etc. all have their own ideas about the future of the kernel. But they all end up implementing a POSIX interface because the UNIX userland is the default.
The kernel space needs to be invigorated using a new userland that demands new and innovative functionality from the underlying system. Suppose you were to design a user environment for the next 30 years. What would the central abstractions be? What sort of applications would it support?
Pike:
At the 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 the same at some level. I don't care nearly as much as I used to about the what the kernel does; it's so easy to emulate your way back to a familiar state.
Applications - web browsers, MP3 players, games, all that jazz - and networks are where the action is today, and aside from irritating little incompatibilities, the kernel has become a commodity. 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 those applications.
And then there's the standard network protocols to glue things together. It's all a uniform sea of interoperability (and bugs).
I think the future lies in new hardware as much as in new software. A generation from now machines will be so much more portable than they are now, so much more powerful, so much more interactive that we haven't begun to think about the changes they will bring. This may be the biggest threat to Microsoft: the PC, the desktop, the laptop, will all go the way of the slide rule. As one example, when flexible organic semiconductor displays roll out in a few years, the transformation in how and where people use computers and other devices will be amazing. It's going to be a wild ride.
===============
Well that was a complete and total ignoring of the intent of the patent question on the basis of not agreeing with a minor portion of the question.
Is he running for office?
" Comparing patents to nuclear weapons is a bit extreme. "
Now there's a sidestep George Bush would approve of.
If guns kill people, then CmdrTaco's keyboard misspells words.
isn't that a fish? why does slashdot interview a fish?
Is he recovering from head trauma or something? It makes it sound like his next step is walking to the restroom without assistance...
He didn't want to talk about the Year 2038 Bug...
I'm disappointed.
Will M$ hire Darl McBride and the whole Canopy Group into the Linux legal department after he destroys SCO?
"Using Unix is the computing equivalent of listening only to music by David Cassidy"
To continue the musical comparison. Windows, 15 different variations of the same mass produced pop song whos only existance is to make money for a company that already has a lot of money.
I'll take David Cassidy, even if he has a CLI only.
it is only after a long journey that you know the strength of the horse.
C'mon... comparing corporate IP/Patents to the nuclear arms race? That kind of flawed reasoning works on slashdot, but not with anyone out in the real world.
He gave an appropriate response to a STUPID analogy.
But I suppose it's not too surprising, considering the havoc that he and ATT wreaked upon X for Pike's save-under patent.
Save-under was/is a good idea, and so insanely simple it's hard to believe that a patent was granted -- much less weilded with such force. For youngsters (and as an oldster, perhaps my memory isn't quite perfect on this) some early machines had overlay planes for menus. You could draw the menu over the frame, then clear the overlay plane, without disturbing the contents of the window beneath. To do this on a bitmapped display without overlays, the idea was that you would screen-grab the image under where the menu would be, then paste it back when the menu disappeared.
Pike defended ATT's refusal to allow the X consortium to use save-under without royalty at the time.
Thad
I love Mondays. On a Monday, anything is possible.
refreshing change from the politicians and executives we've talked to so much recently
Except that Slashdot refuses to confront the real business and political issues facing programmers.
The editors' story selection betrays their biases toward ignorance and denial. There's too many puff pieces on Apple and KDE and not enough on how industry lobbyists have stacked the deck against American labor.
This was one of the most interesting reviews I have read in awhile.
Hmm...The summary claims:
From there he goes on to answer your questions both completely and lucidly. A refreshing change from the politicians and executives we've talked to so much recently, no doubt about it.
The actual interview says:
Pike:
Comparing patents to nuclear weapons is a bit extreme.
Clearly the summary is being sarcastic...
What would you have put?
Nice answer given by Pike (and no, I'm not going to requote the whole thing), but good luck fitting it into the box here on the 'test.' :-)
object-oriented design is the roman numerals of computing.
-- Rob Pike
and seeing as he mentioned perl
> To me perl is the triumph of utalitarianism.
So are cockroaches. So is `sendmail'.
-- jwz [http://groups.google.com/groups?selm=33F4D777.7B
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Great answer to that question: Neither, he wrote his own (twice!), and wrote papers about the products. That's a Unix power user, defined.
four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
Maybe because he's getting tired of this issue? Maybe he wants to focus on actual code instead of politics?
... dismissing the issue on such a weak pretense clearly amounts to taking sides on the issue, namely the side of the status quo, i.e. pro software patents.
And how, pray tell, is he going to do that when all but the most trivial code runs afoul of patents and is vulnerable to litigation? (According to many analysts, this is already the case.)
Refusing to answer the question and using disagreement with the analogy used by the questioner as cover is an exceedingly political answer (and a tried and true method of dodging uncomfortable questions used by virtually every political candidate for office in recent years, as alluded to the "is he running for office" comment)
Hardly a non-political stance, merely a disingenuous one.
The Future of Human Evolution: Autonomy
I don't know where Pike was before Bell Labs, or what he did between Bell Labs and Google. However, if you look closely, both Bell Labs and Google hold patents for competitive uses.
Perhaps Pike's background with non-academic (i.e. commercial) research centers causes him to think about patents in a different light than, say, Stallman's background in working at MIT in the '70s (an academic research center, among other things).
- but some how every time i think of unix i start thinking of Dos 3.2.
That's a dumbed down Disk OS of the 80's. You're thinking "Boy George" to Pike's "David Cassidy" and, yes, we really DO want to hurt you.-- @rjamestaylor on Ello
There's no congruity between IP issues and nuclear weapon stockpiling. Nuclear weapons are mass destruction devices. IP protection embues certain rights under various juridictions. There might be very important issues for the questioner in IP, but the question was worded poorly and was presumed to foster a baited answer. The context was poorly set, and the answer put the question in the nebulous context by which it was asked. Good answer.
---- Teach Peace. It's Cheaper Than War.
These days, developers seem to have their accommodation organised by blind chance, or worse, corporate whim.
Many of my colleagues left their 6-12 man offices to join a 70 desk open-plan floor. The six of us architects (yeah, right) were pretty miffed to be shunted into a 1980's room just for six with beige vinyl on the walls and phones straight out of Flash Gordon. Now, two months later, we appreciate the working community that is our office.
Good call Mr. Pike: humans function well in small self-organising or randomly-organised groups of up to 8. I'll rue the day we have to move out.
Perhaps Pike's background with non-academic (i.e. commercial) research centers causes him to think about patents in a different light than, say, Stallman's background in working at MIT in the '70s (an academic research center, among other things).
Well, since he dodged the question with a disingenuous slam of the questioner, using his disagreement with the questioner's analogy as cover to do so, we really don't know the answer to that. Based on his unwillingness to answer the question and defend his point of view (which one may surmise based on previous behavior and his dismissal of software patents as an issue worthy of addressing, is pro-software patent) we can guess that his perspective does differ from most in both the industry and academia (including Stallman), but with his refusal to answer the question we really don't know.
The Future of Human Evolution: Autonomy
Large companies are stockpiling software patents in exactly the same mutually-assured-destruction mindset anticipated in the cold war: If you sue me to death, I'll sue you to death. They even have the same peace treaties: I promise not to sue you with my patents if you promise the same. You could call them Patent Noproliferation Pacts.
The fact that that question was sent to the interviewee meant that Slashdot's readers wanted to know his opinion of the patent system. He could have answered it in any manner he chose, but he chose to sidestep it instead because his employer (Google) believes in using patents aggressively in a mutually-assured-destruction way, even if it means the end of Linux. That is why he didn't answer, and your faux-objective pseudointellectual babble isn't fooling anyone.
If guns kill people, then CmdrTaco's keyboard misspells words.
Pike:
Comparing patents to nuclear weapons is a bit extreme.
No it isn't. The comparison is drawn often, because both large patent portfolios as well as large nuclear arms stockpiles create a situaiton of Mutually Assured Destruction. Once the nukes start flying, nobody wins. Likewise, once the lawyers start slinging patent lawsuits, only the lawyers win.
So the answer may be, "I have no idea", but the comparison is legitimate.
I modded this question up in the question round because I wanted a real answer, damnit.
I sincerely believe that "one tool for one job" isn't dead, the landscape has simply changed.
Yesteryear, the only way software tools worked together was via stdin/out over the command line.
Nowadays, we have brought the concept into application space through component architectures and IDLs (COM/XPCOM/JavaBeans to name 3). These new tools allow for that clean separation. Plug-ins or components are free to concentrate on doing one thing very well.
The change, IMO, is a good one. Formalized interfaces are good, and components are better optimized than launching a whole separate process.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
You're speculating, too. Patent wars can be lucrative, and they can be disasterous. Is the system broken? I'd say so, but that wasn't the question. Read the question. Read the answer. It fit. What is he going to give as an answer? Something that we don't already know? Patents can be greatly abused, and they have value. Value is ok, and patents can be ok. but we'll agree that software patent abuse is rampant, and the term of patent life is also ridiculous. But read the question, and read the answer.
---- Teach Peace. It's Cheaper Than War.
Well, if he did, it was long before Unix appeared, and far from Bell Labs. Macros appeared in some of the earliest assemblers.
Looks like they can't take criticism either.
Parent AC here,
You remind me of a certain president of a certain union of states in a certain part of the American continent.
dismissing the issue on such a weak pretense clearly amounts to taking sides on the issue, namely the side of the status quo, i.e. pro software patents.
You're either with us, or against us right?
I guess listening to David Cassidy while I write this comment seems so appropiate!
Yes Francis, the world has gone crazy.
I would have loved to see his response to the same question without the analogy. He would have been forced to answer, or explicitly acknowledge his dodging, if the submitter had merely posed the question by itself.
Obviously, as an employee of a corporation with major intellectual property interests, he's not going to kill his career by speaking out against software patents. You gave him an easy out.
Hey! Perl still adheres to the "one tool for one job" metaphor.
It's just that Perl's "one job" seems to be defined as "replace all the other tools"...
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
More here
Pike has a few misused patents to his name, and his unwillingness to answer a perfectly valid question is a good indicator of his stance on the issue. As another poster suggested earlier, Pike really was caught between a rock and a hard place by the question: admit that he supports patents and face the wrath of the slashdot crowd or deny his past stands and expose the duplicity of his current employer. Either of the two answers might've opened some fanboy eyes around here. Too bad it didn't come to pass.
IP and it's rabid use today is a valid question. But when you mix hyperbole to the question, you are asking for a response like he gave.
You come across as a zealot who probably wouldn't care what Rob Pike has to say, YOUR mind is already made up. And yes... Rob probably doesn't feel the same way *we* may feel.
Yep. Ask anybody who ever used askSam for their desktop database needs back in the day. Lordy, I miss that software. When was that, anyway? Back in the late 1980s? The brain's a little foggy today...
Formalized interfaces are good, and components are better optimized than launching a whole separate process.
Not in all cases. It's often easier for a program to contain a misbehaving component if the component runs in a separate process. For instance, if a web browser plug-in segfaults, do you want it to destroy the data you've entered into a form on another page?
"I don't care nearly as much as I used to about the what the kernel does; it's so easy to emulate your way back to a familiar state."
DragonFlyBSD has a system call layer that would allow potentially very different interfaces to be presented to userspace stuff with essentially no penalty. This may allow newer ideas to be explored in a familiar environment.
I rarely criticize things I don't care about.
There's a difference between an "analogy" and "equating". The poster did not try to imply that nukes and patents were equally dangerous, only that entities stockpile each (countries stockpile nukes, companies stockpile patents) to use in a mutually destructive fashion against each other (countries by firing weapons, companies by suing).
The important part of the analogy is that companies stockpile patents now not because of their usefulness but as a deterence. Likewise, countries in the cold war stockpile nukes not because of their use in war, but as a deterent.
So how are you not an idiot for missing this?
(I submitted this particular question, and appreciate the mod point.)
I was looking at it from a slightly simpler and broader angle: the functionality of discrete widgets. There are so many products (software in particular; computing devices in general) that are designed to be a single answer to all of the customer's needs. This is extremely difficult to do correctly, and many efforts end up as one or more of the following:
too hefty/bulky/bloated
too expensive
too resource-hungry (be it RAM or battery power)
too fragile (where one misbehaving widget causes a ripple effect throughout the device/app/entity)
performing several functions but not doing any one task particularly well
Those days are dead and gone and the eulogy was delivered by Perl seems to mean that we only need one tool to do our jobs, and that tool is perl. I respectfully disagree with this: perl is very handy but it is not always The Right Tool for the Job(tm).
Rob - thank you for the answer.
I want to drag this out as long as possible. Bring me my protractor.
"Instead of one big file system, one user community, one secure setup uniting your network of machines, you had a hodgepodge of workarounds to Unix's fundamental design decision that each machine is self-sufficient."
I hate to say this, but doesn't Windows 2000/2003 server, Active Directory (and Novell NDS etc) do a lot of this. One set of users, a network of machines (without being reliant on one master machine*), and one security model. Maybe not quite there on 'one big file system', though can basically be achieved with a bit of setting up.
(* I haven't manafged a Windows domain for a few years, seem to remember 2k had a PDC-like machine as such, but also with backup servers - ready to take over).
You will forget this sig before you next see it
Get a grip. You read far more into the reply than is there. The question *is* extreme. IP stockpiles are more like stockpiling little golden eggs. Nuclear weapons are somethign completely different, and with much different possible results.
---- Teach Peace. It's Cheaper Than War.
I mean...unless you can see the future...
Blar.
There are a couple of important differences.
For one, it is completely obvious to any reader that Mr Pike didn't answer the question. He dismissed the question while making a valid statement. Hardly as bad as, say, Bill Shatner's /. interview, even. I can't think of a good example of a politician dodging a question based on disagreement with the posed analogy in recent history off the top of my head. But - consider Bush's recent response to the question posed to him in the third debate on the minimum wage. He rapidly turned the issue towards education, and essentially said "if you're earning minimum wage, it's because you're too stupid to earn more." A reasonable statement, but not one he'd likely vocalize in so many words. But how many viewers noticed that he a) dodged the question b) made a pretty controversial statement too? That's disingenuous.
For another, in general, most of the questions posed to a politician are fair game. They're bastards if they don't respond to questions about public policy or legislature or economics. Rob Pike is here to talk about software and code and unix and google. HINAL. Does he have anything interesting to say about patents that hasn't already been said hundreds of times by people far more qualified to speak about the subject? Quite possibly not. It's not his job. It's his right to tell the original poster to go Dick Cheney himself.
I'm not a smorgasbord.
It's got an 8.4 meter aperture and 10 square degree field, taking an image every 20 seconds with its 3 gigapixel (sic) camera - in this sentence, what does 3 gigapixel (sic) camera - this thing '(sic)' mean?
You can't handle the truth.
Besides your attitude, there's a *LOT* of congruity. Just because you can't (or don't want to) see it, doesn't mean it's not there.
Nuclear weapons are mass destruction devices. IP protection embues certain rights under various juridictions.
Patents are IP destruction devices. They guarantee that nobody will mess with you because you'll obliterate them in a court battle. A patent stockpile guarantees that nobody will sue you, because then everybody loses. The only response is to build up your own stockpile.
The only difference is that with patents, there are more than two major players.
... but then again so did the person who posed the question.
I understand the idea that anything user-facing should probably be as simple as possible. This means that ideas that require user-supplied metadata (as the typical XML-in-filesystem ideas require) are probably not going to be successful. I also agree that Joe User doesn't care whether or not his data is stored in a RDBMS or in a plain text file if his search tool does a good job.
The phrase "structure is meaningless; search is king" is a non-sequitur to someone aware of data management fundamentals. Structure gives meaning which in turn allows you to relate the data to others. The problem today is that we're creating data and storing it in'plain text' (or flat file, proprietary, etc.) physical formats instead of storing emails, word processing documents, etc. in a RDBMS.
The RDBMS is more than simply a search tool; that it has a sound model, provides for easier application development, etc. Wouldn't search be significantly easier to do if your data is given a consistent logical view? If you know the semantics of a particular piece of data, you no longer need to waste your time classifying it to search.
It seems that a proper solution would be that every PC contained a RDBMS, all data is stored in one, and that the internet would simply be a series of interconnected, distributed RDBMS (D-RDBMS). This idea would probably be fairly difficult to implement, but is already being performed at Google anyway (albeit in a slightly different format). Back when Codd developed the model he was primarily concerned with institutional databases -- centralized schema validation/data storage/etc. The problems implementing D-RDBMS products are not trivial, but then again are not insurmountable. The world has been able to standardize on protocols, etc. so I don't think it is out of the realm of possibility to suggest that different companies/users/applications could agree on a particular schema for, say, emails.
Thanks,
--
Matt
I asked in my +5 interesting post why modern OS's are written in the lowest-level practical modern language (C) instead of the highest-level ones? I noted that at the time C was one of the highest-level languages and that was behind UNIX's success.
Instead he wastes his space completely dodging a decent question on patents, and takes some softball OS question so he can spout off about how his baby Plan 9 is maginally better (you can pass any number of parameters on the command line). Wtf?
Also his analogy about OO being like a wood craftsman is so opposite of reality. The fact is that modern chairs are not crafted but made out of components. Modern anything is made out of interchangeable parts (aka components, objects). There's nothing about C or alef, perl, scripting, etc that is based on components or plugging existing parts together. You can create a beautiful chair in an OO language, but nobody really cares since in an object-oriented language you sit, push in, stand on, whatever the chair. I mean come on, the guy creates his own editor in Alef (aka C) and he's talking as if that's not the craftsman side? wtf is he smoking? Serious.
P.S. don't give me any of that BS that OSs in LISP existed; lisp is the functional-language equivalent of assembly language.
It's simply a fact that the current patent race is quite similar to an arms race, and that if everyone started enforcing their patents we'd have a "software nuclear winter", in the sense that no-one could still write a program without infringing any patent.
It's not a hyperbole, because it's not meant to show that software patents are supposedly just as bad as Hiroshima or Nagasaki, but simply an analogy because of the way they are used.
Donate free food here
Just to clarify, even tho most 2nd generation bios of Rob Pike claim he is an olympic medalist. That was just a joke on his part ... i guess.
It does seem like he enjoys the noteriety because he does nothing to correct those bios, or his own.
Judging by his answer to software patents, it does seem that he picks and chooses when to be funny, flippant, verbose or truthful.
For those of you looking to try out some of the editors Rob mentioned (namely Sam and ACME) - the most recent port of those applications to Linux/BSD/OSX is maintained at the plan 9 port page by Russ Cox - although it would be wise to read the papers before trying the executables.
There's also a recently reactivated project to bring Plan 9 filesystems and namespace concepts to Linux which is maintained over on Sourceforge.
No, it's more like listening only to music composed before Schoenberg. Those of us with taste recognise that that most of the stuff produced since that is either pretentious cacophony or ignorant, synical, commercial bilge.
Thus WinXP is to Unix what Britney Spears is to Beethoven. Plan9 would be some anachronistic romanticism like Pfizner or Elgar.
He answered the question by pointing out that it's nonsensical, as posed. He could have answered any number of other questions that weren't asked. A better question is why the moderator picked that poorly constructed question, rather than any of the answerable ones that weren't asked.
--
make install -not war
Maybe he considers Arms control an issue more significant by many orders of magnitude than patents. I reasonable person might think that even discussing nuclear weapons and IP in the same sentence trivializes the significance that the arms race played in our lives for decades.
Are software patents important? Yes. Do they threaten the very survival of our species? No.
-------------------------
A person of moderate zeal
After all this talk about Doug McIlroy, when will /. interview him?
Windows is still built around the idea that each machine is self-sufficient. And, well, it has to be. You can build a distributed system on top of that, but if it's going to be widely adopted you need to be able to do it all in one machine: that is, Plan 9's problem is that it required a network. I once asked Dennis Ritchie if there was any real point to running one Plan 9 computer, and his response dissuaded me from trying it.
No, what you need is a standalone system that you can build up into a distributed system. The UNIX kernel isn't the ideal place to start (ideally, something that would let you move components across a machine or network boundary... a message-passing microkernel, perhaps... would be better), but it will do. The distributed authentication in Windows 2000 is now built on the distributed authentication from the Project Athena at MIT... which was developed on UNIX and VMS. Distributed file systems? There's a plethora of them. Distributed applications? The Plan 9 model works well on a UNIX system call style of interface...
Novell NDS pioneered the functional and useful PC implementation of this idea with NDS, which was created by hacking the bejabbers out of a genealogical database created by the Mormons (AKA the Church of Jesus Christ of Latter Day Saints).
NDS inherited limitations from the Mormon theology (for example: the concept of multiple roots is anathema in a genealogical database designed to relate all the descendants of Adam. Thus NDS could not handle multiple roots and separate trees had to be merged in order to inhabit the same database).
The pioneering theoretical work was the X500 project, but the programmers on that project were such an arrogant bunch of egotists that they pissed off nearly everyone they came into contact with (for example, with their annoying insistence that only X500 could be called "the Directory" (capital D) and that all the world's existing documentation must be revised to remove references to directories (small d) where the word "folder" could be used instead.
Although the X500 project did produce a software implementation, nearly everyone hated it (although mostly because so many people had been thoroughly antagonized by the attitudes of the X500 gurus) and thought it was too bloated. LDAP was born, in reaction to this situation, as a means of communicating directory information from any arbitrary database - it let you do the important parts of X500 without having to run their code.
Active Directory, Microsoft's entry, is a poor stepchild of NDS that uses LDAP (with purposely arcane schema) and incorporates MIT's Kerberos (a good thing) and embodies Microsoft's policy of "embrace and extend" (a bad thing). It is in many ways an inefficient and poorly structured system, but it functions reasonably well in an all-MS environment.
So, yes, you can do this rather nicely and efficiently under Novell (in which case you have to fight the battle of Microsoft compatibility since Novell is permanently locked in a death struggle with MS's server group) or very sloppily and inefficiently under Microsoft (see Andrew Tridgell's many commentaries on the shortcomings of the CIFS and SMB pseudo-standards).
You can use OpenLDAP and Samba to get pretty much what you are talking about without using either MS or Novell in the server room. MS still rules the desktop, though, because they have the lusr mindshare (it's cheaper to hire people who already know MS than train people to use something else).
In reality, both major browsers (IE, Moz) use component architectures, not separate processes
Then in my opinion both ActiveX and NP are flawed. But in fact, the Adobe Reader plug-in for Mozilla actually calls up a separate process called acrord32.exe to do most of the work.
Testing your product thoroughly and having clean interfaces is a much better way to guarantee stability than simply containing segfaults.
True, but even in a well-tested (but not formally proven) program, the "crumple zones" of multiple processes will often offer better reliability against data loss in the event of a crash that hits an obscure corner case. In addition, web browser plug-ins aren't "your product"; they're someone else's product run in your product's memory space.
Perl hardly refutes it, when in the previous question he gave a laundry list of tools and Perl wasn't on it... and Awk was.
I really think he was evading the answer.
The real answer is that you need a framwork that lets you connect the tools together easily before you can use a software tools approach. For the command line era, that framework was the UNIX shell. For the GUI era, there really hasn't been a popular framwork that's also portable. AREXX, Plan 9, Applescript, these seem to be the best frameworks I've seen so far, and they're all isolated to ghettoes... we're still waiting for the GUI equivalent of the UNIX shell.
+1 Funny doesn't earn the recipient any karma.
--
Humorous coward.
I don't think anyone who managed to get themselves properly registered to vote (that means passing a driver's license test in most states) had trouble noticing that he a) dodged the question and b) made a pretty controversial statement too.
But, by realizing that his answer was something similar to "if you're earning minimum wage, it's because you're too stupid to earn more." you realize that he *did* answer the question... well, tecnically not, he skipped over it, but gave his supporting reasons.
The part he didn't enunciate, was the "No, and here's why..." Instead he just skipped ahead to the "But here is my alternative solution." And, as politicians are wont, tried to gloss over the controversial part couched in terms that would not sound controversial to those who were ignorant or inattentive or malicious.
Everyone who follows politics even a little bit already knows his, and his party's position on the minimum wage.
Ok, I'll go along with it, with a minor correction.
IP protection embues certain rights under various juridictions.
IP protection is about taking rights from the people/society/the public. IP law has at its foundation the concept of communal ownership over ideas. So when you invent something, the Law of Nature is that everybody owns the invention. In order to encourage invention, the Law of Nature is briefly discarded by something called a "patent".
I don't totally disagree with your post, I just take issue with the now-popular assumption that IP Law is all about protecting individual rights, and it's never been about that.
Like what I said? You might like my music
Sure they do. I still don't have a problem with Pike not answering the question. Someone else said it correctly, HINAL.
That said: take the case of a drug company with a patent on a particular medication for say AIDS (just to choose a disease).
Now say this drug in question cost a whole lot to create and the company wants to recoup their costs. They charge an arm and a leg for the drugs. meanwhile some poor country has a major crisis on their hands with people dying by the thousands. The company won't give up the patent on the drug, and refuses to sell it for a reasonable price to this country. Hundreds of thousands of ppl die because of corporate greed. Now imagine AIDS mutates in this country and become an airborne virus... ok, we're extinct. A patent is to blame.
May no camel spit in your yogurt soup.
But how many viewers noticed that he a) dodged the question b) made a pretty controversial statement too? That's disingenuous.
No, it's friggin brilliant. Machiavellian, almost.
I can't believe bush did it on purpose, for that very reason.
"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 of Slashdot"
-- Rob Pike
"Using Unix is the computing equivalent of listening only to music by David Cassidy."
-- Rob Pike
AIDS doesn't need a medial cure. It really doesn't. AIDS is a problem because people are ignorant. If countries would make a significant effort to involve their population and educate their kids AIDS would become irrelevant in a generation.
'Using Unix is the computing equivalent of listening only to music by David Cassidy.'
:)
:)
- Rob Pike
Page Setup... Landscape[x]
Print...
ROFFEL!
Thanks for the cubicle ornamentation
You are in good company, sitting next to Dijkstra, Deutsch, and James Madison.
It's 10 PM. Do you know if you're un-American?
What tool does this?
Guffaw.
Maybe you mean the sort of "Mozart" that comes out of your old brick of a Nokia cell phone?
blah shmah blah shmah shmah shmah blah
I'd say MS Windows is like...umm...Britney Spears!
Or maybe....Jessica Simpson!
Pretty looking but lacking in intelligence. Needs outside help with mentally complex tasks.
Wll, maybe Christina is more appropriate than Jessica. Jessica isn't trashy and promiscuous enough to have the same tendency to pick up viruses as Windows.
Calling UNIX "David Cassidy" doesn't seem right. I'm more inclined to think of it as the Rolling Stones. Still cool, sitll popular and nearly as old as Jesus.
BSD...of course... would be The Grateful Dead.
Quote:
OO is great for problems where an interface applies naturally to a wide range of types, not so good for managing polymorphism (the machinations to get collections into OO languages are astounding to watch and can be hellish to work with), and remarkably ill-suited for network computing.
---
Perl solves half of this problem (collections are relatively easy to throw together) - Unfortunately the other half (making it Network Computing Friendly) is still a royal pain in the posterior.
While I'm not a huge fan of OOP, perhaps future research will conquer this gap and make it somewhat more paletable.
/~mikeg
The process is that usually an individual gets the patent, and the patent is assigned to another entity, usually a corporation, but not necessarily so. You cannot patent ideas. You can patent processes, but not ideas. Ideas are the cheapest currency known; everyone has one and therefore ideas, while great, are valueless in and of themselves. What makes an idea worth something is the energy that propels the idea. Patents, on the other hand, are substantive in some way. How much substance is the crux of quarrelsome combat, and the contents of balloons. In the end, humans only own things for a while, because humans die. By contrast, trusts, corporations, and other artificial bodies live on, physically. Conceptually, we need FOSS for other non-software inventions, and those interested in keeping ideas 'free' need to publish prior art as frequently as possible to prevent the inaccurate manipulation of IP claims on *processes*
---- Teach Peace. It's Cheaper Than War.
Refusing to answer the question and using disagreement with the analogy used by the questioner as cover is an exceedingly political answer
What do we, and you, know?
Why are you so nasty? Probably that guy never had the idea to think about the topic? Probably the comparison the original asker made just pissed hi, he lived in the cold war, you not.
That was not a court trial, it was an interview. You can not DEMAND an answer from a guy who likely ahs no answer.
angel'o'sphere
P.S. he has invented quite a lot, probably you should start inventing something before squating IP/patent law
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
..."mu".
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
It's called Wily, and damn if it ain't the weirdest editor I have ever used. Insane fun, too, and fits the Unix model of putting together arbitrary pieces to build tools as needed.
There are no button or menus per se. There's an initial group of one-line-high windows with some words in them ("Save", "New", etc) and a major window (now we'd call them "tabs" but in Wily they're just windows) for the file... or for more commands... or whatever. You can have a tab hooked to a shell, for example.
Middle-clicking on a word, or on selected text, runs that command. Maybe it's builtin. Maybe it's a complicated shell pipeline. Any text, anywhere; the command words in the initial small windows are just plain text. If you don't like them, backspace over them and write your own. Nothing special about which window you're clicking in; for example, if the words "Save" and "Quit" (capitalized) happen to appear in the body text of your program or paper or whatever, middle click on them to save and exit.
Clipboard operations and a number of other things are all done with mouse chords. Left-click and right-sweep performs such-and-such, etc.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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 and applies it to mail: don't bother organizing your mail messages; just put them away for searching later. It's quite liberating if you can let go your old file-and-folder-oriented mentality. Expect more liberation as searching replaces structure as the way to handle data.
... computer: "4 songs have mached your rhythm and tone."). There is also something to be said for being able to organize things the way you want them organized. I would kill to be able to have sub-folders in Gmail, if not solely to interface it easier with existing mail systems.
Yeah, that's what we need: to spend more time looking for our data than we already do. We need to have systems in place that know exactly where our data should be. This can be done in a way so we don't need to pre-sort it ourselves. For example, a meta-filesystem could be made wherein as soon as you create a file the filesystem determines what kind of file it is and sorts it for you. The filesystem indexer would queue the file to be looked through later and indexed for keywords and hints for further sorting and to ease querys in the future (person: "computer, i don't know the name of the file, but it's a song that goes dum-dum-dittyditty"
While you drive a good point, the parent was referring to the hypothetical situation where AIDS becomes airborne. This does in fact supply the 'extinction' element required by another parent poster in the 'software patents could cause the extinction of humanity.' Would AIDS go away in a generation if both a) proper education and parent-children involvement and b) AIDS becomes an airborne virus in North America? I can hardly imagine.
GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
And then there's Kerry, who surveyed the crowd at the town-hall-style second debate, and pronounced himself, Bush, and the moderator as obviously the only ones in the room who could possibly be making more than $200K/year.
Mmm... limousine liberalism. Grey poupon, anyone?
What I am proposing is not exactly 180* from what you and the other poster have suggested; a search tool would be doing something like what a RDBMS would be doing but would be defining the schema on the fly, without the data creator's input, and with limited information. So, the RDBMS would have a clear advantage because the metadata is already defined up front - you merely have to query it.
I actually pretty much agree with everything else you said - an easy way in an app to add metadata, and approvial from the user for automatic metadata additions.
I think the only way I differ is that I don't think you can ever define a complete schema, so using an RDBMS is kind of s waste of effort. I think the search tool would as you say be defining the schema on the fly but since you could never have a complete schema in an RDBMS it would just weigh you down.
So my nonly problem is with the use of the RDBMS anywhere in the process, which I see as limiting.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
When you ignore IP rights you can:
A) Get some cool software for free.
B) Get some cool music for free.
C) Plagiarize a paper and finish your essay quickly while appearing smart, as long as you don't get caught.
D) Pick up some nifty code, making your project much easier to complete.
etc., etc., etc.
When you ignore nuclear weapons you can:
A) Be the victim of genocidal acts of violence in the span of minutes or seconds, dying in radioactive fire with the vast majority of your countrymen.
The comparison would seem to speak for itself. At the very least IP rights could be said to offer you more options.
This might explain why Mr. Pike found the comparison a bit extreme.
Of blankness, I know nothing.
So the clock of your microwave oven can only count for 16 seconds?
The difference is that on a 4-bit through 16-bit CPU, the developers know not to try to treat a whole date+time as a single machine word; instead, a microwave oven represents cook time as a vector of four 4-bit BCD elements. The temptation to assume implicitly that time_t equals int32_t starts at 32-bit. It'll take another round of programmer reeducation to make the transition to a typedef long long int time_t; go as smoothly as businesses pulled off the so-called "Y2K" transition from two-digit to four-digit BCD years.
-Don
Take a look and feel free: http://www.PieMenu.com
I always thought that "ioctl" was conclusive proof that Unix's approach to files was fucked. To base the whole operating system around files is far too specialized and narrowly focused.
Instead of files, now the latest fads are XML/RPC/SOAP's "everything is a procedure call" philosophy which is battling it out with REST's "everything is a representational state" philosophy. When is somebody going to write an operating system that performs system calls and talks to device drivers by fetching URLs?
Oh yeah, that's called the Internet. "/dev/coffeemachine" is now "http://www.coffeemachine.com".
-Don
Take a look and feel free: http://www.PieMenu.com
You would think he was in politics, the way he dodged that question. He should have had the guts to say something. A well worded defense on software patents might change someone's mind. I know I'd personally be open to changing my mind, if someone would just tell me why.
Someday I might play devil's advocate and come up with a defense. I'm not as well respected, nor as good a writer as he is though, so I'd rather he did it. Instead he played politics, ignoring a question that might inflame people against him.
God rest his soul!
he was using aids as an example, you perverted cunt.
it's fucking annoying
All of his replies come over as condescending, supercilious, patronising, inflammatory, snobbish and disrespectful.
It's quite clear what he thinks of slashdot readers.
He's gone way down in my estimation, guru or not.
I respectfully disagree with your conclusion, even while accepting your premise. The company needs to recoup its investment (thats how it continues to do research). The patent allows it to make money to pay for research. With out the patent the drug would simply not exist. So the only thing the patent is to blame for is the existence of the drug. If the company makes a choice to not discount it for poor patients/countries, that is a completely different question (and a morally indefensible one, in my opinion).
My preferred solution, the company is able to distribute the drug cheaply where needed because it can charge a higher price for those better able to pay. But this would only be possible if the company has a patent on the drug.
-------------------------
A person of moderate zeal
May no camel spit in your yogurt soup.
>And it goes against the grain of building small tools.
Innocent, Your Honor. Perl users build small tools all day long.
--Larry Wall in <1992Aug26.184221.29627@netlabs.com>
With out the patent the drug would simply not exist.
Stop right there.
That is not an assertion you can make to support your argument without proving it.
In fact, it is almost certainly false.
Innovation does not disappear if (enforceable, useful-to-innovators) patents don't exist. Check history.
AIDS drugs and other drugs where there is a strong demand are still very likely to be money makers regardless of the patent system. And the new malaria vaccine, I understand that was funded using money from a private individual (ugh, bleah, it is the least he can do, but I wonder what rights he may maintain on it??).
What was I saying??
well, no, drugs like that aren't big money makers if patent protection doesn't prevent competitors from making the drug and selling them cheaply. The entire reason patents exist is so that someone can do some research, or invent something, and have a period of time in which they have a monopoly on that product. During that time they can charge a higher price and recoup their investment and have some incentive to due the original research.
In the absence of a patent, that period when the company can make an extra profit doesn't exist, so any company that spent the millions of dollars to research the drug would quickly go out of business.
To your point, you are right innovation doesn't disappear in the absence of patents. But certainly innovation that requires ENORMOUS financial investment would dissappear. You make one assertion that is simply wrong: that even with out a patent an aides drug would still be a money maker. Well, yes, it would be money maker, but not for the company that did the research. Instead it would be a money maker for the companies that produce the generic copies of it.
-------------------------
A person of moderate zeal
If anyone codes in a half dozen languages, and picks the right tool for the job then -- they're probably not working for the average company. I love to pick the right tool for the job as well, but IT departments have a tough enough time keeping their staff trained on one technology or development methodology; never mind two or three.
re: Programming paradigms... it's fairly easy to laud procedural development until you see what people have done with PL/SQL. And, conversely, you can say OO is great until you look back to the days when inheritance won out over composition. But hey, how much can you really evolve procedural coding? At least OO is still evolving... especially with AOP on the horizon to address some of its biggest weaknesses.