Hi, 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