But it has to sit on a separate kernel, doesn't it? Which is Linux. Well, now, you could put emacs on HURD, and then, it would be a pure GNU sysem

The GNU site describes the history of HURD's experimentation w/ different microkernels. It doesn't explain why L4 failed - it just somewhat tersely states that its work stopped in 2005, after which 2 more microkernels - Coyotos and Viengoos - were tried out.

As I've noted elsewhere in this page, they could have simply forked Minix 3, which is small and well documented, and gotten a microkernel that provides all the services that HURD requires. After all, Minix is modelled on Unix and provides the microkernel underpinnings, while HURD provides the upper layers that consume the microkernel services. These 2 could have been a beautiful combination if not for the clashes b/w the licenses.

I meant that in VLIW, you have an MIMD model, which would enable multiple dispatches to happen in the first place, which was also true in Transmeta, but is not true in AMD, due to the fewer security rings. I don't exactly know about the Itanium internals, but I think it's a safe bet that it doesn't have fewer rings than x64. Unless they implement the rings in software, which would change things totally. So scheduler instructions would be travelling in parallel separately from the application instructions, but given the multiple execution units that a VLIW normally has, each will find its own playground without having to take turns

They did try, but failed. The one thing they could have done would have been to fork Minix (since it's a BSDL microkernel) and then build Hurd on top of that. Since Minix is so well documented, they'd have had a better chance had they gone that route.

No, that would be Windows 8. Of course, now we are getting into the realm of silly comments

It's worth noting that Rick Rashid - the original creator of the Mach 3.0 microkernel, works/ed at Microsoft, and also contributed to Dave Cutler's NT project. So it's not surprising that Microsoft would have worked on this concept.

Only problem is that HURD doesn't support SMP. Nor x64. Otherwise, an i7 based system would be ideal - it has all the rings of security that HURD needs, the multi-cores would help w/ the message passing & the context switching, while the x64 would make it relevant by not limiting it to a 4GB address space.

As far as the file systems go, I can't think of ONE that is GPL3, which is what HURD would presumably need. I mean, HURD is GPL3, GNU userland is GPL3 but suddenly, the file system is just GPL2? Even the latest file systems for Linux - be it Btrfs or ext4 are not GPL3. Hopefully, they come out w/ one that doesn't suck

No, they think it's the 80s - when Hurd started, and the i386 came out. Since then, the i386 is all but dead, but Hurd is just now ready for any usage by end users

It would seem that CPUs that have VLIW underpinnings, such as Itanium or the ex Transmeta CPUs, would then be ideal for a microkernel based OS, such as Minix (I'm not thinking about HURD here now, but rather mature established OSs that have microkernels, be it QNX or Minix3 or L4 or Chorus). Since one of the ways of extracting more parallelism from workloads could be separating out say scheduler operations or other context switching, and dedicating one or more CPUs to just those, while having the others do just the processes being done on them and nothing else. At least that way, not only is CPU utilization improved, but so is stability of the OS as a whole, without getting dinged in performance.

For educational purposes, Minix is a much better option. As it is, the OS comes with Tanenbaum's textbook Operating Systems Principles

Uh, no, hypervizors are pretty much the very opposite of microkernels. In microkernels, things like device drivers live in user space, and have to pass messages to the kernel to access particular resources. In hypervisors, you have a mammoth kernel at the bottom that supplies services to all host VMs running over it. In case of VMware, the underlying OS is a Linux variant called the ESX server. Which is certainly not microkernel

From what you are describing, the reason microkernel OSs are slow is the switching from running an unprivileged task (a ring 3 task) to a kernel task (a ring 1 or 0 task). But in that case, given that most modern CPUs are multi-core, doesn't that alleviate that issue? I mean, let's say CPU2 is busy doing somethig and an application needs to make a system call, can't that call go to CPU0? That way, CPU2 merrily keeps humming along, and one of the unutilized CPUs starts getting utilized. Also, most processes don't make full use of the extra cores, but if you have a microkernel OS, can't all that task switching be avoided simply by using, say, different cores? Like use CPU0 for ring0, CPU1 for ring1, and so on (since most systems are quad core or more, and you can then route any system request to particular CPUs dedicated for just that)

Is RMS associated w/ HURD any more? He is on record as having endorsed Linux over it.

As some of the above mentioned, QNX is pretty popular, albeit under the hood, so few know about it, although it's also used now by RIM. Also, Mach 3 has been the backbone of OSF/1 and some other OSs. Aside from them, Minix 1 & 2, which were not microkernel, were meant for just educational purposes, but Minix 3 is a microkernel and aimed at embedded systems as well.

That is ironic, given that RMS has always belittled the concept of 'open source' and emphatically stated that the purpose was not to build better software, but to build liberated software. In fact, his philosophy has more tolerance for shabbily written code, as long as it allows the 4 GNU freedoms. Given that, HURD should have been able to be whipped up really quick, but it wasted years experimenting from one microkernel to another. I know the licenses don't allow it, but if it did, taking HURD and putting it on top of Minix3 would give it the best of both worlds