Supporting a GNU Hurd port?

John Moser john.r.moser at
Tue Dec 8 17:26:07 UTC 2009

On Tue, Dec 8, 2009 at 12:14 PM, Scott James Remnant <scott at> wrote:
> On Tue, 2009-12-08 at 01:38 -0500, Danny Piccirillo wrote:
>> A GNU Hurd port may not be for most users, but i was wondering if we
>> had the resources to support such a port as Debian does, and if it
>> would be worth the effort. I think it would be cool, but are there any
>> reasons against this?
> Speaking as the guy who maintains the boot and plumbing layer, I am
> completely and utterly uninterested in such a port.
> All of the improvements made in this layer, leading to things like fast
> boot, fast suspend & resume, reliable hotplug, etc. have been
> fundamentally done by forgetting about portability and writing software
> designed *only* for Linux.
> If you wanted to do a Hurd port (or BSD port), you'd basically have to
> redo all of this work from scratch again.

These are very important points.

I'd be more of a fan of Minix than HURD.  Their designs are
interestingly close, but Minix 3 is much more active whereas HURD is
not; besides, Minix 3 is work from scratch circa 2005, based on
research done actively since before Linux was ever conceived.  FreeBSD
is another boring monolithic chunk; I see no reason to switch kernels
unless we're going to see a completely new paradigm like a true

In which case, I've given this much thought.  If we wanted to switch
to Minix 3 (since I'm already on the topic), the first step would be
to write in inotify, NF_NETLINK, and udev event modules with the same
exact interface as in Linux.  The underlying implementation would be
vastly different (isolate microkernel services), but the correct way
to do this would be to make the kernel effectively appear to be Linux
in those respects.  This is because, as Scott says, the boot process
here is very Linux-specific; the system won't even function without
these operating system services.

The only other method would be to completely restructure Ubuntu for
FreeBSD/Minix/Hurd/whatever, which is actually a more annoying
problem.  Ubuntu is a huge, complex, multi-part system; it strikes me
as vastly easier to make the kernel less hostile to Ubuntu than to
tailor Ubuntu to fit a new kernel.  Besides, then Ubuntu would have to
abandon support for the other kernel; and then hardware support
becomes sort of random.

In any case, both of these problems are highly complex.

More information about the Ubuntu-devel-discuss mailing list