View Single Post
Old 14th March 2005, 23:05   #341
Forum King
xzxzzx's Avatar
Join Date: Aug 2002
Posts: 7,254
Originally posted by zootm
Some systems necessitate complex settings, though, and any generalised system should allow them in simple ways. It is trivially easy to automatically parse a file like the one you mention into XML, but I agree that it adds an extra layer of complication. And I don't agree with using scripts for representation -- it's not really standard in any way, and if nothing else nobody will agree on a language to use.

What I'd favour would replace /etc/, and I feel I have my reasons. This comes into why it seems like a "zen crime", though -- it breaks the UNIX file metaphor. "Everything's a file, files you can edit are text" is basically the system upon which UNIX is based, and it works well with the systems that were available at its inception. I do feel, however, that we have better technologies available now, and it would be very nice if we could build a more modern system design from them. Breaking compatibility, or moving to a different system, will always have vehement complaints from users of the current systems, though. And sysadmins are perhaps the most zealous users of all. You could just move everyone to a compatible configuration and merge the XML file structures to configure (GConf does something similar, but with non-standard formats too).

It is something I'm genuinely interested in, though, and I do like to hear well thought-out criticism of ideas. As for your design quote, though, my argument is that what we'd be taking away is a myriad of incompatible configuration formats and so on.
Ok, I'm going to present a 5-minute counter-argument. This is just everything I can think of that I don't like about your solution, because I only have 5 minutes to post.

First, everything-is-a-file is a perfectly valid design philosophy (even today), because it's so damn close to nothing that it's near perfect.

Second, and I don't know exactly what you're proposing, but let's say you're going to have a big XML file which stores configuration data. How can you reasonably keep that thing secure and fast and reliable and recoverable?

Third, while it's admirable to want to have one configuration format, is that going to be able to be simple enough that it's going to be able to be edited by hand? Or is it going to be 12 levels deep before you can even find application data?

Fourth, while it's nice to have a GUI for these things, and that would mitigate some administration-added-complexity rantings I've been tempted to throw in here, how well are you going to be able to edit it

The problem I see is that a registry is basically a duplication of a file system. With a file system, you've already got security, reliability, and speed. The only thing you're missing is complexity, and I don't think that's a particularly bad thing. If you make complex configurations hard to implement, that means it's easier to simplify configuration options than to build your own configuration system.

Finally, when you're trading complexity for simplicity, you have to consider when the complexity/simplicity is going to show up. If you're complicating common operations (99.9%), and simplifying rare operations, then you'd better well be eliminating a HUGE complexity in your rare cases.

From what I can tell, "vi /etc/sshd" is far, far, FAR more common than anything you'd ever need a database/XML thing to do with more simply.

And now I must go.

Freedom of speech is the basic freedom of humanity. When you've lost that, you've lost everything.
1\/\/4y 34|<$p4y 1gp4y 33714y, 0d4y 0uy4y? | Roses are #FF0000; Violets are #0000FF; chown -R ${YOU} ~/base
The DMCA. It really is that bad. : Count for your life.
xzxzzx is offline   Reply With Quote