[linux-elitists] GNOME report.

Martin Pool mbp@samba.org
Mon Jan 26 21:48:05 PST 2004


On 19 Jan 2004, "Karsten M. Self" <kmself@ix.netcom.com> wrote:

> >    (Why does testing burden matter when we have millions of testers?
> >    Because we don't really have millions of skilled and willing
> >    testers.  If there are paths which are hit for the first time by
> >    users who are not in the mood, don't have time, or don't have the
> >    knowledge to file a useful bug report then it's a potential loss
> >    for the user and the developer.)
> 
> Here's where an appropriate test frame / debug tool / reporting system
> would help.  Mozilla had one (name escapes me), and I think Microsoft's
> Dr. Watson was nominally something like this (though not of much
> use).

GNOME has one, called bug-buddy.  It's pretty good.

This does not reduce the burden of reporting, categorizing, fixing,
and responding to bugs to zero, or the annoyance to a user when
they're hit.

> >  - Sometimes it is better for the developer to just fix the problem
> >    rather than adding an option to kludge around it.  Although it's
> >    easy to just add another if-else, all of these things mean that
> >    you'll pay for it later.
> 
> Agreed.
> 
> Often providing a function for something is a broken mode.  Especially
> stuff that the system should determine automatically.  Sometimes,
> though, the user, or some users, really want or need the choice.
> Earlier choke/clutch discussion.

Yes, it's a design tradeoff, etc etc.  My point is just that it *is* a
tradeoff, and there are some factors pushing away from offering
unbounded options.  They are not zero cost.

> >  - Users will set options in wierd and broken ways.  
> 
> ...and learn to love them.

> >    (People love to break samba by setting options that sound
> >    interesting, and then waste the developers' time asking about it.
> >    Many of these options are things that only developers would want to
> >    set when experimenting, therefore they are being removed or
> >    hidden.)
> 
> Again, for system-level stuff, automated configurators are a good way to
> fly.  Knoppix sets a bar:  it may not configure itself _optimally_ for
> _all_ hardware and networking situations, but it configures itself
> _functionally_ for a _much_, if not most.  A tool which works out sane
> settings and goes forward is useful.  Autoconf is another.  Hairy piece
> of shite, but damned if it didn't work for a wide range of situations.
> 
> Point being:  you get the user back on even footing.  

We seem to be disconnected.  How is anyone served by having options
where every setting but one will always break their system?  Samba had
options like this.

Sometimes it's good to autodetect but then allow customization.
Sometimes it's better to just autodetect and treat any failures as
bugs.  It depends on the particular space.

> Have them get back to you if they still have a bug.  Sort of the
> equivalent of the help desk asking if you're plugged in to wall
> circuit (no joke: about half my support issues at one job involved
> stuff no connected, connected incorrectly, or with broken
> connectors).

> > I think all the above are true regardless of any subjective/personal
> > feelings about how UIs ought to work.  In addition, there are some
> > less universal/objective arguments
> > 
> >  - Excessive customization can make it hard to switch to someone
> >    else's machine.  (In the good old days, I often had to ask how to
> >    drive a colleague's fvwm...)
> 
> Here's where I've got a *major* difference of opininion.
> 
> You make the configuration portable.
> 
> Rather than forcing all your square pegs into round holes, jackbooting
> users, or resetting time-tested and habituated configurations on moves
> and upgrades, *you port the configuration with the user*.  This is one
> place where GNU/Linux wins *SO* overwhelmingly over legacy MS Windows
> that it's not even funny.  At all levels.  I can port a system to a new
> box (or new architecture), including all 1479 installed packages, and
> configs, in a matter of hours (faster for fully automated transfers).
> For user-level setup, seconds or minutes.  See Joey Hess's $HOME under
> CVS (now either arch or svn, IIRC) articles.  The thought of hoofing to
> a job where I can't determine my computing environment frankly bugs the
> bejesus out of me.  And if you think this is just a techie issue -- the
> secretaries and salesfolk bitch about this as much as anyone, the moreso
> because they're frequently intimidated by the technology.

Oh, I agree.  There is a great potential for having gconf do something
like home-in-cvs in a way my Mum could use, by mirroring my setup to a
server.  There are also some tough design issues about distinguishing
things that ought to be global from configurations for particular
machines.

I was specifically talking about those cases where you have to sit at
somebody else's machine for two minutes.  They don't want you
installing or your dotfiles or starting a different wm.  On GNOME it's
reasonably easy to do this, because there is a core of behaviour
underneath the customization that is consistent.  On earlier Unix
systems it could be very hard to e.g. work out how to switch or resize
windows.

> >  - Sometimes there is a single setting that is adequate for everybody.
> 
> I hear that a lot from you folks (Waugh, yourself, in particular).  I'm
> decidedly unconvinced it's as common as I've heard claimed.

Sometimes it's true, sometimes not.  I don't suppose there is a
universal answer.  All I say is that developers should look for the
possibility.

One that springs to mind recently is the trend towards just using
UTF-8 for file and protocol formats and inside programs.  It's not
ideal for every single case but often having a single standard that
works reasonably well for everyone is better than having everything
configured differently.

(Of course you need to support interaction with other systems and
existing data in other encodings.)

> >    Sometimes you can just support both behaviours, or autodetect, or
> >    whatever.
> > 
> > Obviously not all options can or should be eliminated.  But they do
> > have a cost that is not necessarily obvious either to the programmer
> > or the person requesting the feature.
> 
> A lot of what I'm hearing is that many problems can be avoided by
> eliminating the user.  

Huh?

-- 
Martin 
-------------- 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/20040127/507349ef/attachment.pgp 


More information about the linux-elitists mailing list