Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management)

[David Zeuthen]

On Mon, 2006-04-03 at 12:11 -0300, Avi Alkalay wrote:
> On 4/3/06, Horst von Brand <vonbrand at inf.utfsm.cl> wrote:
> > That is the crux of the matter: Glorious schemes for world domination "if
> > only everybody will agree on the same configuration file syntax" are thrown
> > around here, but the ones in charge of adopting said syntax have
> > historically shown very, very little desire to agree on a syntax.
> 
> Here comes the role of distributions as the integrator.
> This is why I say each of these projects (Apache, Samba, everything on
> /etc/*, Gnome, KDE, etc) are a sort of "selfish" and "proprietary"
> when it comes to overall integration architecture.

Maybe these projects wants something more than just a simple replacement
for their configuration file parser?

Maybe parts of their configuration is marked as private and they don't
want to make it easy for wanna-be administrators to change it?

Maybe they want to offer an interactive configuration interface based on
D-BUS with asynchronous notifications when state in the server changes?

> > So your idea is getting rid of configuration files and push everything into
> > LDAP? What if the LDAP server is down?
> 
> What if you don't have/want a network?

Just run the LDAP server locally. You want some caching LDAP server
anyway for disconnected operation.

> What if my mother only wants to install a new multimedia keyboard in
> her standalone Linux box? She'll have to edit /etc/X11/xorg.conf? Or
> wait for the distribution's HW detection tool to know how to handle
> that? Clearly the best solutions is to let the HW provider know that
> X.org configurations are pretty predictable in any distribution, and
> it just have to provide some scripts to precisely integrate itself in
> X.org configuration schema, instead of having to "compile", understand
> and regenerate /etc/X11/xorg.conf only to install itself. Being so
> difficult, this HW provider will simply, obviously, declare they do
> not support Linux.

Maybe I'm repeating myself but here goes:

X.org should require no configuration file and should autodetect the
software. It should also provide a D-BUS interface to desktop apps can
configure the server and it can emit useful asynchronous notifications
when e.g. a new monitor is attached. Hence, all display configuration is
done per-desktop and settings are read from e.g. gconf. We can do
similar tricks of reconfiguring the server on the fly when new hardware
is hotplugged. For example you can disable the internal trackpad on a
laptop when an external mouse is attached.

Btw, system admins can lock this down if they want and it's trivial to
write a display configuration applet that is the same across all distros
just like e.g. removable media handling is now the same across all
distributions.

For the record, many of (influential) X.org developers with whom I've
discussed this agrees this is the road ahead. It's just a lot of work
and the people with these skills are busy with other things.

    David