Date: Sun, 18 Feb 2001 19:48:49 -0800 From: Jordan Hubbard <jkh@winston.osd.bsdi.com> To: Marcel Moolenaar <marcel@cup.hp.com> Cc: Mark Murray <mark@grondar.za>, arch@FreeBSD.ORG Subject: Re: Moving Things Message-ID: <15427.982554529@winston.osd.bsdi.com> In-Reply-To: Message from Marcel Moolenaar <marcel@cup.hp.com> of "Sun, 18 Feb 2001 18:21:24 PST." <3A908324.EF6F4385@cup.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Back to the original question: "should games stay or should it go?". > This question can also be asked like: "Sendmail or postfix?". It's a > question about preferences and pre-selections and thus policies and/or > philosophies. If we let go of the answers and implement a framework that > allows everybody to answer that question for his or herself, then how do > we define FreeBSD? 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. > 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. More flexible mechanisms don't automatically imply that policy is sacrificed as a side-effect. 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. In systems like ours, on the other hand, where much of the policy is enforced through accidental or deliberate limitations in the mechanism, nobody feels any particular compulsion to document policies which are largely hard-coded. I therefore can't really see a supporting argument for lumping policy and mechanism together from *either* side of the coin. - Jordan 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?15427.982554529>