Status of gconf -> dconf

[Simo Sorce]

On Tue, 2009-02-24 at 09:17 -0500, seth vidal wrote:

> Okay, let's stop it with remarks like the "if you have to ask then you
> don't understand".
> 
> We can all play this game, if you want, but it's not a good way of going
> about interaction. It's elitist and dismissive.
> 
> If you have situations where changing config files breaks down - then
> please, explain them. Let us understand the problem. B/c Istr having
> config files change quite commonly from applications from about
> 1999->2002 on shared filesystems and not having the whole world explode.

Fair enough, but projects like augeas are proof that changing files
(*from an application*) is not as easy as people make it seem.

It's bad to seem elitist, but sometimes its not bad to admit that if you
have not really tried to put your hands on a problem you don't grasp the
fine details that turn a seemingly simple problem into something that is
not that simple after all.

> > Except that:
> > - filesystems are not meant to hold huge numbers of small configuration
> > files, most FSs have limits on the number of inodes, have inodes of 4KiB
> > in size, so storing a a couple hundreds byts in a file is a total waste
> 
> 
> By your own previous argument, then let's fix the filesystems. And,
> quite frankly, I think the above concern is going away in the face of
> filesystems like ext4, btrfs, etc.

ext4 and btrfs are just more efficient filesystems, but the minimum
block is still 4KiB (for now) and may even grow, maybe it could shrink
down to 512B, but there are reasons (from FS structures to hw) why there
are lower limits like this, trying to "fix" this limit for a few config
files to (possibly) detriment of all other uses seem not a good idea
(and yet inode size is just one of the issues of using hundreds of small
files for a single application).

> > - notification does not come for free, there are limits for inotify and
> > abusing them is not a good idea
> 
> what are the cases where notification is required?

When you have multiple applications/processes that need to be notified
of a change ?

> > - ACLs are available only for users known to the underlying unix system
> > *when* available, and they are not standard: posix ACLs, NFSv4 ACLs, AFS
> > ACLs, NTFS ACLs ....
> 
> This sounds like an argument for putting things in a file and having a
> common base acl for them.

I thik the suggestion was to split config files in multiple small files
and use ACLs to control access to them. If the objective is just to
protect my config file from yours ACLs are not even needed, unix
permissions are enough. But the point here was to do things like
protecting access to the attribute level in some cases.

> > - Unix filesystem ACLs usually have no concept of things like roles an
> > app may have, can't be set as it would be useful from a user app (only
> > root can easily change ownerships and permissions at will), and are
> > quite restrained in what they allow: read, write, execute, which is
> > often not enough even for files. 
> 
> What's the use case for a user needing to change the ownership of
> his/her own files for configuring an application?

This was not the issue, I assumed we were talking about attribute level
access control.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York