On Thu, 2005-12-29 at 12:30 -0600, Charles Howse wrote:
> > On Thu, 2005-12-29 at 11:27, Charles Howse wrote:
> >>>
> >>> You really have to understand what the shell does to every
> >>> command line before starting a program before reading other
> >>> man pages. The concepts of i/o redirection, wildcard filename
> >>> expansion, and environment variable setting are not repeated
> >>> in the man pages for every program even though they may be
> >>> useful or even necessary. Man pages are meant to be a reference,
> >>> not a tutorial. A tutorial should be a separate volume since
> >>> you normally only need it once and never want to see it again
> >>> while you may need the reference for obscure options later.
> >>> Unfortunately, a tutorial doesn't exist for some programs
> >>> you might want to use.
> >>
> >> Agreed, but apply what you just said to someone who decides to trash Windows
> >> and start using Fedora for the first time.
> >
> > How would it work the other way around? Suppose you were
> > having your first experience by installing windows and about
> > 3,000 programs all at once. It doesn't usually happen that
> > way because you buy the box with windows pre-installed
> > and can't afford that many add-on programs at once.
>
> Whew! I'd hate to know I had to spend that much time installing Windows
> apps.
> I think it's great that Linux comes with so many applications! But, since
> Linux is open-source, not everything works as expected, nor has sufficient
> documentation. Would you agree?
>
The lack of ducumentation in some cases is true. However, How do you
propose to change that?
Applications are written by a developer. From experience I know that it
often takes more time to do good documentation than it does to develop
the application. If the developer is doing the app on his own time (and
most are) with limited time available, the part that often gets ignored
is the documentation.
OTOH, commercial development software (usually closed source) depends on
good documentation for their users. Sometimes more is spent on the
documentation than on the actual coding of the product.
I don't know of any solution that will apply to the wealth of
applications available from a multitude of sources except for users to
step up and volunteer to assist the developers when a need is seen.
> >> I guess I'm saying that there just has to be better help...onboard and
> >> online.
> >
> > There is, but keep in mind the size of the content using the
> > windows equivalents section of a large bookstore as a reference.
> > Quite a bit of that does exist for the Linux versions, but
> > you seem to be asking someone to have it all memorized and
> > be able to quote massive sections on demand. It's one thing
>
> Actually, I'm thinking the other way round on this. Sometimes, it seems
> like I'm required to have memorized everything I've ever read on the web and
> in print. Take for example, the smart-posting page referenced earlier;
> yeah, I read it...probably 2 years ago. I'm getting old, and can't remember
> that far back. ;-)
>
<rant>
Many times the best answer is not a "here is the fix"; but rather a
gentle nudge in the direction of a "how to do that" man page/web
site/mail message/etc., in the tone of 'here you can learn more'.
It I can get a new user to think, try, and research instead of depending
on the mail list for the smallest answer; then ask questions after at
least having made a diligent effort we all gain.
The new user learns how to get answers, how to relate what he
already knows to his current problem, and a wealth of other things.
Always building on his current knowledge base..
The list member gains by having a new user guided in the way to
learn rather than having to answer in detail the "how to" question that
may have worked for him but may not work exactly the same on the other
users machine due to distribution/release level/application
level/misunderstanding of the problem/etc.
One of the biggest failings in new users I see are the ones who have the
attitude of "tell me how to do my job" and will not even make a
reasonable effort to do it on their own.
Answers on this list by most are a balancing act between hand holding
(do this) and guiding (look there) as they answer questions.
</rant>
> > to say "I typed this command and got this error:... - has
> > that happened to anyone else?" and something else to ask
> > how to start something that needs a whole tutorial book
> > to answer.
>
> That's fair, but *really*, I don't post until I run out of reference
> options, or get frustrated after researching for a *long* time.
> If the tutorial exists, just point me to it. If it doesn't exist, we'll
> have to punt, eh?
An attitude I applaud in everyone.
>
> > Of course when you ask the question, you may not know the
> > complexity of the answer...
>
> No one can know everything, that's why we ask questions. :-)
>
