Re: Improving Hurd

[Marcus Brinkmann]

Hi,

most things have ben said in this thread, just a couple of remarks that I
feel are missing.

On Sat, Apr 20, 2002 at 06:46:17PM +0200, Jan Atle Ramsli wrote:
> That, and an attitude that someone who hasn't plowed through the entire
> source tree isn't worth talking too, creates a circle that scares off
> potential recruits.

We don't have the resources to hand held everyone who is merely interested
into the Hurd to become a Hurd hacker.  We try our best, but we are only
few, busy with a real life beside the Hurd and do this for free as in free
beer.  We are happy to answer questions both about the design (and justify
it), and to specifics in the implementation (where to find what), but we
expect some reasonable effort from you to solve the problems yourself and
make good use of our help (so we get something in return).

The best advice I can give is:  Ask as specific questions and as difficult
questions as possible.

Also, it seems you think of this as two sides, which does not hit the spot.
To be able to answer most of the interesting questions, I have to do some
research myself (eg, read the source code, do some debugging).

> What I wanted to do, was remove this 1Gb limit, that would be a simple
> thing to do if I would know which tools were available to me, what I
> could do in the strategy section, and what I could no in the interrupt
> section.

If you want to work on this particular problem, it is reasonable for us to
expect that you already know your in and outs in the Hurd, because otherwise
we can not reasonably expect that you will succeed on it if you are just
starting.  It would probably take us more effort to train you to be able to
do it than to do it ourselves.  It would be much better to pick a somewhat
smaller problem, and work on that.  What you learn in working on that
smaller problem will help you to acquire knowledge you need to solve the
bigger problem.

This all has little to do with the Hurd itself, but with free software
project management under very difficult constraints.

> So, after 10 years, the system is still being built.
> If it was a car, it would start to rust at the back where the tailfins
> are while you were replacing the V8 with a more powerful and economic
> V6.
> If it were a house, it would be in need of repair in the areas that
> didn't have a roof yet.

Luckily, it is software and welld esigned to begin with.  Some of the code
that is 5 years old is as good as at the first day it was written.  It
cooperates nicely with the newer code, because it adheres to clean
interfaces.

Other code is in not as good shape, for example the gnumach drivers, but
that's why we are replacing them.

The Hurd is a very ambitious project.  You can not expect it to write and
finish it in a short time and then turn to maintenance mode.

> If today it was decided to throw away every line of code, delete it all
> and use the gained experience to specify a new Hurd, write down
> everything, and when finished, spend 6 months building a specification
> documents, oulining the system as a whole, what modules it consisted of,
> what the pupose of each module was to be, and specify each modules'
> functionality as an ADT, the Hurd would probably be in beta one year
> after the ducument was published.

Frankly, I think you couldn't be more wrong.  You seem to assume that there
are some hidden resources which can't get to work because some property of
the Hurd (age? lack of interfaces?) stops them.  There is nothing like that.
There are no hidden resources, there is no magic way to get to the goal of a
usable operating system.  It does not require a rewrite or redesign from
scratch.  What we need is incremental improvement.  Phasing out old
code, implementing new code, and debugging, debugging, debugging.  Exactly
what we did the last years, but much more of it.

Luckily, the Hurd was written with this incremental evolvement in mind, so
it is incredible straightforward to replace individual components of the
Hurd by new implementations.  Have a try.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de