Re: about GNU Hurd

[Michael Heath]

Thanks for the response, antrik.

You need to realize that I was speaking mainly in my e-mail about the combination of Hurd + Mach, not just one or the other. I am well aware that continued work on higher-level components of the Hurd is not wasted time or energy, and, as Richard suggested in his e-mail earlier, work on those components would be greatly appreciated.

It's understandable that the issues here and how to fix them are so complex and tedious that there are not any clear answers yet. What I was mainly saying, however, in my previous e-mails is that very little real progress can be made until we find such answers, because the current problems both directly limit progress and limit interest in the project.

I'm going to disagree with you on your statement that nothing useful can be done on new work or research except for those few who are intimately familiar with the current internal workings of Mach and the Hurd. There is ALWAYS lots of helpful work that people of various talents can do to help a project.

I don't know what needs to be done, or exactly what it is that people can help with. I'm just suggesting that we step back and take a closer look at the current status of the project, and what needs to and can be done to improve it. 

If it is truly the consensus that this is indeed going to take a long, long time before it can be fundamentally fixed, perhaps the GNU project SHOULD investigate using another kernel, at least until these problems are fixed.

Michael Heath

On 9/5/07, address@hidden < address@hidden> wrote:

Hi,

On Sun, Sep 02, 2007 at 10:05:48PM -0600, Michael Heath wrote:

> I think the problem people face is: Why work on something that is
> already fundamentally obsolete or bad?

It is not any more fundamentally obsolete or bad than most other
software out there.

We *know* that there are some fundamental issues with the current
implementation. We *know* for example that performance will never quite
match modern monolithic systems; that there are problems that can not be
fully solved within the current design.

However, we do not know how to solve these. Nobody knows. We don't have
any working design for the Hurd better than the current one. Marcus and
Neal at some point believed that they have, and unfortunately were
pretty vocal about it -- resulting in the false believe that the current
implementation is useless and any work on it wasted :-( But that's not
the case.

The current implementation has issues, but nobody know how to solve them
-- not Marcus, not Neal, Shapiro, nor anyone else on this planet. To
some of the issues there are know solutions in specific contexts, but
it's uncertain how they can be applied to a Hurd design. Others are
totally open questions. What Neal and Marcus are currently doing is
bleeding edge research work. They have some ideas to test, but no
complete working design.

We know the current Hurd has issues; yet it is still the best known
working design for the Hurd -- in fact, it's the only working Hurd
design that we know. You think we want to abandon that?

> Why not focus on the reimplementation you know has to come?
>
> And because questions of what that reimplementation is and how people
> can help with it keep being answered with "I don't knows", "Don't you
> worry about that", or half answers, people aren't excited to help with
> anything.

Well, these are about the best answers you can expect. We really hope
that Neal's and Marcus' research will result in something that will
prove useful for the Hurd; will result in improvments to the Hurd
desingn and implementation at some point in the future. But it's
research. There is not some concrete system being worked on, or even a
complete design for one; there is nothing really people could help with
-- unless you want to seriously go into microkernel-related operating
system research.

Seriously means: Working on it more or less full time, for many months
at least, more likely years; to read hudreds of research papers; to
spend hours and hours, months and months contemplating known as well as
possible new approaches; trying to come up with useful designs; testing
new ideas...

(People who really are into this, can get an idea what Neal and Marcus
are presently working on from some of the more recent posts on the
l4-hurd mailing list.)

But even then, even if you really want to help with this research work,
you can hardly contribute anything useful, unless you already spent a
considerable time working on the current implementation -- understanding
what it's about, how it works, where the shortcomings are. You can't
come up with an improved design without really knowing the previous one.

Regarding the reimplementation you are talking about, I don't really
believe the current Hurd will ever be replaced by a total
reimplementation; not if I can prevent it. We must expect; in fact hope,
that sooner or later there will be some major changes to the lower-level
parts of the system. That doesn't mean all existing code (especially
higher-level code) gets thrown away; and more importantly, it doesn't
mean all knowledge aquired, all experience gained with the existing
implementation gets thrown away.

If you want to help the Hurd, work on the existing system -- that's
crucial not only for the current implementation, but also to any
possible future improvements. We have a working system with a small but
active community around it. I'm sure anyone can see how incredibly silly
it would be to abandon that on the prospect of some possible future
design improvements.

> Other projects have a clear road map, clear set of design goals, and a
> clear structure on who is in charge of what - why doesn't the Hurd and
> associated projects?
>
> Road maps are important.

I totally agree that a roadmap would be immensly helpful: A roadmap for
improving the existing implementation. But not a roadmap for research on
possible future design options.

-antrik-