Slashdot Mirror
Ask Unix Co-Creator Rob Pike
Today we return to our Slashdot interview roots with a "Call for questions" for Rob "Commander" Pike, who has been involved in the development of many modern programming concepts, GUI advances, character sets, and operating systems. We'll email 10 - 12 of the highest-moderated questions to Rob and post his answers as soon as he gets them back to us.
Gotta ask the question :-)
Pardon my ignorance, but I was under the impression that Dennis Ritchie and Ken Thompson created Unix (Unics), on disused hardware at Bell Labs.
Am I incorrect in this belief? Someone, kindly, clarify the matter.
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?
UNIX? They're not even circumcised! Savages!
This must be the most awkward question you can give a programmer.
Can you justify why you named your objects/variables/files years ago?
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
Unless I'm very much mistaken, Mr. Pike, you aren't a Unix co-creator. Dennis Ritchie and Ken Thompson are the co-creators of Unix. If my very quick Google research serves, you joined Bell Labs in 1980 and worked a lot on Plan 9 and the first Bitmap window system for Unix.
So why is Roblimo wrong?
What do you think of the work Hans Reiser is doing with file systems? How does it differ from and/or improve upon Plan 9? What do you think of his theory that (nearly) all database functions should be done by the file system? What do you think about being able to treat files as directories in order to get to special (or not special) info? Is it useful to be able to treat a tarball as a file when you want to and as a directory when you want to? How about file metadata? Data forks? Do you think Linux, Windows, or Mac OS X will come up with the better database/search-enhanced file system?
Software sucks. Open Source sucks less.
What will drive the next crop of OS'? Is it in hardware innovations, new programming languages?
it's not going to stop until you wise up, no it's not going to stop. so just give up.
Ah, so maybe you should email Roblimo and tell him this since the whole story is:
"Ask Unix Co-Creator Rob Pike"
Set Roblimo straight then...instead of just spouting off in the forums where no one but me will see it.
"Leo Fender was in a 'state of grace' when he designed the Stratocaster." -- Paul Reed Smith
The early unix filename limit was 14 chars. That gave you two bytes for the inode number in a 16-byte directory entry.
Early C also had the 6 letter limit, not so much in the language itself as a limitation in early linkers/loaders, which only distinguished the first few characters of an identifier. (So for sanity's sake you limited the identifiers in your program to that so you would accidentally get a collision. This is one reason that old C code looks, well, old. (And why some old C coders still tend toward using short variable names.)
-- Alastair
Well, for one thing, "creat" should have had an "e" on the end ;-)
"Freedom means freedom for everybody" -- Dick Cheney
Do you feel that with the current usage in "traditional" operating systems such as Linux and Windows that there is no place, or need, for a Distributed Operating System in the industry?
UNMNT? Seems a little clearer. Especially as u- is vague, meaning both "un-" and "user-" (umount/umask v. ulimit)
Boys from the City. Not yet caught by the Whirlwind of Progress. Feed soda pop to the thirsty pigs.
The command line was the ONLY interface when unix was first developed. X came long after the CLI and even if you're running Windows you still use the command line from time to time. If you don't you're just not using the power of your system, in my opinion.
raw text is the only true inter-system communication protocol. my cats and my computer understand a lot of the same words. my cat can't type but i can, and my computer can't understand the noises my cat makes, but i do - command pipes! where would we be without those, and those ONLY work in the CLI! we would be in the stone ages of computing without the CLI.
Rob Pike wasn't a "co-creator" of Unix. He came to the Labs in the early '80s, more than a decade after Unix was created. He's very important and influential, but not for that...
How much do you think UNIX's success has been shaped by the relatively light restrictions placed on its use, distribution and modification?
The original UNIX, BSD, and now Linux seem to have been 'freeer' than other OSes of the time, do you think they would have been successful without this?
Finally... vi or Emacs? ; )
I have to agree that this question does not make sense. It indicates a total lack of understanding of what OO means. I would argue that much of Unix actually is object-oriented. Think, for example, about the concept in Unix of presenting many types of IO devices as files. This achieves encapsulation, polymorphism, and a very high degree of abstraction by hiding implementation details, and presenting a very clean, intuitive inteface to programmers. There are many different types (you might say "classes") of files - pipes, sockets, regular, etc. - all of which can be passed into read and write calls. I'm sure I and others could go on all day about the OO aspects of Unix.
This is very similar to the another post about OO. Clearly you don't understand OO. There's nothing stopping a C programmer from using OOAD. Language is only incidental. Now I understand that OO languages make OOAD easier, but there's nothing stopping you from using those languages on any platform. If you like Java, well you can develop Java ON UNIX. What exactly is your point about C? C is closer to the metal than most OO languages, which is why OS developers write in C, and many libraries are presented directly to C. But you don't understand the way languages work if you're asking the question, "why C?". Ultimately everything comes down to machine-level instructions, so language is almost completely irrelevant to the OS. Perhaps you mean to ask, "Does the rise of virtual execution environments like Java's or .NET's diminish the importance of the OS?"
Given that Rob Pike works for Google, I wouldn't be surprised if he wrote that question himself...
Download my free songs!
True. CLI is the equivalent of spoken or written language, and the GUI is the equivalent of pointing at something and grunting.
Spoken/written communication is much more powerful (easier, faster, more effective) when both parties understand the language, and the idea is a complex one ("I would like a job at your pie shop.")
Rudimentary communication is easier with point-and-grunt (answering the question "which pie would you like to purchase?" - you point to the one you want)
If the parties don't understand the same language, complex concepts are *much* harder. Learning to communicate by pointing is easier, but the true power of communication comes from spoken/written languages.
Think I'm wrong? Write a detailed response *without* using your keyboard.
1) File systems that are "in use" cannot be unmounted because there may be uncommitted writes to them. When an application writes to a filesystem, the data is not immediately written to the disk for performance reasons.
I don't care. I'm unmounting a filesystem for a reason, and I'm going to kill the offending processes anyway. I'm root dammit! Heh.
Also, its just inconsistant that I cannot unmount a filesystem, but I can do rm -rf on the entire filesystem. Another thing that gets me is that a filesystem can be "in use" just because an app is using it as its current working directory. No open files, no uncommited writes, just because some program is sitting there it can't be unmounted, but again I can rm -rf it. (Yes, I do know that rm -rf only removes the linkcount by one, and the files might actually really still be there and not there at the same time.)
2) The 'D' state does not exist because there is a "problem" with the file system. Processes are but into the D state because two processes are trying to access the same file or resource at the same time.
Thats not true. A 'D' state is when an app is waiting for a disk or tape, it has nothing to do with filesystems, its a device issue. Regardless, I should be able to kill the process vs having to reboot to get rid of it. There should be no software reason for rebooting a computer besides a fundamental OS change.
Yep, good question. When you think about it, conceving an OS, and the language which will build it at the same time must be something totally mind blowing.
Given the power computers have today, the omniprecense of networks, OO and so on, i'm pretty sure that if one conceived an OS that way today and tried to rethink everything from the beginning, he could end up with concepts we don't even dream of.After all we all still think inside concepts which were found 40 years ago, even in network terms.
Things like plan9 are cool, but there is probably *much* more to be done, and the same thing can be done on the windows side.
Who cares--memory and hdd space are cheap.
Do you consider all trademark law to be legal nitpicking?
Correction, when UNIX "came out," it was written in the lowest level language of any operating system. Everything else was either written in straight assembly or a sane language, like Lisp or PL/I. Furthermore, Lisp had all those lovely features in 1975.
It's also worth noting that many the problems we have today are based in the concept of the "operating environment" -- today's software and hardware design paradigms are rooted in C. Implementing any language other than Algol-derivatives on top of C certainly fits into the category of "disgusting machinations."
In short, as people have recognized for twenty years or more, UNIX succeeded because it was the lowest common denominator, not because it was any good.
Recently on the Google Labs Aptitude Test there was a question: "What's broken with Unix? How would you fix it?"
The moment I saw that question I said it must be a trick. UNIX develops by evolution, not by dictation. Whenever an individual change is dictated it almost never survives on its merits.
UNIX is beyond the comprehension of any one. One can introduce a change, but it is up to NATURAL LAW to ultimately decide if the change lives or dies.
That said, pttys, fifos and ioctls do in fact blow.