[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sheflug] https



>>>>> "Martin" == Martin P Holland <m.holland [at] noether.freeserve.co.uk> writes:

    Martin> But I can imagine that config files might start to have
    Martin> richer content than flat ascii, xml say. Maybe when we
    Martin> start to operate in new ways the good points of the GUi
    Martin> will become more apparent and it won't appear just as a
    Martin> least common denominator.

Yes.  In the meantime GUI is weak.

There is nothing that XML can do that "flat ASCII" can't.  Take
~/.emacs as a classic extreme example; Emacs-Lisp is in no sense a
standardized language, except by long usage.  Many much less
formalized "configuration languages" also are very successful;
consider .procmailrc.

What makes XML and similar techniques important is the possibility
they show for supporting new paradigms through a standard
meta-language and via plug-in components for the developers.  This
will hopefully allow the developers to concentrate on the desired
semantics and reliability, rather than on just "getting the user's
settings out of the bloody .rc!"

Unfortunately, and what I am complaining about, far more attention is
paid to the "G" than to the "UI".

    Martin> Well kppp does grovel through /var/log/messages but the
    Martin> clues there with default syslogging are usually
    Martin> minimal. And in any case with fuller debugging it's still
    Martin> a highly nontrivial task.

Right; what I meant was that kppp should automagically set the
debugging higher, and help to produce a bug report.

    Martin> AFAIK the failrly puny attempt that kppp makes is superior
    Martin> to that made by any other app GUI or CLI so it's seems

Have you looked at Emacs with its doctrings, apropos, the ability to
find the file any function was loaded from, copious Info files, and
Custom?  All the stuff that Al says "could be done" I've used on a
daily basis for decades.  It happens that I currently favor XEmacs,
the semi-GUI black sheep of the family, but all of that stuff has
always been available in the GNU Emacs family.

    Martin> churlish to criticise them too strongly, given a daunting
    Martin> task and one that nonone else can be bothered to take on.

I don't mean to single out kppp for criticism, really.  The point is
that if they are best of breed, and yet "fairly puny", and noone else
can be bothered to try that hard, that doesn't say a lot for the rest
of the industry.  That's the problem.

And it sounds to me like the kppp people have probably done a huge
amount of work besides the GUI.  But the GUI is what attracts
attention.  Doesn't seem fair....

    Martin> I'm sure that kppp has connected successfully many more
    Martin> newbies than any other method. That's the benefit.

So it comes back to Al's "if it's GUI, even I can do it."


========================================================================

on something rather different:

    >> And why doesn't the GUI package all that information up into a
    >> nice mail message you can address to the help channel of your
    >> choice?

    Martin> The issue here is decoding the meaning of the detailed
    Martin> logs. There is currently no automatic system in place for
    Martin> this, just the mumblings of gurus in the
    Martin> newsgroups. Mailing hyper gibberish to people is no
    Martin> different from telling them to read it in a file.

It is if they can't read the file because it's on a different system.
The problem is getting the log data and the config into the hands of
the expert.

    Martin> The effort here needs to be directed to decoding the log
    Martin> into a fixable problem.

Not according to all the "how to report bugs" files I've ever read.
They all emphasize sending the logs, the error messages, and the
config verbatim, and discourage attempts by the user to "decode" them.

At least, they strongly encourage users to send all the hyper
gibberish as well as the user's speculations about what happened
(which typically are only considered as a last resort ;-)

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.