The Strengths and Weakness of Fedora/RHEL OS management

[Joe Desbonnet]

Just fantasising here ... the ideal configuration system IMHO would
fulfil the following criteria:

1. For simple configurations it should reduce to a simple key-value
pair text file, except that parsing rules will be very well defined.
2. At the other end of the scale it should handle the most complex applications
3. An optional schema definition can define the schema of the file
4. That schema can optionally provide enough information to enable a
configuration file editor to automatically generate a UI to enable
someone who is not intimate with the application to make changes (help
text, widget hints etc)
5. I18N proof
6. Optional modification history and roll back facility. If the
modification was made programatically, the audit trail should record
what make the modification.
7. Always have the option to edit with a text editor (ie it should be
easy for a human to read it and edit it)
8. API bindings for common languages (C, C++, Python, Java, Perl, bash?)

Joe.

On 3/28/06, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> On Tue, 2006-03-28 at 14:37 -0800, Shane Stixrud wrote:
> > On Tue, 28 Mar 2006, Toshio Kuratomi wrote:
> >
> > >
> > > If you look through the following, monster thread you'll find that
> > > elektra is a bad choice for the desktop configuration api.  System and
> > > desktop configuration requirements are different.  Also, the author of
> > > that GConf comparison doesn't seem to understand the problems GConf is
> > > attempting to solve which doesn't bode well for it ever displacing
> > > GConf.
> >
> > If I am not mistaken since that time elektra has developed its backends so
> > that they can import/modify/export data from other systems like gconf so
> > that gnome can continue to depend on gconf while users/admins can have a
> > single method of modifying data.
> >
> Hmm... but what is really the goal of the project?  To have a unified
> on-disk format?  Or to have a unified API?  Reading through the myriad
> posts and Documentation leaves me with the feeling that which one it is
> depends on which suits them at the time.  Elektra using a Gconf backend
> would give you a unified API -- but if the GConf API is more suitable
> for the desktop than Elektra then what are you gaining?
>
> OTOH, if the on-disk-format is what's important (so the system admin can
> edit the text files consistently) then Elektra would have to be the
> backend for GConf (which is possible, contrary to the implication on
> http://www.libelektra.org/GConf )
>
> > In either case Elektra may very well not be the correct solution, but a
> > technical solution does exist, it may just not of been found/developed
> > yet.  There is a problem to be solved here, I haven't heard anyone argue
> > seriously to the contrary
>
> I think Nicholas Mailhot had an extremely valid point:  The
> configuration format (key = value; <key>value</key>; etc) is not a major
> stumbling block for a system admin.  It's what the application
> developers choose as the name for key and what they fill value with that
> make configuration files easy or hard to understand.  Elektra and the
> like are seeking to solve a problem that will only marginally aid a
> system administrator in editing a config file from a text editor.
>
> -Toshio
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQBEKb/iX6yAic2E7kgRApBAAJ9ZecfzBkoDI6RlUtNmDoImkSwjzwCfWSwr
> KLRWkDMJ2mCemySz5XQ95L0=
> =gvoY
> -----END PGP SIGNATURE-----
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>