On Tuesday 28 March 2006 23:24, Shane Stixrud wrote: > This reasoning is flawed and I think it illustrates an example of where > our Darwinist Meritocracy has difficultly dealing with problems that are > global and counter to our evolutionary path. It's not flawed reasoning, it's a statement. There are plenty of reasons why it hasn't happened, among which are a number of experiments with various forms of "registry" ... The reason most applications use individual config files instead of a central repository is because that makes it much, *much* easier to: 1. Design a domain-specific config language. XML does *NOT* solve this problem; it is a *lexical* (meta)language. The structure goes on top. 2. Point to a different config file when you start a program. 3. Copy config files, rename them, reuse them, move them into chroot() environments, and generally be *free* to do so. 4. There is no step 4. > Tell me, what motivators > exist for any project or even groups of projects to adapt a > non-standard 3rd parties configuration schema?? None, in fact I am > sure there are plenty of reasons NOT to adapt such a thing. When > looking at this issue from within a specific microcosms perspective it > makes perfect sense why UNIX and Linux have failed to create this standard > API after 40+ years of evolution. So what are you saying? In fairness I won't attack the straw man. It looks like you are holding one, though. > It is when you look at GNU/LINUX as a whole that this problem becomes > obvious and it is for this reason I think Fedora/freedesktop/LSB/FHS > or some other entity with ties to the system as a whole will have to > champion this standard. A global configuration scheme has little benefit > until a large portion of the system is using it, until that threshold is > meet it is but another configuration format adding to the systems > complexity. Ah. The "it must all be integrated" straw man. (sigh) > > And why are they bothering with SysVinit at all... > > My guess is because at the time they did the patches this debate was not > hot. It seems they treated sysvinit as a proof of concept that > libelektra is usable even at the earliest stages of os initialization. Why are we all so intent on picking a sysvinit replacement before we have one that's fully useful and does all that the current system does? -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list