Don't be fooled. This is not a book about Linux, but rather about Linus Torvalds himself. Once that idea is very clear in your mind, it's not bad at all. But simply don't expect it to provide you with a lot of insights into how to design an operating system or how to optimize the code for that particular device driver you have been working on lately. That's all.

Said that, do we learn anything from Linus' personal experience as described in this book? Well, he seems to have an interesting theory about "the meaning of life":

There are three things that have meaning for life. They are the motivational forces for everything in your life --for anythin that you do or any living thing does: The first is survival, the second is social order, and the third is entertainment. Everything in life progresses in that order. And there is nothing after entertainment.

(p. XVIII)

Of course, this would explain among other things the success of Linux and why so many opensource programmers appear to work for free, for the love of it. You guessed right, we have already reached the entertainment stage where not only sex becomes an excuse to practice some voyeurism and experiment with the KamaSutra, but even war becomes a mass attraction that we can enjoy live on CNN.

Once we get that out of the way (although Linus comes back to talk about this idea several times during the book), it is safe to say that the rest of it deals more with that gave him fame: the Linux operating system and why it even occurred to him to write it in the first place.

We learn quite a bit about Linus' first years in Finland, his environment, his family (some people at Microsoft will be very glad to hear that his parents, especially his father, were radical leftists), his first steps with a computer at the house of his maternal grandfather, etc. Don't get me wrong, there are some nice stories in these pages but... let's face it, Linus was a boring child! I mean, for crying out loud, while other kids were enjoying themselves at widl parties he was sitting in a dark room typing away at an old keyboard! There is room, nevertheless, to study the portrait of the young hacker a little bit in these first few chapters of the book (for those who may be interested in psychology, that is).

The second section of the book (Birth of an operating system) should appeal more to the vast majority of people interested in Linux and computers out there, although the authors warn that it contains "intermediate geek language until page 119", which I thought was quite humorous. In this section, Linus reminisces about the first computer he had (a 32-bit Sinclair QL), and pretty soon attempted to hack the machine:

One of the things I hated about the QL was that it had a read-only operating system. You couldn't change things. It did have hooks -places where you can insert your own code to take over certain functions- but only at particular places. It's so much nicer to be able to replace your operating system completely. Doing an operating system in ROM (read-only memory) is a bad idea. (...) I added a few commands to the basic interpreter that came with the machine so that when I wanted to edit something I basically just ran my editor automatically and it was instantly there. My editor was faster than the one that came with the machine. I was particularly proud of how fast I could write characters to the screen.

(pp. 44-45)

Isn't that a sweet child? On the other hand, I suppose one could trace back Linus' love for open source back to these days.

From those "humble" beginnings, Linus moved to writing games and then to his all-time favorite PC architecture. What attracted him to those machines was not only the price (tempting as it was for a poor high-school student) but also the ease with which they could be upgraded and peripherals could be added to them. In other words, the same reasons why PCs triumphed in the then nascent market of personal computers.

By the time Linus made it to the University of Helsinki, he was already the perfect geek. By his own accounts, he would then be exposed for the first time to UNIX and the book that would have such a big influence in his life: Operating Systems: Design and Implementation, by Andrew S. Tanenbaum. This is also perhaps the section of the book where Linus introduces more insightful comments:

... one of the beauties of Unix is realizing that you don't need to have complex interfaces to build up something complex. You can build up any amount of complexity from the interactions of simple things. What you do is create channels of communication (called "pipes" in Unix-speak) between simple processes to create complex problem-solving. (...) An ugly system is one in which there are special interfaces for everything you want to do. Unix is the opposite. It gives youthe building blocks that are sufficient for doing everything. That's what having a clean design is all about.

(p. 55)

A clear "small is beautiful" approach to system's design.

He then moves on to tell us the story of his well-known disagreements with Andrew Tanenbaum over the direction that Minix (the operating system Tanenbaum wrote as an educational piece of sofware, and that came bundled with his book) was taking. These are the differences that ultimately led Linus Torvalds to write the Linux kernel. His story about the origins of Linux are definitely modest and even self-deprecating at times, but we also learn how the whole thing was to a great extent improvised. If there is something that should be clear in our minds by now is that Linus' style while managing a project is to let a thousand flowers bloom in order to see which one is the most beautiful:

Much of Linux's success can be attributted to my own personality flaws: 1) I'm lazy; 2) I like to get credit for the work of others. (...) I divested myself of things that didn't hold much interest for me. The first of these was the user level, the external parts of the system that end users deal with directly, as opposed to deep-down, internal code. First somebody volunteers to maintain it. Then the process for maintaining all the subsystems becomes organic. People know who has been active and who they can trust, and it just happens. No voting. No orders. No recounts. (...) If two people are maintaining similar kinds of software drivers, for example, I'll sometimes accept the work from both of them and see which one ends up getting used. Users tend to lean on one versus the other. Or, if you let both maintainers work it out, they may end up evolving in different directions and their contributions end up having very distinct uses.

(p. 121)

Talk about applying the concepts of democracy and free market to the software development process. The problem is that, strange as it may sound to most people's ears, it seemed to work. Just as in the case of the opposition between democratic societies and dictatorships the former won in spite of all its supposed weaknesses, in the realm of computer science the most anarchic, chaotic, democratic and open approach also appears to be winning hands down. And to those who still don't understand why so many open source programmers are willing to work countless hours "for free", Linus explains:

Open source hackers aren't the high-tech counterpart of Mother Theresa. They do get their names associated with their contributions in the form of the "credit list" or "history file" that is attached to each project. The most prolific contributors attract the attention of employers who troll the code, hoping to spot, and hire, top programmers. Hackers are also motivated, in large part, by the esteem they can gain in the eyes of their peers by making solid contributions. It's a significant motivating factor. Everybody wants to impress their peers, improve their reputation, elevate their social status. Open source development gives programmers the chance.

(p. 122)

... and, in this sense, one should stress that the chance is given to everyone out there. It's up for grabs. All one need to do is download the code, study it, and then contribute fixes and new features. The dreams of both free market and socialism come true.

The final section of the book (King of the Ball) covers the years of success: Linux becomes an international movement, Linus Torvalds comes to the US to work for Transmeta, big corporations struggle to support the operating system... But what made Linux so successful? Linus is convinced it was not only (not even mainly) its low price. He thinks it should be chalked up to its open nature, the fact that nobody seems to control it directly, and most importantly that it did not occupy a niche:

It's a lot better to be everywhere and take over every niche, and that's what Microsoft did. Think of a fluid organism that flows into any place it can find. If one niche is lost, it's not a big deal. The organism surrounds the world, flowing into anything that's interested.

(p. 161)

In other words, the theory of the "good enough". If a product is good enough, cheap and it offers other advantages, it will take over other specialized products that are excellent but limit themselves to a single niche. This is the way Microsoft and the PCs killed many commercial UNIX vendors, and this is precisely also the way Linux threatens Microsoft now.

Does Linus see any danger in the commercialization of Linux? Not really. Actually, he thinks it will make it easier for the operating system to expand to all those niches he was talking about. But how about his own role as the leader of the kernel development? Is it vital? Not so either.

The point about open source has never been that I'm more accessible than anybody else. It's never been that I'm more accessible than anybody else. It's never been that I'm more open to other people's suggestions. That's never been the issue. The issue is that even if I'm the blackest daemon from Hell, even if I'm outright evil, people can choose to ignore me because they can just do the stuff themselves. It's not about me being open, it's about them having the power to ignore me. That's important.

(p. 190)

Linus also has strong feelings about the GPL license that is at the very basis of the free software movement. He does support it, but in a non-dogmatic way that pitches him against Richard Stallman's more dogmatic approach:

The GPL is wonderful in its gift of letting anyone play. Just think about what a major advance for humanity that is! But does that mean that every innovation should be GPL'd? (...) No way! This is the abortion issue of technology. It should be up to the individual innovator to decide for herself or himself whether to GPL the project or to use a more conventional approach to copyright. The thing that drives me crazy about Rihard [Richard Stallman] is that he sees everything in black and white. And that creates unnecessary political divisions. He never understands the viewpoint of anybody else. If he were into religion, you would call him a religious fanatic.

(p. 195)

The book closes with a few short chapters on different topics, such as intellectual property ("I find myself certifiable schizophrenic on the issue", in page 204) to some thoughts on how an obsession to control processes may backfire ("If you try to make money by controlling a resource, you'll eventually find yourself out of business", in page 215) or a few pages explaining why open source makes sense ("Think Zen. The project belongs to no one and to everyone. When a project is opened up, there is rapid and continual improvement. With teams of contributors working in parallel, the results can happen far more speedily and successfully than if the work were being conducted behind closed doors", in page 226).

So, altogether the book is entertaining and it manages to give us some insight as to why a developer might be willing to spend endless hours programming and then give his work away for free. In other words, it does take us into the mind of a hacker and, along the way, manages to teach us a few concepts about open source, UNIX and the computer business. However, this is definitely not a great classic. It is just that. An entertaining read.

---

Entertainment factor: 5/10
Intellectual factor: 3/10

---