Assuming XNU was indeed a mach-like microkernel (which it's not, it's a "hydrid" kernel), Apple would get a huge bump in performance. Something like a 80% increase on a more modern microkernel like L4.
I agree with most of your points, and feel that there is a large amount of arbitrarity in the microkernel vs monolithic kernel debate. It IS indeed possible to design a monolithic kernel well (look at the BSD's, esp. DragonFly). It is also possible to design a monolitich kernel very poorly. It's possible to design a microkernel well and poorly (l4, qnx vs mach). What I disagree with are people who ignore Scientific evidence and replace it with religious dogma, apparent all over this thread.
So Mr. T says Microkernels are good. So what? Let him live in his world, develop his pet OS that will attempt to make a general purpose microkernel, and see if it works. Until it does or it doesn't, shut up about it! Don't assume it will be crap because your linux-guru friend that you look up to oh so much told you all microkerels are crap (No, i'm not referring to you, but the general sentiment on slashdot). If some dudes want to work on a microkernel, let them work on a microkernel. And in the meantime, read up on the RECENT research before sticking your neck out.
I also disagree with your characterization of Mr. T's comments towards slashdot. In my experience, most slashdotters have no idea what they're talking about. I happen to agree with his characterization of the slashdot response to the original article he got published in IEEE. Most of it was baseless, and the comments that had a base were mostly founded on old, irrelevant studies.
I'm aware of the history of linux, thank you very much. But it's longevity and development curve has nothing to do with minix. AT ALL. It's irrelevant. My point was that you're selling minix's recent developments far too short. Minix stopped being actively developed for a REASON: it was a EDUCATIONAL OS back then and increasing complexity would only serve to defeat that purpose! Now it is NOT an educational OS, rather it is striving to be a GENERAL PURPOSE OS and has increased it's development click dramatically. It's not because people suddenly lost interest, as you seem to imply, or that it was a go-nowhere project. It had completed it's goal during that time. Period.
After posing a theory, the next scientific step is to find proof of the theory by observing/measuring.
Proof? No. Support. There is no such thing as "proof" in science, proof is an attempt to irrefutably reason using theory (ie, mathematical proofs, logical proofs, etc). They have no place in Science because science relies on refutable statements. Science, in practice, only refutes or supports. It does not prove.
Back to the issue at hand, if you want evidence of the utility of a general purpose microkernel check l4linux here and here with this one being the paper most relevant to the discussion.
They report less than a 5% slowdown on x86 kernels, which is below the realm of significance in science (10%+ is significant). If this is true, I doubt the user would even be able to percieve the difference. If you want details on their numbers, read the papers. As far as i'm concerned, the microkernel community HAS provided evidence to refute the claims that their architecture incurs an unacceptable performance hit. It just seems people either ignore the evidence, or are so stooped in their own dogma that they refuse to believe it. If you don't believe it, maybe you should give l4linux a try and see how general purpose a microkernel can actually be.
The available measurements don't look good for the microkernel theory.
I'd like to see the measurements that are based on modern microkernels like l4, coyotos or QNX, and not Mach. Mach is, indeed, extremely slow. But it's also extremely old and fairly out of date as far as microkernels go. It would be like comparing linux to OS/2 and saying "LOOK! Linux is way better than anything IBM puts out!"
If you're trying to be fair, then really be fair. Minix 1 was never meant to be functional. It was meant as a teaching aid. Minix 3 was written in scratch over the last year by three people, and it is a functional OS that can be used right now. While "minix" existed way before linux, this iteration of it has not. It has, actually, developed quite quickly to this point on very limited resources.
Except, most of the stuff you would mess with would be in userland in a microkernel (the actual kernel would just be an interface to which things like filesystems, audio and video subsystems, etc talk to). So, you could still mess with it, tweak it...and not have to reboot. That is, to me, a huge plus of microkernels. Say a new audio subsystem is in development to replace Minix 3's implementation of OSS. Want to try it? Compile the server, unload the OSS server, load up the new server, boom. You're done. No rebooting. No recompiling the entire kernel for the low-level hooks needed to make it work. Want to try a new VM subsystem? Same deal.
More like, the problem has shown it will not go away, so Mr. T is trying to show us a way that will basically make the problem go away from the user's perspective.
Here's the thing. In a general purpose OS, you can't control code quality as well as you would like (for example, look at the quality of the linux kernel code. Sure, it works, but there's a difference between efficacy and quality). This is the main problem a microkernel tries to overcome. If there is a bad driver, and you're running a system that requires extreme uptime and availability, the entire system won't die. The resuretion server senses the death of a driver or server and restarts it, giving you a fault-tolerant, usable system.
It's all well and good for you to be bitched out for writing bad code. Infact, that's a VERY good thing. However, don't assume that microkernel systems exists as a crutch to programmers. That's just plain wrong. It exists as a firewall between users and crappy code. I would also venture to say that its inherent modularity will allow developers to pay more attention to the actual working bits of their code, and spend less time developing kludges and hacks to get their drivers working in a monolithic system.
The bottom line is this. Say you've built an OS. Some corporations decides they want their pro-audio card to work on your OS. They design, program, and compile their driver and release it. Users around the world start using this driver, and it sucks. Sucks ass. The developer was drunk most of the time he was coding it. From here there are two possibilities:
1) You have a monolithic system. In this case, the driver brings the entire system down, causes all kinds of mysterious problems for end users (see windows 95 - windows 2000, and linux circa early nvidia drivers). Your users are not happy. They point the finger at you. You're chastized on Slashdot (well, except for linux, then they rationalize away the problem with different ridiculous excuses).
2) You have a microkernel system. The driver doesn't cause any noticable change to end users. Your system stays up and e-mails you that the driver is failing, with dumps and failure information. You send these to the company, the company fixes the driver (hopefully).
This is how *I* view the microkernel vs monolithic kernel debate. I think the system response issues are mostly overblown and based on out-of-date models (Mach and Minux 1 are definitely out of date microkernels - l4 seems to have response times that are measurably slower, but mostly unnoticable to the end user). I think this is a valuable area of research and I look forward to minux 3 maturing and becoming more usable.
Interesting. Just sitting in front of KDE for 10 minutes gives me a headache. Gnome, not so much. Also, 100% of the GUI apps i use are GTK+ apps, and I can't stand their qt equivalents. So...why would *I* want to choose KDE over gnome?
Well, i actually use pwm, but if i want a DE, i go with gnome.
While I tend to agree, the boot manager set up could be easier. I'd love to see an option in the main installer menu to just reinstall the installer to the boot loader. Right now its kind of mickey mouse.
There are always little annoyances, though. With Ubuntu, in order to get multimedia fully working with all the 32-bit codecs one might need for audio and video, you either have to sift through thousands of packages in synaptic, or run a third-party, unsupported script that could be easily tampered with. On gentoo, masking and unmasking is dangerous and generally does more harm than good. On FreeBSD, what's there is there. There's no need for stable, testing, unstable, and nuclear-waste branches, as everything that is in ports is stable. The ports framework hasn't changed in the years i've been using it. The system is easily modifiable after some general use (ie, you can force it to work when it decides not to - which is extremely rare).
The most comparable system i've seen - that is, the system that accomplishes the third party software installation goal with the least ammount of over-engineering - is pacman. Similar in that the build scripts are no-brainers, the package installer is elegant from the command line, and it just works. Portage, in comparison, is like an ape that's all feet and no legs.
Well, here's my two cents. I recently converted my caomputer over to a freebsd-only environment with two 7200 RPM sata drives striped (dangerous, sure, but I have a file server to hold important things that i don't want to lose). A couple nights ago i decided to see if default, out of the box multitrack recording has improved. So, i installed audacity, started recording one acoustic guitar track, then layed anohter on top. Playback was horrible. The first track recorded beautifully, but the second track (even when listening to it by itself) was distorted and extremely low quality.
I'd be interested to know what tweaks I can pull to make it be a better recording machine. I have very low-end hardware (ie, onboard sound), but i can record multitrack in audacity under both linux and windows, thus I *should* be able to do it in freebsd. Any help?
Gnome is not more usable under freebsd than in linux, neither the reverse.
Not totally true. Things like HAL are still a little sloppy (if even existant?) on FreeBSD. As gnome becomes more reliant on little userland daemons that make things magically appear on your desktop, the state of FreeBSD's port of Gnome falls behind. The main difficulty to note, however, is that the coders for projects like HAL and dbus generally write code that is very tied into linux kernel specifics and is not greatly portable. And, of course, FreeBSD's main focus has been on making a server OS that is fast, reliable, and fairly general. It seems now they're trying to get in on some of the fancy shit linux has been flaunting. I sure ain't got no problem with it.
I can see that reasoning, and i certainly don't agree with outsourcing (i'm vehemently against it, and most globalization practices), however is that reasoning enough to convince top-level managers not to outsource? Will the quality to the end user be visible enough to justify the decreased margins of maintaining a US or Canada based code farm? This is the area where a Union - perhaps not a union in the classical, heavy-handed draconian sense but SOME KIND of employee organization - could be brought in to help convince upper management that the returns from putting out a product whose coder base is centralized far exceeds the costs associated.
It was, yes, but at the time it was encumbered by lots of AT&T code. Lawsuits were flying, developers didn't want to touch it until that cleared up...which offered linux enough time to gain the momentum it needed to develop it's legendary mind-share. That said, the resulting projects that came out of 386BSD (open, free, net, and the darwin userland) are nothing to scoff at.
Slashdot Mirror
Your post just shows that you're either a troll, or have no idea what you're talking about.
Assuming XNU was indeed a mach-like microkernel (which it's not, it's a "hydrid" kernel), Apple would get a huge bump in performance. Something like a 80% increase on a more modern microkernel like L4.
Yeah, well, reality is dystopian.
developers and "opinion leaders" can be replaced.
Your views most likely represent 1/10th of 1% of their userbase. They're not worried about this aspect, and they have no practical reason to be.
I agree with most of your points, and feel that there is a large amount of arbitrarity in the microkernel vs monolithic kernel debate. It IS indeed possible to design a monolithic kernel well (look at the BSD's, esp. DragonFly). It is also possible to design a monolitich kernel very poorly. It's possible to design a microkernel well and poorly (l4, qnx vs mach). What I disagree with are people who ignore Scientific evidence and replace it with religious dogma, apparent all over this thread.
So Mr. T says Microkernels are good. So what? Let him live in his world, develop his pet OS that will attempt to make a general purpose microkernel, and see if it works. Until it does or it doesn't, shut up about it! Don't assume it will be crap because your linux-guru friend that you look up to oh so much told you all microkerels are crap (No, i'm not referring to you, but the general sentiment on slashdot). If some dudes want to work on a microkernel, let them work on a microkernel. And in the meantime, read up on the RECENT research before sticking your neck out.
I also disagree with your characterization of Mr. T's comments towards slashdot. In my experience, most slashdotters have no idea what they're talking about. I happen to agree with his characterization of the slashdot response to the original article he got published in IEEE. Most of it was baseless, and the comments that had a base were mostly founded on old, irrelevant studies.
I'm aware of the history of linux, thank you very much. But it's longevity and development curve has nothing to do with minix. AT ALL. It's irrelevant. My point was that you're selling minix's recent developments far too short. Minix stopped being actively developed for a REASON: it was a EDUCATIONAL OS back then and increasing complexity would only serve to defeat that purpose! Now it is NOT an educational OS, rather it is striving to be a GENERAL PURPOSE OS and has increased it's development click dramatically. It's not because people suddenly lost interest, as you seem to imply, or that it was a go-nowhere project. It had completed it's goal during that time. Period.
After posing a theory, the next scientific step is to find proof of the theory by observing/measuring.
Proof? No. Support. There is no such thing as "proof" in science, proof is an attempt to irrefutably reason using theory (ie, mathematical proofs, logical proofs, etc). They have no place in Science because science relies on refutable statements. Science, in practice, only refutes or supports. It does not prove.
Back to the issue at hand, if you want evidence of the utility of a general purpose microkernel check l4linux here and here with this one being the paper most relevant to the discussion.
They report less than a 5% slowdown on x86 kernels, which is below the realm of significance in science (10%+ is significant). If this is true, I doubt the user would even be able to percieve the difference. If you want details on their numbers, read the papers. As far as i'm concerned, the microkernel community HAS provided evidence to refute the claims that their architecture incurs an unacceptable performance hit. It just seems people either ignore the evidence, or are so stooped in their own dogma that they refuse to believe it. If you don't believe it, maybe you should give l4linux a try and see how general purpose a microkernel can actually be.
The available measurements don't look good for the microkernel theory.
I'd like to see the measurements that are based on modern microkernels like l4, coyotos or QNX, and not Mach. Mach is, indeed, extremely slow. But it's also extremely old and fairly out of date as far as microkernels go. It would be like comparing linux to OS/2 and saying "LOOK! Linux is way better than anything IBM puts out!"
If you're trying to be fair, then really be fair. Minix 1 was never meant to be functional. It was meant as a teaching aid. Minix 3 was written in scratch over the last year by three people, and it is a functional OS that can be used right now. While "minix" existed way before linux, this iteration of it has not. It has, actually, developed quite quickly to this point on very limited resources.
Except, most of the stuff you would mess with would be in userland in a microkernel (the actual kernel would just be an interface to which things like filesystems, audio and video subsystems, etc talk to). So, you could still mess with it, tweak it...and not have to reboot. That is, to me, a huge plus of microkernels. Say a new audio subsystem is in development to replace Minix 3's implementation of OSS. Want to try it? Compile the server, unload the OSS server, load up the new server, boom. You're done. No rebooting. No recompiling the entire kernel for the low-level hooks needed to make it work. Want to try a new VM subsystem? Same deal.
Why wouldn't slashdotters want that? Oh, right. Because linus says it's wrong.
More like, the problem has shown it will not go away, so Mr. T is trying to show us a way that will basically make the problem go away from the user's perspective.
Here's the thing. In a general purpose OS, you can't control code quality as well as you would like (for example, look at the quality of the linux kernel code. Sure, it works, but there's a difference between efficacy and quality). This is the main problem a microkernel tries to overcome. If there is a bad driver, and you're running a system that requires extreme uptime and availability, the entire system won't die. The resuretion server senses the death of a driver or server and restarts it, giving you a fault-tolerant, usable system.
It's all well and good for you to be bitched out for writing bad code. Infact, that's a VERY good thing. However, don't assume that microkernel systems exists as a crutch to programmers. That's just plain wrong. It exists as a firewall between users and crappy code. I would also venture to say that its inherent modularity will allow developers to pay more attention to the actual working bits of their code, and spend less time developing kludges and hacks to get their drivers working in a monolithic system.
The bottom line is this. Say you've built an OS. Some corporations decides they want their pro-audio card to work on your OS. They design, program, and compile their driver and release it. Users around the world start using this driver, and it sucks. Sucks ass. The developer was drunk most of the time he was coding it. From here there are two possibilities:
1) You have a monolithic system. In this case, the driver brings the entire system down, causes all kinds of mysterious problems for end users (see windows 95 - windows 2000, and linux circa early nvidia drivers). Your users are not happy. They point the finger at you. You're chastized on Slashdot (well, except for linux, then they rationalize away the problem with different ridiculous excuses).
2) You have a microkernel system. The driver doesn't cause any noticable change to end users. Your system stays up and e-mails you that the driver is failing, with dumps and failure information. You send these to the company, the company fixes the driver (hopefully).
This is how *I* view the microkernel vs monolithic kernel debate. I think the system response issues are mostly overblown and based on out-of-date models (Mach and Minux 1 are definitely out of date microkernels - l4 seems to have response times that are measurably slower, but mostly unnoticable to the end user). I think this is a valuable area of research and I look forward to minux 3 maturing and becoming more usable.
Yes, but I would pick assiting in scientific research over farming code for some random corporate application anyday.
Interesting. Just sitting in front of KDE for 10 minutes gives me a headache. Gnome, not so much. Also, 100% of the GUI apps i use are GTK+ apps, and I can't stand their qt equivalents. So...why would *I* want to choose KDE over gnome?
Well, i actually use pwm, but if i want a DE, i go with gnome.
reinstall the installer to the boot loader
make that "reinstall the boot loader to the MBR."
While I tend to agree, the boot manager set up could be easier. I'd love to see an option in the main installer menu to just reinstall the installer to the boot loader. Right now its kind of mickey mouse.
There are always little annoyances, though. With Ubuntu, in order to get multimedia fully working with all the 32-bit codecs one might need for audio and video, you either have to sift through thousands of packages in synaptic, or run a third-party, unsupported script that could be easily tampered with. On gentoo, masking and unmasking is dangerous and generally does more harm than good. On FreeBSD, what's there is there. There's no need for stable, testing, unstable, and nuclear-waste branches, as everything that is in ports is stable. The ports framework hasn't changed in the years i've been using it. The system is easily modifiable after some general use (ie, you can force it to work when it decides not to - which is extremely rare).
The most comparable system i've seen - that is, the system that accomplishes the third party software installation goal with the least ammount of over-engineering - is pacman. Similar in that the build scripts are no-brainers, the package installer is elegant from the command line, and it just works. Portage, in comparison, is like an ape that's all feet and no legs.
Well, here's my two cents. I recently converted my caomputer over to a freebsd-only environment with two 7200 RPM sata drives striped (dangerous, sure, but I have a file server to hold important things that i don't want to lose). A couple nights ago i decided to see if default, out of the box multitrack recording has improved. So, i installed audacity, started recording one acoustic guitar track, then layed anohter on top. Playback was horrible. The first track recorded beautifully, but the second track (even when listening to it by itself) was distorted and extremely low quality.
I'd be interested to know what tweaks I can pull to make it be a better recording machine. I have very low-end hardware (ie, onboard sound), but i can record multitrack in audacity under both linux and windows, thus I *should* be able to do it in freebsd. Any help?
Well, it's called video4linux for a reason.
fvwm2? Pft. Bloatware. You should try pwm.
Gnome is not more usable under freebsd than in linux, neither the reverse.
Not totally true. Things like HAL are still a little sloppy (if even existant?) on FreeBSD. As gnome becomes more reliant on little userland daemons that make things magically appear on your desktop, the state of FreeBSD's port of Gnome falls behind. The main difficulty to note, however, is that the coders for projects like HAL and dbus generally write code that is very tied into linux kernel specifics and is not greatly portable. And, of course, FreeBSD's main focus has been on making a server OS that is fast, reliable, and fairly general. It seems now they're trying to get in on some of the fancy shit linux has been flaunting. I sure ain't got no problem with it.
Depends on the person, but I could not stomach writing code from someone else's program...being their code bitch. To me, that is slavery, not a job.
I can see that reasoning, and i certainly don't agree with outsourcing (i'm vehemently against it, and most globalization practices), however is that reasoning enough to convince top-level managers not to outsource? Will the quality to the end user be visible enough to justify the decreased margins of maintaining a US or Canada based code farm? This is the area where a Union - perhaps not a union in the classical, heavy-handed draconian sense but SOME KIND of employee organization - could be brought in to help convince upper management that the returns from putting out a product whose coder base is centralized far exceeds the costs associated.
It was, yes, but at the time it was encumbered by lots of AT&T code. Lawsuits were flying, developers didn't want to touch it until that cleared up...which offered linux enough time to gain the momentum it needed to develop it's legendary mind-share. That said, the resulting projects that came out of 386BSD (open, free, net, and the darwin userland) are nothing to scoff at.