Date: Sun, 18 Feb 2001 00:45:32 -0800 From: Jordan Hubbard <jkh@winston.osd.bsdi.com> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: Mark Murray <mark@grondar.za>, arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] Message-ID: <9070.982485932@winston.osd.bsdi.com> In-Reply-To: Message from "Daniel C. Sobral" <dcs@newsguy.com> of "Sun, 18 Feb 2001 14:54:03 %2B0900." <3A8F637B.45C18CFC@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I disagree. One of FreeBSD strong points with many users is that we are > not a "distribution", a bundle of assorted software thrown in together, > but a whole OS, tightly integrated and balanced, to which the user may > add extra software if he wants to. I don't think you actually need to disagree with any of this. What you're talking about here is a "policy", e.g. a set of sets which describes what "FreeBSD is" and something which is quite important. It's also, however, something which should also go at least one level above all the mechanism foo. What we have now is a hard coded policy which can't be changed without editing Makefiles and such. We further justify the existence of all that hard-coded mess to ourselves, even though it often gets in our own way, on the grounds that we're taking a firm stand on what FreeBSD means to the user and that what we have works well enough for delivering a single, well-defined "FreeBSD" product. None of those fast and loose "Linux distro" scenes for us, no sir! Sadly, such arguments are also woefully deficient from a perspective of good software engineering. We shouldn't be setting policy based on the limits of our build and release technology, that's backwards. The system should instead be designed with as much flexiblity as it's reasonable to have and let policy decisions be largely as a configuration function. To put it more simply, just because our software might allow for all sorts of modular plug-and-play configuration behind the scenes doesn't mean that end-users need actually see ANY of that. Even if our /usr/src grew into a fully modular package-fed framework which did everything the current /usr/src did and more tomorrow, you would still see FreeBSD installations and "make world" runs which looked exactly like the end-product of a make world or full install today. POLA would more or less demand that what constituted FreeBSD, in all its current perl, sendmail and uucp containing glory, did not change at all until we had the full chance to seriously consider changing such policies. Until we actually change the underlying build technology, however, actually changing these policies remains painful or not easily reversible on a per-developer basis, so we go round and round arguing about the individual items. Which is where I first came into all this discussion. :-) - 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?9070.982485932>