tech/TanenbaumWrong written at 23:05:46; Add Comment
Tanenbaum was wrong in the Tanenbaum-Torvalds debate
One of the reactions to the Stackoverflow question that asked why Tanenbaum was wrong in his predictions for the future in the Tanenbaum/Torvalds debate was for people to say that Tanenbaum was right or mostly right (although not as fast as expected). This is incorrect.
The question quotes three Tanenbaum predictions:
The usual defense of the first prediction is to point to the growing use of virtualization hypervisors and claim that this counts. It doesn't; hypervisors are not microkernels. Neither are kernels with loadable device drivers and other sorts of modularity; well structured kernels are not anywhere near the same thing as microkernels. When Tanenbaum was talking about microkernels here, he really meant microkernels.
I've seen two defenses of the second prediction. The first is to point to the growth of ARM-based devices, and the second is to note that the microcode and internal execution units of x86 chips are increasing RISCy; the x86 instruction set is sort of a CISC frontend to a RISC. To mount either defense either misses or deliberately ignores the historical context of Tanenbaum's prediction (and ignores the first part of it). At the time he made it, Tanenbaum was clearly predicting the replacement of x86 chips and the ugly x86 architecture in general purpose computers by RISC chips. He was not making a wide-ranging prediction about a future world with lots of smart devices (many of them RISC-based), and he was not predicting the future of the inner bits of the x86 implementation. He was predicting that your desktop computer, your laptop, and your servers would all use some RISC chipset and not run x86 code. This has clearly not come to pass and doesn't seem likely to come to pass any time soon.
Anyone who wants to argue that the growing number of Android devices is starting to validate Tanenbaum's third prediction is similarly misreading it. In the time and place Tanenbaum made the prediction, he did not mean 'in non-computer smart devices', he meant on your computers (desktop, server, etc). Even if we allow Linux to meet his criteria (which is unlikely to be what he meant at the time, since he was arguing against Torvalds), this is a clear failure.
(I'm ignoring the time limit given in the third prediction for fuzzy reasons. If you don't, the prediction clearly and unarguably failed.)
PS: I don't think that we should be harsh on Tanenbaum for getting these predictions wrong. Among other reasons, remember the context of the entire thing; Tanenbaum was having a casual argument on Usenet, not conducting a carefully thought out academic debate. Only through an odd series of happenstances has this episode been exhumed years later to be scrutinized minutely.
tech/HypervisorVsMicrokernel written at 02:39:54; Add Comment
Hypervisors are not microkernels
As a result of a Stackoverflow question on the Tanenbaum/Torvalds debate I got to see a certain number of people claim that (virtualization) hypervisors are more or less microkernels, certainly enough so to make one of Tanenbaum's predictions (ultimately) correct. This is wrong. It's true that hypervisors and microkernels can both sit 'underneath' normal monolithic kernels as a low-level layer, and both can potentially be 'small' for some vague definition of small. But those are about the only solid points of similarity, and once you look at their purposes and how they are supposed to be used they become very different.
Microkernels are intended to create a minimal set of low-level operations that would be used to build an operating system. While it's popular to slap a monolithic kernel on top of your microkernel, this is not how microkernel based OSes are supposed to be; a real microkernel OS should have lots of separate pieces that used the microkernel services to work with each other. Using a microkernel as not much more than an overgrown MMU and task switching abstraction layer for someone's monolithic kernel is a cheap hack driven by the needs of academic research, not how they are supposed to be.
(There have been a few real microkernel OSes, such as QNX; Tanenbaum's Minix is or was one as well.)
By contrast, hypervisors virtualize and emulate hardware at various levels of abstraction. This involves providing some of the same things that microkernels do (eg memory isolation, scheduling), but people interact with hypervisors in very different ways than they interact with microkernels. Even with 'cooperative' hypervisors, where the guest OSes must be guest-aware and make explicit calls to the hypervisor, the guests are far more independent, self-contained, and isolated than they would be in a microkernel. With typical 'hardware emulating' hypervisors this is even more extremely so because much or all of the interaction with the hypervisor is indirect, done by manipulating emulated hardware and then having the hypervisor reverse engineer your manipulations. As a consequence, something like guest to guest communication delays are likely to be several orders of magnitude worse than IPC between processes in a microkernel.
Or in short: writing a microkernel style OS on top of a hypervisor is pretty clearly an absurd notion. This shows that hypervisors are not a species of microkernel.
(I'm sure this is plenty obvious to most people as it is, but I feel like writing it down here in order to be explicit.)
* * *
Atom feeds are available; see the bottom of most pages.