The Ghostscript codefest is over now. It went well, I think. We fixed a bunch of bugs, came to understand issues in such areas as embedded controllers for color laser printers a lot better, had a lively discussion about Fitz, and spent a little time hanging out and getting to know each other. I'm convinced that this is quite important, especially when the developers are geographically dispersed.
I got a number of responses on the Billy bookcases, generally expressing disbelief that they really were sold with such a basic defect as the holes drilled in the wrong place. No, they really were. rillian and jack both looked at them, and found pretty direct evidence - for the bolts that hold the thing together, there are two holes; one thinner and drilled all the way through, and one shallow but with greater diameter for insetting the head of the bolt. On correct pieces, the centers align exactly. On the two defective ones, they're misaligned by about a half inch.
I seem to have a knack for getting defective products. Perhaps it's just because it bothers me more than most other people.
I didn't mean to imply that microkernels are bad. In fact, there are definitely some good kernels based on the microkernel idea out there (QNX comes to mind), and a number of even more exciting research projects either based directly on microkernels or inspired by them (User-mode Linux, exokernel and eros come to mind).
What I was criticizing is the belief that, other things being more or less equal, a microkernel will turn out better than a comparable monolithic kernel. Experience now indicates otherwise. In particular, it seems you have to work quite a bit harder to get top-flight performance from a microkernel design. And, the really good ideas from microkernels (modules) have been ported to the monolithic style.
Beliefs of the form "X is a good way to build a system of type Y" are not easy to prove or disprove, because there are so many other variables that affect the quality of the result. If the question is important, the way to settle it is to build many systems using both X and non-X, and see if you can pick out a quality trend. If possible, though, it's better to focus on more crisply testable beliefs.
I'll give an example of one of those: a dynamic specializer is an effective way to get good performance out of highly dynamic interpreted languages. In particular, I was skeptical about Psyco, but at the rate it appears to be going, it looks like it will prove this belief. I hope this demonstrates that "show me the code" is useful for overcoming unwarranted skepticism as well as filtering out junk ideas.