Can someone explain to me if the problem with Hurd was that the basic idea was impossible, or it was the way they went about it? 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?
Microkernels were an immensely popular idea in academia (Mach, Minix, …) when Hurd was begun; I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. Microkernel design is probably a good idea, but the message passing overhead kills actual microkernel implementations. I've heard the Windows NT kernel described as being designed like a microkernel architecture (separate m…
Whatever happened to the Hurd? – The story of the GNU OS
41–50 of 93 posts
Re: Whatever happened to the Hurd? – The story of the GNU OS
#42Earlier quoted context omitted.
I thought XNU was considered a micro-kernel because of the Mach part.
To quote that bastion of Jimmy Wales: "Although Mach is often mentioned as one of the earliest examples of a microkernel, not all versions of Mach are microkernels. The project at Carnegie Mellon ran from 1985 to 1994, ending in apparent failure with Mach 3.0, which was finally a true microkernel. Mach and its derivatives are in use in a number of commercial operating systems, … most notably Mac OS X using the XNU op…
Re: Whatever happened to the Hurd? – The story of the GNU OS
#43Can someone explain to me if the problem with Hurd was that the basic idea was impossible, or it was the way they went about it? 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".
Re: Whatever happened to the Hurd? – The story of the GNU OS
#44Can someone explain to me if the problem with Hurd was that the basic idea was impossible, or it was the way they went about it? 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?
Microkernels were an immensely popular idea in academia (Mach, Minix, …) when Hurd was begun; I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. Microkernel design is probably a good idea, but the message passing overhead kills actual microkernel implementations. I've heard the Windows NT kernel described as being designed like a microkernel architecture (separate m…
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...
Re: Whatever happened to the Hurd? – The story of the GNU OS
#45I think there is another story: Not that many people where working on GNU.
The story mentions this. The industry had a working Linux and jumped on board. It is like how the industry jumped on C++, or x64, javascript, or unicode. The small imperfections in form of these tools didn't, at the time of their inception, justify the more massive immediate workload of trying to completely replace them with no backwards compatibility for something without the blemishes. Competitors weren't mature en…
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.
Re: Whatever happened to the Hurd? – The story of the GNU OS
#46Can someone explain to me if the problem with Hurd was that the basic idea was impossible, or it was the way they went about it? 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?
Microkernels were an immensely popular idea in academia (Mach, Minix, …) when Hurd was begun; I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. Microkernel design is probably a good idea, but the message passing overhead kills actual microkernel implementations. I've heard the Windows NT kernel described as being designed like a microkernel architecture (separate m…
[1] This paper, for example, argues that VMMs are "microkernels done right": http://static.usenix.org/event/hotos05/final_papers/full_pap...
Re: Whatever happened to the Hurd? – The story of the GNU OS
#47An oft-quoted phrase that applies here is "the enemy of good is 'better'". 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.
It's easy (and legitimate) to blame the failure of Hurd on poor design and management choices. 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.
Re: Whatever happened to the Hurd? – The story of the GNU OS
#48Earlier quoted context omitted.
Microkernels were an immensely popular idea in academia (Mach, Minix, …) when Hurd was begun; I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. Microkernel design is probably a good idea, but the message passing overhead kills actual microkernel implementations. I've heard the Windows NT kernel described as being designed like a microkernel architecture (separate m…
> I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. 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…
Why, when we already have VMs like Xen which are modern, practical, free, host guest OSes that run at full speed to provide whatever API the applications want, and provide a level of isolation and modularity microkernels never could?
Re: Whatever happened to the Hurd? – The story of the GNU OS
#49IBM 386? What in the world is an IBM 386?