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? Dan > It seems to me that people are not looking at the full picture here, > there are people in the world for whom this would be godsend, not just > desktop users but admins - that is aside all the nice things that this > will enable us to do according to davidz. It will enable us to give the > users greater understanding of settings and a greater ease in tinkering > with them, largely thanks to having one uniform interface, with > comprehensive comments and explanations in their language. > > - David Nielsen > > > -- > fedora-devel-list mailing list > fedora-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
