The Strengths and Weakness of Fedora/RHEL OS management

[Bill Crawford]

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?