Status of gconf -> dconf

[Joe Nall]

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