Re: [Fwd: Lockdown stuff]

On Thu, 2003-09-18 at 23:51, seth vidal wrote:
> > That's pretty much my impression too, but at least it's localised to GConf
> > (even though it might mean deep changes internally, it shouldn't require API
> > or ABI changes, so it's not going to break apps on top). Gotta pull in Havoc
> > for the real deal though. :-)
> 
> ok - let's do that.
> 
> Havoc,
>  What are we talking about to fix the problems we've highlighted in
> gconf? I've subscribed to gconf-list but I don't think I've ever
> received a message there. Is there any discussion going on as to
> when/how to fix this?
> 

You mean home-directory-sharing/lockfile, right?

There hasn't been recent discussion, simply because there isn't a likely
volunteer to hack on it that I know of.

GNOME 2.4 defaults to the lockfile in /tmp ; I don't know if that will
result in more problems or less. It is however almost equivalent to
having applications simply write to text files directly, which is the
traditional method of doing configuration. The one reason it isn't is
that a single app may have config in multiple files. So a possible
short-term hack would be to do a file backend that puts each /apps/foo
subdir in a single text file? That might be a simple thing to try that I
just thought of to avoid funky states. Perhaps long-term it's even The
Solution for the local files backend.

/tmp locks are also currently hosed with GNOME 1.x apps, but we should
get that fixed and also Evolution was the last of those I believe, other
than Gnucash.

My long-term plan is to simplify the gconf code quite a bit (for stuff
like the logfile problem, just stop logging; gconfd should be a lot
smaller by keeping less state; libgconf could also be significantly
smaller). Then have two backends, one LDAP (working toward this, I
finally read a book on it), and one plain files (but no longer assuming
a single daemon accessing them; change-monitor and lock each file).

The without-redoing-all-of-gconf solution is probably to do only the
backend part of this, to move change notification to the backend, and
have some system where file changes by other daemons are noticed and
each daemon sends out notifications. Probably you also need to lock each
individual file while changing it, instead of just writing it
atomically.

But of course then you're in file-locking hell again. ;-)
For the D-BUS cookie file, I have some code that doesn't use kernel
locks, just has a really long timeout on a very briefly-held lockfile;
maybe that is the right approach for the backend files.

Reading your larger-scope mail:
http://mail.gnome.org/archives/gnome-deployment-list/2003-September/msg00000.html

I'm hoping a number of those problems can be solved by two things that
I've been advocating:

 - the Xserver/D-BUS lifecycle model instead of the Bonobo one; i.e. 
   there's a process that when that process dies, all apps connected
   to it exit; and said process lets apps track each other's lifetimes.
   This should eliminate the funky process-left-over issues and things 
   like Evolution losing its composer which keeps happening to me.

 - fix the session manager. I believe the session manager should be 
   responsible for sanity-checking disk space on login, and also 
   gracefully helping with multiple login if we can figure out how.

Some of them though I'm pretty afraid we are only going to be able to
fix by comprehensively testing and fixing the failed-IO error handling
of every place in every app. This will have to be an effort on the scale
of the a11y effort, with someone dedicated constantly auditing, filing
bugs, creating patches. Jonathan did try to make gnome-settings-daemon
constantly check for low disk space and offer to fix it, I _think_ that
ended up in CVS, not sure. Also, we could get a long way by just
ensuring nautilus runs so you can clean up some files.

Ultimately the multiple-login problem is probably best solved by _not_
sharing homedirs, but instead using dedicated file shares, IMAP, LDAP,
and other specialized servers. Or perhaps by having a network file
system that sucked less, using the homedir as the all-singing way to
keep your data on the network would be more robust.

Anyway, I can't begin to fix all this myself. I do want to get it fixed
though. It would be very helpful to me if someone could adopt the menu
problem, btw. ;-) Basically I want to polish up D-BUS and get it going,
base a GConf reworking on that in addition to having that address many
lifecycle/robustness issues, then tackle the session manager. I would
also like to offload some of the RPMs I maintain and get a good
maintainer for some of the packages I own. But it's all a fantasy. ;-)
Ultimately I'm only going to be able to do 5% of the work myself.
I don't even see how I'll get to finish the menu stuff at the moment,
and I'm not keeping up with bugs on my modules.

Havoc