Frequently Asked Questions about Unix - with Answers [Monthly posting]

[David Elliott]

In article <495 at rufus.UUCP>, drake at drake.almaden.ibm.com writes:
|> In article <15073 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
|> >
|> >It's not all "dirty laundry".  In many cases the questions should have
|> >been answered with "Why do you think you need to do this?", because
|> >they reflect fundamental misunderstandings about the way that things
|> >work.  
|> 
|> True in several cases.  But, unfortunately for us all, far too many of the 
|> answers didn't fall into this category; many of the answers simply amounted
|> to, "you can't".  A FAQ list is a great place to find usability problems 
|> in software; hopefully the day will come with the FAQ list has answers, not
|> rationalizations, for all the legitimate questions.

I'm not sure I understand what you are getting at.  Let me take a step
back...

The FAQ list came about because two human traits:

	1. People find it easier to ask someone else than to look
	   it up for themselves.

	2. People are willing to say what they know, whether it's
	   right or wrong.

The groups comp.unix.questions and comp.unix.wizards were being filled
with the same questions month after month.  Answers to these questions
varied from correct on all systems to correct on some systems to
correct on one system to incorrect.

The FAQ list was created to provide consistent, correct answers to the
questions that were getting asked a lot.

At first, I thought you were saying that it should only contain answers
to questions that were answerable, but that wouldn't make any sense,
since people would have to get a "you can't" from someone.

If, on the other hand, what you are saying is that there is too much
"you can't, and here's why you can't" rather than "you can't, and
here's why you shouldn't", I see your point.

We do need the "why you can't", because otherwise people will find an
unportable or incomplete solution that ends up getting them in trouble
later.  I'd rather be told in advance why I can't make an assumption
than to find out that my whole design rested on an invalid assumption.

If you think we are missing the "why you shouldn't" parts, help
us out.  Point out which questions don't have very good answers,
and let's discuss them to come up with better answers.

But, realize that some of the "why you shouldn't" answers are going
to be "you shouldn't because you can't".  For example, I've always
believed that I should be able to get "a" filename for the program
I'm executing.  I even know how to do this in special circumstances,
but I would never design a program that couldn't work without this
ability because I know that it's easy to break.

--
...David Elliott
...dce at smsc.sony.com | ...!{uunet,mips}!sonyusa!dce
...(408)944-4073
..."His lower lip waved poutily with defiance..."