Supporting a GNU Hurd port?

[John Moser]

On Wed, Dec 9, 2009 at 11:56 AM, Patrick Goetz <pgoetz at mail.utexas.edu> wrote:
>> Subject: Re: Supporting a GNU Hurd port?
>> From: John Moser <john.r.moser at gmail.com>
>> Date: Wed, 9 Dec 2009 10:07:44 -0500
>>
>> you know the microkernel arguments, and they're actually
>> pretty considerable.  The idea of a system that's easier to maintain
>> (face it, operating systems are huge now; smaller chunks are easier)
>> and self-error-correcting (MULTICS did it, Minix does it) is not
>> really far fetched
>
> If this were really true, why has it taken so long to get GNU Hurd into
> an even vaguely functional state?
>

Or Minix for that matter.

Lack of interest doesn't mean lack of practicalability.  Why did it
take so long to get an airplane?  DaVinci thought we could fly, Edison
was the only person working on the light bulb.  Most major surgical or
pharmapseutical treatments today were considered impossible and not
worth investigating at some point, aside from by one person or firm.

Again, I only submit that statemets like "This is a useless waste of
resources" in this particular topic are impossible to validate in
either direction.  We are in a state of waiting for somebody else with
minimal commercial interest and minimal general visibility to prove or
disprove this for us.  Consider the two major options here?

GNU HURD is a joke, GNU is a political entity and not a technical one,
and their driver is pushing the political agenda of the FSF rather
than making their technical product popular (much less finishing it).
There's no reason for GNU to ever finish HURD, when they can drive
people towards Linux, built on their compiler, with their userland,
with a kernel that falls under their license and thus is valid in
their philosophy.

Minix, the only other visible "Next Big Thing" shift if microkernels
are the next big thing, is a research OS now in its third stage, which
happens to be "make an actual, practical operating system."  This
happens to be condusive to our needs:  one day Minix will be a viable
alternative, probably at the core of a shakey Debian system it's
wedged under, and we can see how that goes.  Unfortunately, it's also
driven by the specific purpose of teaching a bunch of students about
operating systems; this isn't a huge, widely visible, well-funded
(either by money or popularity drawing engineers) project that's going
to get drilled through hard and fast.  It won't be 2, 3, 5 years;
it'll be 10, 15, 20 years.

> Speaking as a mathematician, a good rule of thumb to keep in mind at all
> times: theory != reality.
>

No kidding.  Be mindful that goes both ways.

> The linux kernel is an amazingly stable piece of software with a
> mind-numbingly rapid rate of constant revision.  There are plenty of
> things in Ubuntu that could use some attention (gnome comes to mind
> immediately); the linux kernel is not one of them.
>

This is actually a core part of my argument:  Linux is working, the
fact that HURD or Minix "Could" be better (BSD is irrelevant, we can
see that plainly) is a big step with no -visible- guaranteed or
strongly likely benefit, and thus devotion of engineering resources to
any effort to evaluate and possibly migrate to Minix particularly fall
more towards "lack of clear benefit" rather than the previously stated
"known lack of any benefit."  There's a difference.

I'm not arguing that it's imperitive we move to a microkernel; I'm
just arguing against the arguments made against the move.  I know this
seems strange, but to me the argument presented sounds more like dogma
than a real argument; it takes a decision that basically ends with
"this may be interesting but right now we have other, more clearly
beneficial things to do; we may examine this at a later date if it
becomes interesting" and changes it to "no, that's stupid, stop being
an idiot; we should never look at this again."

For the moment, I think a move to a microkernel would be interesting
as someone's personal side project, and a very valuable effort for
study (we could say this about LOTS of crap we could do but don't due
to lack of perceived benefits, i.e. using something other than gcc);
but I don't believe there's any argument currently that would place
such a thing as an appropriate task for major effort.  If it ever
falls into scope, I'll be making feature suggestions that I don't
think are physically possible on a monolythic kernel architecture (at
least, not in any non-hideous way).