[linux-elitists] Re: Yet another mozilla atrocity

Martin Pool mbp@samba.org
Mon Oct 6 19:40:43 PDT 2003

On  5 Oct 2003, Jeremy Hankins <nowan@nowan.org> wrote:
> Jeff Waugh <jdub@perkypants.org> writes:
> > <quote who="Karsten M. Self">
> >> For the most part, where I like GNOME apps it's *despite* rather
> >> than on account of many of the GNOME tight-integration features.
> Definitely.  What's more, I have yet to use a gnome app where I didn't
> eventually decided wasn't worth the headache.
> > May as well use it, particularly if you
> > want a consistent interface (both from a developer POV and an
> > administrator's POV). Little text files in users home directories
> > are not group/host/all enforceable, etc.
> These are such hard problems that you needed gconf -- as opposed to,
> say, a set of conf-file-reading libraries?  If this is all you're
> trying to do gconfd seems like incredible overkill.
> I can easily see the point of a lib that provides a standard syntax
> for config files, is capable of setting policy (e.g., read global
> config first, and allow it to override the per-user config), and takes
> care of locking in a consistent, predictable way.

So tell me: if you're going to allow people to edit the configuration
files with any old text editor, then how are you going to do locking?
You can't use file locks or atomic replace.

A traditional unix way around this is to provide a command which
invokes the editor with appropriate wrapping to do locking, error
checking and so on.  (See: visudo, vipw, crontab, cvs ci, etc...)
This could be easily built on top of gconftool, and probably will be
eventually.  Probably a couple of hours of scripting.  For a donation
to the FSF I'll do it for you.

How do you report syntax or semantic errors to the user?  Traditional
tools write to stderr (often to ~/.xsession-errors), and hope the user
can find the message.  If some of the configuration items can't be
read because the file is corrupt, should they suddenly pop back to
their default values?

How does the application know when to reload the changes?  Nick
suggested that it should poll the configuration files, which is
typical of the "oh it's so easy" response from people who haven't
really thought through the problem.  To make it not too laggy, you'd
need to poll at least every couple of seconds.  Is having every
application poll the disk every second really so elegant?  (Heaven
help anyone with home on NFS).  And of course you still have race
conditions, since you can't rely on locking.

What happens if the application needs to store an option while it's
open in the editor?  Another race.

Don said that each application should have one dot file called
~/.${app}rc.  OK, that does make it easy to find and copy around.  But
what about options that apply to more than one application?  If you
have a ~/.guirc, ~/.printerrc, ~/.networkrc, ~/.apprc then you
converge on a similarly confusing state.

Here's an example of a power-user task: people might like to
synchronize their options between intermittently connected machines.
I do this using Unison and emerge, but this doesn't work for people
who don't want to see the guts of the configuration file.  gconf, by
having mtimes on options, has the possibility of a good solution in
the future.  In the interim, you can do it by either copying the files
or using gconftool.

There are some genuinely nontrivial issues which gconf's critics are
glossing over.  At first glance gconfd might seem like overkill when
you just want to read a configuration file, but on further
consideration it seems reasonable to me, at least for a first cut.

People who write applications have chosen to use gconf because it
seemed like the best available solution for them.  If you want to
write a library which has a better solution, then please go ahead!  If
the application annoys you, don't use it.

> > Why would you have so many options and preferences that you have no
> > choice but to provide search facilities for them? (Yes, we're
> > talking about a different world to vim, mutt and friends.) The KDE
> > control center provides this, mostly because it is stuffed to the
> > gills with pointless, masturbatory preferences.
> Yes, of course.  Anything graphical needs to be dumbed down.  Keep
> those (l)users in their place.  As far as I can tell, this is the core
> of your position, yet it's completely without support.  There's a
> problem with the configuration interface?  Well, you shouldn't really
> be using that anyway.  Configuration is only for the mentally ill.

I think you have a chip on your shoulder here.

My car doesn't have a choke control.  That isn't because the designers
were dumb, or thought I was dumb.  It's because they were smart enough
to make it automatically adjust to conditions, and indeed it has never
failed to start.  At its best, GNOME achieve a similar elegant


More information about the linux-elitists mailing list