He seems to have a pretty "exotic" view of NAT and P2P, that's for sure. Point by point...
While waiting for IPv6 to mature, some people decided to design a time-stalling tactic that would ensure IP address space did not run out. This is where NAT comes in. I think NAT worked well to keep the Internet going and it also attracted the telecomms world to adopt the Internet as it gave them "walled gardens" and they were able to sell their IP address space on to customers who had to connect through them. So it has attracted a bigger Internet community.
Most people didn't adopt NAT for that reason, and in fact wouldn't even know what you meant if you told them about an IP-address shortage. Many consumers use NAT because their ISP would only give them one IP address. That's not going to change going from IPv4 to IPv6 without other structural changes at the ISPs. They're just not set up to track multiple addresses for one customer, no matter what kind of addresses those are. Their databases only have one field for that, and that one field gets used to seed their MAC filter etc. Where's the incentive for them to accomodate this guy's wishes?
Another reason many people use NAT is for security. Never mind whether they actually achieve greater security; they believe that they do and that reason is distinct from concern over an address shortage.
When you look at the traffic on the Internet, 72 percent is peer-to-peer, so that is what people want. People think 'I want to send a piece of music directly to a friend. I don't want to pay someone else to do it for me.' At the moment peer-to-peer is facilitated by a server. We need to use that server in order to talk to each other. With IPv6 we won't need that server anymore. We will each have our own IPv6 address open all the time and can decide who to publish it to. We will in effect each become little ISPs and we decide who will connect to us and who won't.
What part of "peer to peer" doesn't he understand? Why does he think it's called that, instead of "client to server"? The whole point of P2P is that there's no such thing as a server. Also, again, he doesn't seem to understand why people use P2P systems. It's not just about getting content, which we've all been able to do via FTP for ages. It's also about storing multiple copies in multiple locations so that it will still be there despite a failure of a single node, and about finding it in one or more of those multiple locations, and about downloading pieces of it from multiple locations to maximize speed, and about keeping it all anonymous, etc. None of these are addressed by a switch from IPv4 to IPv6. Yes, NAT traversal is an issue that people have to deal with when they adopt P2P, but it's not the reason they did so in the first place.
It's wonderful that this guy is beating the IPv6 drum, because there are legitimate reasons why we should switch to IPv6. However, he should not let partisanship lead him into misrepresenting the facts.
Internal state transitions to an application are not verified, merely the externally visible communication transitions. Strong typing gets you closer to compiler verification of correctness. Dependent types would get you even closer. A built-in proof system could get you all the way there (if a bit tediously). The Singularity communication protocol verifier has the potential to also get you closer if the software component happens to be tightly coupled to a communication protocol.
The software components in Singularity are tightly coupled to a communications protocol over a channel. That's the whole point. It's precisely those internal transitions that can be verified. It's the external (to Singularity) ones like HTTP that can't, but that hardly makes the verifier useless. You can say "not what I was originally concerned about" and "irrelevant to the issue at hand" and "not the class of bugs I was describing" but anyone reading this exchange can see you're lying. Those are exactly the things what you were concerned about, and your claims about them have all been wrong. No number of red herrings or whines about how you're being treated change that. You simply should have read and tried to understand the paper before you spouted off, and you didn't. Be smarter next time.
every personal attack you make and every strawman you propose just makes you look more ignorant and childish.
That's rich, coming from someone who has repeatedly been caught making false statements and won't even admit it. At least my responses have some actual content, even if I do let my annoyance show. I'd rather be rude than a liar.
You are classifying "algorithmic" bugs as the superset of all types of bugs
I am doing no such thing. You're the one who first referred to "algorithmic bugs" so why don't you define it? Until you do, I'll assume the intuitive meaning of bugs that represent high-level logic errors (e.g. deadlock/livelock, indefinite postponement, race conditions) as opposed to low-level implementation artifacts (e.g. incrementing the wrong variable, fencepost errors).
Returning to my original example, a web server which incorrectly dispatches to a POST handler on a GET request has performed an invalid application state transition, even though the protocol state transition was valid. My original statement, stands: the verifier can do nothing about this sort of bug.
Your statement stands as false, no matter how much you rely on argument by repetition. Dispatching to the wrong handler will often lead to generation of an invalid response, which can very much be caught by a verifier. This is less apparent in HTTP than in other protocols because HTTP was designed by an amateur, but it can still manifest in the form of invalid error codes or reply headers. In a better protocol it might be blazingly obvious in the form of a POST_REPLY to a GET request or GET_REPLY for a POST. Even if that weren't the case, the fact that there's one error a verifier could not detect in no way proves your claim that a verifier can do nothing. You still seem to be struggling with that distinction between "not every" and "none" don't you?
But this distinction does not exist in the software world; there are no "external" entities, merely interfaces to "other objects".
Yes, I'm sure a lazy app programmer who doesn't understand how protocols are implemented might think that. I'm not going to address that further because this distinction of protocols is a big red herring. It doesn't change whether your claim about verifiers not being able to do anything about protocol or "algorithmic" bugs is true or not.
Why would you assume I'm not fluent in English?
Because you have demonstrated repeatedly during this conversation that you have trouble not only with technical terminology but with basic language such as "not every" vs. "none" which would be quite obvious to most people. Granted, though, it might not be a language thing. There are other explanations.
Not everyone who disagrees with you...is an idiot.
There's that problem with "not every" again. No, not every person who disagrees with me is an idiot. That doesn't mean that none are, and the example that illustrates the distinction apparently thinks having the last word really matters. Go ahead. I'm done with you. You were wrong about Singularity not being a single-address-space OS, you were wrong that type and memory protection were the only guarantees, and you've been wrong on every secondary point since - even the irrelevant ones. You're obviously here just to argue, not to participate in any exchange of ideas.
The original statement stands: an application can indeed be left in an "invalid state" following a communication and the verifier cannot catch these sorts of bugs.
Wrong again. It cannot catch all of these sorts of bugs, and nobody has said that it could. I even provided some counterexamples four days before this thread started. Your statement, though, was that a verifier can do nothing about such bugs. "Nothing" is an absolute negation. Since you're being such an ass about this, I'll reduce it to purely logical terms. Let X be the set of algorithmic errors, Y the subset of protocol errors (according to the definition used by myself and the Singularity team), and Z the set of errors that can be caught by a verifier. Your statement was that the intersection of X and Z is empty - not small, but empty. The Singularity paper shows that the set of Y and Z is not empty. Because Y is a subset of X, that means your claim must be false. It doesn't matter one bit whether there are bugs that are members of X but not Z, i.e. other kinds of algorithmic errors. No matter how many times you come back to it, that remains a red herring.
Only a system programmed fully with verification proofs can make guarantees about total correctness in the face of changing state.
That is not in dispute but, again, you are confusing "not all" with "none" and are guilty of moving the goalposts. We're not talking all or nothing; we're talking about zero vs. non-zero.
perhaps you can clarify what you mean by HTTP being an "external protocol". Do you only mean that it does not use the platform's built-in protocol mechanisms? Hate to break it to you, but most of the world is composed of protocols of this nature.
Either you're the stupidest person on Slashdot (quite an achievement) or you're playing dumb to red herring to distract from your previous dishonesty. An external protocol is, quite obviously, one that is used to communicate with an external entity - i.e. on another box, running a different OS image, accessed via an external network interface. You can look on the back of your machine and see one of those if you're still confused. The world is not, in fact, composed only of such protocols, but many think so because they generally only hear the word used in that context. What you're unaware of is that there are protocols running within your system as well. There are CPU/memory-bus protocols and I/O-bus protocols which can actually be quite complex and are often studied using the exact same tools as are used for the more familiar kind of network protocols. There are also protocols within software that are often not recognized as such but can be treated that way for purposes of verification. "Call open() to get a file descriptor and then pass that to read()" is a protocol, and automated tools can check e.g. that you don't call read() before calling open() or free() before calling malloc() etc. almost ad infinitum. Protocols are actually all around you, and only your own narrowness of vision prevents you from seeing that.
I'm sure you agree that every quote is a selective quote.
It's selective in the sense of argument by selective observation. I realize you're not fluent in English, but please at least try to understand people before you disagree with them.
I say "algorithmic errors". You say "protocol errors". We are not saying the same thing. Example: a SIP receives an HTTP GET request. It incorrectly parses it as an HTTP DELETE request. Is the verifier going to catch that? This is an algorithmic (programming) error. In the absence of a proof system that understands the HTTP protocol, a verifier/compiler will not be able to catch these sorts of bugs.
So unless the verifier can catch all algorithmic errors, it's worthless? Bullshit. You said type and memory safety were the only guarantees. Key word: only. A single existence proof is sufficient to refute that, and that existence proof is right in the paper. What is meant by protocol error is also quite clear from the paper - it's a protocol between components in the system (not one handled externally like HTTP) expressed as state transitions forming a channel contract. It really is right in there. It's what distinguishes Sing# from Spec#. The verifier can catch those errors, and the fact that it's a subset of all algorithmic errors is a red herring. Your statement remains false.
nowhere did I drag EROS into it (except in addressing the original EROS claim)
...and that doesn't count because...? Oh, because it's not convenient for you. Because disavowing it, however speciously, gives you an opportunity to play "I'm rubber, you're glue" games. Grow up.
I asked you two posts ago to define "invalid state transition" so that we could have a common understanding
Read the damn paper. They're very clear about what they're referring to...oh, forget it. You obviously won't accept anything that undermines your position unless you have no choice, so I refer you to the description of channel contracts on page 15 of the document:
a contract specifies the allowable message interactions via a state machine driven by send and receive actions
A send and receive action inconsistent with this state machine is therefore quite obviously an invalid state transition. Should I define "state" and "transition" for you now, or is that enough?
I'm confused why you would consider citing quotes from the actual source a bad thing.
Quoting a source in good faith is a good thing. Selectively quoting or misquoting is not. Clear enough?
Look again at what you just quoted. Here, I'll even help you by highlighting the part you obviously skipped over.
The Sing# compiler checks type safety, ownership rules, and protocol conformance during compilation.
What do you suppose "protocol conformance" means? It means avoidance of exactly the kind of invalid state transition that we've been talking about. Your claim that "there is nothing a verifier can do to prevent this" is clearly false since the verifier can and does prevent the module from compiling if it contains such errors. Likewise, while the safety guarantees are by no means complete (I've already pointed out the lack of coverage for both livelock/deadlock and indefinite postponement as a result of component failure in posts here and on my website), there are clearly some guarantees beyond type and memory safety so your statement above is also false.
You're letting bias get in the way of understanding what you're looking at, naasking. Please take off the EROS-colored glasses for a moment and actually look at what Singularity is doing instead of just trying to mine the document for quotes that you (wrongly) think support your predetermined position.
Look again. SIPs are explicitly defined as "closed object spaces, not separate address spaces" that "do not rely on memory management hardware for isolation."
From the application perspective, if it contains an algorithmic error, the state transition may trigger a bug, so a message may induce an incorrect state transition. There is nothing a verifier can do to prevent this.
Look again, this time at the section on Sing# and Boogie which do plenty to prevent this.
f someone makes an incorrect statement, I will correct them. I would expect nothing less.
from your postings, it is evident that your emphasis is the opposite: you view the specific fault isolation mechanism as an unimportant implementation detail and think that the architectural ideas are what matters.
Actually, any rational person who looked at my postings either in this thread or on my own site would come away with the exact opposite impression. I think fault-isolation mechanisms are a very important aspect of OS design, which is why your idea of running an interpreted or JIT-compiled language in the kernel is ridiculous. The performance and complexity implications are simply unacceptable.
the fact that you think that a tech report about a half-finished implementation constitutes "proof" of any form illustrates a fundamental problem with operating systems architecture research: it's still all a bunch of handwaving
The very fact that you don't realize when your own arguments have been disproven shows that you're the one doing the handwaving - but it could hardly be any other way when you're commenting on a domain where you've never done any actual work. You claimed that microkernels had to be based on hardware protection; Singularity is clearly a microkernel and everyone recognizes it as such but it has no such dependency. You assumed that a complex runtime is the only way to maintain language safety guarantees; Sing# and SIPs prove you wrong. I've been very clear that the progress on Singularity so far doesn't prove that they've found the One Best Way to write an OS, but they have done enough experiments and provided enough analysis to disprove your claims and assumptions. You're simply full of shit when it comes to operating systems, idlake. Stick to whatever it is that you know, which seems to be very little, and let the grownups do the real work.
at issue is developing kernel modules in an unsafe language without reflection, without class loaders, and without garbage collection.
In Singularity, class loaders are essentially [i]verboten[/i], reflection is compile-time, and garbage collection isn't what you're used to either. Furthermore, they run fully native code, not interpreted or JIT-compiled. In fact, they do a pretty good job of proving you wrong on just about every point you made in the previous thread, so maybe you shouldn't be trying to cite their experience as support for your still-broken ideas about OS design.
I don't want to re-hash our previous argument on this subject, but the above statement is trivially falsifiable. Singularity is built on a microkernel. EROS is built on a microkernel. Anything that can be built on Singularity, can be built on EROS, including verifiers, virtual machines, Software Isolated Processes, etc.
EROS has a default mechanism for isolating faults and loading untrusted code in the absence of any safety guarantees: the constructor.
I was also involved in that previous discussion (in fact your post there was spawned by one of mine) and I think idlake is on the right side this time. The EROS architecture still relies on hardware memory protection between processes, which is a fundamentally different paradigm than a single-address-space OS that uses either compile-time or load-time verification to guarantee safety. In addition, the EROS contructor does not provide any of the higher-level guarantees (e.g. regarding invalid state transitions) that Sing# does via the "Boogie" verifier. Yes, you could build all the important parts of Singularity in EROS (and vice versa) but the result would be more of a emulation or virtualization like User-Mode Linux than like a single OS. The hooks just aren't there to fuse the two approaches into a coherent whole.
There's nothing wrong with EROS, and there's nothing wrong with Singularity. They can both help us learn different things. Pissing contests about which one trumps the other are just pointless and childish.
I already wrote about this four days ago so I won't repeat the whole thing here. Short version:
Microkernel design, single-address-space implementation: good
Extensive compile-time checking of code that eventually runs native (not interpreted/JIT): good
Checking protocol behavior as well as lower-level function contracts: great
No deadlock/livelock checking: ok for now (it's a hard problem)
No checking of responses to component failure: oops
Not even a mention of making it distributed: weird
Even shorter version: lots of great ideas, lots of work still to be done. Anybody with a clue about operating systems should be following this with interest.
The governemnt has alot of stuff that falls inot the catagory of IP wich isn't released to the general public.
...and many people, including myself, believe that should not be the case. In fact, copyright law explicitly denies protection to those whose work is done directly for the government, and there have been attempts to extend that to cover grant-funded research. Patents are, unfortunately, not subject to the same requirements for open access. Obviously there are reasons to keep certain information from becoming public, but granting patent/copyright protection to the fruits of government work so that the government can make a profit from them is wrong. If my tax dollars paid for research I should be able to apply it, and whoever proves to be the best competitor in bringing it to market - not whoever has the best access to the halls of power - should profit most.
Don't call bullshit unless you have Clue One what you're talking about, coward. "Intellectual property" refers to copyright, trademarks, patents etc. - not to state secrets, private conversations, or just any old kind of knowledge that happens not to be widely known. The two are easily distinguishable by which section of US Code is invoked. Now run along and leave the grownups alone.
Because the government is supposed to represent the people, and therefore not to hold any exclusive IP. As others have pointed out, though, this is not an IP issue. Using the seal is more akin to copying someone's signature than copying their trademark, and it's forbidden by other laws. That doesn't mean that the government's action in this case is right or a good use of taxpayer money, but it's necessary to understand which laws and principles are involved before we can make that determination.
I hope you have a good rear-view mirror while you backpedal.
it's the C/asm implementation and using separate address spaces that necessarily follow from that
...except that they don't. Microkernels have been implemented in other languages, and it has already pointed out to you that they have been implemented in single address spaces.
Drivers usually take more code since they often have large tables in the code
...and you base that statement on...what? It's no more true of drivers than the rest of the kernel. You also fail to note that almost everything under fs/ and most of net/ is really driver code too.
I'd say it's a pretty safe bet that the vast majority of the code in a running kernel is not drivers.
By your own count, which is flawed, over 70% of the code is drivers. By a more realistic count it's likely to be 85-90%. Many would say that's the real metric of code size, since that's what has to be debugged and accounted for in designs. It's true that the percentage of code loaded into any given instance of the kernel is likely to be lower, but that actually highlights an interesting point: loadable modules represent an evolution toward microkernel ideas. In the Bad Old Days vendors shipped truly monolithic generic kernels, and then users would configure and relink for the devices they had. I don't recall offhand whether Linux was originally that way, but I think it was and I know for sure that BSD was. Even though they're loaded into a common address space, loadable drivers are very much a microkernel idea. Even process and I/O schedulers can be loaded nowadays, which moves us further in that direction (leaving little but the VM system). Now that they're widely adopted the majority of code that's loaded might not be drivers, but it's still not a vast majority and the majority of instructions during any given time quantum might well be drivers of one kind of another. By two out of three metrics - written, loaded, run - drivers are the majority of code. It's lovely that you could write a script to count lines, but it would be even better if you could understand the numbers you were looking at before you make more false claims.
You know, all that would be interesting if it wasn't blown out of the water by the existance of machines that used a high level language as the operating system.
Implementing code in an HLL (a compile/link time decision) is not at all the same as running it in a "managed code" type of environment. Those LISP machines (LMI, Symbolics, or Xerox) compiled down to what the hardware understood, thereafter not requiring software mediation to do whatever it was they needed to do. As I'm sure you know, code runs faster directly on hardware than on top of an abstraction/emulation layer to translate between its interface and the hardware's. Yes, I know about JIT compilers but they don't fully solve that problem. Furthermore, those LISP machines ran on hardware specifically designed for that mode of operation. That's a far cry from today, when the most common processors on people's desktops or in their devices are not so narrowly targeted to running specific languages. Go ask a CPU designer about undoing the RISC Revolution and going back to "high level" processors like the iAPX432 or the various Burroughs stack machines. Those guys could always use a good laugh.
Just because something can be done doesn't mean it should be done. Yes, we can implement monolithic kernels that run on special-purpose processors with all of the important primitives those kernels need implemented in hardware (which would be equivalent to implementing a microkernel in hardware). There might even be certain applications for which that would be a good idea - e.g. the same applications already using FORTH or "BASIC stamp" chips. For general-purpose computing with the expected complement of speed and bus-interface compatibility and virtual memory and multiuser protection, though, it would be an incredibly poor design choice.
It's pretty amusing to hear such "back to the 70s" suggestions from those who have the gall to accuse others of being old-fashioned.
Perhaps you would care to define what you consider those "microkernel design principles" to be? Be sure to contrast them against object oriented programming, active objects, and message passing.
Oh, I get it. I'm supposed to distinguish microkernels from other things only in terms of aspects you dislike, allowing you to appropriate anything you do like for "your side" of the debate? Sorry, not falling for it. As I said earlier, both microkernels and OOP are variants of the same basic concept: modularity. Like one, like both. Hate one, hate both. Making arbitrary distinctions for the sole sake of hyping one and dissing the other is dishonest.
Monolithic kernels written in languages like Java make it impossible for components to "twiddle" each other's data
Then such a kernel's not very monolithic, is it? Idiot. What do you call that piece of code that takes care of loading classes and dealing with reflection and garbage collection and other forms of inter-component mediation and safety enforcement in your microkernel-less utopia, Mr. Smartass? Oh, right. It's a microkernel. Sheesh.
Conversely, microkernels frequently "twiddle" each other's data--they just do so by sending requests to do so.
Oh, so Java objects can't exchange messages, or implement trivial getter/setter methods? Yeah, right. The kind of twiddling you mention is trivially possible in any language or environment, whether it be C or Java or Linux or QNX. I've even written about that problem. ..twice, and both before you showed up to be educated. Attributing a problem only to one paradigm when it applies to both is, again, dishonest.
You're just lucky I'm not charging you my usual hourly rate for being your own private tutor. You couldn't afford it, and will never be able to while you have more attitude than knowledge.
Experience with Mach, Hurd, Darwin, and Minix shows that this is clearly not the case: many common microkernels have proven to be more difficult to extend and maintain, to be less robust, and to perform worse than monolithic kernels.
How unscientific of you, to draw such an unrelated conclusion from that data. The operating systems you have mentioned have been less prevalent in the marketplace. They have had smaller numbers of users and, more importantly, engineers working on them than, say, Linux. That does not in any way demonstrate that they are more difficult to extend and maintain, as there are plenty of other reasons for what has happened in the market. How do you know that they wouldn't be even more marginal than they are had they been designed as monolithic kernels, or that Linux wouldn't be even more successful if it had been designed as a microkernel? What actual evidence do you have to say otherwise? None.
Microkernels are an attempt to overcome the problems with unsafe, static runtimes and languages by putting components into separate address spaces
Wrong. Shared vs. separate address space is an implementation choice; microkernel vs. monolithic is a design choice. That microkernels are typically implemented using separate address spaces is irrelevant. If you had actually worked in operating systems you'd also know that totally shared vs. totally separate are not the only options for address-space relationships. Linux's process/thread/address-space model is based (without attribution, naturally) on something called nUnix, which Dave Mitchell implemented and I inherited at Encore before Linux existed. One of its key ideas is/was that parts of a process could be shared without having to share everything. SysV's shared memory goes back even further than that. Even within the kernel one can implement some forms of inter-component memory protection without resorting to completely separate address spaces. Been there, done that. I was the one who wrote code at Encore to let two operating systems run side by side in the same box, on separate sets of processors with separate memory and exception vectors and - most importantly - so that a memory fault in one wouldn't take the other down. That was done in a slightly different context (one was an RTOS and the other a GPOS) but the same techniques could just as easily be applied to a microkernel.
If you have a safe, dynamic runtime, you don't need a microkernel architecture.
And how is that "safe, dynamic runtime" not itself a microkernel?
Among software developers, people like you are among the last holdouts that think it's OK to write millions of lines of C code with ad-hoc self-invented object-like dispatch tables and manual storage management.
Yeah, I'm such a dinosaur, working here in what is acknowledged as one of the leading-edge areas of the storage industry, implementing a highly available distributed system. Riiight. What do you do that anyone should remember you for, Mr. Expert? In actual fact I don't think it's a good idea to write "millions of lines of C..." when one has a choice. If I were to design another microkernel it would be every bit as current in terms of software-engineering methodology as anything you've ever done, but that doesn't mean it would be implemented as a "managed code" environment. I understand the concept of informed tradeoffs as opposed to mere uninformed dogma. I produce working and shipping systems based on that. Come back when you've done likewise.
Instead of making it easier for people to modify the kernel, they try to keep it some obscure art form.
OS development doesn't need to be made hard; it's inherently hard. In an OS, everything you do has to be done with an eye toward reentrancy and concurrency, performance and minimal resource consum
You safe-kernel naysaysers act like writing kernel code is hard. It isn't. It just takes a lot of patience and diligence (mostly because it's in C). It's not like there's anything CS-hard in the linux kernel.
The classic response of someone who has never actually done any serious kernel work. Just because it's not CS-hard doesn't mean it's not real-world-hard, and I think I know a bit about that because I've been solving problems that are hard in both senses for quite a while. Your use of "naysayer" only gives away your own bigotry. Think about what "safe" means in that context. It means that the code doesn't have direct access to underlying resources, with that access then done on your behalf by "someone else" but there is no someone else when you're the kernel. Those "safe" environments require exactly the kind of performance-robbing intermediation for which you criticize microkernels; in a way, what you're proposing is actually a microkernel of a different (and inferior) sort. Do you want to have every PCI-register access trap to a safety-guaranteeing handler? If you don't see how badly that would suck, grow a clue.
Compile-time safety checks are a wonderful thing, and I've applied cutting-edge forms of that technology in both kernel and user work. The run-time checks of your "managed code" utopia, though, are simply impractical for an OS kernel.
there has been excellent prior work in that area, with fault isolation in single-address space kernels; experiments suggest that single-address space approaches are significantly faster.
Yes, and some of the more performant microkernels do share address spaces. Don't confuse microkernel design with microkernel implementation. It's entirely possible to adhere to the design principles of a microkernel, perhaps even prototype or test using separate address spaces, and then implement a version in which components run in a single address space - with or without special provisions made to isolate each module from memory faults caused by another. It's still not the same as a monolithic kernel in which every component can and often does twiddle others' data, regardless of which language is used for its implementation.
Tanenbaum is unscientific: he focuses on a single variable and ignores all the others; he fails to even state his claims properly, let alone support them with data; and he fails to justify a novel approach with a detailed empirical analysis of prior work.
Bullshit. He has written whole books on the subject, stating his claims and supporting them with data more than you will ever do in your entire lifetime.
As for microkernels being new, they are not. They have been around for at least a quarter of a century
Yes, that's about how long ago Tanenbaum suggested them. Criticizing Tanenbaum's idea as "not new" when he's the very one who makes it quite old is just ridiculous.
Perhaps the most obvious and straightforward idea for how to improve reliability and decrease development costs for operating systems is to start applying modern, proven software development technologies: object-oriented programming languages, tools, design methodologies, safe runtimes, reflection, garbage collection, etc.
Object-oriented programming, tools, etc.? Very useful in an OS context, where dispatch tables for things like device drivers and filesystems predate the languages you probably use. Design methodologies? Obviously useful, and tautologically so, but what an OS designer considers a good methodology might not be the same as what some UML/pattern masturbator thinks is good. Safe runtimes? Yeah, that would suck for performance even more than microkernels are claimed to (incorrectly in light of examples such as L4 and QNX). Reflection? Simply useless in this context. Garbage collection? Ridiculous.
Have you ever worked on operating systems? It sure doesn't look like it. What you propose might be good for application space, but part of the reason those tools and applications work is because of the support they get from the kernel and other parts of the base system on which they run. Kernels and embedded systems are fundamentally different. Some of what you suggest might provide valid alternatives to the problem of what to do after code has failed, but none of it addresses the issue of how to prevent it from failing in the first place. Part of the point of microkernels is to reduce dependencies and make code more maintainable; it's a specific application of good old modularity, just as OOP is a different application of that same age-old concept. All of the things you mention are essentially orthogonal to microkernel vs. monolithic. You could implement every one of your ideas in either context, but I guarantee that a microkernel without reflection and garbage collection would be more maintainable and thus (over time) more robust and performant than a monolithic kernel with them. Stick to wimpy user code. Leave OS design to those with experience in that domain.
Specs tell you how a program "should" work and tend to be full of BS unless they're at very high level, documentation tells you how a program "does" work.
First, learn that quotes aren't for emphasis. Second, you're making a totally bogus distinction between specs and documentation. Something that describes how a component or subsystem works is still a spec even if it's written retroactively. Ideally, how something should work at an earlier point in time is how it does work at a later point, so a good spec can cover both.
Specs may suck in some cases; if they do, they're badly written. It's an indictment of the person who wrote that spec, not the concept of specs in general. When I call a function, I expect it to do exactly what its documentation says, and it should comply with the documentation exactly.
Thank you. Your expectation will of course not be met much of the time, but...well, what you said. That's an indictment of that particular spec's authors (or coders who diverged from the spec without updating it) not of specs in general.
On a related note, some will probably argue that such an approach might be fine for flight control or medical instruments, but doesn't apply to something like Linux. That's bullshit. It might be true that Linux doesn't need phone-book-size specs for minor changes, but if something is good for the most demanding kinds of applications a responsible programmer might naturally wonder what subset (or variant) of that process might still be useful for something less demanding. The answer is almost certainly not 100% but it's just as certainly not 0% either. Rejecting something in its entirety because the two problem domains are not completely identical is just sloppy. Maybe Linus and his chief lieutenants can't write a useful spec, but that doesn't mean nobody can.
Yeah, too bad the Linux kernel doesn't use CVS - or Subversion, to answer another moronic poster. Even if that were the case, such tools often give the wrong answer in large projects where one person often propagates another's changes through different levels of a development-stream hierarchy, or no answer at all when code is transferred between organizations and loses its history. Even aside from that (note how your "helpful comment" is three full levels removed from actual usefulness), focusing too tightly on the tools misses the point because the hard part of finding an actual bug comes before you know which line in which file needs to change.
Knowing the mechanics of one command in one version-control system might seem like the epitome of programming knowledge to some, but it's really not what's at issue here. The problem of programmers dumping garbage on one another goes much deeper than that, and OSS doesn't magically change human nature. A good development leader on an OSS project can set a good example and enforce high standards, but so can a good development leader on any other kind of project. Relying on self-interest and avoidance of shame just doesn't get you very far when half of your programmers don't even know why what they're doing is bad, and that's at least as true on projects full of college-student volunteers as on those run by professionals. For the majority of programmers, the infiltration of bad code into a project has to be actively prevented, not wished away.
FOSS coders expect their code will be read and that every semicolon will be traceable to them in perpetuity.
Perhaps to some degree, but less than generally supposed. Can you point to a particular line in the Linux kernel or Apache, for example, and identify who screwed it up? Not without significant effort. Project originators are definitely subject to the effect you mention, but others much less so. The more complex and/or specialized the code, the fewer eyeballs it will have and the less likely it becomes that blame for a bug will ever be laid where it belongs. Then there are the people who just don't care, or the excuse-makers who always blame the "impedance mismatch" between two pieces of code on the other guy or say that you can't apply traditional software-engineering standards when anyone who doesn't like it can change it themselves, etc. etc.
Many eyes might make all bugs shallow, but they don't do all that much to prevent bugs in the first place. "Cowboy spaghetti code" is everywhere, and from the hundreds of thousands or perhaps even millions of lines I've read there doesn't seem to be an appreciable difference in quality between open vs. closed source. Programmers are still programmers regardless of what license they use.
Slashdot Mirror
He seems to have a pretty "exotic" view of NAT and P2P, that's for sure. Point by point...
Most people didn't adopt NAT for that reason, and in fact wouldn't even know what you meant if you told them about an IP-address shortage. Many consumers use NAT because their ISP would only give them one IP address. That's not going to change going from IPv4 to IPv6 without other structural changes at the ISPs. They're just not set up to track multiple addresses for one customer, no matter what kind of addresses those are. Their databases only have one field for that, and that one field gets used to seed their MAC filter etc. Where's the incentive for them to accomodate this guy's wishes?
Another reason many people use NAT is for security. Never mind whether they actually achieve greater security; they believe that they do and that reason is distinct from concern over an address shortage.
What part of "peer to peer" doesn't he understand? Why does he think it's called that, instead of "client to server"? The whole point of P2P is that there's no such thing as a server. Also, again, he doesn't seem to understand why people use P2P systems. It's not just about getting content, which we've all been able to do via FTP for ages. It's also about storing multiple copies in multiple locations so that it will still be there despite a failure of a single node, and about finding it in one or more of those multiple locations, and about downloading pieces of it from multiple locations to maximize speed, and about keeping it all anonymous, etc. None of these are addressed by a switch from IPv4 to IPv6. Yes, NAT traversal is an issue that people have to deal with when they adopt P2P, but it's not the reason they did so in the first place.
It's wonderful that this guy is beating the IPv6 drum, because there are legitimate reasons why we should switch to IPv6. However, he should not let partisanship lead him into misrepresenting the facts.
The software components in Singularity are tightly coupled to a communications protocol over a channel. That's the whole point. It's precisely those internal transitions that can be verified. It's the external (to Singularity) ones like HTTP that can't, but that hardly makes the verifier useless. You can say "not what I was originally concerned about" and "irrelevant to the issue at hand" and "not the class of bugs I was describing" but anyone reading this exchange can see you're lying. Those are exactly the things what you were concerned about, and your claims about them have all been wrong. No number of red herrings or whines about how you're being treated change that. You simply should have read and tried to understand the paper before you spouted off, and you didn't. Be smarter next time.
That's rich, coming from someone who has repeatedly been caught making false statements and won't even admit it. At least my responses have some actual content, even if I do let my annoyance show. I'd rather be rude than a liar.
I am doing no such thing. You're the one who first referred to "algorithmic bugs" so why don't you define it? Until you do, I'll assume the intuitive meaning of bugs that represent high-level logic errors (e.g. deadlock/livelock, indefinite postponement, race conditions) as opposed to low-level implementation artifacts (e.g. incrementing the wrong variable, fencepost errors).
Your statement stands as false, no matter how much you rely on argument by repetition. Dispatching to the wrong handler will often lead to generation of an invalid response, which can very much be caught by a verifier. This is less apparent in HTTP than in other protocols because HTTP was designed by an amateur, but it can still manifest in the form of invalid error codes or reply headers. In a better protocol it might be blazingly obvious in the form of a POST_REPLY to a GET request or GET_REPLY for a POST. Even if that weren't the case, the fact that there's one error a verifier could not detect in no way proves your claim that a verifier can do nothing. You still seem to be struggling with that distinction between "not every" and "none" don't you?
Yes, I'm sure a lazy app programmer who doesn't understand how protocols are implemented might think that. I'm not going to address that further because this distinction of protocols is a big red herring. It doesn't change whether your claim about verifiers not being able to do anything about protocol or "algorithmic" bugs is true or not.
Because you have demonstrated repeatedly during this conversation that you have trouble not only with technical terminology but with basic language such as "not every" vs. "none" which would be quite obvious to most people. Granted, though, it might not be a language thing. There are other explanations.
There's that problem with "not every" again. No, not every person who disagrees with me is an idiot. That doesn't mean that none are, and the example that illustrates the distinction apparently thinks having the last word really matters. Go ahead. I'm done with you. You were wrong about Singularity not being a single-address-space OS, you were wrong that type and memory protection were the only guarantees, and you've been wrong on every secondary point since - even the irrelevant ones. You're obviously here just to argue, not to participate in any exchange of ideas.
Wrong again. It cannot catch all of these sorts of bugs, and nobody has said that it could. I even provided some counterexamples four days before this thread started. Your statement, though, was that a verifier can do nothing about such bugs. "Nothing" is an absolute negation. Since you're being such an ass about this, I'll reduce it to purely logical terms. Let X be the set of algorithmic errors, Y the subset of protocol errors (according to the definition used by myself and the Singularity team), and Z the set of errors that can be caught by a verifier. Your statement was that the intersection of X and Z is empty - not small, but empty. The Singularity paper shows that the set of Y and Z is not empty. Because Y is a subset of X, that means your claim must be false. It doesn't matter one bit whether there are bugs that are members of X but not Z, i.e. other kinds of algorithmic errors. No matter how many times you come back to it, that remains a red herring.
That is not in dispute but, again, you are confusing "not all" with "none" and are guilty of moving the goalposts. We're not talking all or nothing; we're talking about zero vs. non-zero.
Either you're the stupidest person on Slashdot (quite an achievement) or you're playing dumb to red herring to distract from your previous dishonesty. An external protocol is, quite obviously, one that is used to communicate with an external entity - i.e. on another box, running a different OS image, accessed via an external network interface. You can look on the back of your machine and see one of those if you're still confused. The world is not, in fact, composed only of such protocols, but many think so because they generally only hear the word used in that context. What you're unaware of is that there are protocols running within your system as well. There are CPU/memory-bus protocols and I/O-bus protocols which can actually be quite complex and are often studied using the exact same tools as are used for the more familiar kind of network protocols. There are also protocols within software that are often not recognized as such but can be treated that way for purposes of verification. "Call open() to get a file descriptor and then pass that to read()" is a protocol, and automated tools can check e.g. that you don't call read() before calling open() or free() before calling malloc() etc. almost ad infinitum. Protocols are actually all around you, and only your own narrowness of vision prevents you from seeing that.
It's selective in the sense of argument by selective observation. I realize you're not fluent in English, but please at least try to understand people before you disagree with them.
So unless the verifier can catch all algorithmic errors, it's worthless? Bullshit. You said type and memory safety were the only guarantees. Key word: only. A single existence proof is sufficient to refute that, and that existence proof is right in the paper. What is meant by protocol error is also quite clear from the paper - it's a protocol between components in the system (not one handled externally like HTTP) expressed as state transitions forming a channel contract. It really is right in there. It's what distinguishes Sing# from Spec#. The verifier can catch those errors, and the fact that it's a subset of all algorithmic errors is a red herring. Your statement remains false.
...and that doesn't count because...? Oh, because it's not convenient for you. Because disavowing it, however speciously, gives you an opportunity to play "I'm rubber, you're glue" games. Grow up.
Read the damn paper. They're very clear about what they're referring to...oh, forget it. You obviously won't accept anything that undermines your position unless you have no choice, so I refer you to the description of channel contracts on page 15 of the document:
A send and receive action inconsistent with this state machine is therefore quite obviously an invalid state transition. Should I define "state" and "transition" for you now, or is that enough?
Quoting a source in good faith is a good thing. Selectively quoting or misquoting is not. Clear enough?
Look again at what you just quoted. Here, I'll even help you by highlighting the part you obviously skipped over.
What do you suppose "protocol conformance" means? It means avoidance of exactly the kind of invalid state transition that we've been talking about. Your claim that "there is nothing a verifier can do to prevent this" is clearly false since the verifier can and does prevent the module from compiling if it contains such errors. Likewise, while the safety guarantees are by no means complete (I've already pointed out the lack of coverage for both livelock/deadlock and indefinite postponement as a result of component failure in posts here and on my website), there are clearly some guarantees beyond type and memory safety so your statement above is also false.
You're letting bias get in the way of understanding what you're looking at, naasking. Please take off the EROS-colored glasses for a moment and actually look at what Singularity is doing instead of just trying to mine the document for quotes that you (wrongly) think support your predetermined position.
Look again. SIPs are explicitly defined as "closed object spaces, not separate address spaces" that "do not rely on memory management hardware for isolation."
Look again, this time at the section on Sing# and Boogie which do plenty to prevent this.
You're welcome.
Actually, any rational person who looked at my postings either in this thread or on my own site would come away with the exact opposite impression. I think fault-isolation mechanisms are a very important aspect of OS design, which is why your idea of running an interpreted or JIT-compiled language in the kernel is ridiculous. The performance and complexity implications are simply unacceptable.
The very fact that you don't realize when your own arguments have been disproven shows that you're the one doing the handwaving - but it could hardly be any other way when you're commenting on a domain where you've never done any actual work. You claimed that microkernels had to be based on hardware protection; Singularity is clearly a microkernel and everyone recognizes it as such but it has no such dependency. You assumed that a complex runtime is the only way to maintain language safety guarantees; Sing# and SIPs prove you wrong. I've been very clear that the progress on Singularity so far doesn't prove that they've found the One Best Way to write an OS, but they have done enough experiments and provided enough analysis to disprove your claims and assumptions. You're simply full of shit when it comes to operating systems, idlake. Stick to whatever it is that you know, which seems to be very little, and let the grownups do the real work.
In Singularity, class loaders are essentially [i]verboten[/i], reflection is compile-time, and garbage collection isn't what you're used to either. Furthermore, they run fully native code, not interpreted or JIT-compiled. In fact, they do a pretty good job of proving you wrong on just about every point you made in the previous thread, so maybe you shouldn't be trying to cite their experience as support for your still-broken ideas about OS design.
I was also involved in that previous discussion (in fact your post there was spawned by one of mine) and I think idlake is on the right side this time. The EROS architecture still relies on hardware memory protection between processes, which is a fundamentally different paradigm than a single-address-space OS that uses either compile-time or load-time verification to guarantee safety. In addition, the EROS contructor does not provide any of the higher-level guarantees (e.g. regarding invalid state transitions) that Sing# does via the "Boogie" verifier. Yes, you could build all the important parts of Singularity in EROS (and vice versa) but the result would be more of a emulation or virtualization like User-Mode Linux than like a single OS. The hooks just aren't there to fuse the two approaches into a coherent whole. There's nothing wrong with EROS, and there's nothing wrong with Singularity. They can both help us learn different things. Pissing contests about which one trumps the other are just pointless and childish.
I already wrote about this four days ago so I won't repeat the whole thing here. Short version:
Even shorter version: lots of great ideas, lots of work still to be done. Anybody with a clue about operating systems should be following this with interest.
...and many people, including myself, believe that should not be the case. In fact, copyright law explicitly denies protection to those whose work is done directly for the government, and there have been attempts to extend that to cover grant-funded research. Patents are, unfortunately, not subject to the same requirements for open access. Obviously there are reasons to keep certain information from becoming public, but granting patent/copyright protection to the fruits of government work so that the government can make a profit from them is wrong. If my tax dollars paid for research I should be able to apply it, and whoever proves to be the best competitor in bringing it to market - not whoever has the best access to the halls of power - should profit most.
Don't call bullshit unless you have Clue One what you're talking about, coward. "Intellectual property" refers to copyright, trademarks, patents etc. - not to state secrets, private conversations, or just any old kind of knowledge that happens not to be widely known. The two are easily distinguishable by which section of US Code is invoked. Now run along and leave the grownups alone.
Because the government is supposed to represent the people, and therefore not to hold any exclusive IP. As others have pointed out, though, this is not an IP issue. Using the seal is more akin to copying someone's signature than copying their trademark, and it's forbidden by other laws. That doesn't mean that the government's action in this case is right or a good use of taxpayer money, but it's necessary to understand which laws and principles are involved before we can make that determination.
I hope you have a good rear-view mirror while you backpedal.
...except that they don't. Microkernels have been implemented in other languages, and it has already pointed out to you that they have been implemented in single address spaces.
...and you base that statement on...what? It's no more true of drivers than the rest of the kernel. You also fail to note that almost everything under fs/ and most of net/ is really driver code too.
By your own count, which is flawed, over 70% of the code is drivers. By a more realistic count it's likely to be 85-90%. Many would say that's the real metric of code size, since that's what has to be debugged and accounted for in designs. It's true that the percentage of code loaded into any given instance of the kernel is likely to be lower, but that actually highlights an interesting point: loadable modules represent an evolution toward microkernel ideas. In the Bad Old Days vendors shipped truly monolithic generic kernels, and then users would configure and relink for the devices they had. I don't recall offhand whether Linux was originally that way, but I think it was and I know for sure that BSD was. Even though they're loaded into a common address space, loadable drivers are very much a microkernel idea. Even process and I/O schedulers can be loaded nowadays, which moves us further in that direction (leaving little but the VM system). Now that they're widely adopted the majority of code that's loaded might not be drivers, but it's still not a vast majority and the majority of instructions during any given time quantum might well be drivers of one kind of another. By two out of three metrics - written, loaded, run - drivers are the majority of code. It's lovely that you could write a script to count lines, but it would be even better if you could understand the numbers you were looking at before you make more false claims.
Implementing code in an HLL (a compile/link time decision) is not at all the same as running it in a "managed code" type of environment. Those LISP machines (LMI, Symbolics, or Xerox) compiled down to what the hardware understood, thereafter not requiring software mediation to do whatever it was they needed to do. As I'm sure you know, code runs faster directly on hardware than on top of an abstraction/emulation layer to translate between its interface and the hardware's. Yes, I know about JIT compilers but they don't fully solve that problem. Furthermore, those LISP machines ran on hardware specifically designed for that mode of operation. That's a far cry from today, when the most common processors on people's desktops or in their devices are not so narrowly targeted to running specific languages. Go ask a CPU designer about undoing the RISC Revolution and going back to "high level" processors like the iAPX432 or the various Burroughs stack machines. Those guys could always use a good laugh.
Just because something can be done doesn't mean it should be done. Yes, we can implement monolithic kernels that run on special-purpose processors with all of the important primitives those kernels need implemented in hardware (which would be equivalent to implementing a microkernel in hardware). There might even be certain applications for which that would be a good idea - e.g. the same applications already using FORTH or "BASIC stamp" chips. For general-purpose computing with the expected complement of speed and bus-interface compatibility and virtual memory and multiuser protection, though, it would be an incredibly poor design choice.
It's pretty amusing to hear such "back to the 70s" suggestions from those who have the gall to accuse others of being old-fashioned.
Oh, I get it. I'm supposed to distinguish microkernels from other things only in terms of aspects you dislike, allowing you to appropriate anything you do like for "your side" of the debate? Sorry, not falling for it. As I said earlier, both microkernels and OOP are variants of the same basic concept: modularity. Like one, like both. Hate one, hate both. Making arbitrary distinctions for the sole sake of hyping one and dissing the other is dishonest.
Then such a kernel's not very monolithic, is it? Idiot. What do you call that piece of code that takes care of loading classes and dealing with reflection and garbage collection and other forms of inter-component mediation and safety enforcement in your microkernel-less utopia, Mr. Smartass? Oh, right. It's a microkernel. Sheesh.
Oh, so Java objects can't exchange messages, or implement trivial getter/setter methods? Yeah, right. The kind of twiddling you mention is trivially possible in any language or environment, whether it be C or Java or Linux or QNX. I've even written about that problem. . .twice, and both before you showed up to be educated. Attributing a problem only to one paradigm when it applies to both is, again, dishonest.
You're just lucky I'm not charging you my usual hourly rate for being your own private tutor. You couldn't afford it, and will never be able to while you have more attitude than knowledge.
How unscientific of you, to draw such an unrelated conclusion from that data. The operating systems you have mentioned have been less prevalent in the marketplace. They have had smaller numbers of users and, more importantly, engineers working on them than, say, Linux. That does not in any way demonstrate that they are more difficult to extend and maintain, as there are plenty of other reasons for what has happened in the market. How do you know that they wouldn't be even more marginal than they are had they been designed as monolithic kernels, or that Linux wouldn't be even more successful if it had been designed as a microkernel? What actual evidence do you have to say otherwise? None.
Wrong. Shared vs. separate address space is an implementation choice; microkernel vs. monolithic is a design choice. That microkernels are typically implemented using separate address spaces is irrelevant. If you had actually worked in operating systems you'd also know that totally shared vs. totally separate are not the only options for address-space relationships. Linux's process/thread/address-space model is based (without attribution, naturally) on something called nUnix, which Dave Mitchell implemented and I inherited at Encore before Linux existed. One of its key ideas is/was that parts of a process could be shared without having to share everything. SysV's shared memory goes back even further than that. Even within the kernel one can implement some forms of inter-component memory protection without resorting to completely separate address spaces. Been there, done that. I was the one who wrote code at Encore to let two operating systems run side by side in the same box, on separate sets of processors with separate memory and exception vectors and - most importantly - so that a memory fault in one wouldn't take the other down. That was done in a slightly different context (one was an RTOS and the other a GPOS) but the same techniques could just as easily be applied to a microkernel.
And how is that "safe, dynamic runtime" not itself a microkernel?
Yeah, I'm such a dinosaur, working here in what is acknowledged as one of the leading-edge areas of the storage industry, implementing a highly available distributed system. Riiight. What do you do that anyone should remember you for, Mr. Expert? In actual fact I don't think it's a good idea to write "millions of lines of C..." when one has a choice. If I were to design another microkernel it would be every bit as current in terms of software-engineering methodology as anything you've ever done, but that doesn't mean it would be implemented as a "managed code" environment. I understand the concept of informed tradeoffs as opposed to mere uninformed dogma. I produce working and shipping systems based on that. Come back when you've done likewise.
OS development doesn't need to be made hard; it's inherently hard. In an OS, everything you do has to be done with an eye toward reentrancy and concurrency, performance and minimal resource consum
The classic response of someone who has never actually done any serious kernel work. Just because it's not CS-hard doesn't mean it's not real-world-hard, and I think I know a bit about that because I've been solving problems that are hard in both senses for quite a while. Your use of "naysayer" only gives away your own bigotry. Think about what "safe" means in that context. It means that the code doesn't have direct access to underlying resources, with that access then done on your behalf by "someone else" but there is no someone else when you're the kernel. Those "safe" environments require exactly the kind of performance-robbing intermediation for which you criticize microkernels; in a way, what you're proposing is actually a microkernel of a different (and inferior) sort. Do you want to have every PCI-register access trap to a safety-guaranteeing handler? If you don't see how badly that would suck, grow a clue.
Compile-time safety checks are a wonderful thing, and I've applied cutting-edge forms of that technology in both kernel and user work. The run-time checks of your "managed code" utopia, though, are simply impractical for an OS kernel.
Yes, and some of the more performant microkernels do share address spaces. Don't confuse microkernel design with microkernel implementation. It's entirely possible to adhere to the design principles of a microkernel, perhaps even prototype or test using separate address spaces, and then implement a version in which components run in a single address space - with or without special provisions made to isolate each module from memory faults caused by another. It's still not the same as a monolithic kernel in which every component can and often does twiddle others' data, regardless of which language is used for its implementation.
Bullshit. He has written whole books on the subject, stating his claims and supporting them with data more than you will ever do in your entire lifetime.
Yes, that's about how long ago Tanenbaum suggested them. Criticizing Tanenbaum's idea as "not new" when he's the very one who makes it quite old is just ridiculous.
Object-oriented programming, tools, etc.? Very useful in an OS context, where dispatch tables for things like device drivers and filesystems predate the languages you probably use. Design methodologies? Obviously useful, and tautologically so, but what an OS designer considers a good methodology might not be the same as what some UML/pattern masturbator thinks is good. Safe runtimes? Yeah, that would suck for performance even more than microkernels are claimed to (incorrectly in light of examples such as L4 and QNX). Reflection? Simply useless in this context. Garbage collection? Ridiculous.
Have you ever worked on operating systems? It sure doesn't look like it. What you propose might be good for application space, but part of the reason those tools and applications work is because of the support they get from the kernel and other parts of the base system on which they run. Kernels and embedded systems are fundamentally different. Some of what you suggest might provide valid alternatives to the problem of what to do after code has failed, but none of it addresses the issue of how to prevent it from failing in the first place. Part of the point of microkernels is to reduce dependencies and make code more maintainable; it's a specific application of good old modularity, just as OOP is a different application of that same age-old concept. All of the things you mention are essentially orthogonal to microkernel vs. monolithic. You could implement every one of your ideas in either context, but I guarantee that a microkernel without reflection and garbage collection would be more maintainable and thus (over time) more robust and performant than a monolithic kernel with them. Stick to wimpy user code. Leave OS design to those with experience in that domain.
Rarely.
First, learn that quotes aren't for emphasis. Second, you're making a totally bogus distinction between specs and documentation. Something that describes how a component or subsystem works is still a spec even if it's written retroactively. Ideally, how something should work at an earlier point in time is how it does work at a later point, so a good spec can cover both.
Thank you. Your expectation will of course not be met much of the time, but...well, what you said. That's an indictment of that particular spec's authors (or coders who diverged from the spec without updating it) not of specs in general.
On a related note, some will probably argue that such an approach might be fine for flight control or medical instruments, but doesn't apply to something like Linux. That's bullshit. It might be true that Linux doesn't need phone-book-size specs for minor changes, but if something is good for the most demanding kinds of applications a responsible programmer might naturally wonder what subset (or variant) of that process might still be useful for something less demanding. The answer is almost certainly not 100% but it's just as certainly not 0% either. Rejecting something in its entirety because the two problem domains are not completely identical is just sloppy. Maybe Linus and his chief lieutenants can't write a useful spec, but that doesn't mean nobody can.
Yeah, too bad the Linux kernel doesn't use CVS - or Subversion, to answer another moronic poster. Even if that were the case, such tools often give the wrong answer in large projects where one person often propagates another's changes through different levels of a development-stream hierarchy, or no answer at all when code is transferred between organizations and loses its history. Even aside from that (note how your "helpful comment" is three full levels removed from actual usefulness), focusing too tightly on the tools misses the point because the hard part of finding an actual bug comes before you know which line in which file needs to change.
Knowing the mechanics of one command in one version-control system might seem like the epitome of programming knowledge to some, but it's really not what's at issue here. The problem of programmers dumping garbage on one another goes much deeper than that, and OSS doesn't magically change human nature. A good development leader on an OSS project can set a good example and enforce high standards, but so can a good development leader on any other kind of project. Relying on self-interest and avoidance of shame just doesn't get you very far when half of your programmers don't even know why what they're doing is bad, and that's at least as true on projects full of college-student volunteers as on those run by professionals. For the majority of programmers, the infiltration of bad code into a project has to be actively prevented, not wished away.
Perhaps to some degree, but less than generally supposed. Can you point to a particular line in the Linux kernel or Apache, for example, and identify who screwed it up? Not without significant effort. Project originators are definitely subject to the effect you mention, but others much less so. The more complex and/or specialized the code, the fewer eyeballs it will have and the less likely it becomes that blame for a bug will ever be laid where it belongs. Then there are the people who just don't care, or the excuse-makers who always blame the "impedance mismatch" between two pieces of code on the other guy or say that you can't apply traditional software-engineering standards when anyone who doesn't like it can change it themselves, etc. etc.
Many eyes might make all bugs shallow, but they don't do all that much to prevent bugs in the first place. "Cowboy spaghetti code" is everywhere, and from the hundreds of thousands or perhaps even millions of lines I've read there doesn't seem to be an appreciable difference in quality between open vs. closed source. Programmers are still programmers regardless of what license they use.