Mail Archives: cygwin/2002/09/11/20:54:27
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/
- Raw text -