Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Wed, 11 Sep 2002 20:54:39 -0400
From: Christopher Faylor <cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Beginnings of a patch: /etc/hosts
Message-ID: <20020912005439.GB8834@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <Pine DOT GSO DOT 4 DOT 44 DOT 0209111845010 DOT 1269-300000 AT slinky DOT cs DOT nyu DOT edu> <Pine DOT GSO DOT 4 DOT 44 DOT 0209111845010 DOT 1269-300000 AT slinky DOT cs DOT nyu DOT edu> <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020911162837 DOT 02a7c438 AT pop3 DOT cris DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20020911162837.02a7c438@pop3.cris.com>
User-Agent: Mutt/1.4i

On Wed, Sep 11, 2002 at 04:35:58PM -0700, Randall R Schulz wrote:
>That rule is only apt if the user knows what external state is used as 
>input to the program they're running. If that input or dependency is made 
>explicit somehow (documentation might suffice), then you're right and it's 
>a matter of user control. However, if the user must examine the program's 
>source code to know why it's not behaving in the manner its authors 
>describe, that's not cool.

I agree with this, especially in this case.  If a user casually changes
an environment variable to something "nonstandard" then they shouldn't
be surprised by the behavior of our tools.  This is different from
prompting them for OS and letting the user lie if they want to.  In
that case, I'd agree that they should be able to do this.

>As you may know, I don't subscribe to that "Use the Source, Duke"
>business.  If one must understand the internal workings of a thing just
>to use it, it's not very good technology.  It virtually negates the
>concept of automation!

It's not necessarily bad technology.  It could be bad documentation.  It
could be poor comprehension.  People *often* jump to the conclusion that
if something is confusing to them it is an indication of some flaw in
the product or documentation.  While consistent complaints of a problem
probably do indicate this, isolated cases of "This is confusing to me!"
do not necessarily mean anything other than the fact that someone may
have limited capabilities.

However, regardless of any of the above, in a free software project, the
source could well be the best documentation available.  If it isn't then
that boils down to either helping to fix the documentation, or to fix
the program itself, or being satisfied that you got what you paid for.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/