For the last couple of weeks, my bedside reading has been this half-biography, half-autobiography on Linus Torvalds. I have to say, however, that the book is like two books mixed into one. Chapters alternate between Linus talking about his life and about big moments in Linux’s history to David Diamond describing modern-day Linus with a kind of forced wonder. Truthfully, Diamond comes off as a sycophant who could care less about Linus’s flaws and positive characteristics, and cares more about molding some kind of “image” of Linus as containing a humility and genius simultaneously. Near the end, I started only skimming the chapters not written by Linus. Diamond’s really not a good writer, either. (Sorry Dave.)
Truthfully, the book kind of pops the lid off Linux and makes you understand it as much less glamorous than say Wired Magazine described it to the public. Linus really just talks about not having a social life, sitting in his room with curtains covering his window, coding all day. Not exactly the ideal role model, I think. Don’t get me wrong, I love the Linux kernel (as much as one can love imperfect software), and Linus made a great contribution toward keeping the UNIX world and UNIX principles alive, but it’s just that I like to think of open source developers as something other than the stereotypical, introverted geek. In fact, much of Linus’s chapters is devoted to his apprehension about giving a public talk about Linux. When I think about the fact that I’ve given three or four of them to date, and enjoy it more every time, I see how different I am from this kind of stereotypical geek.
It also kind of made me dislike Linus. When I saw Revolution OS (a DVD on the rise of open source), the movie kind of endeared me to Linus’s practical nature as opposed to Richard Stallman’s religious idealism. I like idealism, but Stallman is really religious about it. And he’s bitter. Linus, on the other hand, has that great Northern European, “I’m just gonna go with the flow” attitude.
But this book made me realize that Linus is religious is his own sort of way. Included in the book is Linus’s flame war with Andy Tanenbaum on monolithic versus microkernel designs. Truthfully, I’ve studied operating systems and I’m not even sure which design is best, and Linus makes a decent argument of why microkernels end up being just as complex, or more complex than monolithic ones. But what I didn’t like is that in the flamefest, Tanenbaum said that deficiencies in MINIX were due to it being a hobby, and that he had duties as a professor. Linus responded, “Re 2: your job is being a professor and researcher: That’s one hell of a good excuse for some of the brain-damages of minix. I can only hope (and assume) that Amoeba [Tanenbaum’s future OS project] doesn’t suck like minix does.”
This just shows me that Linus really is an asshole sometimes. He states this outright in his book. So now, truthfully, I may like the open source movement, but I think I “at least dislike” two of its most major players (Torvalds and Stallman).
Finally, I think a clip from Tanenbaum’s website points out a nice principal in OS design:
Also, Linus and I are not “enemies” or anything like that. I met him once and he seemed like a nice friendly, smart guy. My only regret is that he didn’t develop Linux based on the microkernel technology of MINIX. With all the security problems Windows has now, it is increasingly obvious to everyone that tiny microkernels, like that of MINIX, are a better base for operating systems than huge monolithic systems. Linux has been the victim of fewer attacks than Windows because (1) it actually is more secure, but also (2) most attackers think hitting Windows offers a bigger bang for the buck so Windows simply gets attacked more. 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.
I agree. But does a microkernel design actually reduce the overall size of the operating system, or does it just reduce the size of whatever you consider to be the “microkernel”? That is, just because a file system is implemented as a file system daemon talking to a driver subsystem through message passing doesn’t necessarily mean the file system, or driver subsystem, are secure. Insecurity could exist even at the boundaries, no? Not to mention instability.
I think Linus and Tanenbaum have to agree that this debate isn’t an open and shut case. The best kernel is probably one that mixes modularity, a strong kernel/userspace boundary, and some of the fancier features of a microkernel approach, while not sacrificing elegance of design or performance.
“That is, just because a file system is implemented as a file system daemon talking to a driver subsystem through message passing doesn’t necessarily mean the file system, or driver subsystem, are secure. Insecurity could exist even at the boundaries, no? Not to mention instability.”
Yes, but a crash in a file system daemon will not necessarily cause a GPF or kernel panic.
You may lose the file system, but the protection boundary between the FS and kernel will isolate the kernel from the fault. So at worst it requires re-initialization of the FS daemon.
Right. But does that really buy you anything? If the file system daemon crashes because of some non-standard format in the bits and bytes underlying the logical organization of files and folders, don’t you think the crash will just keep happening every time that read/write occurs, in which case even re-initialization of the FS daemon still gives us an unusable system. I also think that just because writing file systems as a daemon (which still has good performance) is more error prone means it will be less stable. The threat of a GPF or kernel panic in the monolithically-implemented puts pressure on developers to make sure that doesn’t happen. The fact that a more stable FS layer is easier to implement in a monolithic kernel helps. And I think experience with modern-day FS layers (ext3/reiser in Linux) show that FSes end up being pretty stable even in the monolithic world.
Truthfully, I don’t think microkernels lead you to security or stability. They may have other benefits–like making code more maintainable and approachable, two benefits for the open source world, but we’ll see how that goes.
I actually really like the design of so-called ‘exokernels.’ My major operating systems course in school had us hacking on one such exokernel called ‘jos’, although we never implemented the crazy features that make exokernels fun, namely writing ‘libraries’ that implement traditional kernel functionality. I think the exokernel approach essentially builds upon the microkernel wisdom (keep the main kernel small), but also makes the code more manageable. Instead of daemons which talk to the kernel via message passing, you have the kernel be just another library that ‘exports’ resources of the hardware to application writers. If you want your own file system, you simply create your own ‘libFS’, and override the user’s general purpose file system with your own for that application.
The benefit is that you still get all the traditional UNIX applications running, but you can do things like code your own web server (with your own optimized network stack and file system) which will be much faster than Apache/equivalents running under traditional monolithic kernels.
There’s a great slide show on this (from 1998, but still quite valid) here:
http://pdos.csail.mit.edu/exo/exo-slides/index.htm
Thanks for stopping by.