Date: Sun, 14 Jul 2002 23:13:08 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mark Valentine <mark@thuvia.demon.co.uk> Cc: "Louis A. Mamakos" <louie@TransSys.COM>, Thomas Seck <tmseck-lists@netcologne.de>, freebsd-arch@freebsd.org Subject: Re: Package system flaws? Message-ID: <3D3267F4.2C72E5D@mindspring.com> References: <200207150428.g6F4SAsT089566@dotar.thuvia.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Valentine wrote: > > Rather than trusting people with this, I would like to see the > > ability to learn institutionalized in the project and the tools, > > so that when individuals responsible leave, either voluntarily, > > or by getting hit by a bus, that the learning is not lost. > > I'd like to hear your ideas on how to make _that_ happen! :-) A system is always greater than the sum of its parts. I know this seems incredibly cliche, but it's nonetheless true; that's how things get to be cliches in the first place. The way you get systems with self-sustaining properties that are desirable is by designing the system so that the properties you think are desirable are themselves emergent from the set of simple rules that govern the system. So in the limit, you pick the rules that, when combined, result in the systemic behaviour you desire. Note that the rules don't directly dictate this behaviour: the behaviour is an emergent property. So it comes down to being able to pick "the right rules". FreeBSD has done pretty well; but it could do better. One of the emergent properties of the current "rules of FreeBSD", which include a set of configuration management tools which are not capable of being applied to a rigidly defined base system, is that applications for an OS, which are not a good fit to that base system, are seperately defined outside of it. The most friendly of these is my recent "pet example" PicoBSD. But the rule here is arbitrary: the base system is rigidly defined because it is difficult to change, and it's difficult to change for a lack of tools that permit easy redefinition. It's *not* difficult to change because there's a particular systemic *need* for it to be difficult to change. You *might* argue that tools which permit an easy redefinition will make it easier for the group definition of "the base system" to lose power, and erode. Ignoring the merit of the delegation of power towards that particular ends... by that rationale, the lack of such tools should have prevented the existance of PicoBSD in the first place. The argument is flawed: self organizing systems *will* route around the damage, no matter what/ You might as well embrace them: at least it permits you to keep control over the context in which they emerge. To put it another way, if you're an Oxygen breather, it's in your best interests to embrace other Oxygen breathers, particularly if the altternative is a Chlorine-breater. 8-). -- Terry 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?3D3267F4.2C72E5D>