"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes: > > Unix is a operating system developed by Bell labs. That is quite > > concrete. > > Huh? Is Unix BSD, or is it System V? Which?! Or is it SCO? > > UNIX V6 for example, but you knew that...
It is as if you are not listening still. Unix 32V (the Vax port of V7) was certainly Unix. There were two successor projects: BSD and System III. It was meaningless at that time to ask "which one is Unix"; Unix was both. Indeed, it was officially both, by decision of the federal courts, who found that BSD had the right to continue to use the trademark. But how does that change anything? How does labelling this or that change the world? Suppose I declared, "The Mach-based codebase is the Hurd, the L4 stuff is not the Hurd." How would that have affected reality? It could still be that work on the L4 port is a better use of people's time, and how would the labelling clarification have done anything? 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." But hey, maybe I don't have a preference? Maybe I don't know which the most productive use of people's time is? (And declaring that it's my responsibility to know doesn't somehow beam the knowledge into my head.) It is not as if I had some seekrit knowledge or seekrit plan which I was refusing to divulge. You know, already, everything I know about the issue. There are no facts in my head about this, no plans about this question whether solid or vague, nothing sitting waiting in the wings. Your tone has made this even harder; instead of asking questions, you have berated me for not knowing the answer to a question that simply *has no* answer. I am not obliged to "bless" this or that code base; if I choose to do so, it would be based on more knowledge and information than I have right now. I simply do not have the knowledge or information upon which to make such a judgment; I suspect that nobody does. Generating that information and knowledge is something anyone could do; it does not require any special privileges. It requires people investigating the details of L4, the details of Mach. It requires people coming up with technical arguments about the plusses and minuses of both. I am not in a position to declare that I know the answer ahead of time; I do not have any intuition about the question to offer except the following: It is extremely unlikely that we want to use Mach forever. Whether we switch to L4 or something else, it is a near certainty that, at some point, we will switch. Mach simply has too many problems to be a long-term solution. It is therefore true that any work which factors as much Mach-dependency out of the code-base would be productive. It is a guarantee that such work will help whatever the ultimate decision is, whenever it is reached. Many of the issues that the L4 port brought up are issues that affect the Mach-based Hurd as well. They are therefore issues that we should seriously consider. 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). 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. Another task would be clarifying an exact list of what is expected from a microkernel that the Hurd is to run on, much in the way that GCC has its processor-specific and os-specific .h files. (Though, I expect, much much less complicated that what GCC has.) So there, if you want direction, that's what I can offer. Thomas _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
