Slashdot Mirror

← Back to Stories (view on slashdot.org)

Solving the /etc Situation?

Posted by Cliff on from the config-file-wars dept.

mrfibbi asks: "/etc is a mess, plain and simple. Each program has its own (incompatible) config file format and the naming scheme/hierarchy is left almost solely to the author. Furthermore, package updates are a mess, either choosing to replace the entire config file, reject any updated versions (which leads to inconsistencies), or, as is the case with etc-update, asking the user to manually merge the files, which takes forever after a big update. We've revamped /dev with udev, but we've still failed to come up with a universal, duct-tape-free solution for the problem. Though solutions exist, there has been little or no adoption, either due to a personal dislike for the idea or API, or just an indifference to the problem. Should we work toward migrating to an Elektra-like system? Something else? Or do most simply find it not worth the trouble?"

2 of 293 comments (clear)

  1. Re:Messes are inevitable by Just+Some+Guy · · Score: 4, Informative
    I agree, with the exception that I think XML is infinitely preferable to some of the hand-rolled workalikes I've seen, and you can use a standard set of tools to parse any particular XML file sitting around.

    What's the conceptual differences between

    [TopSection]
    Setting1 = true
    Setting2 = yes
    Setting3 = no
    Setting4 = false
    and
    <section name="Top">
    <Setting1>true</Setting1>
    <Setting2>true</Setting2>
    <Setting3>false</Setting3>
    <Setting4>false</Setting4>
    </section>
    except that the latter can be browsed and edited with any editor that understands XML (as opposed to only Vim with the file-format-specific highlighter), can be deterministically validated by generic tools, and doesn't require the program's author to implement his own configuration file parser?

    XML isn't a perfect fit everywhere, but /etc is one of the places I think it works brilliantly.

    --
    Dewey, what part of this looks like authorities should be involved?
  2. Re:I got an ... _angle_ by Foolhardy · · Score: 3, Informative

    The only things centralized about the registry are that it has a single database server that does the actual file writes while providing a high level API, and it has a single-root hierarchy.
    Data in the registry is stored in hives mounted at various places in the registry's hierarchy. The registry's root is a key named \REGISTRY in the Object Manager's namespace. Win32 confuses things a little by renaming \REGISTRY\MACHINE to HKEY_LOCAL_MACHINE and \REGISTRY\USER to HKEY_USERS, and providing some pseudo keys, like for the current user, but the idea is the same. The RegLoadKey, RegUnLoadKey and RegSaveKey functions can be used to dynamically mount, unmount and copy hives in the registry. The key \REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control \hivelist contains a list of all the hives to be automatically mounted at startup. Go ahead, divide the registry into as many hives as you want, and put them where ever you want.

    What I'm trying to say is that the registry is no more centralized than the VFS is in Linux. The registry consists of various hives mounted at different locations, just like the VFS consists of various filesystems mounted at different locations.

    As for messyness, is this due to the structure of the registry itself, or Microsoft's usage of it: do you really think that if Windows used an /etc it would be any better documented or organized?
    Personally, I don't think the layout is all that bad.