On Feb 24, 2009, at 4:43 AM, Bastien Nocera wrote:
On Mon, 2009-02-23 at 20:47 -0600, Callum Lerwick wrote:
On Mon, 2009-02-23 at 17:17 -0500, Colin Walters wrote:
<snip>
Don't get me wrong - GConf has some very bad design flaws (at least
should have used something like Protocol Buffers instead of XML),
and
I'm not defending the weird dconf licensing.
But "let's just use lots of files" is not the answer.
So group your keys if too many files is such a problem. You know,
like
we've been doing for decades. Config files are a Solved Problem, the
only problem here is people want to write some overwrought universal
library and make everything use it. While centralizing code is
generally
a Good Thing, people seem determined to overthink and overdesign it.
Second system effect at its finest.
A modern configuration system needs:
- strong typing of values
- a way to set defaults and revert them
- changesets to avoid races
- notifications of changes
- protection against data loss when two applications want to edit the
same configuration (or configuration file)
You left out SELinux support and security.
So let's use less files isn't the answer. If you're designing a daemon
to be installed and administered by power users, go for it. Otherwise,
simple files in a tree is completely under-engineered for the desktop.
You need a daemon sitting on top of it.
And your daemon is going to be an SELinux object manager and enforce
the security policies of the underlying system?
Everything not greppable, diffable, human readable and editable,
should
be dragged out in to the street and shot. This is /configuration/
we're
talking about.
Agreed
For GConf, we were human editable and readable through gconf-editor,
and
greppable/diffable through gconftool-2.
Either you're fueling a flamefest, or you don't understand what's
required for a modern configuration system.
I think these gizmo driven, daemon oriented configuration systems
ignore requirements (e.g. security, simplicity) to optimize others. It
is all about the metric you are choosing to optimize. By leaving out
security and simplicity, you end up with a different solution.
It is easy to write SELinux security policy to allow one domain to
read but not write a file in another domain. It can't be done with a
TCP connection to a daemon unless the daemon is an SELinux object
manager and much more complex. Configuration systems that use the
filesystem are much easier to deal with from a security perspective.
joe
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
