Clearly RMS wanted his idea of perfection, and almost 30 years on, perfection remains out of reach while "good enough" rules the world on Linux.
An important lesson to learn.
I think it's also instructive, though, to observe how no "better than Unix" project has really attained any success. Some of them have delivered more workable code than Hurd, but Plan 9, Inferno, Amoeba - none of them have really caught on.
Stallman later admitted, “I take full responsibility for the technical decision to develop the GNU kernel based on Mach, a decision which seems to have been responsible for the slowness of the development. I thought using Mach would speed the work by saving us a large part of the job, but I was wrong.”
He made what he thought was a pragmatic choice that ended up being wrong, not the "perfect" kernel.
The idea is that if Linux were not available, the open source community would have been working in Hurd and not in Linux. But without Linus perhaps the community could not exist (new member leave after a few quarrels) or all the effort is lost in complete rewrites.
i.e. was it the relentless restarting of the project that was to blame, or did they keep restarting because every way they approached it turned out to be impossible?
The GNU project tended to work very cathedral like, while Linux was very bazaar like. The latter meant people could support and update the kernel for their own devices ("crowdsourcing" in today's terminology). http://www.catb.org/esr/writings/homesteading/cathedral-baza...
To give you an idea of how many shortcuts Linux took, the way the original kernel worked was that it used a single large address space. Each process was slotted into 64MB of that address space. That left you with a maximum of 63 processes. A context switch just involved changing protections to enable the appropriate slot. This is far more lightweight than how Linux now and other operating systems do it with no such process limits and a far more heavyweight full address space switch. Back then it made Linux really fast at process switching. This is an example of "worse is better": http://en.wikipedia.org/wiki/Worse_is_better
What the detractors didn't realise is that the initial simplistic Linux implementation could evolve away the constraints, and were instead betting on up front "intelligent design".
I've heard the Windows NT kernel described as being designed like a microkernel architecture (separate modules with clear APIs), but with direct function calls instead of message passing. I don't know if the Linux/BSD kernels are much different — I've poked at all three, and at a high level they look very similar.
On the contrary, the idea that performance of microkernels is "horrible" is the current received wisdom, believed by the majority of programmers without critical examination, and based on very performance-poor early microkernel designs like Mach.
The truth is that modern microkernel designs like L4 can perform IPC over 20 times faster than Mach. Another important advance for microkernels are tagged TLBs which can alleviate the TLB misses that are usually incurred on every context switch.
Someday, hopefully not too far in the future, someone is going to write a modern, practical, and free microkernel-based OS that implements all of POSIX with performance the rivals Linux, but that offers a level of isolation and modularity that Linux could never offer. When that happens, a lot of people are going to scratch their heads and wonder why they believed the people who told them that microkernels are "fundamentally" slow.
I had hoped that HelenOS would become this (http://www.helenos.org/), but its lowest-layer ipc abstraction is async-based, which I think is a mistake. One of L4's innovations was to use sync IPC, which offers the highest possible performance and gets the kernel out of the business of queueing. You can always build async ipc on top of sync without loss of performance; this puts the queues in user-space which is where they belong (they're easier to account for this way).
I asked the HelenOS people why they decided to go this way, and this is their response (one of their points was "the L4's focus on performance is not that important these days", which I disagree with). http://www.mail-archive.com/helenos-devel@lists.modry.cz/msg...
[1] This paper, for example, argues that VMMs are "microkernels done right": http://static.usenix.org/event/hotos05/final_papers/full_pap...
http://ertos.nicta.com.au/research/l4/ http://ssrg.nicta.com.au/publications/papers/Heiser_08lca.sl...
Microkernels can be just as fast as macrokernels and other than raw throughput can give latency guarantees that a macrokernel can't.
Message passing overhead can be minimized (by using the paging mechanism for passing messages between tasks on the same node).
It would probably be more elegant to just run Hurd or whatever instead of for example running multiple JVMs on top of multiple Linux instances on top of a hypervisor (yes, this happens), but them's the breaks.
(J/K)
Micro kernels are very hard to debug.
Microkernels are not harder to debug than monolithic kernels. I'd even say that they are easier to debug, much easier. (Personal experience in debugging both.)
The problem with microkernel-based OSes is, as Linus Torvarlds aptly put it, that they turn well understood memory-protection problems into not-so-well-studied IPC problems. (The actual quote is «They push the problem space into communication, which is actually a much bigger and fundamental problem than the small problem they are purporting to fix.»)
The microkernel is not the real problem here, the big issue is debugging faulty IPC sequences between the servers that implement the OS services. A problem that is almost non-existent in monolithic kernel.
HOWEVER, current monolithic kernels are facing growth problems now because of two aspect: we want fancy remote storage accessed as easily as local storage (do you want to mmap a file stored in a RAID setup implemented with SATA-over-ethernet disks?) and the fact that the process model is too leaky and so we need stronger containers like VMs (that are becoming as much leaky abstractions as the current processes). All these new features require communication between various components that were previously though and implemented as independent. This means that the IPC problems are now creeping into the world of monolithic kernels.
Compared to say an SOA platform with 200 service endpoints, a database with about 2000 tables, integration with 15 other providers with XML, CSV, SFTP and some wierd shitty non standard binary protocol. All written entirely by the lowest bidder without unit tests because they knocked the budget up. Oh and with a toolchain which barely works and no VCS system past an old corrupt source safe database full of compiled DLLs which there is no source for any more.
I've done both and am currently stuck doing the latter - I'd rather poke one of my eyes out and debug a microkernel if I had a choice.
Absolute nonsense. Micro kernels are much easier to debug than macro-kernels.
The reasons are obvious to anybody that has spent more than an afternoon working with both, a microkernel is so small that the chances that your problem is in the kernel are minute compared to having your problem in user space. That means that all your luxury debug tools are available to debug the vast majority of your problems.
After the initial write the kernel code of a microkernel system is hardly ever touched. A good microkernel will limit itself to do the most limited subset that will still allow the system to function and will move everything else to regular processes.
I think that might be one of the lesser appreciable legacies of 80s - 00s in software. We have tools that are now really showing their flaws but we built the empire on cracked bricks and the unstable foundations force us to throw more man hours and effort into keeping the whole thing standing than if we just started with a fresh foundation when the better alternatives presented themselves, even if they would have taken some more work.
I still really wonder where we would be if we had a C++ with a clean grammar and Python level readability. Where we didn't try to layer interpreters and JITs over convoluted C ABI compatibility.
Basically, by designing exactly the necessary language for each layer, they've reduced the code requirements to reach useful applications by multiple orders of magnitude.
I honestly wouldn't be surprised if the results of this project eventually creep into industry.
So true. It's unfortunate AT&T/Unix System Laboratories kept the BSD kernel code locked up in a lawsuit. Would have loved the article to have had a deeper insight into that as Stallman had already chosen to abandon Hurd by the time Linux came around.
It wasn't just that Linux was available, it was that BSD wasn't. It's too bad that the last few years have seen a decline in FreeBSD / other BSD OS's especially as it is an amazing operating system still light years ahead of GNU/Linux is many areas. Not to mention that it's one unified OS rather than hundreds of GNU/Linux distros.
One can only imagine what would have happened had the BSD code not been tied up in lawsuits. I bet they would have gone with the mature BSD kernel, leading to a better OS, and Linux would probably be a footnote in history if that.
Interesting how inferior technology wins a lot more than it loses. That said, I still love GNU/Linux. :)
I admittedly haven't used any BSD enough to make a well informed opinion but I was under the impression that BSDs are fragmented at the OS level (i.e.: different kernels), while Linux is fragmented at the distribution level (i.e.: default collection of software, file-system layout, etc).
I imagine that, in addition to there being different kernel flavors there are also distribution level differences (e.g.: there are subtle differences between FreeBSD's rc.conf and NetBSD's) so I'm not sure which approach is better or worse, but I tend to lean on the "one kernel, several distributions" camp.
GNU/Linux is one OS with hundreds of distros. That's fragmentation.
Likely. For myself, in 1993 I recall being totally underwhelmed with Windows 3.1 when I got my first 386 SX PC. I went looking for something better and came across some BSD derivatives and Linux. I knew that there were some vague legal issues with BSD, so I chose to download the 30 or so SLS floppies that made up a Linux "distribution" and I haven't looked back since.
One of the most valuable opportunities with mobile is that current technologies can become irrelevant. A big success for L4 is that it made it into mobile phones.
IBM 386? What in the world is an IBM 386?
Very interesting. Thank you.
On the other hand, it's ridiculous to think of how far things have come since then... people who complain about Linux usability and driver issues in 2012 really don't know what they missed!
[1] and failing!
