[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The Hurd: what is it?

From: Thomas Bushnell BSG
Subject: Re: The Hurd: what is it?
Date: Thu, 10 Nov 2005 12:53:56 -0800
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

"Alfred M\. Szmidt" <ams@gnu.org> writes:

> I don't know about System III, but BSD was a _fork_ of UNIX, it wasn't
> developed as part of the `offical' UNIX system.  You didn't have 2
> different UNIX systems, one different from the other using differnet
> API's from Bell labs now did yah? :-)

Actually, that's not true historically.

>    It is extremely unlikely that we want to use Mach forever.
> Mach as it _currently_ looks like.  I think that it would be possible
> to frob Mach so badly that it wouldn't look like what it looks like
> today (i.e. develop our own microkernel).

Ok, but then I'm not sure we would call it Mach.  We would certainly
want to change so many of the interfaces that it would be very

>    It is therefore true that any work which factors as much
>    Mach-dependency out of the code-base would be productive.
> Problem with that is that you don't even know if the code-base will be
> used, so such factoring will be useless.

Not if it's done well.  The point is that if you can make the code
base suitable well designed, it will become *portable* and of course
it will be used.

>    This redesign could be conveniently done piecemeal in most cases,
>    and could be done together with the above-mentioned refactoring.
>    Giving the Hurd its own IDL, for example, not tied so strongly to
>    Mach, would be an excellent start.
> That would be cool, if the current code base will be used at all.  It
> the transition from Mach to L4 or whatever was done in a incremental
> way, I wouldn't be bitching.  But it simply is not done that way.

It sounds now as if you are bitching that other people are doing some
other project which you aren't interested in, and you are worried that
things would be better if they worked on the Mach-based project.  This
may be, but the way to argue it is to argue that work is more
productively accomplished in place A than place B, not to try and get
maintainers to declare.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]