Status of gconf -> dconf

[seth vidal]

On Tue, 2009-02-24 at 08:42 -0500, Simo Sorce wrote:

> Seth, the fact that sqlite or other db-style files have problems on some
> networked filesystem either indicate a bug in the db or in such
> filesystems.
> 
> NFS(v2/3) is known to be a bad file system, sure it "mostly" works for
> users, but has so many problems I do not even care to think anymore
> (riduculous locking, stateless, no decent client caching ...).


nfs v2/v3 are known to be filesystems in common use. They are also known
to be the filesystems that worked with multiuser configurations in the
past. It's not like this has been a problem for networks all along and
people only suddenly realized it.

When I started managing shared resource unix/linux systems a decade ago
multiple logins to multiple desktops were running all the time. Hell, in
many cases the end-user systems didn't even have local disks to speak
of.

Somehow we managed with nfsv2.

> NFSv4 and CIFS should be much better, is sqlite breaks on these
> filesystems there are perhaps bugs in their client kernel components.

> It would be better to fix the FSs rather then just ditch the problem
> completely.

It might be worthwhile to ask what the features are we're getting out of
moving things to sqlite, for example, before deciding that there is a
problem to be fixed at all.

The foregone conclusion seems to be that we have to add data-rich
features. I don't think that's a good given.

> That said, given home directories must stay on a trusted server anyway,
> building a central daemon that the networked desktops can use instead of
> trying to open databases over networked filesystems (performance sucks
> when opened from multiple clients) is also a good idea.

central daemons are a problem unless they are designed like filesystem
infrastructure are designed: fault tolerant, capable of fail over and
redundant. And configuration daemons have, in the past, been designed
very poorly and/or horribly over engineered (ACAP as an example, ORBit
as another).

We need to NOT lock out one set of users for another set of users.

-sv