I think that some really productive work would be anything that reduces the Mach-dependence of the existing code base. Abstracting away Mach-specific elements would be a really really good thing, valuable work whatever happens, that anyone could start on right now.
Not knowing that the current Hurd code base will even be used makes this simply not practical until someone figures out what direction to take. > The maintainers should know, and should care enough to make such > a decision. Otherwise what is the job of a maintainer? Knowing things takes time and is hard. It requires a lot of thinking and careful evaluation of alternatives. Marcus has delineated some of the important issues concerned. Working through those things takes time, and the more heads doing so, the better. Some of this work requires concrete hacking. It has taken 5 years now, 5 years ago it was more or less decided that we should wait for L4.X2, 5 years later it looks like L4.X2 is not suitable, so one waits for L4.sec or Coytos. There has been time, and there has been lots of thinking done about this. Stamping feet and insisting on a prognostication of how that goes is not productive. So we should wait another 5? 10? 20 years? before someone makes a solid decision and one decides that we should just throw away a bunch of years worth of work? If anything, that is what is not productive, it is also not productive to work on two code bases at the same time. _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
