[linux-elitists] Re: Yet another mozilla atrocity

Karsten M. Self kmself@ix.netcom.com
Tue Oct 7 16:11:50 PDT 2003

on Tue, Oct 07, 2003 at 12:40:43PM +1000, Martin Pool (mbp@samba.org) wrote:
> On  5 Oct 2003, Jeremy Hankins <nowan@nowan.org> wrote:

> > 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.

OK:  why not?

Mind:  I'm not an applications hacker (more data stuff and sysmonkey,
myself).  But:

  - So long as we're talking user-space apps, the likelihood of
    collisions between multiple users seems pretty low.  Unless there
    are design intents behind GNOME I'm not grokking.  But in general,
    if I find I'm editing a file I'm already editing, I'll tap myself on
    the shoulder and ask if I don't mind releasing the lock or if I
    should tell myself to go away and try again later.

  - Automated tools could check file state prior to / after
    modification.  The issue essentially becomes one of version control
    / cache coherence.  And while there may be *some* warts in systems
    that cope with same, it's not a wholly insoluble problem.

  - If state mangling is _that_ critical, you'll design in a state
    recovery capability -- back up files, version control or something
    similar, to allow you to roll back.

I don't buy this.

> 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.

This assumes a single config file.  If we're accepting the model of a
config file per application, that's an awful lot of dedicated editors.

There Has To Be A Better Way[tm].

Unless I'm mistaken, 'Nix lacks _real_ file locks, correct?  Is this a
fatal flaw?

> How do you report syntax or semantic errors to the user?  

In the case of xrdb (which actually has _some_ similarities to gconf),
the messages are written to stdout when parsing scripts.

An alternative would be to have a script parser tool or mode, a'la
apachectl configtest.

> If some of the configuration items can't be read because the file is
> corrupt, should they suddenly pop back to their default values?

I'd think current values rather than default.  Why should I change the
value of X if my assignment of X was invalid?

> 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.

How does gconf solve this problem?

I'd think that the situation would tend to have a number of likely

  - Use configuration tool specific to app/desktop.  Update polling is
    handled within the application after modifications completed.

  - Edit via text tools.  Either polling (peridoc) or manual application
    of changes.

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

I can think of several approaches to this sitation, including file
locking, checking state, waiting to save the change when the file is
free, etc.

> 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.

Again, this is a situation which is already handled in xrdb.

One option is to have an application (real or virtual) which is
responsible for global state settings.  Again, this becomes similar to
work that's already been done elsewhere.

> 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.

Is there any reason multiple modes couldn't be supported?  E.g.:  an
"export" or "sync settings" menu option.  Or a command-line driven rsync

> 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.

My specific beefs:

  - Specific application implementation is inconsistent.  This appears
    to be a bug with Galeon 1.2.5:   proxy settings only take hold when
    set via gconf, rather than with preferences config or manual file
    edit of user.js.

  - Data storage formats can be opaque:  previously cited Evolution
    instances for "My Weather" and "My Headlines".  Which I'll note the
    GNOME crowd here have punted on identifying or decoding.

  - Data storage structure doesn't allow comments or commenting out
    settings on a temporary basis.

  - Documentation of available tools (specifically:  manpages) is

> 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.

I don't have the means myself to write something different.  I'm not a

> > 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.  

I responded at greater length on this point to Mr. Bad.

A choke controls inner workings of the engine.  Where in past automated
control systems weren't feasible, they now are.  Note that the last time
I used a power mower it *did* have a choke -- apparently the price-point
at which automation becomes feasible is somewhere between the $10k that
a basic car will cost, and the $300 that a power mower runs.

OTOH:  I have and vastly prefer stick to automatic transmission:  my own
response cycles are sufficiently matched to the need, _and_ the decision
is based on factors an automatic gearbox can't determine:  oncoming road
or traffic conditions, my own driving plans.  While auto is suitable to
many, it's not _my_ preference.

Most of the settings that I'm concerned with are either directly
external -- fonts, colors, window manager bindings and the like -- or
settings which control functionality in ways that aren't immediately
determinable -- say, an http_proxy environment variable (yes, it's
possible to configure transparent proxies, but that's more work at


Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Bush/Cheney '04: Less CIA -- More CYA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20031008/3e6fd09d/attachment.pgp 

More information about the linux-elitists mailing list