On Tue, 2006-12-05 at 07:28 -0500, Dan Williams wrote: > On Tue, 2006-12-05 at 13:27 +0100, David Nielsen wrote: > > tir, 05 12 2006 kl. 06:09 -0500, skrev seth vidal: > > > On Tue, 2006-12-05 at 12:44 +0100, David Nielsen wrote: > > > > > > > Solution, fix gconf rather than complain over davidz and friends at > > > > least suggesting a forward minded solution to the horror that is "human > > > > readable" configuration files. > > > > > > I've been reading this whole thread and I'm tired of a couple of > > > semantics being used: > > > > > > 1. the assumption that all new development is 'progressive' or > > > 'visionary'. Forward motion isn't always positive. So let's cut the spin > > > and just call it what it is - a new interface. > > > > > > 2. That anyone promoting sticking with the status-quo is somehow > > > backward. > > > > This also assumes that there are no problems with the current scheme > > though. By moving to a configuration storage scheme like gconf we get > > the option of having all key explanations be translated and having one > > common format and syntax, I think those two factors alone make it worth > > considering seriously. > > It's also easier to auto-update GConf with new settings. The horror > that is autoupdating, say, /etc/pam.conf or httpd.conf. _Every_ > distributor gets killed by trying to issue updates that might have to > automatically change httpd.conf, even if it's just a few lines, (even > Apple!). > > Human manipulatable != machine maniuplatable > > Many cases are optimum for human manipulation. I don't think anyone > wants /etc/resolv.conf to be in XML somewhere. That > said, /etc/resolv.conf will never get split DNS resolution because the > config file format _cannot_ change. Hence you need a local caching DNS > resolver. But for complex configurations, often-times > human-manipulatable config files are _not_ the best solution, especially > when you want to auto-update configuration from an RPM, or some other > mechanism that may have to take user/site-specific changes into account. > It's simply a non-starter to attempt to automatically merge > configuration updates into existing config files that that may be > different than expected even in a few places. > > Which leads me to the next point. Most config file formats these days > are pretty dumb. They don't have all the information that's needed to > (a) verify conf format, (b) change narrowly scoped pieces of > configuration, or (c) be editable in something other than English. XML > can do all of this, but is much less human-readable in complex form. > > Red Hat tried to do a grand unified configuration project years ago, > with GUI config tools that edited things like /etc/passwd, > httpd.conf, /etc/fstab, and many more. I think everyone would agree > that having GUI config tools makes Linux more accessible to some portion > of the system administration audience, but the horrors uncovered by that > project mean that what we've got today really doesn't work for GUI > config in most cases. > > So it's a tradeoff. Do you want to keep all the configuration human > manipulatable, and therefore inaccessible to those sysadmins who _don't_ > want to edit 10 different config files to get something done, each with > their own config file format? Or do you add _some_ measure of machine > manipulation ability to the configuration format, at the expense of a > slightly harder to understand configuration format for humans? After > all, machines are our tools no matter whether we SSH into them to edit > the files directly, or whether we deploy updates via RPM or whatever > automatically. > > So perhaps GConf isn't the best solution. But then what? What provides > better experience for GUI-based config tools and people who don't want > to get that far down and dirty with hand editing files? How _do_ you > provide a better way to update little pieces of configuration without > the almost-all-or-nothing approach of automatically updating config > files today? How many .rpmsave or .rpmnew files do you have lying > around? > You don't. You work around that problem and, fortunately, we already know how to do that. As opposed to the gconf-mechanism where we will have to learn a whole new way to do it, unless of course, there is no option to learn b/c it just isn't possible to automatically correct it. Try fixing evolution settings that used to be in gconf using gconftool. Not a fun option. That's the point - we keep trotting out new mechanisms that claim to make sysadmin life easier/better/something but seem to have few ACTUAL sysadmins who would back up that claim. Seriously, who are you deriving these claims about sysadmins from? Clearly not actual linux sysadmins. -sv -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
