Date: Sun, 18 Feb 2001 23:57:47 -0800 From: Marcel Moolenaar <marcel@cup.hp.com> To: Jordan Hubbard <jkh@winston.osd.bsdi.com> Cc: Mark Murray <mark@grondar.za>, arch@FreeBSD.ORG Subject: Re: Moving Things Message-ID: <3A90D1FB.D02C2931@cup.hp.com> References: <15427.982554529@winston.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan Hubbard wrote: > > I think the point has already been made more than once that how we > "define FreeBSD" need be no less stringent and carved-in-stone than it > is now. Sure, a redesigned mechanism might more easily allow people > to walk off the beaten path, but that doesn't mean we won't still > furnish a very clear "approved path" and make it equally clear that > people walking elsewhere do so at their own risk. I suddenly have to think about the Garden of Eden, apples and snakes. I think that making it easy for people to choose "the path less travelled by" is not necessarily a bad thing. But I don't think we can get away with the idea that it's at their own risk if they do so. You can't expect people to not go through doors you hold open for them. You can't also expect that only the "right" people go through those doors. How do you see the demand for support in such a flexible environment? > > For example: The question "Did you test your changes with a make world?" > > would be completely meaningless. > > Not at all. It just becomes true that "make world" only has meaning > for those tracking one of the standard configuration sets, just as it > currently holds meaning only for those who don't manually hack their > /usr/src trees before making the world. I assume that tracking one of the configuration sets means that these sets will differ only to small extends that we avoid the problem that commits tested with one configuration can break another configuration? If so, how does that allow us to create a configuration in which we replace a core tool, such as a compiler so that we can benefit from it on certain platforms? If not, doesn't that only exaggerate the problem we already have between different platforms? > More flexible mechanisms don't automatically imply that policy is > sacrificed as a side-effect. Agreed. > Actually, if one looks to the real world > for examples, it would appear that policies actually become even more > strict and well-defined as the mechanisms become more flexible. They > have to. True. Do you see a benefit for FreeBSD when this happens? Don't you think that strictness and well-definedness and FreeBSD developers don't go together? Can you say style(9)? :-) > I therefore can't really see a > supporting argument for lumping policy and mechanism together from > *either* side of the coin. I have my doubts that policy without it being enforced by mechanism will survive. The discussions on the subject of style(9) can't be that easily forgotten. I do see the advantages of policy-free mechanisms; I just question our ability to enforce policies upon ourselves without the aid of policy enforcing mechanisms... -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A90D1FB.D02C2931>