>From what I understand, describing present-day CPUs as either RISC or
CISC is somewhat inaccurate - they combine the best features of both, to
a certain extent. Andy wasn't absolutely wrong or right - the assumption
his prediction rested upon ("RISC vs CISC") simply became untrue.(I also disagree somewhat with your generalization that RISC is somehow inherently "better" than CISC, but that's an argument for another day.) Historical note: Andy Tanenbaum was and is a CS prof. His idea of a good solution for a kernel is probably going to be academically-oriented - is this advancing the state of CS, and does it have an elegant design? Likewise, Linus' definition of a good kernel (he was a student when he started Linux) is going to be student-and-user-oriented - is it easy to develop, and is it easy to use? Advancing the state of CS is not such an important consideration. Also, in Andy's defense, he was spot-on about the portability issues. Don't get me wrong, I'm not in love with the guy, but I often feel like he gets derided a little more than he should on this topic. -DMZ On Wed, 2005-12-21 at 12:29 -0500, David Eisner wrote: > Rob wrote: > > statements that it makes me question his general sense. Just because > > someone had the free time to sit down and write an OS, and was able to > > follow it up with the goodness of their heart to release it for free, > > doesn't make their words gospel. > > > > I agree, but history seems to have favored Linus in the great Linus v. > Tanenbaum debates, don't you think? > > Tanenbaum: " Once upon a time there was the 4004 CPU. When it grew up > it became an 8008. Then it underwent plastic surgery and became the > 8080. It begat the 8086, which begat the 8088, which begat the 80286, > which begat the 80386, which begat the 80486, and so on unto the N-th > generation. In the meantime, RISC chips happened, and some of them are > running at over 100 MIPS. Speeds of 200 MIPS and more are likely in the > coming years. These things are not going to suddenly vanish. What is > going to happen is that they will gradually take over from the 80x86 > line. They will run old MS-DOS programs by interpreting the 80386 in > software. (I even wrote my own IBM PC simulator in C, which you can get > by FTP from ftp.cs.vu.nl = 192.31.231.42 in dir minix/simulator.) I > think it is a gross error to design an OS for any specific architecture, > since that is not going to be around all that long." > > I held my breath waiting for the x86 architecture to die. RISC *was* > clearly superior to CISC. But, as we now know, x86 chips became RISC on > the inside, and we're still using them today. Not such a "gross error" > after all. > > As far as microkernel architectures, Tanenbaum again: "MINIX is a > microkernel-based system. The file system and memory management are > separate processes, running outside the kernel. The I/O drivers are also > separate processes (in the kernel, but only because the brain-dead > nature of the Intel CPUs makes that difficult to do otherwise). LINUX is > a monolithic style system. This is a giant step back into the 1970s. > That is like taking an existing, working C program and rewriting it in > BASIC. To me, writing a monolithic system in 1991 is a truly poor idea." > > Linus, on the other hand, seems to have had more of a "That would be > nice, but the monolithic kernel approach is something we can do now." > This is sometimes a poor argument, but not always. How many of us are > using GNU Hurd? One could argue, I suppose, that had the manpower that > went into Linux gone into Hurd, this would be the UM-HURD list. But I > get the impression efficient message passing is harder than people > realized. Are there any widely used operating systems today in which > the filesystem, I/O, and memory management do not run in the same > address space as the rest of the kernel? > > -David > > > > One of my favorites is : > > > > http://people.fluidsignal.com/~luferbu/misc/Linus_vs_Tanenbaum.html > > > > >From Andrew Tanenbaum (OS instructor who wrote the book Linus used to > > create Linux): > > > > "I still maintain the point that designing a monolithic kernel in 1991 > > is a fundamental error. Be thankful you are not my student. You would > > not get a high grade for such a design :-)" > > > > Granted, loadable kernel modules duck most of the issues with monolithic > > kernels, but they didn't exist at the time. > > > > - Rob > > . > > > > > >
