Date: Fri, 23 Feb 2001 23:42:30 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: wes@softweyr.com (Wes Peters) Cc: arch@freebsd.org Subject: Configuration management Message-ID: <200102232342.QAA01378@usr05.primenet.com> In-Reply-To: <3A969CD0.DE9E94E1@softweyr.com> from "Wes Peters" at Feb 23, 2001 10:24:32 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > Storing program-specific configuration data for many diverse applications > > in a single file is (A) a stupid idea, (B) a stupid idea, and most > > importantly (C) ... a stupid idea. Having config parameters all > > in one place does not magically make the idiot tring to manipulate > > them any better at his job, but it sure makes it more likely that he > > will take the whole system down with him when he does make a mistake! > > <agreement type=violent> > Nor does stuffing a GUI on top of said configuration data, no matter where > it is located, give somebody the experience to operate a complex system. > Knowing how to do something does not imply knowing what to do. > </agreement> The lack of a configuration data API, and a common configuration file layout syntax has been a problem with UNIX since day 1. When you learn how to configure one program, the knowledge is not transferrable over to another program; you must relearn it for each program, which make UNIX unnecessarily dense, with an unnecessarily high learning curve, but with no benefit of having achieved a greater altitude for having climbed N of these curves, as opposed to N-1 of these curves. Further, the lack of a single data channel to which the API talks means that proxy configuration of a number of machines can't be done over a network. Nor can one multiplex the proxy stream to change machine independent data on a large number of machines simultaneously. Neither can computable machine specific data be handled this way (e.g. renumbering a network). Additionally, when a GUI is provided, even if that GUI is not a direct representation of the configuration hierarchy, or it abstracts the complexity to a level usable by an end user at any given level of capability (as the MVC -- Model, View, Controller -- paradigm favored by Activity Theory and HCI -- Human Computer Interaction -- dictates should be done), it is _gratuitously_ difficult to supply, due to the exhausting number of back end interfaces which have to be written. So _you_ don't want a GUI: BFD. So _you_ don't want to do cluster configuration: BFD. So _you_ don't want to do role based configuration of subsets of a cluster spread over multiple colocation facilities: BFD. The point is that just because some people don't see a need for something doesn't make it useless. Ask the next Amish person you meet whether or not there should be cars; then tell me if you're prepared to give up your car, if you have one. Even if we stick with "flat text files", and we continue to edit them by hand, instead of using a method with subschema inforcement which makes non-sensical configurations impossible (per Jordan's XML example), the idea that it should be _possible_ to easily and efficiently machine parse and write these files using a single API, which can be proxied over a network through a single data channel, is a valid one. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200102232342.QAA01378>