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

Re: Confusion about where to go in Hurd


Thanks for writing such an extensive reply. You especially answered my
questions. (Not to put down Michael Casadevall's reply).

On 200708011732, olafBuddenhagen@gmx.net wrote:
> On Thu, Jul 26, 2007 at 03:43:57AM +0200, Anders Breindahl wrote:
> > I can't tell, but if I am not mistaken, it has been (is?) a design
> > goal of the Hurd to be microkernel-independent.
> This is not really possible. The lower-level system parts are very
> closely related to the microkernel; it doesn't make any sense to be
> portable at this level. If the higher-level design is kept intact, most
> translators should work without much change however.

I don't know whether it wouldn't be feasible.

Clean interfaces at this level could be hard to do, especially if one
considers oneself with performance. But the value gained would be to
decouple microkernel development from Hurd development, so that
IPC-speedups (e.g.) could be research in some possible nextgen
microkernel, and hardware support could be added to Mach in the
meantime, by others. All on the same Hurd, equally being able to use
ext2,pfinet and the likes.

But of course, I'm not considering the trouble of actually doing so. I
could imagine that it would be amongst the worst refactoring jobs.

> >   Alas, it soon dawns on us newcomers that it's mostly toughlived
> >   vaporware,
> I don't think it's really appropriate to call the Hurd vaporware.

I also regret using that term. It's too aggressive. But some of the
features and talked-up projects have been.

> What really causes frustration is how close the Hurd seems to be to
> general usability, but at the same time isn't able to take that last
> step...

You hit the head on the nail, IMO. Hopefully newer newcomers than me
will also find the patience and enthusiasm that tracking Hurd
development demands of you.

> The fact that a CVS branch didn't do much good, is hardly proof that no
> better VCS is necessary...
> The whole point of using a distributed VCS is that you no longer need to
> care about upstream: It's not a problem at all to do development with
> changes not going upstream for a long time; while in CVS (or SVN) it's a
> real pain to work with stuff not on the trunk.

I have been reading up on it, including Linus' rationale for basically
writing git during April 2005 (which I find to be impressively fast).

Distributed VCS may well be an efficient tool to ease experimental
development. I assume that understanding git will be a good thing for
me, so that will be the next few days' project. 

Regards, skrewz.

Attachment: signature.asc
Description: Digital signature

Reply to: