Andy Tanenbaum on 'Who Wrote Linux'

Andy Tanenbaum writes "Ken Brown has just released a book on open source code. In it, he claims (1) to have interviewed me, and (2) that Linus Torvalds didn't write Linux. I think Brown is batting .500, which is not bad for an amateur (for people other than Americans, Japanese, and Cubans, this is an obscure reference to baseball). Since I am one of the principals in this matter, I thought it might be useful for me to put my 2 eurocents' worth into the hopper. If you were weren't hacking much code in the 1980s, you might learn something." Tanenbaum's description of the interview process with Brown is classic. See also Slashdot's original story and Linus' reply.

Comments

It's an old copyright strategy

[argoff]

In old world media, who creates something of value is more important than what gets created. Hence there is often alot of slander, lies, and outright fraud (and a lot of crapy media). In Hollywood, it's so bad it's pratically institutionalized.

I think the enemies of Linux are trying a similar strategy based on the addage "if you kill the shepard - the sheep will scatter", "If you lie about something long enough or hard enough, people will believe it". They can't discredit Linux for technological or commercial reasons anymore, so their only option is to discredit Linus. With billions at stake, it could get nasty.

Re:I like the last bit

[gowen]

Well, there are certainly benefits to a modular micro-kernel design. I wouldn't deny it (and haven't). But there are also drawbacks (message passing is terribly hard to make secure in a multi-tasking context, and is frequently slower than dirt. Add to that some of the braindead design decisions of the x386 w.r.t. privileged processes...) Yuck.

Treating the micro v. monolithic debate as a solved problem ("microkernels win!") is as idiotic as suggesting that object orientation is the ideal solution to all programming problems.

Fighting features

[amightywind]

..As I did 20 years ago, I still fervently believe that the only way to make software secure, reliable, and fast is to make it small. Fight Features.

Credit Mr. Tanenbaum sticking to his guns on the micro kernel design. But the brilliance of Linus is that he realises you must first have features to fight!

Re:I like the last bit

[gowen]

And you disagree with this? Why?

Because if you want any kind of decent performance out of a server system you need both those things. Otherwise you've got a couple of designed-in bottlenecks to throughput. Now *that's* a braindead design decision. Of course, its completely understandable in the context of MINIX's design as a teaching system, but to deride those features in other OS's as "a hack" is just pure prejudice.

In conclusion ..

[Macka]

My conclusion is the Ken Brown doesn't have a clue what he is talking about. I also have grave questions about his methodology. After he talked to me, he prowled the university halls buttonholing random students and asking them questions. Not exactly primary sources

What more needs to be said !

Re:I like the last bit

[brunson]

I think he made such a big stink about it during the infamous flame war that, even if it was somehow proven that a macro-kernel is a better design, Tanenbaum could never back down from his premise without losing face.

Re:I like the last bit

[cyb97]

Performance of the compiler is probably more guilty when it comes to overall performance than the kernel. Further you are comparing apples with oranges comparing a Mac to a PC when it comes to compiling...

Re:How can Linux be a copy of Minix

[Tarantolato]

I don't think Tanenbaum is bitter. He just wants to point this out.

Since I don't think anyone here has RTFA'd (/. effect and all) it's not worth judging right now. I think it's pretty classy of Tanenbaum to step up and offer some perspective on the AdTI FUD. If he does that as someone who still doesn't buy into Linux, that makes it all the more credible. Do we really want every response to this to be written by a Linux fanboy?

Re:I like the last bit

[kfg]

Bitter much?

Perhaps, just perhaps mind you, he is simply stating what, in his opinion, is true.

KFG

Really A Secret ?

[polyp2000]

I dont think Linus or anyone else has tried to conceal or hide the origins of linux. Anyone who has taken more than a passing interest in the history of linux knows that Linus got interested in kernel development while hacking Minix which was supplied in source code form in an educational book called "Operating Systems: Their design and Implementation". Rebel Code (Glynn Moody) is an excellent history of linux and open source and a great read. If people are interested in getting a good background its a great place to start.

I think its fair to say that "shock horror!" Andy Tanenbaum probably "learned" how to write Minix from somewhere else. In any case in the initial phases of Linux I think its fair to say that Linus did 99% of the work. And after the seed was planted.. well lots of people are now involoved with writing linux.

Its the nature of the beast almost all human acheivements are adaptations of something that came before . Its called development and its incredibly difficult to come up with an idea that doesnt have its basis in something else.

I challenge anyone to try and come up with an idea that doesnt have its origins in something else.

nick

The Important Point

[Dark Paladin]

Whatever anyone does - do not read Brown's book when it comes out.

Thanks to Mr. Tanenbaum, we have the proof here:

People can create operating systems on their own. Even UNIX-like operating systems. Linus learned from Mr. Tanenbaum. Linus wrote the first kernel, published it and asked for input, which the rest of the world provided.

Linus then acted as a proper project manager, and the rest is history.

So again, whatever people do - do not buy the book.

Now, here's the problem: if we talk about this upcoming book, people will want to buy it. It's the Gibson Effect - the more its denounced, the more people will want to read it, and next thing you know there will be lines of people at the bookstores claiming they can see Jesus's face on this book.

So instead, I recommend to all intelligent folks in the programming community: ignore it. From here on out, don't even refer to the book by name, or its foundation, or the author. The more we pretend it doesn't exist and it's not important, the less interest people will have in it. If someone asks (such as a Pointy Haired Boss guy), shrug and lie as you say "No idea. I heard it was some book, but that it wasn't that good." And then shut up and leave it at that.

Don't give these guys free advertising. Don't even give them an ounce of respect, they don't deserve it.

Re:I like the last bit

[arkanes]

I've re-read that old flameware a few times over the years. It's kinda interesting how one reason he derides the performance hack is that "you don't need them", because normal PCs only have one job running. Certainly nobody envisioned the kind of systems we'd be running today (note the comment about 10 years from now when we're all on 200mips 64MB sparcs. That'd barely qualify as a toaster today....), but Linux rose to the challenge, Minix pretty much didn't. I think the freedom of Linux had alot to do with that (and he misses the point during the flamewar on that, too).

12 years ago, who would have imagined that it is normal and in fact essential for a desktop OS to be able to smoothly handle many IO intensive processes at the same time?

Level-headed and interesting

[Junks Jerzey]

I know many in the Linux community like to paint Mr. Tanenbaum as a bitter lunatic, but this is a great article, one that every Linux user/zealot should read.

First, he goes into the history of why people were souring on UNIX and the various independently-written UNIXalikes. These were mostly individual projects, which really sets the record straight for the people who seem to think that Linus was the first person to do this, and that Linus was somehow the only person intelligent and manly enough to write his own kernel.

At the same time, he lays out the history of UNIX clones, of which Linux was definitely one. It's surprising to me how many people seem to think of Linux as a great, independent OS, and fight so hard to deny that it has roots in UNIX. Of course these people are mostly young and don't know much about computer history. In that respect, this is an educational article.

And, yes, he does talk about the micro vs. monolithic kernel issue, but he does so without fanaticism, and, you know, what he says is generally correct. He's all for small and reliable software, which is something that UNIX was originally but rapidly became the antithesis of. Performance issues, back when people were using 4.77 and 8 MHz desktop processors, well, let's just say that things were different then. Now you have people writing big applications in Python. The real reason Linux ended up with a monolithic kernel is because that's what Linus understood and it was easier for him to write that way.

Re:Backhanded and Grudging

[jjohnson]

I thought it added credibility to Tanenbaum's recounting of the interview, insofar as he was acknowledging the simple fact that Linus wrote Linux without expressing any solidarity with him. It wasn't a case of academics and hackers closing ranks against a hostile interviewer, it was a competitor acknowledging that no wrongdoing had occurred.

It's on the order of Michael Cowpland's acknowledging that Microsoft's undocumented APIs were no threat and no hindrance in the development of WordPerfect because they were just for internal plumbing and of no benefit to someone writing an app on top of them.

Writing a kernel is easy!

[Anonymous Coward]

Writing a simple OS kernel is easy. I wrote one, and believe me, it wasn't that hard. At the university where I am a grad student, we require the undergrads to write most of an OS kernel (including virtual memory and a filesystem) in a one-semester course. I read alt.os.development regularly, and there are high school students who are writing OS kernels. (I'm often depressed by the fact that they are much better programmers than I am :-)

Writing a scalable, production-quality OS kernel is another matter entirely. That takes hundreds or thousands of person-years by talented programmers.

Ken Brown is obviously a complete shithead if he doesn't understand this distinction. AST's rebuttal made the facts of the matter abundantly clear, and I'm sure any competent OS developer he asked would have told him the same thing.

Re:Monolithic versus microkernel

[Laxitive]

There's a little bit more to it than that.

The microkernel idea derives from one basic principle: anything that doesn't need to run in kernelspace, shouldn't be in kernelspace.

There are several hypothetical benefits to this approach. For one, code that executes in kernel space is trusted. You'll notice that a lot of CS academics advocate microkernel architectures. It's because the less you have in the kernel, the easier it is to verify the kernel. The fewer the set of kernel primitives you have, the easier it is to reason about how the kernel will behave. In modern microkernels (see: L4, or it's free variant Fiasco), pretty much the only thing of importance left in kernel space is the scheduler, process management, and a few basic stubs for memory management. Most of the memory management implementation itself is pulled out into userspace.

The other benefit of microkernels is that they allow the system to be more flexible, when designed correctly. For example, having drivers in userspace means that you don't have the Linux issue with having to match driver versions with kernel versions. Another good example is that you _still_ cannot reasonably mount filesystems as a non-priviledged user in Linux. It's not unreasonable to expect that if you have access to a filesystem image, and you have access to the mount point, that you be allowed to extend the mount point with a view into the filesystem that you have control of. It should be possible, but it's not - mostly because the FS core is embedded into the kernel. And yes, there are kernel modules that promote the VFS layer to userspace - and they work pretty well. But there's really no need to have an artificial distinction between userspace FS impementations and kernelspace. There's nothing special about parsing directory and file structures that really needs to be in the kernel.

There are, and always will be, performance hits associated with moving kernel stuff into userspace. You necessarily have to have context switches for message passing - which has to be implemented in the kernel to be trusted in a microkernel design. The question is wether you think the benefits of microkernel design are worth that tradeoff.

I think they are. A 10% hit in performance is going to get eaten up as hardware gets better and faster. But that 50% increase in manageability and flexibility is going to pay dividends well into the future.

-Laxitive

The dog that didn't bark

[maroberts]

Quote from Tannenbaum:
That's when I discovered that (1) he had never heard of the patent, (2) did not know what it meant to dedicate a patent (i.e., put it in the public domain), and (3) really did not know a thing about intellectual property law. He was confused about patents, copyrights, and trademarks.

Do you not find it strange that the President of an organisation involved in arguments about patents, copyrights and trademarks should be so ignorant of patents, copyrights and trademarks?

Re:I like the last bit

[Profane MuthaFucka]

Thirteen years ago, I didn't give a flying FUCK about how outdatated Linus' monolithic kernel was. Remember, we were all running DOS, and desperate to break out of real mode hell.

Arguing about monolithic versus microkernel was like arguing about whether a starving man's meal should be vegetarian or not.

Re:How can Linux be a copy of Minix

[crotherm]

The bitter part comes in the last couple of paragraphs, where he takes the opportunity to say that Linus was a misguided kid who should have paid more attention in class such that he would have seen the obvious superiority of a microkernel over a macrokernel. But he's quick to point out that he and Linus are not enemies.

When I read it, to me it came across as a gentle rub, more good natured than bitter. Alas, when reading text, very often it is hard to determine the mind set of the author at the time of witing...

Re:On second thought

[ca1v1n]

From everything I've read, I'd say Linus is anything but casual about freedom. What he is *not* is an idealist. That's what we have RMS for. He's a pragmatist, exactly the kind of person you want in charge of an engineering project. Perhaps not the person you want at the head of a movement, but that's not what he is. He's first and foremost an engineer.

If you want to "secure our freedoms in the technology space" with F/OSS, you need to actually have F/OSS that works well to convince the 99.99% of the world to whom the need and benefit is not intuitively obvious. If all we had were a bunch of RMS clones, we'd be a lot worse off, because he scares the hell out of business types, who are much more concerned with the economic benefits of F/OSS that Linus Torvalds provides.

We need leaders with a variety of different strengths to spread the message to people with a variety of different interests. Linus Torvalds does an excellent job selling the benefits of F/OSS to engineers. The fact that he lets people like Eben Moglen handle the freedom side doesn't mean that he's causing any harm. If Eben Moglen spent his precious time hacking kernel code, we'd all be worse off.

Re:QNX

[Tony-A]

A 20% performance hit really doesn't matter. Look at the rate of speed increases in hardware. When new systems come out doubling performance at such a regular pace, a one-time 20% slowdown to switch to an otherwise superior architecture with other benefits is an easy pill to swallow.

Good theory. Practice seems to work out differently.

Speed comparisons between products. Seems like 5% difference is enough to declare a clear winner. Unless you look behind the curtain.

Speed increases in hardware? At work I have two computers. I am typing this on NT4 on a 400MHz Gateway. My "other" computer is XP on a 2.4GHz Dell. Other than some legacy dBase for DOS applications the "faster" computer isn't any faster. It does boot faster which means that the XP machine is booted a lot more often than the NT. A 20% performance hit would be the same 20% on both machines.

The quoted improved performance doesn't quite translate into reality. A legitimate 10-times performance (IBM 1410 to IBM 370/135) transated into a 2-times difference in actual throughput. By the way, going the other direction won't work. As a rule of thumb, you will feel 90% of all slowdowns and only 10% of all speedups. This works both directions, like the "uphill both ways" quip.

Re:How can Linux be a copy of Minix

[Tarantolato]

I really have to figure out how to do this scam. Get money from big corporations

They started off taking money from the Swiss. The process seems to go something like this:

1. Get some hack-journalist experience (overfunded and obscure policy journals publish damn near anything; ditto for the Washington Times, as long as it purports to be conservative).
2. Get to know rich people
--a. get cushy internships in college
--b. marry a lawyer at a Big Firm
3. Convince the rich people you know to pay you for hack journalism.
4. Use hack journalism to push dubious foreign-investment schemes
5. PROFIT!!!

The key is that business, academia, law, journalism and government don't really know how to function with one another. They want to, for both good and bad reasons, so a lot of the time they're willing to throw big money conferences, fellowships, publications and "research institutions" that are supposed to grease the wheels.

Added to this, washed-up bigwigs usually want some place to go, and their former friends often set up make-work jobs for them. Lose an election? Why don't you give a lecture once a month at my public policy school. Get shitcanned from your CEO job? Why don't you sit on my government advisory committee. Newspaper column dried up? How bout you be a fellow at my think-tank. And of course, all of these people need gophers, personal assistants, research aides, etc. - a whole industry of suckups scurrying around washups.

The pay is peanuts for the honorees, sometimes even nonexistent. But they like the honorary titles. In exchange, the institution that hands out the titles gets more prestige from having Big Names attached to it. Look at the name-dropping on AdTI website: Jack Kemp, Newt Gingrich (Republicans), John Norquist (Democrat). In turn, the aura of Big Names clustered around an institution makes it easier to sucker donors.

That's basically the scam: laundering prestige for money. All you have to do is Know People(tm).

Why it was brought up

[Synn]

He brought it up because it proves the point that Linus wrote Linux. If he had copied MINIX Linux would've been a microkernel design instead of a macro one.

The fact that Linus wrote Linux "wrong", proves he wrote it and didn't steal it.

Is Microsoft really behind this?

[belmolis]

The nonsense coming out out of AdTI together with Andrew Tanenbaum's description of his interview make me wonder whether the speculation that Microsoft is behind this is really correct. Microsoft has tons of money and some fairly smart people, even in management. I find it hard to believe that they couldn't do a better job than this. Even if they need a putatively independent institution as a front, they could write the material themselves. They could even have their chosen institution hire somebody halfway competant for the project. It's hard to believe that they couldn't do better than this.

I wonder if this is perhaps just somebody trying to make a name for himself and/or bring in money for himself or his institute rather than something directly arranged by Microsoft.

Re:I like the last bit

[smittyoneeach]

I contend with the characterization of the last para as 'ragging'.

The tone I got was of an affectionate tip o' the hat to what is surely one of the all-time classic flame wars.

Besides, when you >make menuconfig, and you go through there and choose whether you want various bits compiled into the kernel or loaded as modules,

isn't that an admission that the 'truth' on the modular/monolithic argument falls somewhere in the mote in the eye of the Tannenbaum/Torvalds Tempest?