All: I would like to summarize the discussion as I see it so far. This is my view. Marcus will certainly disagree.
Marcus has made the decision to reject confinement. I believe that he is making a profound mistake, but the Hurd is his system (and yours). It is your decision to make. Marcus states repeatedly that "there are no use cases for the constructor that are of interest to the Hurd". This is obviously false. Several of you have offered example use cases. What *may* be true is that there are no use cases that are of interest to Marcus. This is *also* his decision (and yours) to make. I too have decisions that I must make. As all of you know, the Hurd project is a secondary goal for me. I would like you to succeed, and I would like to support your success, but it is increasingly clear that Marcus and I are focused on incompatible problems. Marcus wishes to prevent what he sees as the "ownership" of "digital information". I simply do not believe that his proposal will achieve this, and I am reluctant to compromise a working architecture for no gain. I disagree very fundamentally with his view about the ethics of digital information ownership. As I said earlier, I am an advocate of "open source", but I do not subscribe to the ideology of "free software" (and *definitely* not to its generalization: free digital information). I believe that software should be free because this is more effective, not because it is a moral right. For my part, I wish to create a computing environment in which mutually suspicious parties can collaborate in spite of their suspicions. In order to support mutually suspicious collaboration, it is necessary to be able to set certain types of controls and boundaries on the use of information. I do *not* mean DRM, but I definitely *do* need to be able to establish situations in which the right to execute a program does not imply the right to examine it's state -- this is the "encapsulation" property, and it is exactly the property that Marcus desires to remove. Because of the importance of encapsulation for the problems that I am trying to solve, the constructor is extremely fundamental to the Coyotos design, and it is at the center of the Coyotos system security architecture. I simply do not have time to actively pursue two radically different systems. I have classes to teach, students to advise, and a business to run. If the Hurd chooses to abandon constructors, that is okay, but it moves the Hurd design outside of anything that can potentially support "suspicious collaboration." In my opinion, it also moves the Hurd outside the space of potentially useful system designs in the eyes of the real world, but that is very much a matter of opinion. Later this week, when I am not working on three other things at the same time (which has been a large part of the problem today), I will try to set out in writing some of the things that Coyotos is trying to achieve, and why confinement is essential to achieve them. Many of these are not Hurd objectives, and I do not assert that they should be. Perhaps they will provoke thought, and that is useful. Perhaps they will prompt Marcus to re-examine, and perhaps not. If the Hurd group decides that encapsulation is wrong for the Hurd, you are certainly welcome to use the Coyotos kernel, and I will be happy to explain how it works and make necessary repairs. However, I do not believe that the resulting system will be relevant in the real world. And just to be clear: if it goes that way, and if I discover in five years that I was wrong, I will be very happy for Marcus and for all of you! We have not yet reached this point, but we all need to be aware that it is approaching rapidly. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
