IRC, freenode, #hurd, 2012-01-13:

<veganman> sothere's absolutelyno way,evenslowly to run i386 linuxcode
  under hurd/i386? Ihave a small app, commercial, which I have to get
  running there
<veganman> no source
<braunr> no way
<braunr> you'd need to create a userspace linux server catching linux
  system calls and calling hurd specific stuff to implement them
<braunr> it doesn't exist, it may be hard to implement
<braunr> some cases will definitely be hard to implement
<veganman> so, no magic linux lxemu on windows?
<veganman> or linuxemu on plan9
<pinotree> nope
<veganman> I remember somethingsilly, sonmone hadcompiled linux asauser
  applicationon plan9 and inserted his own binaries as
  acodeobject,toberunon plan9, for useon ibm hpc hatrdware
<veganman> it was ron minich
<veganman> 5e.iwp9.org/slides/linuxemu.pdf
<veganman> I think that was it
<veganman> google for linux & cnk for additional clues

IRC, freenode, #hurd, 2012-01-21:

<chromaticwt> is it possible to transfer servers running on one microkernel
  on one machine, to another microkernel running on a different machine?
<chromaticwt> two machines will be running the complete os
<antrik> well, if the code for network-transparent IPC still existed, it
  might be possible to move a task to another machine, while keeping the
  port associations with the original system...
<antrik> if you mean actually moving it to another system, that's pretty
  much impossible in any system that has stateful interfaces

How difficult is it to port the GNU/Hurd system to run on another architecture?

The GNU/Hurd system consists of Hurd servers running as user-space processes on top of the GNU Mach microkernel. The system functionality is usually accessed through the POSIX interface that is provided by glibc and libpthread.

A whole-system port involves touching all these components, with varying degree, of course.

For a CPU architecture port, the microkernel is the most involved part, followed by glibc and the threading library.

The original Mach microkernel was portable to a number of architectures which were a lot more popular at the beginning of the 1990s than they are now.

The GNU/Hurd system is currently available for the x86 architecture. This includes emulators such as QEMU (or KVM), or VirtualBox. Besides this, there is a port for the Xen domU sub-architecture.

Further on, there are some unfinished porting attempts for the Alpha, MIPS and PowerPC architectures. These have not been completed due to little developer interest.

Another option is to do the port at a different layer: port the Hurd servers to not run on the GNU Mach microkernel, but instead on top of another microkernel. Or, even by providing a Mach emulation layer on top of a monolithic kernel. For example, there could be a port for having Mach run as a POSIX user-space process, or by implementing the Mach IPC facility (as well as several others) as Linux kernel modules. While there have been some experiments, no such port has been completed yet.

It is a frequently asked question, which microkernel the Hurd should be based upon assuming that Mach is no longer considered state of the art, and it is well known that there has been a lot of discussion about this topic, and also some code produced, but then, years later, the Hurd is still based on GNU Mach.

Around the turn of the millenium, some of the Hurd developers began experimenting with using other microkernels for the Hurd, as they have been encountering a number of fundamental design issues with the Mach microkernel, mostly with respect to resource management problems.

At that time, L4 (Pistachio) was the prime candidate. A reimplementation of the Hurd on this microkernel looked promising, and got pretty far (running some simple POSIX programs, such as banner). However, over time some lingering design issues turned out to be fundamental problems: the original L4 is not suitable for building object-capability systems like the Hurd. Thus development was aborted in 2005.

During that process, Neal Walfield and Marcus Brinkmann started on a period of research on other microkernels, getting in deeper contact with other researchers. There was a lot of discussion, and a lot of good ideas produced, but a straight-forward port of the Hurd to such a modern microkernel (Coyotos, or the new L4 variants, for example) didn't seem feasible to them anymore: they found microkernel design and system design to be interconnected in very intricate ways, and this demanded design changes in the Hurd's core itself.

Based on this experience, the next step was to write an own microkernel instead, which Neal Walfield began doing with his experimental Viengoos project, for his research on resource management. Currently he works in another research area though, and thus Viengoos is on hold.

Note that while none of the microkernel research work is active now, the previous experiments already yielded a lot of experience, which will be very useful in the further development / improvement of the mainline (Mach-based) Hurd implementation.

For more details about this topic, please see our history page about the port to another microkernel.

The Hurd servers themselves are multithreaded, so they should be able to take benefit of the parallelism brought by SMP/Multicore boxes. This has however never been tested yet because of the following.

Mach used to be running on SMP boxes like the Intel iPSC/860, so principally has the required infrastructure. It has however not yet been enhanced to support nowadays' SMP standards like ACPI, etc. Also, GNU Mach's Linux device driver glue code likely isn't SMP-safe. As this glue code layer is not used in the Xen port of GNU Mach, the plan is to try it in this enviroment first.

That is why for now GNU/Hurd will only use one logical processor (i.e. one core or one thread, depending on the socket type).

Once this issue is solved, there are follow-up issues about multiprocessing and multithreading.

Is it favorable of rather a hindrance to be compatible to POSIX and similar standards?

A lot of things in POSIX et al. are designed for UNIX-like systems with traditional monolithic kernels.

Thus, a microkernel-based system, as ours is, has to employ a bunch of detours, for example to implement the fork system call.

On the other hand, (mostly) complying to these standards, made a really big body of software just work without any (or just trivial) porting. Especially so for command-line programs, and libraries.

But: a large part of today's user programs are not written according to POSIX et al. low-level interfaces, but against GNOME, GTK+2, and other high-level frameworks and libraries. It may be a valid option to enrich these instead of striving for total POSIX compliance -- and the high-level programs (that is, their users) may not even notice this, but we would avoid a lot of overhead that comes with wrapping the Hurd interfaces to be POSIX compliant.

GHAMP is the GNU/Hurd-based Apache, MySQL, PHP solution stack -- analoguous to GLAMP, which is based on GNU/Linux.

Pronounce it like the G in GNU, followed by a mostly silent H, and AMP as in amplifier.

How Many Developers?

One handful works on the core of the system in their free time, and another handful helps with Debian GNU/Hurd and Arch Hurd packaging. Also, an additional handful of former developers are still available for answering technical questions, but are not participating in the current development anymore.

In the past (that is, a lot of years ago), the FSF did pay a few developers for working full time on the GNU Hurd. But that was for a limited amount of time only, and evidently, it was too little for getting the system into a competitive state. Nowadays, it's only unpaid (apart from some bounties) and free-time volunteers' work.

In contrast to the Linux kernel, there is no industry involvement in development. For one, this is a good thing: independency; no conflicts of interests. For another, it is also a bad thing: no dedicated full-time manpower -- which matters a lot.

Why So Few?

We can only speculate. One major problem might be that the architectural benefits are generally perceived as very abstract, with little practical benefit. We currently don't have many tools that are actually making use of all the possibilities.

Another reason is that it's been taking too long. Today, most people don't believe it will ever be ready for production use, and thus would consider involvement a waste of time. This latter point is invalid, of course, as learning can never be a waste of time. The same holds for the challenges raised by the GNU Hurd -- we can only learn and improve upon working on them.

For likely the same reasons there is no industry interest in the GNU Hurd: its advantages are too abstract and incomplete for being of interest there.

As for the scientific sector, the GNU Hurd projects was rather about using a microkernel intead of doing research on them, for example. But, there have been some projects and theses done, and some scientific papers published on GNU Hurd topics, and we're generally very interested in further such projects.

Attracting New Faces

We're an open project: any interested party (you!) are very welcome to start contributing. Mentoring is possible, too, to help you get started.

Likewise, for reaching out to new developers, we're participating in Google's Summer of Code program.

Question: Could it be possible to have a system installation where you can dual-boot using either the ?Linux kernel, or the GNU Hurd, so that everything but the kernel is shared?

Answer: Given that both Linux and GNU Hurd are using the ?ELF binary format, this could indeed be made possible, if all programs agreed to rely on only one abstraction layer, for example the standard C library (glibc). (Additionally, for example for system calls that are not covered by glibc calls, you'd need to be able to reliably trap and emulate these.) However, Linux' and the GNU Hurd's ?ABI's have sufficiently diverged, so that this is not easy to do. That's why you can't currently install a system in this way, but you need a separate installation of the userspace suited for the Linux kernel, or the GNU Hurd.