Date: Sun, 18 Feb 2001 18:21:24 -0800 From: Marcel Moolenaar <marcel@cup.hp.com> To: Mark Murray <mark@grondar.za> Cc: Jordan Hubbard <jkh@winston.osd.bsdi.com>, arch@FreeBSD.ORG Subject: Re: Moving Things Message-ID: <3A908324.EF6F4385@cup.hp.com> References: <11284.982487979@winston.osd.bsdi.com> <200102181055.f1IAt6957670@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Murray wrote: > > PLEASE PLEASE do not look for implementation details in the following; I > know it will be hard, but until a decent design comes out, arguing about > programming details is futile. I'm going to play devil's advocate now. Mostly because I'm cynical WRT this, but also because it allows us all (yes, that includes me) to verify our views and/or give us (again, "moi aussi") a chance to set our minds straight.... I claim that what we're discussing is implementation by definition: (taking a good dose of that ol' Janx Spirit) 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? For example: The question "Did you test your changes with a make world?" would be completely meaningless. World for that matter could be anything. Currently world is defined by what we consider FreeBSD to be, or put differently: the implementation of what FreeBSD is, defines what world is. If we have a policy-free framework then to be able to validate a change, we have to define a "configuration" that is considered "minimal" in the sense that any change should leave that configuration unbroken. Consequently, this consiguration will result in the same preferences and pre-selections as we currently have in our source tree and by definition will define what FreeBSD is. The problem of what to keep or remove from a configuration is exactly the same as the problem we're discussing now: what to keep or remove from the source tree. Since we didn't change or solve the problem, the only thing we must have changed is the implementation! (taking another dose of that "good ol' Janx Spirit" --- I'm getting even more vague now :-) What makes us different from NetBSD and OpenBSD (for example) is first of all our philosophy, not so much our implementation. It's our philosophy that gives shape to our implementation and it's our philosophy that defines what we consider important. If we manage to come up with an objective and policy-free framework then, consequently, we should be able to implement NetBSD and OpenBSD with it, right? The initial issue of whether or not we should remove games is not so much an attempt to change an implementation, it's more a change in policy/philosophy. The immediate discussion that followed (ie: UUCP should go as well; remove the r* tools) is also policy/philosophy. It's an attempt to change what FreeBSD is considered to be and what we think is important. Our current implementation encodes this policy and philosophy. The idea to remove the wall between ports and source tree is an approach to overcome that limitation: it addresses the implementation. Not looking at implementations is therefore impossible... (sobering up...) In general I think that flexibility is good. But there's also such a thing as too much flexibility, because with flexibility comes complexity. Not only implementation complexity, but also comprehension complexity. I think we should allow people to install postfix(1) without having to install sendmail(1). We should allow gcc(1) to be replaced by a compiler that produces better code on certain platforms. However, I don't think there's much value in being able to *not* install sleep(1), only because the maintainer doesn't get any himself. I fear that a framework that allows that level of freedom will simply not work, because the meta-information involved to guarantee a consistent "configuration" or a stable system (as it is installed) will require more work to maintain than what would have been needed for the actual sources in a more resticted framework; hence the lack of sleep :-) I also fear that any attempt to design such a policy-free framework will end up in the same situation as sysinstall/NG: it's always coming, but it never arrives. The reason being that there are so many solutions and they're all flawed... -- 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?3A908324.EF6F4385>