Can you honestly tell me with a straight face that JITC techniques, garbage collection, and other high-level features are competitive with C for producing such code?
Why not? What do you think people were using for writing operating systems before C and UNIX became popular with academics and a misguided generation of CS graduates? Of course, you do add a little bit of assembly code in a few places, like the scheduler, but if you are careful, you can keep that to below a few thousand lines. The rest can be entirely done in a HLL other than C. Don't get me wrong: C was a neat hack and great fun on a PDP-11, but it has never been either a well-designed language or a high performance language.
As for JITs and GC, both of them are bonuses from a performance point of view. A well-implemented JIT gives you cross-module optimization and inlining even in the presence of dynamic loading, something potentially quite useful in a kernel. And a GC is not only less error prone than manual storage management, it is also more efficient.
The only efforts I've seen in this regard are BitC, Nitro, and Cyclone (projects that actually have implementations that is). None of them are there yet.
I haven't tried BitC or Nitro, but Cyclone's performance is pathetically poor. I think Cyclone has tried to stick too close to C.
There is absolutely no reason why CapROS could not become a practical system. There is nothing research-centric about EROS/CapROS except its unfinished nature.
But that's what I'm talking about. I mean, who is going to work on CapROS and who is going to bother using it? If I want capabilities, I can get them in Linux or BSD.
No matter how badly C and C-based monolithic kernels may suck, the path towards better OSes is likely going to be incremental, starting from Linux or BSD: permitting the loading of modules written in other languages, adding a JIT, adding capabilities, etc.
And if you believe in microkernels, then the path to making it happen is likely to be adding microkernel-like facilities to the Linux kernel. If microkernel designs are so great, then people will naturally start using those new microkernel facilities to add new drivers, file systems, etc.
This sort of complaint would sound silly in another context. Imagine writing to a medical magazine about how "neurosurgery is too complicated" and they should make it easier to understand. Or rocket science? "They should make the 10 most common kinds of rockets easier to design".
No, it wouldn't sound silly. Neurosurgeons are constantly looking for tools that are easier to use and require less training because that means less risk, lower costs, and higher earnings.
And Photoshop's interface really is awful--it takes far too many mouse clicks to do common things.
How exactly is organizing your photos by the dates they were taken a "crazy scheme?
Because it splits up related photos and groups together unrelated ones. iPhoto should keep things organized by "film roll", where each film roll is stored directly in the Pictures folder. I should also be able to point iPhoto at arbitrary directories and work with them without having to import them.
The reason iPhoto gets away with that is because it's consumer software. It falls apart once you have 10-20k images (something a pro can easily shoot within a few days).
"Fault isolation within a single address space can be provided in software via safe languages, safe runtimes, sandboxing via instruction rewriting, and certified compilers, to name just a few." I doubt very much that this would be acceptable on modern hardware. Greatest performance enhancements on current archiectures due to caches. JITC, instruction rewriting, etc. are cache killers.
All those techniques yield competitive performance to C in user space. Why do you think they wouldn't do so in kernel space?
CapROS/EROS can potentially deliver within two years but Coyotos is definitely further than that.
I don't think any of those systems will ever result in a practical OS; they were/are research projects. If you want some those features in a real-world system, you need to figure out how to bring them to Linux.
While potentially an interesting direction for research, it does not at all seem feasible with current hardware.
Why not? Man operating systems have been implemented in languages with more safety and fault isolation features than C (languages like PL1, Modula-3, Oberon, ObjectPascal, Cedar/Mesa, Algol, Ada, Lisp, and Smalltalk). Fault isolation within a single address space can be provided in software via safe languages, safe runtimes, sandboxing via instruction rewriting, and certified compilers, to name just a few. And even if you want to use a full JVM or CLR, they are efficient and have footprints that ought to be perfectly acceptable for a modern kernel.
I think you'll learn a lot from the papers written on EROS/CapROS.
I doubt I would learn anything more from them than last time I read them...
Coyotos for pure object-oriented operating systems (Actors message-passing syle with true capability security).
Well, Coyotos at least looks like a far more worthwhile project than either Minix3 or EROS.
Now I understand you don't trust them, but how will you respond if you can't say their product sucks?
That sort of situation isn't new: there have been plenty of companies that have come out with good technology that was proprietary and unavailable in open source form or from other vendors. How do people deal with it? By making cost/benefit/risk analyses. Is the licensing cost worth it? Is the risk of being tied to a single vendor worth it? Frequently, the technologically best solution isn't the best solution from a business point of view.
Let's say it's the Longhorn Server, WinFS, Monad, and everything MS has been touting works.
Keep in mind that every major technology Microsoft is planning for Longhorn (WinFS, Avalon, Monad, etc.) is already available on Linux, often in multiple implementations, so even if Longhorn was released tomorrow, Microsoft would still be years behind.
Well, as you keep pointing out yourself, you are a typical example of a highly skilled and experienced systems programmer. Thank you for sharing your views and attitudes towards software development and application programmers with us. I think your remarks speak for themselves.
The real problem is that microkernels have a stigma attached to them, and because they are hard to properly design and implement
OK, we agree on that.
Now, if that's the case, in what sense is a microkernel "more reliable"? Let's say that in 100 man years, my team can produce a fully functional and extensively tested monolithic kernel. If microkernels are harder to design and implement, in the same time, the same team may only implement some of the functionality and do less testing for an equivalent microkernel. So, the microkernel design is then actually inferior.
And practical experience with kernels like Mach and Linux suggests that the microkernel design never catches up: no matter how long you hack on both kernels, the monolithic kernel always seems to be ahead.
So, in what sense is the microkernel design supposed to be better than the monolithic design, then?
Your games with terminology don't change the fact that Tanenbaum made two specific design decisions in Minix3: he uses an intrinsically unsafe language and runtime with almost no built-in data abstraction facilities, and he relies on separate address spaces for fault isolation. Nobody has ever been able to demonstrate that those are good design decisions, and the repeated failure of that approach in real-world operating systems strongly suggest it is not.
New kernels should be written in languages with better support for abstraction and fault isolation than ANSI C, and they should not rely on multiple address spaces for fault isolation.
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
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.
It sounds to me increasingly like "microkernel" to you means "a kernel implemented in ANSI C that uses a hand-crafted message passing object system".
It's still not the same as a monolithic kernel in which every component can and often does twiddle others' data
Monolithic kernels written in languages like Java make it impossible for components to "twiddle" each other's data; they can only "twiddle" what they can access. Some languages make it impossible in principle to access data in other objects without calling a method.
Conversely, microkernels frequently "twiddle" each other's data--they just do so by sending requests to do so. The effects and risks (race conditions, aliasing, etc.) are the same as calling a method, it simply happens to be a little less efficient in the microkernel.
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.
I'm not criticizing them for being an old idea, I'm just pointing out that the idea has had a long time to prove itself.
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.
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.
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.
Yes, and in the 21st century, we have standardized these things and put them into programming languages and runtimes. People like Tanenbaum should move out of the 1960's and get with the program.
All of the things you mention are essentially orthogonal to microkernel vs. monolithic.
That is quite incorrect. Microkernels are an attempt to overcome the problems with unsafe, static runtimes and languages by putting components into separate address spaces. If you have a safe, dynamic runtime, you don't need a microkernel architecture.
Kernels and embedded systems are fundamentally different.
That assumption is your and Tanenbaum's mistake. 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. And then you come up with schemes like microkernel architectures to try and work around those self-created problems.
Stick to wimpy user code. Leave OS design to those with experience in that domain.
Yes, and in a nutshell, that sums up the problem: OS designers have an attitude problem. Instead of making it easier for people to modify the kernel, they try to keep it some obscure art form. I think the reason they can get away with it is because kernels matter less and less. Application programmers stopped expecting anything useful from kernel developers long ago and started implementing security, remote file access, hardware access, and other features completely in user code. I suppose it's a form of "microkernel" as well.
I agree 100%. And 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. And it doesn't even have to be Java or C#; languages like Modula-3 or Object Pascal are far safer than C and can get by with a tiny runtime. Heck, even consistent use of C++ for writing kernels would be better than what people are doing now, despite the numerous problems that C++ has.
It is just astounding to me that while anybody else would be laughed at if they tried to write a modern, complex application in ANSI C, operating system designers are somehow considered special, as if concepts like "abstraction", "error handling", and "runtime safety" didn't matter for kernels that are millions of lines big.
The difference is that you can build a microkernel and prove it is reliable, secure, meets performance specifications, etc. No one has been able to do that for a monolithic kernel.
Come on, you yourself must realize that that assertion is preposterous; numerous kernels in applications like smart cards have been formally verified.
(Let's not even go into all the theoretical and practical problems associated with using proof techniques for attempting to establish reliability and security.)
system design to such a level that his work was the BASIS from which Linus was "inspired".
Linus may have been "inspired" to create Linux by the existence of MINIX, but MINIX cannot be said to be the "basis" for Linux. In fact, Tanenbaum's work represents an approach to OS design that UNIX was originally created in reaction to.
His stuff is very much NOT Ivory Tower (I speak as someone who has had to do bespoke OS work) and very practical way to build operating systems
Well, then maybe you can give examples of significant contributions that Tanenbaum has made to systems like UNIX, Linux, Windows NT, Darwin, MPI, PVM, or other major operating systems or distributed programming systems in common use.
(And, no, OSI and writing some nice textbooks, don't count.)
At issue isn't whether Tanenbaum is right or whether he is wrong, at issue is his methdology. 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. Tanenbaum just tinkers and makes grand claims. That's why he should receive a failing grade.
As for microkernels being new, they are not. They have been around for at least a quarter of a century (arguably longer), and they have received more than their fair share of attention and study. There have been many other ideas in OS design since then; if anything deserves attention, it is them.
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. The hypothesis that doing so improves reliability is far more plausible than Tanenbaum's hypothesis that we can stick with using ANSI C if we only use some hare-brained scheme of dividing everything up into separate address spaces. And, in fact, there is actual experimental evidence that using safe runtimes with monolithic kernels is more efficient for fault isolation than using unsafe runtimes with microkernels.
There is nothing to "dispute" since that's not even a meaningful claim. People have built very unreliable microkernels and very reliable monolithic kernels.
So far, there is no data to support the idea that among the many variables that determine reliability (effort, programming language, architecture, testing, etc.), the microkernel/monolithic distinction makes any difference whatsoever.
How can that be? Well, for example, microkernel architectures may complicate software development to the point where less time can be devoted to testing or where essential features can't be implemented at all and the project fails altogether.
Tanenbaum rightly criticized Linus for creating a big monolithic operating system kernel, but at least Linus was copying something that was successful and he made it a success himself.
But, geez, how often do microkernels have to fail before Tanenbaum will admit that there must be something fundamentally wrong with his approach, too? Microkernels attempt to address the right problem (kernel fault isolation), just in such an idiotic way that they keep failing in the real world. But instead of a detailed criticial analysis of previous failures, Tanenbaum and Herder just go on merrily implementing Minix3, apparently on the assumption that all previous failures of microkernels were just due to programmer incompetence, an incompetence that they themselves naturally don't suffer from.
Both Linux-style monolithic kernels and Tanenbaum-style microkernels are dead ends. But at least Linux gets the job done more or less in the short term. In the long term, we'll probably have to wait for dinosaurs like Tanenbaum to die out before a new generation of computer science students can approach the problem of operating system design with a fresh perspective.
The $3 billion in subsidy comes from the auction of the spectrum.
It's still public money and it's still a subsidy and government handout to big corporations. I mean, what's the point of using a public resource to generate revenue when you hand the proceeds of the acution right back to the people who paid it?
Let me be clear, this $3 billion isn't coming from some other agency or program, it is coming from the proceeds of the auction.
Yes, and those $3 billion should go to funding NASA, not TV receivers.
Because the government is forcing the television broadcasters to give up their portion of the analog spectrum, in favor of the new Digital standard
No, the government isn't "forcing" anybody; the government is simply changing the terms under which it has been providing a highly valuable resource to broadcaster at a discount price. In principle, the government could cancel the agreement entirely and unilaterally.
MySQL's dual licensing scheme is suspect anyway; while it matters less for a database than for something like a GUI toolkit (where dual licensing is really problematic), dual licensing in general reduces the ability of the community to contribute (because they can't accept contributions under the GPL), makes the developers less responsive to community needs (because the developers attempt to optimize profit in parallel with FOSS goals), and makes it difficult to fork (because any fork would have to compete with the original developer, who has an advantage in being able to derive revenue from commercial licensing). While software like MySQL may ship under an optional open source license, it is not run like an open source development project.
I won't be sorry to see MySQL go anyway; technologically, it is getting better, but there are enough good relational databases out there that are truly FOSS and don't have the same history of technical corner cutting as MySQL.
Of course it can happen in Macs as well, I never said that it couldn't. And what should the Mac do? Give the user an electric-shock if he tries to unplug the device without unmounting it?
I told you what it should do. In a nutshell, it should automatically unmount the device when it is not in use so that I can just unplug it safely when it is not in use.
And if I unplug the device while in use, it should do the obvious thing. So, if I unplug an iPod that is syncing music, some songs don't get transferred, nothing more. And if I unplug a USB stick that I'm writing data to, the data doesn't get fully written, but the file system should remain consistent. Making those things work is something a student could do as a senior project.
Well, iTunes DOES have a text saying "updating iPod" (or something like that) with a progress-bar. And the iPod has a text saying "Do not disconnect". I think those are pretty self-explanatory.
Yes, and that's a problem because there is no reason to tell me that.
Mark my words: Apple is going to fix this in a release or two and do exactly what I described. It's obvious, it's simple, and it's user friendly. And then people like you are going to defend it and are going to tell everybody how amazingly innovative Apple is.
I use toothpaste; YMMV. And now that I got the Nano Tube, it protects the screen quite well.
However, the Nano is worse than other players when it comes to scratching. For example, my Rio Carbon and non-name Chinese players don't have a single scratch on it despite being a year or more old. OTOH, $250 for 4G of flash is not a bad deal.
If we keep our fingers crossed and don't mention the obvious prior art, maybe we get lucky and this thing kills XML. Then, we can go back to the prior art systems, like s-expressions, which were actually a lot nicer and a lot simpler than XML.
Slashdot Mirror
Can you honestly tell me with a straight face that JITC techniques, garbage collection, and other high-level features are competitive with C for producing such code?
Why not? What do you think people were using for writing operating systems before C and UNIX became popular with academics and a misguided generation of CS graduates? Of course, you do add a little bit of assembly code in a few places, like the scheduler, but if you are careful, you can keep that to below a few thousand lines. The rest can be entirely done in a HLL other than C. Don't get me wrong: C was a neat hack and great fun on a PDP-11, but it has never been either a well-designed language or a high performance language.
As for JITs and GC, both of them are bonuses from a performance point of view. A well-implemented JIT gives you cross-module optimization and inlining even in the presence of dynamic loading, something potentially quite useful in a kernel. And a GC is not only less error prone than manual storage management, it is also more efficient.
The only efforts I've seen in this regard are BitC, Nitro, and Cyclone (projects that actually have implementations that is). None of them are there yet.
I haven't tried BitC or Nitro, but Cyclone's performance is pathetically poor. I think Cyclone has tried to stick too close to C.
There is absolutely no reason why CapROS could not become a practical system. There is nothing research-centric about EROS/CapROS except its unfinished nature.
But that's what I'm talking about. I mean, who is going to work on CapROS and who is going to bother using it? If I want capabilities, I can get them in Linux or BSD.
No matter how badly C and C-based monolithic kernels may suck, the path towards better OSes is likely going to be incremental, starting from Linux or BSD: permitting the loading of modules written in other languages, adding a JIT, adding capabilities, etc.
And if you believe in microkernels, then the path to making it happen is likely to be adding microkernel-like facilities to the Linux kernel. If microkernel designs are so great, then people will naturally start using those new microkernel facilities to add new drivers, file systems, etc.
This sort of complaint would sound silly in another context. Imagine writing to a medical magazine about how "neurosurgery is too complicated" and they should make it easier to understand. Or rocket science? "They should make the 10 most common kinds of rockets easier to design".
No, it wouldn't sound silly. Neurosurgeons are constantly looking for tools that are easier to use and require less training because that means less risk, lower costs, and higher earnings.
And Photoshop's interface really is awful--it takes far too many mouse clicks to do common things.
How exactly is organizing your photos by the dates they were taken a "crazy scheme?
Because it splits up related photos and groups together unrelated ones. iPhoto should keep things organized by "film roll", where each film roll is stored directly in the Pictures folder. I should also be able to point iPhoto at arbitrary directories and work with them without having to import them.
The reason iPhoto gets away with that is because it's consumer software. It falls apart once you have 10-20k images (something a pro can easily shoot within a few days).
"Fault isolation within a single address space can be provided in software via safe languages, safe runtimes, sandboxing via instruction rewriting, and certified compilers, to name just a few." I doubt very much that this would be acceptable on modern hardware. Greatest performance enhancements on current archiectures due to caches. JITC, instruction rewriting, etc. are cache killers.
All those techniques yield competitive performance to C in user space. Why do you think they wouldn't do so in kernel space?
CapROS/EROS can potentially deliver within two years but Coyotos is definitely further than that.
I don't think any of those systems will ever result in a practical OS; they were/are research projects. If you want some those features in a real-world system, you need to figure out how to bring them to Linux.
While potentially an interesting direction for research, it does not at all seem feasible with current hardware.
Why not? Man operating systems have been implemented in languages with more safety and fault isolation features than C (languages like PL1, Modula-3, Oberon, ObjectPascal, Cedar/Mesa, Algol, Ada, Lisp, and Smalltalk). Fault isolation within a single address space can be provided in software via safe languages, safe runtimes, sandboxing via instruction rewriting, and certified compilers, to name just a few. And even if you want to use a full JVM or CLR, they are efficient and have footprints that ought to be perfectly acceptable for a modern kernel.
I think you'll learn a lot from the papers written on EROS/CapROS.
I doubt I would learn anything more from them than last time I read them...
Coyotos for pure object-oriented operating systems (Actors message-passing syle with true capability security).
Well, Coyotos at least looks like a far more worthwhile project than either Minix3 or EROS.
Now I understand you don't trust them, but how will you respond if you can't say their product sucks?
That sort of situation isn't new: there have been plenty of companies that have come out with good technology that was proprietary and unavailable in open source form or from other vendors. How do people deal with it? By making cost/benefit/risk analyses. Is the licensing cost worth it? Is the risk of being tied to a single vendor worth it? Frequently, the technologically best solution isn't the best solution from a business point of view.
Let's say it's the Longhorn Server, WinFS, Monad, and everything MS has been touting works.
Keep in mind that every major technology Microsoft is planning for Longhorn (WinFS, Avalon, Monad, etc.) is already available on Linux, often in multiple implementations, so even if Longhorn was released tomorrow, Microsoft would still be years behind.
Well, as you keep pointing out yourself, you are a typical example of a highly skilled and experienced systems programmer. Thank you for sharing your views and attitudes towards software development and application programmers with us. I think your remarks speak for themselves.
The real problem is that microkernels have a stigma attached to them, and because they are hard to properly design and implement
OK, we agree on that.
Now, if that's the case, in what sense is a microkernel "more reliable"? Let's say that in 100 man years, my team can produce a fully functional and extensively tested monolithic kernel. If microkernels are harder to design and implement, in the same time, the same team may only implement some of the functionality and do less testing for an equivalent microkernel. So, the microkernel design is then actually inferior.
And practical experience with kernels like Mach and Linux suggests that the microkernel design never catches up: no matter how long you hack on both kernels, the monolithic kernel always seems to be ahead.
So, in what sense is the microkernel design supposed to be better than the monolithic design, then?
Your games with terminology don't change the fact that Tanenbaum made two specific design decisions in Minix3: he uses an intrinsically unsafe language and runtime with almost no built-in data abstraction facilities, and he relies on separate address spaces for fault isolation. Nobody has ever been able to demonstrate that those are good design decisions, and the repeated failure of that approach in real-world operating systems strongly suggest it is not.
New kernels should be written in languages with better support for abstraction and fault isolation than ANSI C, and they should not rely on multiple address spaces for fault isolation.
The defining characteristic of microkernels is a small set of kernel-implemented primitives upon which an entire system can be built in userspace.
I agree with that definition of microkernel, but "Salamander" apparently does not.
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
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.
It sounds to me increasingly like "microkernel" to you means "a kernel implemented in ANSI C that uses a hand-crafted message passing object system".
It's still not the same as a monolithic kernel in which every component can and often does twiddle others' data
Monolithic kernels written in languages like Java make it impossible for components to "twiddle" each other's data; they can only "twiddle" what they can access. Some languages make it impossible in principle to access data in other objects without calling a method.
Conversely, microkernels frequently "twiddle" each other's data--they just do so by sending requests to do so. The effects and risks (race conditions, aliasing, etc.) are the same as calling a method, it simply happens to be a little less efficient in the microkernel.
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.
I'm not criticizing them for being an old idea, I'm just pointing out that the idea has had a long time to prove itself.
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.
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.
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.
Yes, and in the 21st century, we have standardized these things and put them into programming languages and runtimes. People like Tanenbaum should move out of the 1960's and get with the program.
All of the things you mention are essentially orthogonal to microkernel vs. monolithic.
That is quite incorrect. Microkernels are an attempt to overcome the problems with unsafe, static runtimes and languages by putting components into separate address spaces. If you have a safe, dynamic runtime, you don't need a microkernel architecture.
Kernels and embedded systems are fundamentally different.
That assumption is your and Tanenbaum's mistake. 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. And then you come up with schemes like microkernel architectures to try and work around those self-created problems.
Stick to wimpy user code. Leave OS design to those with experience in that domain.
Yes, and in a nutshell, that sums up the problem: OS designers have an attitude problem. Instead of making it easier for people to modify the kernel, they try to keep it some obscure art form. I think the reason they can get away with it is because kernels matter less and less. Application programmers stopped expecting anything useful from kernel developers long ago and started implementing security, remote file access, hardware access, and other features completely in user code. I suppose it's a form of "microkernel" as well.
I agree 100%. And 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. And it doesn't even have to be Java or C#; languages like Modula-3 or Object Pascal are far safer than C and can get by with a tiny runtime. Heck, even consistent use of C++ for writing kernels would be better than what people are doing now, despite the numerous problems that C++ has.
It is just astounding to me that while anybody else would be laughed at if they tried to write a modern, complex application in ANSI C, operating system designers are somehow considered special, as if concepts like "abstraction", "error handling", and "runtime safety" didn't matter for kernels that are millions of lines big.
The difference is that you can build a microkernel and prove it is reliable, secure, meets performance specifications, etc. No one has been able to do that for a monolithic kernel.
Come on, you yourself must realize that that assertion is preposterous; numerous kernels in applications like smart cards have been formally verified.
(Let's not even go into all the theoretical and practical problems associated with using proof techniques for attempting to establish reliability and security.)
system design to such a level that his work was the BASIS from which Linus was "inspired".
Linus may have been "inspired" to create Linux by the existence of MINIX, but MINIX cannot be said to be the "basis" for Linux. In fact, Tanenbaum's work represents an approach to OS design that UNIX was originally created in reaction to.
His stuff is very much NOT Ivory Tower (I speak as someone who has had to do bespoke OS work) and very practical way to build operating systems
Well, then maybe you can give examples of significant contributions that Tanenbaum has made to systems like UNIX, Linux, Windows NT, Darwin, MPI, PVM, or other major operating systems or distributed programming systems in common use.
(And, no, OSI and writing some nice textbooks, don't count.)
At issue isn't whether Tanenbaum is right or whether he is wrong, at issue is his methdology. 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. Tanenbaum just tinkers and makes grand claims. That's why he should receive a failing grade.
As for microkernels being new, they are not. They have been around for at least a quarter of a century (arguably longer), and they have received more than their fair share of attention and study. There have been many other ideas in OS design since then; if anything deserves attention, it is them.
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. The hypothesis that doing so improves reliability is far more plausible than Tanenbaum's hypothesis that we can stick with using ANSI C if we only use some hare-brained scheme of dividing everything up into separate address spaces. And, in fact, there is actual experimental evidence that using safe runtimes with monolithic kernels is more efficient for fault isolation than using unsafe runtimes with microkernels.
There is nothing to "dispute" since that's not even a meaningful claim. People have built very unreliable microkernels and very reliable monolithic kernels.
So far, there is no data to support the idea that among the many variables that determine reliability (effort, programming language, architecture, testing, etc.), the microkernel/monolithic distinction makes any difference whatsoever.
How can that be? Well, for example, microkernel architectures may complicate software development to the point where less time can be devoted to testing or where essential features can't be implemented at all and the project fails altogether.
If they make stuff for NASA, that's more useful than funding network television.
Tanenbaum rightly criticized Linus for creating a big monolithic operating system kernel, but at least Linus was copying something that was successful and he made it a success himself.
But, geez, how often do microkernels have to fail before Tanenbaum will admit that there must be something fundamentally wrong with his approach, too? Microkernels attempt to address the right problem (kernel fault isolation), just in such an idiotic way that they keep failing in the real world. But instead of a detailed criticial analysis of previous failures, Tanenbaum and Herder just go on merrily implementing Minix3, apparently on the assumption that all previous failures of microkernels were just due to programmer incompetence, an incompetence that they themselves naturally don't suffer from.
Both Linux-style monolithic kernels and Tanenbaum-style microkernels are dead ends. But at least Linux gets the job done more or less in the short term. In the long term, we'll probably have to wait for dinosaurs like Tanenbaum to die out before a new generation of computer science students can approach the problem of operating system design with a fresh perspective.
The $3 billion in subsidy comes from the auction of the spectrum.
It's still public money and it's still a subsidy and government handout to big corporations. I mean, what's the point of using a public resource to generate revenue when you hand the proceeds of the acution right back to the people who paid it?
Let me be clear, this $3 billion isn't coming from some other agency or program, it is coming from the proceeds of the auction.
Yes, and those $3 billion should go to funding NASA, not TV receivers.
Because the government is forcing the television broadcasters to give up their portion of the analog spectrum, in favor of the new Digital standard
No, the government isn't "forcing" anybody; the government is simply changing the terms under which it has been providing a highly valuable resource to broadcaster at a discount price. In principle, the government could cancel the agreement entirely and unilaterally.
MySQL's dual licensing scheme is suspect anyway; while it matters less for a database than for something like a GUI toolkit (where dual licensing is really problematic), dual licensing in general reduces the ability of the community to contribute (because they can't accept contributions under the GPL), makes the developers less responsive to community needs (because the developers attempt to optimize profit in parallel with FOSS goals), and makes it difficult to fork (because any fork would have to compete with the original developer, who has an advantage in being able to derive revenue from commercial licensing). While software like MySQL may ship under an optional open source license, it is not run like an open source development project.
I won't be sorry to see MySQL go anyway; technologically, it is getting better, but there are enough good relational databases out there that are truly FOSS and don't have the same history of technical corner cutting as MySQL.
Of course it can happen in Macs as well, I never said that it couldn't. And what should the Mac do? Give the user an electric-shock if he tries to unplug the device without unmounting it?
I told you what it should do. In a nutshell, it should automatically unmount the device when it is not in use so that I can just unplug it safely when it is not in use.
And if I unplug the device while in use, it should do the obvious thing. So, if I unplug an iPod that is syncing music, some songs don't get transferred, nothing more. And if I unplug a USB stick that I'm writing data to, the data doesn't get fully written, but the file system should remain consistent. Making those things work is something a student could do as a senior project.
Well, iTunes DOES have a text saying "updating iPod" (or something like that) with a progress-bar. And the iPod has a text saying "Do not disconnect". I think those are pretty self-explanatory.
Yes, and that's a problem because there is no reason to tell me that.
Mark my words: Apple is going to fix this in a release or two and do exactly what I described. It's obvious, it's simple, and it's user friendly. And then people like you are going to defend it and are going to tell everybody how amazingly innovative Apple is.
I use toothpaste; YMMV. And now that I got the Nano Tube, it protects the screen quite well.
However, the Nano is worse than other players when it comes to scratching. For example, my Rio Carbon and non-name Chinese players don't have a single scratch on it despite being a year or more old. OTOH, $250 for 4G of flash is not a bad deal.
If we keep our fingers crossed and don't mention the obvious prior art, maybe we get lucky and this thing kills XML. Then, we can go back to the prior art systems, like s-expressions, which were actually a lot nicer and a lot simpler than XML.