gnu-system-discuss
[Top][All Lists]
Advanced

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

Re: The next step of GNU in pure technical perspective


From: Olaf Buddenhagen
Subject: Re: The next step of GNU in pure technical perspective
Date: Sat, 13 Dec 2014 05:08:22 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,

On Tue, Dec 09, 2014 at 03:53:23PM +0000, Omar Radwan wrote:

> With All the differences of the HURD, plus all the features that are
> still needed for it to be able to compete with Linux, it would make it
> very difficult and counter productive to write a clone,

The problem with the Hurd is that it took an existing microkernel
(Mach), with a predefined set of mechanisms and interfaces, and
implemented an entirely different set of mechanisms and interfaces
(POSIX) on top of it. Working around the discrepancies added a *lot* of
complexity to the core of the system, making it very difficult to get it
compliant, stable, and performant. While it got much better over the
past years, it's still not entirely there; and there are still some
fundamental shortcomings that do not make the system unusable, but they
will have to be addressed sooner or later to make it really good --
which will require some major changes at the lowest levels...

A more streamlined architecture on the other hand, with the system and
the underlying microkernel developed in tandem, implementing interfaces
and mechanisms exactly tailored for the actual needs, would likely allow
for much faster progress. Adding to that the experience gained with the
Hurd (and to some degree also in other multiserver systems that came
into being in the mean time), it appears quite plausible that a new
system with similar features could be written in considerably less time
than the original Hurd. (As for the lack of non-core features such as
support for various hardware, filesystems, networking features etc.,
that just means there is less to loose...)

Having said that, I'm still not quite convinced it's a good idea to
start from scratch. On one hand I'm thinking, the Hurd is so tangled, it
might be easier to go with a new implementation rather than trying to
get the existing one in shape; but then again, it's already there, and
(mostly) works, and it would be better to build on that rather then
spending another bunch of years until something new gets to the same
point...

> and that time and effort would be most useful hacking in the HURD
> repo.

Or maybe on entirely different things?...

In the end, it's a question of what the (volunteer) developer in
question is most interested in working on. If he is no longer motivated
to work on the existing Hurd, I'd rather he hacks on something
Hurd-like, instead of giving up alltogether.

Of course that doesn't mean the other developers will necessarily jump
ship as well.

-antrik-



reply via email to

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