Rob Pike Responds 284
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.
===============
Disappointed in Pike's flip answer to patent Q (Score:5, Interesting)
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
Re:Emacs or vi (Score:5, Interesting)
(I'm reading the ACME paper now. Looks interesting.)
Jules, who writes his own editors too.
Re:If You Want a Serious Answer... Don't Get Cute (Score:2, Interesting)
In terms of comparing it to a nuclear arms race, I think the analogy hit the nail on the head.
Now, just acquiring patents to put the clamps down on innovation is what the original poster was probably referring to and that doesn't really apply to nuclear arms races. Maybe its more like being a rancher [from the movies] that owns thousands of acres of land and tries to squash other smaller cattle ranches out of business just so he can maintain his power. New ranchers can't find a piece of land to use to feed their cattle, so they go out of business.
#8 One tool for one job? (Score:5, Interesting)
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.
Re:If You Want a Serious Answer... Don't Get Cute (Score:5, Interesting)
The fact of the matter is that software patents are not going to go away, something that I touched upon in the original question. Aside from that, thier main use, so far at least, seems to be either for dying companies too leech some more existance from a more successful one, or too browbeat a smaller competitor into competition through the threat of legal costs they cannot sustain. Whether you think that is equivalent to the intent of a patent; essentially granting the inventor a reward for their efforts, no matter how stupid or obvious that invention might seem, is another matter.
Patents in general, and software patents in particular, are undeniably a big issue in the IT world at the moment. That Rob Pike dismissed the entire question out of hand leaves me with two more possible conclusions to yours: He's pro-IP patents, but is afraid to admit to it on Slashdot, although to be fair he'd *would* get savaged in the comments. Alternatively, he is anti-IP patents, but is afraid to admit it where his employers might see - which would say a lot about his employers if that is the case.
Re:The Unix Room (Score:1, Interesting)
discussing/talking/sharing/peer reviewing, everybody could
go to their own office and implement the damn thing they were
working on. Comunal space is good but it should not be the only
space provided.
We do know (Score:5, Interesting)
More here [mit.edu]
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.
Re:Doug McIlroy invented macros??? (Score:3, Interesting)
I was hoping for a bit more detail, too (Score:4, Interesting)
(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.
Re:Damn. (Score:3, Interesting)
Plan 9, Unix may not have it, but another OS does (Score:3, Interesting)
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).
Question for next time (Score:3, Interesting)
He got #5 wrong... (Score:5, Interesting)
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.
Re:Containment (Score:3, Interesting)
Also, a formalized interface means two things that help stabalize components:
Testing your product thoroughly and having clean interfaces is a much better way to guarantee stability than simply containing segfaults.
Damn, missed my Olympics question. (Score:1, Interesting)
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.
Musical analogies (Score:5, Interesting)
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.
Re:Musical analogies (Score:3, Interesting)
Steady on, old man, steady on. You're getting awfully carried away...
---
I like to use lines like that. "There hasn't been any good music since Joplin died... no, I mean Scott Joplin..."
Windows XP is like the Monkees. It's not just commercial pap, it's old commercial pap.
Plan 9? Plan 9 is Jazz.
Re:Plan 9, Unix may not have it, but another OS do (Score:3, Interesting)
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...
He didn't say why... (Score:4, Interesting)
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.
Re:He got #5 wrong... (Score:3, Interesting)
PageRank is an algorithm of popularity and not an algorithm of relevancy and as such, it really bears little relevance to implementation of relevancy algorithms as we are discussing. Of course, relevancy algorithms could contain page rank as a heuristic. See http://www.google.com/technology/
Google, in essence, is creating a schema for every page that it indexes. This schema is, in virtually every case, incomplete (because Google's algorithms are not perfect). In order for you to create a document (in the New World Order there really is no such thing as a web page any more) about Atlantic Slave Trade, you would have to have some sort of schema that defines it (by definition, it would require one). Of course, there would probably be schemas for historical documents, product literature, etc. which share a common foundation and attributes (kind of like inheritance in OO). This is not an impossible task; HTML was standardized, we have standards for everything nowadays.
This idea ("All the world's an RDBMS") merely formalizes this process. Note that this hinges upon whatever document creation software you use to perform this process for you; the nice part is this is not a fundamentally unsolvable problem (Codd did a lot of the hard theoretical work already; all someone now needs to do is implement it). The XML guys are trying to do it with the semantic web; unfortunately they chose a poor implementation technology (XML).
Your metadata is lost because current algorithms are imperfect. Let's consider your trip to Versailles. You probably want to share that information to the world, as people are wont to do. Currently, you probably type something in like:
Here are pics from my trip: X Y Z
How does Google know that "my trip" refers to the trip that you took from 01-OCT-1995 to 20-OCT-1995 with three friends? What about the content of the pictures?
Could you ask Google "Where was I on 12-OCT-1995?" What about "Who was I with?" or "Where was this picture taken? What is this picture of?".
You could make "your trip" link to another HTML page which has some information about your trip, but then Google has no capability to make those connections (unless you explicitly have matchable text in the document). If your query was against a defined schema, then those attributes would be available for the engine to utilize. Of course, we're not talking about a magic AI engine that does this; the schema drives and defines the query.
Finally, there is no requirement for a 'formal language' - when you do a Google search do you have to specify a formal language? That is a matter of implementation (as is look/feel: when you view a particular web page, you are unaware as to the source of the data - it could be generated by a DBMS or is simply a static text file.)
Re:He got #5 wrong... (Score:2, Interesting)
Application programs are easier to write
No need to write custom file format
RDBMS embeds business logic and simplifies code generation (WHAT, not HOW)
Perfect extension of "Information Wants [sic] to be Free" - more accurately "Your Information is Free"
Any application can read data created by any other application (security controls permitting)
Source code can be stored in RDBMS
No longer have 'tabs vs. spaces' arguments
Can convert from one language to another easily (just a different view of same data)
Data and programs no longer are confined to 'web' or 'local'
It will be impossible to tell whether or not a particular piece of data lives on your own PC, or on a central server (or cluster)
(Depends on universal connectivity)
there are more, but that was a quick bullet-list
Re:He got #5 wrong... (Score:4, Interesting)
Simply because most of the world is ignorant does not make it a particularly welcome idea to willingly embrace their ignorance. Hence, I try and use correct terms whenever possible (RDBMS vs. SQL DBMS, Cracker vs. Hacker, the Terrorist Attacks of September 11, 2001 vs. 9/11) etc. But, that is neither here nor there.
I'll address your points briefly before I get to the root of my initial desire for posting.
"Technically superior solutions may have aesthetic superiority"
That seems like a contradiction. Something that is "technically" (I am assuming you mean 'of a technical nature' and not 'abstractly') superior is certainly more than aesthetically superior!!
RDBMS certainly have considerably more functionality than SQL DBMS products. This is clear once you read the original theories and the foundations behind them. Your sentence illustrates the myth that, in the IT industry, technically superior products will rise to the top. Your mention of "worse is better" (I really, really hate that title, it should really be "Worse is Sometimes More Marketable" or the like) reinforces this point exactly.
"The query, my name Versailles pictures is probably good enough"
It is good enough only in the micro. There is a statistic which mentions the geometric (maybe even exponential) rate at which we are creating and storing new data. Sure, for your current family album this level of granularity may suffice - but I suspect in the future our family albums will be composed of video, audio, stills, etc. at a magnitude that makes getting 10,000 results impossible to sort through by hand. You'll require more accurate search results and will want to ask more precise questions. The RDBMS is the way to get this; read my other posts on this thread to see some suggestions re: metadata; in short, the solution for tagging metadata is obviously not a 'solved problem' yet - this is mostly because no one has seriously tried to study it; also having a complete RDBMS there would aid immensely with relating and tagging your information. Properly implemented (whatever that may be) I would think that there would be little typing required.
The reason why I decided to post my initial reply was that this was a questionnaire by a guy at Google. If there is one company that could/would implement a D-RDBMS it would be Google.
It's obvious that Microsoft, Oracle, et al would not lead the way in this sort of innovation. Their products, marketing strategy, and internal politics would not allow for a TRDBMS to be at the core of any Microsoft operating system and Office Suite they ship, nor would Oracle want to adapt to something which required a shift from SQL or allow for easy migration to a competing product.
That brings us back to Google. Google is just the right kind of company to pull it off: it's got the technical expertise, name recognition and reputation, and the willingness to truly revolutionize the way we work with computers.
Ideally, Google would start using a form of RDBMS for all the search indexes it creates for their desktop search tool (I don't know what kind of DB it uses now). It would take a given document, rip it into their RDBMS, and then allow for searching. Since Google has virtually written the textbook on large scale data distribution they could load your local DB into their pool, so now whenever you log into Google.com you can search (and with enough bandwidth, retrieve) your information anywhere, any time (this would be perfect for companies trying to manage data for projects, etc.).
But, since it was in a RDBMS, other applications could be written to extend the idea. I could extend my product with the Google tool by storing my data in some format edible by the search tool. I now have Google Search built into my application. Or, I write a different UI which allows you to abandon the Windows "Explorer.exe" altogether - it gets rid of the archaic 'files' an
Re:I think you and are are defining the same thing (Score:2, Interesting)
It is the case that, in order for a search to work across systems, there would have to be some commonality of the schema. I would think, though, that this would not be as impossible as you are making it. The "semantic web" people are developing just that, although are using yucky XML to do it. Think of all the standards out there - from SOAP to TCP/IP to RDF to ASCII. All have to do with a common format for exchange and/or meaning. The need for search would drive application developers to adopt similar logical models. The nice thing about the RDBMS concept is that you can define any logical view of the data that you want. If you have someone that cannot access your data your way, you can create a view of that data which corresponds to their schema.
I would think, over time, schemas would converge. Traditional, text-based search tools would perhaps need to be employed to search information that is not correctly defined, but why should that restrict someone from providing more information about their data the way the RDBMS does?
Re:#8 One tool for one job? (Score:3, Interesting)
Microsoft had an "object" model in COM, but that model only allowed extension of an object into a new object by composition - did not support inheritance. The notion of "object" in VB 6 was the same way.
There is a school of thought that inheritance is to be avoided, that everything should be composition. Inheritance may be bad -- think of OO newbies making inheritance trees 12 levels deep. Also think how hard it is to extend objects in someone else's framework by inheritance (think OWL or MFC). And think of the contortions one goes through to live with single inheritance and the perils of multiple inheritance.
And inheritance can always be simulated by composition by implementing functions on the interface that simply forward. In fact, they way multiple interfaces (as in Java) gives you a poor-man's multiple inheritance is that you have to write member functions to implement each interface that end up forwarding to composed objects because you get only one path of inheritance.
But there are times when you want inheritance. All of that implementing functions that forward to the function of another object gets old afterwhile -- it is so much busy work that we rely on "code wizards" in our development environment (Visual Studio) to write all of that mess. Implementing a COM object means writing tons of functions that simply call other functions.
I believe Microsoft must have come to that conclusion with .NET because COM was the kind of OO-neutral component system you are talking about, and Microsoft must have come to some realization that the approach is too restrictive. COM is essentially procedural at its very lowest level because that is the lowest common denominator of the languages it needs to support. .NET has an object model (an a VM) built into the operating system level, and it allows inheritance of classes across language boundaries, something one cannot consider with COM.
While inheritance (or any other element of OO) can have to "golden hammer" syndrome, there are times when what you want is a hammer, and in the absence of a hammer you end up pounding stuff with a heavy wrench or screw driver handle. I believe the OO holdouts want to live in a hammer-free society (Hammers Considered Harmful), and while OO people see everything as a nail, there are things that are nails and require proper hammers.
I used to think that OO was a solution seeking a problem, but I am beginning to think that OO is something that exists in the nature of programming architectures, and a lot of procedural programming is a simulation of OO (think Windows API, Gnome/GTK) so you may as well use an OO language. Professor Wirth tried to be an OO holdout with his Oberon language, and he caved with Oberon-2 and completely crossed over to the Dark Side with Component Pascal.
I don't know enough about Lisp and maybe I am awed by those who do, but I am beginning to wonder as to whatever Lisp does is even closer to the true essence of software and what OO is doing is a kind of emulation of Lisp, just as a lot of procedural programming really wants to be OO but doesn't know it.