Slashdot Mirror

TopSpin writes "Alcatel-Lucent has authorized The University of California, Berkeley to 'release all Plan 9 software previously governed by the Lucent Public License, Version 1.02 under the GNU General Public License, Version 2.' Plan 9 was developed primarily for research purposes as the successor to Unix by the Computing Sciences Research Center at Bell Labs between the mid-1980s and 2002. Plan 9 has subsequently emerged as Inferno, a commercially supported derivative, and ports to various platforms, including a recent port to the Raspberry Pi. In Plan 9, all system interfaces, including those required for networking and the user interface, are represented through the file system rather than specialized interfaces. The system provides a generic protocol, 9P, to perform all communication with the system, among processes and with network resources. Applications compose resources using union file systems to form isolated namespaces."

eldavojohn writes "The Information: A History, a Theory, a Flood by James Gleick has a rather nebulous title and the subtitle doesn't really help one understand what this book hopes to be about. The extensive citations are welcomed as the author barely scratches the surface of any theory of information. It also cherry picks odd and interesting facets of the history of information but presents them in a chronologically challenged order. This book is, however, a flood and as a result it could best be described as a rambling, romantic love note to Information — eloquently written and at times wondrously inspiring but at the same time imparting very little actual knowledge or tools to the reader. If I were half my age, this book would be the perfect fit for me (just like Chaos was) but knowing all the punchlines and how the story ends ahead of time rather ruined it for me. While wandering through interesting anecdotes, Gleick masks the reader from most of the gory details." Read on for the rest of eldavojohn's review. The Information: A History, a Theory, a Flood author James Gleick pages 544 publisher Pantheon rating 5/10 reviewer eldavojohn ISBN 978-0375423727 summary A wandering well-written historical who's who of Information Theory salted with references to hot topics. The book starts out with an introduction to the hero of The Information: Claude Shannon. It also introduces the hero's sidekick: Alan Turing. Aside from our initial introduction to Shannon's work at Bell Labs and his monumental paper from 1948, the author drops many names — a foreshadowing of what is to come in the book. George Campbell, George Boole, Norbert Wiener, Vannevar Bush, John Archibald Wheeler, Richard Dawkins and many many more. This sets the tone for the rest of the book as each chapter jumps around in time and grabs many quotations and excerpts to provide a gem studded narration by Gleick.

Chapter one provided me a piece of anecdotal information that I had actually never come across. It concerns the talking drums of Africa, an apparently ill-documented form of communication that existed in Africa. Rather, I had heard of the talking drums but never considered it in a context of information theory. It appears to be one of the earliest forms of long distance communication, predating all telegraphs. A drummer in one village would drum out the syllables and nuances in a lengthy sentence and often repeat it a few times. Drummers in distant villages would hear this and try to parse out what the drums were saying. As a result of this, they wouldn't just say 'moon' they would say something like 'the shiny white face that rises in the night' or something lengthier to ensure that the message was interpreted correctly. An ingenuous method of communicating, the chapter oddly never mentions parity bits or error detection, two things I basically equated with the additional words that were redundant. It does, of course, return to our hero Shannon who would later investigate the redundancy in the English language.

The next chapter concerns Walter J. Ong and his work concerning the persistence of information. Gleick discusses the find at Uruk and the subsequent deciphering of the cuneiform tablets. What was interesting about these tablets, however, is that they were inane things like bills and recipes. But when Donald Knuth saw one at a museum, he called what he read 'an algorithm.' The third chapter jumps to 1604 and the publishing of the very first dictionaries. Although amusing, this chapter merely extrapolates how difficult it was for us to codify our language (and still is nigh impossible). At the end Gleick translates this effort to cyberspace and similar problems.

The next chapter introduces Charles Babbage and his difference engine. To keep it interesting, Gleick includes excerpts from Charles Dickens, Edgar Allan Poe, Oliver Wendell Holmes and Lord Byron. And oddly enough there was some mentor relationship between Charles Babbage and Augusta Ada Byron King, Countess of Lovelace. Concerning Babbage, Gleick calls Ada 'first his acolyte and then his muse' for some reason this odd relationship is preserved in The Information. Lady Lovelace had many intuitions into how symbolic logic and algorithms would work in the future but I found much of this chapter to be concerning relationships and excerpts from letters. To give you an example of what I'm talking about, I learned that Ada died many years before Babbage of cancer of the womb and she took laudanum and cannabis to ease the pain. What does this have to do with The Information? You also learn that Babbage told a friend before his death that he would gladly give up whatever time he had left if he could spend three days five centuries in the future. Only one of the many stories of foolishly optimistic hope this book sells to the reader.

The next chapter involves the evolution of the telegraph. And the bulk of it concentrated on a telegraph that was quite unknown to me. The French Telegraph — or rather system of signs from high buildings — that could send messages by signaling from village to village. Aside from being an extrapolation of a binary signal from ages of yore like the lighting of fires on elevated land or smoke signals, I didn't really understand why the politics and problems of these devices were explored so in depth. When we finally get to the electric telegraph, we get some odd (albeit interesting) details about it instead of the theory. From the abbreviation of common sentences down to codewords to the fight of patenting the signaling mechanism, Gleick again avoids any sort of real numerical or even technical analysis of how humans were progressing from one bandwidth level to another. Cost per letter drove some odd advancements like acronyms and the investigation of how words could be encoded into less symbols. It ends with a reference to George Boole and logic as these symbolic representations lead the way for words to be replaced and turned into equations.

The book moves on to Claude Shannon and briefly touches on his work on signal noise. It jumps around to Russell and Whitehead's Principia Mathematica and Gödel's subsequent destruction of any dreams of representing everything with symbols by way of his famous Incompleteness Theorem. It goes on to talk about Weyl, Nyquist, Hartley, etc continuing the veritable who's who while providing very little actual knowledge of their work. Who could mention Gödel without also talking about Nazis? Certainly not Gleick. The politics of the time, the references back to Lovelace and Babbage dominate this chapter leaving very little room for any actual Information Theory. On page 201 you'll find H = n log s. Although you won't find more than a paragraph of explanation nor any extrapolations on that formula. Thsi chapter did yield something interesting — a piece of paper from Shannon's estimates of data storage on a logarithmic scale. While some estimates are close, others are very far off but he was already thinking of DNA as information storage. The anecdotes and quotations from peers of the time are impressively researched and cross referenced but at what cost?

The next chapter concentrates on the enemy: Norbert Wiener from MIT. He comes across as a cigar smoking, condescending, self involved, snobby professor who's primary contribution is a now defunct 'science' once called Cybernetics. He's quick to identify other's works as derivatives as his own and is presented as the antithesis to Claude Shannon who is portrayed as modest, cautious, well spoken. On top of that, not only is Shannon's work not defunct it is the basis of so much of everything that is useful today. Gleick portrays Wiener so negatively I almost wondered if the condescending label 'wiener' was somehow related to Norbert. This chapter delves into conferences once held and the interactions between the participants. While it lead for great humor in Shannon/Wiener interactions, I don't understand why they were relayed to the reader. Shannon's rat and its demonstration resulted in interesting remarks but I don't understand why the reader is given so much insight into these proceedings of Cybernetics when the field turned out to be little more than buzzwords. An interesting note, however, is how some of the members would let the media run away with phrases that the scientist had never actually said. They would do this almost strategically to both validate this new field and provide interest from Universities and funding sources ... but should anyone corner them and ask for clarifications they could always truthfully say that they never said that verbatim. I wonder how often this happens today?

This next chapter on Maxwell's demon and entropy was actually a little enlightening in that it provided a fairly clear discussion of entropy (physics) and entropy (information). In addition to this correlation, it discusses why it's often negentropy or negative entropy. Leo Szilárd's work is discussed as well as this concept that 'information is not free.' Although Maxwell's demon is simply a exercise in physics philosophy, this chapter begins what will be finished later: an English explanation of how information is fundamentally tied to matter and the universe.

Gleick now reaches biological information: DNA. He spends a chapter on the origins of DNA and how contemporaries of information theory approached it upon its inception. Of course Dawkins and Gould had interesting things to say in this chapter but also Hofstadtler and Gamow had perhaps the most interesting things to add. That DNA is essentially a number and that number represents a machine that can replicate and say things about itself. One thing this book does well is build this sort of interesting relationship between information and humans. This chapter takes a stab at establishing that we are all at our cores just information in the universe. As biological beings we are feeding off of negative entropy.

The book takes a bizarre twist now into memes. That's right, chain letters and lolcats. And how they replicate and infect our brain despite being nothing more than information. I found this chapter to be obvious and boring — worthy of complete removal from the text. This interjection is out of place entirely and I'm still scratching my head wondering what merit it had in this book. Since it is such an odd assortment and arrangement of the history of information, this could be skipped by the reader.

The chapter on randomness opens with an individual I've never heard of before: Gregory Chaitin. Gleick seems to imply that Incompleteness and Quantum Physics are somehow tied together by way of Turing's Uncomputability Proof — or so Chaitin (once?) thought. Because they were both related to entropy (the word I guess) and the connection was randomness. I didn't understand why this was in here if not to mislead the reader. What follows are some of the giants work and quotes about randomness and random numbers. While mildly interesting, there's not a whole lot to be gleaned from this chapter. I did appreciate the references to Andrei Nikolaevich Kolmogorov who did some original and even parallel work on information theory behind the iron curtain. Of course the text is rife with political situations and anecdotes (i.e. Kolmogorov's run in with one of Stalin's favorite pseudo-scientists). Oh and what book on information would be complete without G. H. Hardy visiting Srinivasa Ramanujan and remarking on the boring number of his taxi? The oft repeated story of the number 1,729. This anecdote feels out of place but Gleick uses it to probe the reader deeper into what randomness really means. Throw in Bach's Well-Tempered Clavier and I almost wondered if Gleick had re-read Gödel, Escher, Bach before writing this chapter.

The next chapter did actually touch on work that ties information to physics in that very basic sense of information is unable to be destroyed in our universe. The famous Preskill Hawking wager is discussed as well as the thermodynamics of computation and the resulting implications for quantum mechanics. The chapter wanders around to quantum cryptography (feeling a bit out of place) to qubits to RSA to ... well, it all (as it does throughout the book) comes back to Shannon. The chapter does end with an interesting quote from John Wheeler who apparently advocated translating the quantum versions of string theory and Einstein's geometrodynamics 'from the language of the continuum to the language of bit.' Sounds pretty interesting, right? Too bad all you get is the quote.

Was that chapter too technical for you? Don't worry, the text moves back to Wikipedia (shouldn't this have been addressed in the early chapters of dictionaries?) and actually talks about deletionism versus inclusionism and the Wikipedia debates on Pokemon articles. Of course, our old friends Babbage, Turing, Shannon, et al are brought back to somehow comment on this modern encyclopedia with quotes from Gleick like 'The universe is computing its own destiny' (for added drama that sentence is its own paragraph on page 377). Strangely enough there is no reference to Edward Fredkin throughout this book. Gleick jumps to domain name saturation on the internet and hits up 'the cloud' at the very end. I almost marvel at how many bases he can touch in one chapter. The penultimate chapter covers our inundation with news every single day of our lives probably from now to eternity. Unsurprisingly, Gleick conjures up quotes of ages long past (almost to the dark ages) of people complaining of the printing press or telegraph or newspaper or internet ruining their lives by assaulting them with information and news. Turns out 'Information Overload' is not a new concept. A chapter devoted to people complaining about too much information in a book on information seems to be too much credit for them, in my opinion.

The book really fizzles out as it tries to wrap up. Far from finalizing anything, the reader is given the concept of 'the library of babel' alongside the famous six degrees of separation. We are now more interconnected than ever before thanks to ... information!

Luckily this book has almost fifty pages of references to other books that contain far more complete and far more organized thoughts on information. I would not recommend this book to any of my colleagues unless they never went to college and never once picked up another book on Information. That said, I felt it was very well written and will no doubt continue to be sold en masse in bookstores. If anyone else read this book and came away with some very deep and profound understanding of the subject matter, I would love to hear it. Right now, the audience for this book is very small in my mind. It might best be given to a young engineer who has yet to go to college but has the vim and vigor to track down the real sources of The Information.

You can purchase The Information: A History, a Theory, a Flood from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

theodp writes "Why do some programmers,' asks Chris Hemedinger, 'place little value on code reviews?' This apparently includes even Programming Greats like Ken 'C' Thompson, who quipped, 'we were all pretty good coders' when asked about the importance of code reviews in his work. Hemedinger, on the other hand, subscribes to the school of thought that peer code reviews are Things Everyone Should Do. Not only do reviews keep you on your toes, Hemedinger says, they also 'improve quality, ensure continuity, and keep it fresh. Who can argue against that?'"

quartertime writes "Remember Reflections on Trusting Trust, the classic paper describing how to hide a nearly undetectable backdoor inside the C compiler? Here's an interesting piece about how to hide a nearly undetectable backdoor inside hardware. The post describes how to install a backdoor in the expansion ROM of a PCI card, which during the boot process patches the BIOS to patch grub to patch the kernel to give the controller remote root access. Because the backdoor is actually housed in the hardware, even if the victim reinstalls the operating system from a CD, they won't clear out the backdoor. I wonder whether China, with its dominant position in the computer hardware assembly business, has already used this technique for espionage. This perhaps explains why the NSA has its own chip fabrication plant."

Ian Lamont writes "Suspicions about China slipping eavesdropping technology into computer exports have been around for years. But the recent spying attacks, attributed to China, on Google and other Internet companies have revived the hardware spying concerns. An IT World blogger suggests the gear can't be trusted, noting that it wouldn't be hard to add security holes to the firmware of Chinese-made USB memory sticks, computers, hard drives, and cameras. He also implies that running automatic checks for data of interest in the compromised gear would not be difficult." The blog post mentions Ken Thompson's admission in 1983 that he had put a backdoor into the Unix C compiler; he laid out the details in the 1983 Turing Award lecture, Reflections On Trusting Trust: "The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect."

KentuckyFC writes "One of the cornerstones of modern physics is Claude Shannon's theory of communication, which he published in 1948. If you've ever made a phone call, watched TV, or used a computer, you've got Shannon to thank for describing how information can be moved from one place in the universe to another using an idea called the channel capacity. But nobody has been able to develop a quantum version of this theory. So physicists have no idea how much quantum information can be sent from one point to another. Now two American physicists have made an important breakthrough by proving that two quantum channels with zero capacity can carry information when used together. That's interesting because it indicates that physicists may have been barking up the wrong tree with this problem: it implies that the quantum capacity of a channel does not uniquely specify its ability for transmitting quantum information (abstract). And that could be the idea that breaks the logjam in this area."

gholmer writes "Eric Van Hensbergen reports that Plan 9 has been successfully booted on IBM's Blue Gene supercomputer. A live demo will be attempted during a poster session at this year's Usenix. There is also the obligatory Space Glenda picture."

Glenda_lives_on writes "OSnews has an alternative OS review on Plan 9. Plan 9 is a research OS produced by Bell Labs. It was open sourced a few years back, and has enjoyed a revival of sorts. Los Alamos National Labs is continuing to favor Plan 9 for their new generation of super computing because its the fastest thing out there. I have downloaded and ran Plan 9 before. In fact the Plan 9 live cd sits here on my desk. Its not an operating system for noobs however, and lacks some graphical refinement. Plan 9 is a very cool and a interesting test drive however. Its definitely worth the price of admission (free) for exploring, and education."

Simon P. Chappell writes "This is a hard review to write because I feel that I should be biased in favour of this book. I was one of the original reviewers of the book proposal. I read it and said "Yes, they'll be lining up around the block for a book like this!" Well, maybe those weren't my exact words, but I did offer my endorsement. After all, the Jakarta project of the Apache Software Foundation has an excellent reputation for quality Java code products and the Commons is quite the supply of diamonds in the rough. What could go wrong?" Read on for the rest of Chappell's review to find out. Apache Jakarta Commons - Reusable Java Components author Will Iverson pages 338 (8 page index) publisher Prentice Hall rating 4 reviewer Simon P. Chappell ISBN 0131478303 summary There are other books about the Jakarta Commons; buy one of those instead.

What's To Like

The book takes the reader on a journey through the Jakarta Commons. The Commons is like a massive utility library of Java code. Much of the code has been promoted out of the other Jakarta projects as it became more useful. One of the first such components was the Digester, which is a component to initialise a Java object from the contents of an XML configuration file. Very useful, originally from Struts and now used extensively by other Jakarta projects.

As the subject matter for a book, the Commons seems like a natural winner (I guess I have to say that!). There are so many components in the Commons that a guide to their types and usage does need to be available for developers.

Naturally, the book has a website to accompany it.

What's To Consider

Where to begin? I was actually surprised to find that I did not care for this book. The last review I wrote was for Mr. Iverson's very good Hibernate book. That was well written and structured. Unfortunately, this book feels kind of thrown together. The lack of care shows in the cramped layout and typesetting, the over-abundance of UML diagrams (a few here and there are great, but this felt like padding), code examples that can only be described as under-whelming and an approach that feels like an annotated telephone directory.

Despite the lack of quality of the primary chapters, they only actually account for the first 199 pages of the book. This is actually a very reasonable number of pages for a book, especially when you consider that classics like the first edition of Kernighan and Ritchie's "The C Programming Language" weighed in at about 220 pages. Sadly, the book then goes on for another 125 pages churning out what looks like repackaged JavaDoc for each of the major classes in the commons. You may like this, but it annoys the beans out of me and it'll reduce the score on one of my reviews faster than the Linux community can debunk a SCO IP infringement claim.

Summary

I really wanted to like this book. But it feels like someone was cranking the handle on a cash machine and thought that if they printed stuff about Jakarta, that the geeks would obediently buy it. Not this time. There are other books about the Jakarta Commons; buy one of those."

You could purchase Apache Jakarta Commons - Reusable Java Components from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

jg21 writes "Although this reader-compiled list of software development's giants omits pioneers like George Boole, John Louis von Neumann, and the 'Forgotten Father of the Computer' John Vincent Atanasoff - among others - it does a pretty good job of mapping the Code Masters, from Alan Turing who gave us the algorithm, to Klaus Knopper the one-man band behind Knoppix. They're mostly here - the inventors of C, C++, C#, Java, and Python; example. There are a couple of programmers who have snuck in more for their business acumen than their programming talent, like the former Powersoft/Sybase CEO Mitchell Kertzman but otherwise the 40 nominees seem pretty 'pure' and the overall idea is to narrow the list down to the Top Twenty Software People in the World - a phrase invented by Tim Bray, who blogged that Adam Bosworth would be among them. Be careful what you wish for when blogging - looks like Bray's about to find out who the community thinks the the 19 others are."

ajs writes "In November 2002 everyone who wasn't Red Hat was gathering behind a banner that many thought would spell the beginning of a new chapter in the Unix Wars. That banner was called United Linux. Much has changed in the Linux world since then, and some Founding Partners in the United Linux camp have decided that there are other ways to change the market. Thankfully there are more level headed members of that group. Today, we're not so focused on the differences between Linux distributions, Sun's rants, the aforementioned lawsuits and ever-present, market-gobbling Microsoft keep everyone focused and united enough as it is, and United Linux has begun to fade into memory. So what has United Linux done? Well, it unified three distributions at least, focused attention on Linux standards and made hardware vendors feel a bit less lost when writing drivers for Linux, so it wasn't all a loss. Alas, according the the United Linux site, "There are no plans for a version 2.0 at this time.""

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.

===============

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.

===============

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.

===============

Tarantolato writes "A new preliminary public release of the Inferno distributed operating system is now available for downloading from Vita Nuova's website. Inferno is meant to be a better Plan 9, which was meant to be a better Unix. It can run as a standalone OS, as an application on top of an existing one, or even as a browser plugin. Also, all of its major components are named after things related to hell."

Simon P. Chappell writes "Linux programming is the C Programming Language. Elaborating a little, Linux programming is C, with the GLIBC library and the POSIX standard API. Even a language as powerful as C needs libraries and to get the Holy Grail of cross-platform portability, it's necessary to have them standardised. The POSIX API is that standardisation and Linux adheres to it very well (opinions from those litigious folks in Utah aside). For those of us who already know C, Linux Programming by Example sets out to teach you the rest in a step by step, helpful, relaxed and incremental manner." Linux Programming by Example author Arnold Robbins pages 687 (21 page index) publisher Prentice Hall rating 10 reviewer Simon P. Chappell ISBN 0131429647 summary An exellent tutorial for real-world Linux software development

What's To Like There are many things to like about this book (over and above the fact that page 118 has my all-time favourite UserFriendly cartoon on it :-). Linux Programming by Example (LinuxPbE hereafter) takes a steady, incremental path through the concepts required to write software that can effectively interact with the Linux environment.

It is a truism many of us have proven multiple times in our lives that one of the finest learning tools available to programmers is to read and grok good, working code, written in the language that we are learning. LinuxPbE takes this philosophy and walks you through actual example code from various Unixes and Linux. The first part of the book, specifically chapters one through six, covers all of the aspects of Linux programming necessary to understand the Unix V7 ls program in its full glory in chapter seven. I feel that this approach works very well.

Part two dives into processes, walking us through creating them, managing them, communicating with them by using pipes and sending them signals. A few other general topics are included for completeness. Part three then covers the art and tools of debugging in fairly substantial detail.

All the code in the book is very well laid out, with line numbers provided to the left, and comments (in a small sans-serif font) on the right-hand side of the code. This is a very readable combination that is enhanced further by the fact that at each logical division, an explanation is given of the design and implementation used by that section.

I can't resist admiring the addition of the essay "Teach Yourself Programming in Ten Years" by Peter Norvig. This is a classic exploration of the effort needed to attain mastery of any skill, concluding that the minimum length of time required is ten years. The inclusion of this article, to me, speaks well of the author and his understanding of the learning process. One can only hope that those learning from this book will come to the same understanding and realise that the book is the start of their journey to mastering Linux programming.

What's To Consider

Nothing notable.

Summary If you want to learn how to do this stuff for real, then this book will get you started. As "Teach Yourself Programming in Ten Years" explains, no book is going to cause you to become an expert in 24 hours, 24 days or even, perhaps, 24 months. That said, this book will be useful for many of those ten years, so run or surf to your favourite bookstore and purchase it now.

You can purchase Linux Programming by Example from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

E1ven writes "First Microsoft detergent, now, UNIX Diapers, among other niceties. The author of this page has apparently worked to photograph and categorize the use of the term UNIX in other, non software products." (And don't forget Linux detergent.) Update: 10/12 21:23 GMT by T : Less garbled now ;)

jellings writes "Dennis Ritchie and Kenneth Thompson will be recipients of this years' Harold Pender Award, given "to an outstanding member of the engineering profession who has achieved distinction by significant contributions to society" by the University Of Pennsylvania School of Engineering. Under the direction of Pender, ENIAC was born, and under Ritchie and Thompson, UNIX was born."

jellings writes "Dennis Ritchie and Kenneth Thompson will be recipients of this years' Harold Pender Award, given "to an outstanding member of the engineering profession who has achieved distinction by significant contributions to society" by the University Of Pennsylvania School of Engineering. Under the direction of Pender, ENIAC was born, and under Ritchie and Thompson, UNIX was born."

jellings writes "Dennis Ritchie and Kenneth Thompson will be recipients of this years' Harold Pender Award, given "to an outstanding member of the engineering profession who has achieved distinction by significant contributions to society" by the University Of Pennsylvania School of Engineering. Under the direction of Pender, ENIAC was born, and under Ritchie and Thompson, UNIX was born."

SeanIBaby asks: "I was wondering if anyone used Plan 9, and Inferno/Charon for a web browser. Are there any other web browsers for Plan 9, or do you have to code your own? I've noticed that Inferno's company sells Plan 9 boxed sets for $150US. I guess this is because they include the Inferno/Charon binaries with the image, even though they let you download Inferno for free from their website. Plan 9 is free from Bell Labs."

SeanIBaby asks: "I was wondering if anyone used Plan 9, and Inferno/Charon for a web browser. Are there any other web browsers for Plan 9, or do you have to code your own? I've noticed that Inferno's company sells Plan 9 boxed sets for $150US. I guess this is because they include the Inferno/Charon binaries with the image, even though they let you download Inferno for free from their website. Plan 9 is free from Bell Labs."

Dibyendu Majumdar writes "Dennis Ritchie has posted some court papers from the lawsuit by USL against BSDI about UNIX intellectual property. Some of the SCO claims, such as identical comments in the code, etc. also occur in the claims made by USL. Interesting read in the context of SCO vs IBM case."

Dibyendu Majumdar writes "Dennis Ritchie has posted some court papers from the lawsuit by USL against BSDI about UNIX intellectual property. Some of the SCO claims, such as identical comments in the code, etc. also occur in the claims made by USL. Interesting read in the context of SCO vs IBM case."

DrSkwid writes "The OSI have approved the revised license for the plan 9 operating system according to attendees returning from this year's Usenix Bof."

DrSkwid writes "The OSI have approved the revised license for the plan 9 operating system according to attendees returning from this year's Usenix Bof."

icantblvitsnotbutter writes "An excellent -- and clear! -- article over at LinuxWorld.com has a multipoint analysis of SCO's 40-page complaint (this is a brief?!). For all those IANAL's out there, here's something to sink your teeth into. On the balance, the outlook seems positive for IBM. Still, the parallel invocation of a contractural clause potentially nixing AIX lends some credence to claims that this is a just way for SCO to coerce IBM into buying them out..." Some old documents from a similar lawsuit have surfaced, and naturally ESR has his own take on the case.

nycheetah submits a story about the collective voice of the internet. There's also a Bell Labs webpage with some more technical information about the project.

Arnaud Sahuguet asks: "I have a cell-phone with my phone book, a PDA with my calendar info and my address book. I have my home desktop bookmarks, my work desktop bookmarks, my laptop bookmarks, my PDA bookmarks, etc. They are all mine, but somehow they are not, because they live in different networks (or on the same network but with different operators).Everybody keeps talking about convergence, but I don't see any convergence on the user profile front (data that matters to me). Microsoft is pushing for .NET MyServices, Sun et al. are pushing for Liberty Alliance, Apple is pushing for .Mac. Is it the right way to go?" One of the large major issues surrounding such a system would be implementing it in a way where the user can control the flow of data: where it is stored, when a certain piece of data can be sent, and who is allowed to get it. Sounds like a fine idea to me, what do you all think?

"As a user:

• would you be willing to have your personal profile information stored on the network?
• who would you trust? Your bank, your ISP, your cell phone provider, your company, the EFF, no one but you?
• what kind of guarantees would you require?

I have been struggling with this idea for a while and the best solution I can see is to reuse the Napster paradigm for my generic user profile infrastructure (let's call it GUPster).

Napster is (I should say was) a community of users willing to share MP3 music files, administered by a central server managing meta-data about users and files. I don't know what the exact goal was, but I can see it as a way to free ourselves from the music industry monopoly.

GUPster would be a community of network entities (e.g. servers at Yahoo!, server at SprintPCS, servers at my university, my home machine, etc.) willing to share standardized user profile components, administered conceptually by a central server managing meta-data about entities and components. The goal is to create synergies between network components in order to deploy value added services for the user. (Since I am working for the telecom industry, the goal is to make network operators happy by making end users happier.)

Just like in Napster, my user profile information will be distributed but the meta-data will be centralized (at least from a logical point of view) at the GUPster server. This way, I can decide that my credit card information will be stored at my bank, my calendar information on my Yahoo! account, my game scores on the Sony web site, etc. Network components storing my profile information will have to support the right set of interfaces and protocol and will register to the server the pieces of my profile they are storing.

Note: I will be the one deciding who stores what. Think of it as like moving to a new place. You can choose your electricity, gas, phone, cable and Internet providers.

Applications willing to access any of this information will talk to the GUPster server. And just like Napster, the server will not return data, but referrals (i.e. where this information can be found).

Unlike Napster, the central server will also enforce some access control policies defined by the user (let's call them my 'privacy shield'). If the request for user profile information is not OK (e.g. nobody can access my presence information after 9pm), the returned referral is empty.

Does it sound crazy?"

Ami_Chan writes: "According to Nature, researchers at Bell Labs have created a new type of optical fibre. This fibre is hollow, and can be tuned to different wavelengths of light using 'plugs of fluid' and temperature changes within the fibre. This allows the fibres to process signals as well as transmit them. The full article is here."

s20451 writes "Bell Labs' claims to have manufactured transistors consisting of a single-molecule switch are being met with skepticism in the scientific community, following difficulties in reproducing the experiment. Now a panel has been formed to investigate research misconduct related to not only that claim, but others regarding organic transistors." We've run several stories about the extremely tiny transistors and the innovative ways of assembling them which Lucent has been working on. A reader's summary of a subscriber-only story on Science's website suggests that there is strong evidence that some of the data in the published papers was faked.

F2F writes "Plan 9 from Bell Labs Fourth Release was announced yesterday marking a major overhaul of the entire operating system. VMware images are now supported, together with hoards of new hardware. The operating system now sports a new security model (on top of the old one, which was already quite secure), new network-resident secure storage system and improvements in the thread library, among others. See the release notes here: release4 notes or simply go to the download page at: plan9 download." T. adds: erikdalen sent in these links to critiques of the Plan 9 license from Richard Stallman and Nathan Myers.

F2F writes "Plan 9 from Bell Labs Fourth Release was announced yesterday marking a major overhaul of the entire operating system. VMware images are now supported, together with hoards of new hardware. The operating system now sports a new security model (on top of the old one, which was already quite secure), new network-resident secure storage system and improvements in the thread library, among others. See the release notes here: release4 notes or simply go to the download page at: plan9 download." T. adds: erikdalen sent in these links to critiques of the Plan 9 license from Richard Stallman and Nathan Myers.

F2F writes "Plan 9 from Bell Labs Fourth Release was announced yesterday marking a major overhaul of the entire operating system. VMware images are now supported, together with hoards of new hardware. The operating system now sports a new security model (on top of the old one, which was already quite secure), new network-resident secure storage system and improvements in the thread library, among others. See the release notes here: release4 notes or simply go to the download page at: plan9 download." T. adds: erikdalen sent in these links to critiques of the Plan 9 license from Richard Stallman and Nathan Myers.

IceFoot writes "Bell Labs announced it has created organic transistors with a single-molecule channel length, more than a factor of ten smaller than anything that has been demonstrated even with the most advanced lithography techniques. The really cool part is the transistors assemble themselves: the molecules do the work of finding the electrodes and attaching themselves. Webcast on Wednesday, October 17, 2001 at 3:00 p.m. Eastern time"

Tetard asks: "Long live the pipe! Since the `|' was invented by Doug McIlroy in 1973, has there ever been a more effective way of reusing tools and connecting data ? The mouse is a device of the Beatles era; Rather than try and provoke nostalgia in the older ones among us, I'm asking myself, as are others: when we don't try to reinvent the wheel, or at least improve it, why must we try and copy it every time ? Xerox PARC exposed us to WIMPs and we haven't done better: some innovation, some plastic surgery -- but no "paradigm shift" -- where's the creative destruction that will take us further ? Graphical component programming is turning us into click-happy bonobos^H^H^Hchimpanzees, as we fail to find new ways to manage and connect richer data streams. My web designer friends are damaged for life because of mice, and yet we persist... Where do we go from here ? If we ever invent the graphical pipe, let if have keyboard shortcuts." Yes, you've probably seen a similar question to this run by Ask Slashdot before, but this time I'm wondering if maybe we need new input devices before the WIMP paradigm is replaced with something better. Might any of you have ideas on what form these input devices might take?

For those interested, here are the previous stories that have handled this type of question:

• GUI Research - Is it Still Being Done?
• Pipes In GUI's?
• Pipes in GUI's? (Redux)

So what it will take to break us out of the WIMP box (or prison, depending on your bias), maybe new input devices would do it, but quite frankly, I wouldn't be surprised if a 3D interface might be another route (it would possibly spark interest in designing a new input device that would work better with 3D interfaces, or maybe data-gloves could serve this purpose?). Going on a limb, maybe this guy might just be the ticket.

Phase Shifter writes: "I was looking at Lucent's website when I found a link to this article about how a dim galaxy cluster was discovered by its gravity instead of its light. They say the same technique could be used to determine the distribution of dark matter in the universe."

LuserOnFire writes: "There is a PigDog article talking about the Bell Labs Text-to-Speech Synthesis. The amazing thing is not the technology itself, but that fact that Bell-Labs has a checkbox next to it that says 'If you plan to enter text which our system might consider to be obscene, check here to certify that you are old enough to hear the resulting output.'?!?! Like if you are old enough to spell a swear, you don't know what the word sounds like?" More fun than a TI-99/4A with speech-synthesis card. Those wouldn't say the bad words at all.

Multics writes "It is with considerable sadness I report the death of the parent of Information Theory -- Claude Shannon. Here is his obituary over at Bell Labs. He was 85."

e271828 writes "Brian Kernighan, Marvin Minsky, Ron Rivest, and Richard Stallman are among the CS stalwarts that have jointly filed an amici curiae brief supporting the EFF and 2600. The brief, hosted on Cryptome makes for excellent reading." This is to accompany the appeal that we mentioned a few days ago.

A reader writes: "I was doing some research on Bell-Labs, and I stumbled across Ken Thompson's Chess page. ( that's not the interesting part ) The interesting part is that at the top he says that he's leaving Bell Labs yesterday - Dec 1 2000, to pursue flight instruction full time. I dont know about everyone else, but it seems sort of important that one of the co-creators of Unix appears to be retiring."

Whaddya wanna hear? a) Microsoft's licensing practices, while never to everyone's taste, perhaps, seem to have mellowed at least a bit from the projected future of pay-per-reinstall. 2) The SDMI boycott you read about here lately has lost a key proponent; the reasons are unclear and so is the eventual outcome. iii) If Linux is too cool, BSD too smug, Windows too ridiculous, perhaps you need ... a truly infernal OS. N) Yet more proof that Carnivore and its ilk may be annoying and a threat to the average user, but hardly a sting to a wired criminal worth his salt. All below.

Frankly, this would have been just too silly. steveha writes: "Microsoft just changed their 're-imaging' payment policy. Companies buying computers that come with Windows installed can once again re-image the system hard disk without Microsoft demanding an extra license payment. Here is the official Microsoft document. Computer Reseller News had the story."

Burn baby burn. rpeppe writes: "briefly, you can download Inferno here, for free.

you might remember from a month or so back that the UK firm Vita Nuova obtained rights to Inferno, a next-generation virtual/embedded OS created by the likes of Rob Pike, Ken Thompson and Dennis Ritchie. Inferno uses many of the ideas from Plan9 but, unlike Plan 9, there are no restrictive hardware requirements - it runs as a "virtual OS" under Linux, Windows, Plan 9 and others, mapping the resources provided by the host OS into a standard form for programs running within Inferno, which will run without change on any platform running it (including on bare hardware, such as SA1100 or MIPS)

we've just made free downloads available (for any use) for Linux, Windows and Plan 9. the actual kernel is not open source, but the download includes open source for all the user-level code in the system (applications, libraries, etc), plus unix-style documentation so there's plenty to tinker with.

this is a system that is genuinely trying to address the problems that are "too deep for unix to fix" and includes all sorts of interesting takes on some of the original unix philosophy (after all, it represents 30 years of evolution from the unix original). plus it's a really nice environment in which to write genuinely (and elegantly) portable programs."

Taking the meat from the jaws of Carnivore. An unnamed correspondent writes "Found a nice article on the circumvention of Carnivore which details steps one can take to avoid big brother. Article is nicely written which has a strange reference to the NSA's Verona project of World War II."

Nothing here may be all that new or surprizing to those already interested in online privacy or cryptography in general, but if you ever need ammunition in an argument about the nice government versus slithering heroin-dealing kiddie-porn terrorists, it'd be nice to point out how accessable these methods are to all involved.

OK, who has what up their sleeves, and why? Fervent writes "Interesting twist in the SDMI boycott -- Don Marti's backing down a bit. Apparently he and Leonardo Chiariglione, executive director of the SDMI, talked and found ways to get along about secure music. The article is here."

I'll be impressed if the music industry or anyone else can come up with a high-quality music format which can't be effectively copied with a modicum of hassle. "Anything that can be read," etc. Thta's not about to stop them from trying on both technological and legal fronts. Of the two, I'll take technological any day.

Tucros writes "There is a nice article over at Bell-Labs.com detailing the History of UNIX." This is a somewhat lengthy bit with lots of entertaining stuff that normally would just be sorta anecdotal. I enjoyed this one a lot.

Read on for clarification about the alleged Gnome/KDE collaboration reported a few days ago, which ... ain't. And about the project to put Linux on the Royal DaVinci, which promises slow but steady progress. There's also infernally good news for anyone intrigued by the recent open-source Plan 9 release.

Pardon me, sir, are you in the market for a nice strong bridge? Aaron J. Seigo writes: "A letter from Mosfet can be found at knews.derkarl.org which clearly states the official KDE position regarding the recent "news" with regard to Gnome and KDE getting together on a common component model. Which is: It isn't happening. And for good reason.

KDE2 is in the final stages of preperation, so this is not the time to go messing with the foundations of things. Also, KParts wasn't designed on a whim. The KDE team put a lot of thought into it and came up with something that has some very real benefits to it (speed/overhead/etc). While interoperability would be nice, don't expect it on the component level just yet. Be happy with drag 'n drop and the like. For now."

Fair enough. Also on the KDE front, Joseph points you to knews.derkarl.org, which seems like a useful one for anyone looking for KDE updates.

Will a Linux PDA become their strong suit? jsinnema writes "News on the Linux Powered Royal daVinci from Wayland Bruns, CEO/CTO/Chief Geek CompanionLink Software at PDA Buzz Royal: 'Unfortunately, development is not on the timeline originally hoped. What's shaping out is two 16MB ROM/16MB Ram units, one 4 color grayscale for a low price, the other full color for a higher price. Size and weight are about the same as a Palm III. The color unit will have a flash slot.' and
'One of the interesting aspects of the project is that this is the first time we can directly compare performance of a particular app on both PC and PDA. I'm happy to report the PDA units are surprisingly powerful, except to note that memory access is relatively slow.'"

It sure would be neat if Linux becomes the default OS for palm-top computing; will Royal's project, though, stand a chance against the flashier ones which keep peeking like Monty Python animation over the horizon?

I'm sorry, but I'll have to call you back after I set my computer on fire. rpeppe writes "those who were intrigued by the Plan 9 release but don't have the appropriate hardware, or in fact anyone interested in new languages and OS's should be interested in the following:

vita nuova has released a new edition of the Inferno OS, source code and all, under a new licence, which allows distribution of core OS source code to inferno subscribers only, but unencumbered personal and commercial use of the binaries and the rest of the source code (including a javascript capable Web browser).

inferno is a cousin to Plan 9, but includes a virtual machine and a new language, limbo, and can run hosted under linux, free bsd, windows and other OS's, as well as natively on x86, ARM, MIPS, 68000, 68020 processors. because the whole operating system is virtualised, programs written for inferno are completely portable, something it would be difficult to say about java, for instance.

the language, limbo, deserves some attention - it's C-like, and OO in the deeper sense, but avoids the inheritance pitfalls that languages like java fall into. it's a joy to write in.

in my opinion, inferno was the coolest thing ever to have come out of bell labs CSRG - and we've now got exclusive rights to it, and intend to make as much of this excellent technology as we can. i hope others will too!"

Joined by dozens of other readers, johnmullin writes: "Bell Labs has made the third release of its Plan 9 computer operating system available on the World Wide Web under an open-source agreement. Anyone interested in using Plan 9 may download the system, including source code and documentation, from http://plan9.bell-labs.com/plan9dist/. Check out the full story here here." Note for the lazy: An English company called Vita Nuova will also be selling "a full boxed set with CDs and manuals." Surely, systems research is not dead ...

Joined by dozens of other readers, johnmullin writes: "Bell Labs has made the third release of its Plan 9 computer operating system available on the World Wide Web under an open-source agreement. Anyone interested in using Plan 9 may download the system, including source code and documentation, from http://plan9.bell-labs.com/plan9dist/. Check out the full story here here." Note for the lazy: An English company called Vita Nuova will also be selling "a full boxed set with CDs and manuals." Surely, systems research is not dead ...

Manoj writes "Rob Pike of Bell Labs (Yes, that [Rob Pike]) says that systems software research is irrelevant. At a time when computing is almost the definition of innovation, research in both software and hardware at universities and much of industry is becoming insular, ossified, and irrelevant. Where is innovation? At Microsoft, mostly. Exercise: compare MS software in 1990 vs MS software today. He states that Microsoft has been working hard, and that on many (not all) dimensions, their products are superior technically. Linux is the hot new thing, but it is merely a copy of the same old stuff. And anyway, the exciting thing about Linux is the development model, and researchers contributed little to that. He states that the excitement, the art, of systems research is gone. "

Penguin_99 writes "Wired.com has an article about a Lucent Technologies' Bell Labs researcher (Lov Grover) who came up with a quantum algorithm that is able to instantly search a massive database (of websites or whatever you might have) and return amazingly precise results even if the input is vague or incomplete. This particular algorithm can be used for other things besides searching for instance solving equations. Apperently this algorithm is only one of a handful of quantum algorithms in existance. The down side is that it requires a quantum computer so you are not likely to see Yahoo! using it anytime soon. Imagine a day when you do not have to wade through pages of usless websites after performing a search. "

Penguin_99 writes "Wired.com has an article about a Lucent Technologies' Bell Labs researcher (Lov Grover) who came up with a quantum algorithm that is able to instantly search a massive database (of websites or whatever you might have) and return amazingly precise results even if the input is vague or incomplete. This particular algorithm can be used for other things besides searching for instance solving equations. Apperently this algorithm is only one of a handful of quantum algorithms in existance. The down side is that it requires a quantum computer so you are not likely to see Yahoo! using it anytime soon. Imagine a day when you do not have to wade through pages of usless websites after performing a search. "

pomac writes "Check out Libsafe for a great effort in protecting outdated systems against stack attacks or buffer overflows. I would love to see some constructive opinions on this. " You and me both.