It is as if you are not listening still. The same can be said about you.
Unix 32V (the Vax port of V7) was certainly Unix. There were two successor projects: BSD and System III. I don't know about System III, but BSD was a _fork_ of UNIX, it wasn't developed as part of the `offical' UNIX system. You didn't have 2 different UNIX systems, one different from the other using differnet API's from Bell labs now did yah? :-) So I suspect that labelling is *not* the issue; that the real issue is that you want me to declare "People should work on the Mach version and give up on L4" or else to declare "People should work on the L4 port and abandon the Mach version." That is the same thing as labeling. But hey, maybe I don't have a preference? I think you made that clear by now... It is extremely unlikely that we want to use Mach forever. Mach as it _currently_ looks like. I think that it would be possible to frob Mach so badly that it wouldn't look like what it looks like today (i.e. develop our own microkernel). It is therefore true that any work which factors as much Mach-dependency out of the code-base would be productive. Problem with that is that you don't even know if the code-base will be used, so such factoring will be useless. I do not have any particular opinions about what should be considered and in what order, but I do agree with Marcus that some redesign of some core interfaces may be in order (though, I repeat, I do not have an opinion about *when* that should be done). Nobody is opposing a redesign of core interfaces. I atleast if I'm opposing anything is the total rewrite, and total redesign philosophy. This redesign could be conveniently done piecemeal in most cases, and could be done together with the above-mentioned refactoring. Giving the Hurd its own IDL, for example, not tied so strongly to Mach, would be an excellent start. That would be cool, if the current code base will be used at all. It the transition from Mach to L4 or whatever was done in a incremental way, I wouldn't be bitching. But it simply is not done that way. _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
