Supporting a GNU Hurd port?

[Alexandre Strube]

I thought there were already an open-source microkernel being used out
there: Darwin's Mach, deeply buried into every Mac OS X.

On Wed, Dec 9, 2009 at 7:11 PM, John Moser <john.r.moser at gmail.com> wrote:

> 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).
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>



-- 
[]
Alexandre Strube
surak at ubuntu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20091209/d1582bab/attachment.html>