[Top][All Lists]

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

Re: Hurd and Unix/Linux and Plan9 features

From: olafBuddenhagen
Subject: Re: Hurd and Unix/Linux and Plan9 features
Date: Sun, 4 Feb 2007 03:08:05 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hi again,

On Sun, Feb 04, 2007 at 12:37:16AM +1300, Shams wrote:

> 1. Now HurdNG is this going to be recognised by GNU as the official
> kernel/userland or is this going to run as a separate research
> project?

Only time will tell.

Until recently, ngHurd was discussed as a very different system, with
little likeness to the existing Hurd or UNIX concepts in general, thus
totally unsuitable as a kernel for GNU. I considered it an interesting
research project, but nothing more.

Recently however Marcus Brinkmann seems to have changed his mind, and he
now strives for something more similar and compatible with the existing
stuff, so it *might* one day replace the current implementation as the
mainline Hurd.

However, this will take at least a couple of years, so it's not really a
concern right now.

> 2. Are all Debian GNU/Hurd efforts and existing developers efforts
> going to be towards HurdNG.

As for Debian, it's not even clear presently whether it will be possible
to port it to ngHurd at all. Depends on how much it will deviate from
traditional UNIX concepts.

> More specifically is the current Hurd going to be abandoned in favour
> of HurdNG, what is the future of this current Hurd?

Certainly not, at least not any time soon. ngHurd should be seen as an
experiment for now; the existing implmentation is still the mainline,
and very likely will stay so for quite some time.

IMHO, development efforts should focus mostly on the existing

> 3. Has the microkernel for HurdNG been chosen


> and if so then what language is going to be used for HurdNG and the
> microkernel?

ngHurd itself will surely use C. As for the microkernel, whatever the
kernel which is chosen will use... If it's decided to implement an own
one, surely it will be in C as well.

> 4. Regarding finding sym links and hard links. I mean currently
> /usr/bin/find resorts to traversing the directory tree (which may be
> timeconsuming for example traversing from the root path ("/") to find
> each coressponding sym/hard link for the given directory? Couldn't
> this be done somehow with i-nodes directly where the i-node that given
> directory keeps records of all symlinks and hardlinks for it?

Well, the way symlinks and hardlinks are traditionaly used in UNIX, I
don't think there is much need for that.

Of course, one could think of applications that use links in a
bidirectional manner, e.g. for tagging. However, it's questionable
whether traditional symlinks or hardlinks are appropriate for such
applications. I have discussed this somewhat in a specific context at .


reply via email to

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