At Sun, 30 Apr 2006 19:56:05 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > Assuming that no legitimate use case is found, and that you are right > > that introducing this feature means a fundamental shift in the > > over-all system design, then the answer is clearly that the patch > > would be rejected for technical reasons, independent of any political > > evaluation. > > Yes. I understand this. But it does not answer the question. Pierre is > asking whether your political objections are also decisive independent > of the technical argument.
I know better than to answer a speculative question in such a heated debate. You can not expect me to make a decision here on speculative grounds that has to be made by the Hurd project maintainers collectively on factual grounds in the future. Plus, the GNU project also has something to say about that. > You write that you do not know a technical argument that decisively > requires true confinement. In the context of the GNU Hurd, yes. I do know some use cases which I have no interest in supporting (with a varying degree :). > We will certainly work to find one. But if we > *fail* to find one, this is an insufficient reason to reject such a > foundational mechanism. You are omitting the other half of my argument, where I said that I have good reasons to belief that inclusion of this feature is harmful (based on the use cases that _do_ exist), and that in fact there is reason to belief that it has properties which make it intrinsically unfit for a free software operating system. You do not need to follow my arguments. At this point, you clearly do not. But, you have at least to give me credit for being consistent and rejecting a feature which I feel violates an important design goal (user freedom, which I have not yet formally stated, but will), _and_ which is proposed to be included on the pure speculation that it may be useful in the future, _but_ with the full knowledge that it is harmful in the short and medium run. I have learned too much about principle-based operating system design from you to make such a leap of faith ;) > Even if other mechanisms can apparently achieve > similar results, those other mechanisms will not have the strength of > formal foundations that the confinement mechanism already has today. We > will be unable to reason about the correctness of those systems -- > merely to get back to where we stand today with confinement in this > regard will be more than a decade of work. This is not true. Because the trivial confinement property still holds true, you can still apply the same tools of reasons that you can in the EROS system. What you can _not_ do is to use certain design patterns to construct certain types of confined applications that hide information. The hierarchical system structure, induced by the exclusive parent-child relationship, is a very strong property, and I predict that it will be sufficient for our needs. The few exceptions where we have to make calls to non-confined services will _by nature_ be unconfined, because the service they implement is an unconfined service. This is not different from EROS either. > Therefore, I would argue: unless there is an overwhelmingly compelling > reason to *exclude* true confinement, I believe that it should be > included. I do not want to lose 10 to 15 years of progress on verifiable > systems unless there is an overwhelming reason to tolerate this. This warrants a separate discussion. I think that if we look at the properties that we can verify or not in the two systems, we will find out that, again, we are looking at a certain number of use cases for which the need in the context of the GNU Hurd has yet to be demonstrated. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
