[linux-elitists] Re: Yet another mozilla atrocity

Karsten M. Self kmself@ix.netcom.com
Thu Oct 9 03:46:47 PDT 2003

on Wed, Oct 08, 2003 at 11:34:00AM +1000, Martin Pool (mbp@samba.org) wrote:
> On  8 Oct 2003, "Karsten M. Self" <kmself@ix.netcom.com> wrote:
> > > 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?

First:  note that this was a straight question.  I have some
understanding of file locking issues.  Not deep though.  I'm asking for
information to get a better understanding of the problems.

> One of several smart things Havoc said is 
>   If you don't know how to code, then you don't know how to design the
>   software either. Period. You can only cause trouble.
>                 -- Havoc Pennington, http://ometer.com/hacking.html

Bogus.  Adequately discussed elsewhere.

> You can't rely on file locks, atomic replace, or other Unix patterns
> for safely accessing files because you can't control how the user will
> update the file.  For example, if they cat some data to it, the
> application might see it as half written.  Unix has no way to say,
> "when you update this file you must lock it".

Agreed -- this is as I understand.  Which is one reason why I suggested
dispensing with file locking entirely by ducking down a level, and
putting version control on top of the system.  In this case:

  - One process updates the file with no conflict.  The edit is made and
    committed.  No problem.

  - Two processess update the file in the same time period.  One sees
    that the versioned file has changed since it began edits, and tries
    to work out an accomodation:

    - If the edits don't conflict, submit the changes.  This is likely
      the vastly most frequent situation.
    - If the edits do conflict, you've got the option of attempting to
      think through it yourself, punt to the user (what do you want to
      do), or abandon the requested change, reload the file, and trie

The appeal to a solution like this is that it's basically well
understood with numerous implemnetations to choose from.  It also works
well with text files (as gconf uses).  Essentially:  if you can't do
something easily, punt, and add an appropriate wrapper layer.  In this
case, version control.

Would this be acceptable at all?  I'm attracted to the possibility.  I'm
not committed.

> gconf's model, for better or worse, is that preferences are saved as
> the user changes them, rather than through an explicit "save options"
> command.  This means that the files might be rewritten at any time,
> because of user action.  

Note that this isn't clear to the user.  I'm generally used to having
separate "indicate changes" and "commit changeset" operations.   The few
times I've worked with gconf-editor directly, I've been confused at
times over when, exactly, the changes are committed.

> (Possibly quite a small user option like displaying a new tool
> palette.)  If the preferences file is open in an editor at that
> moment, then you have a race condition.  At best one of them will win,
> but it's possible it will just be corrupted.

See above for versioning.

> Basically every Unix application that has files updated by multiple
> processes requires people to go through a wrapper layer rather than
> editing things directly.

Yes.  What's the gconf wrapper for this?  Or is it the flock() within
the gconf tools and libraries directly?

> Corrupting user data is one of the bad things about the Windows
> Registry.  We want to avoid that.  We don't want to say "well, it
> won't happen very often."
> >   - 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.
> So gconf solves it, by doing all updates atomically.

As would version control.

> >   - 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.
> Yeah, or you could just make it safe in the first place.  

Version control also offers rollback and commenting capabilities.  A set
of configurations could be tagged as a specific test case.

> > > 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.
> No it doesn't.  The hypothetical
>   $ gconftool --edit /Apps/Metacity
> would pop you into $EDITOR.  You could tweak the settings and when you
> save and exit they would be syntax checked and take effect.

Do you envision gconf-specific support within $EDITOR?  Given the key
values I'm seeing for applications, pulling these out of my head will be
difficult.  Are the gconf schemas something that could conceivable be
parsed by some emacs utility?  Seems feasible, even if not currently

> > Unless I'm mistaken, 'Nix lacks _real_ file locks, correct?  Is this a
> > fatal flaw?
> Linux doesn't normally have mandatory file locks.
> Somebody else might write an operating system where files are
> transactional and applications can be notified of updates.  On such a
> nice system, gconf would be far simpler and wouldn't need a daemon.
> Unfortunately, we have to work with the tools unix gives us.

My own feeling on this is that for general purpose tools (e.g.:  gconf),
building in features only supported in a specific advanced filesystem
would be a bad design decision.  Too many problems when you drop to a
less-featureful, but more typical, FS.  For specific applications (say a
high-end, performance/volume oriented database) this might be suitable.

> > > 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?
> gconfd notifies the application when the variable is changed.  The API
> is easy to use correctly.

Assuming version control -- this is the sort of thing that could be
triggered on a commit, no?

> > 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.
> Yes, there are several other approaches, but they're not as good.

Pointers to prior discussion -- I suspect there's been some?

> > > 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.
> Let me explan gconf in terms of xrdb:
> In both gconf and xrdb, the settings actually "live" inside the
> machine (in the X server or gconfd).  You cannot modify the variables
> themselves.  What you *can* do is use a tool (xrdb/gconftool) which
> will get or set the values of selected or all properties.  Although
> you're not "directly" accessing the variables in memory, from the
> user's point of view it makes little difference.

Right.  In my case, xrdb settings live under a directory tree, I run a
bash loop w/ find to load each to xrdb.

> Unlike xrdb, gconf settings automatically persist between settings by
> being stored in files.  (You don't need "xrdb -load ~/.Xresources")

I could (and do) effectively emulate this by running the bash loop
within my ~/.xsession.
> gconf's variable names are less wacky than xrdb patterns.  Things have
> simple unix-style pathnames, not bizarro wildcards.

The variable names may be less wacky.  The variable data leaves
something to be desired.

Wildcards can be useful when setting values to apply across a range of
settings.  An aquired taste, perhaps, but we've got regexps and shell
globs, they fit within the 'Nix idosphere.

> gconf schemas tell you what variables and values are meaningful, and
> variables can have documentation attached.  There is a way to set
> system-wide default or mandatory values.

This is something I need to look at more closely.  Previously mentioned
online reference (the one I dissed for not mentioning gconf-editor)?

> gconf applications can easily store user settings; xrdb applications
> can typically only be configured by noninteractively.

I've used some (though admittedly not many) applications which have a
menu-based picker which sets xrdb values, which are then squirreled away
in a conf file someplace.  SAS does this for some of its Xt/Motif
widgets.  You must of course restart SAS for the settings to take effect
-- best of my knowledge, xrdb is not dynamically updatable for an
application.  gconf wins here.

> gconf is more or less a strict superset of xrdb.

Buzzword bingo ;-)

> > > 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
> > transfer.
> Yes, I've been trying to say that that can be done!  Try running
>   gconftool --recursive-list /

I'll pretend I didn't understand that one more time ;-)


> > > 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
> >     lacking.
> All of these are bugs, I agree.  I'm not denying that some software
> which uses gconf has bugs, or that gconf itself has some things that
> should be fixed.  That doesn't mean the design is bad, or that gconf
> should be discarded.  Dirty bathwater, cute baby.

Unfortunately, I'm usually bathing cats.

What does seem clear to me is that usage notes on how application
developers implemnt gconf should be stated.  I don't know what distros
you have familiarity with, but Debian's policy is very useful for
working out issues such as this.

> > A choke controls inner workings of the engine.  Where in past automated
> > control systems weren't feasible, they now are.
> Please read Havoc's essay.  This is what he says.

I suspect violent agreement on this one point.


Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
   At the sound of the toner, boycott Lexmark:  trade restraint via DMCA.
-------------- 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/20031009/8e51aee1/attachment.pgp 

More information about the linux-elitists mailing list