19. How To
Get Further Assistance
19.1. If
this Document Still Hasn't Answered Your Question....
Please read all of this answer before posting. I know it's
a bit long, but you may be about to make a fool of yourself in
front of 50,000 people and waste hundreds of hours of their time.
Don't you think it's worth spending some of your time to read
and follow these instructions?
If you think an answer is incomplete or inaccurate, please
e-mail David Merrill at dmerrill@ibiblio.org.
Read the appropriate Linux Documentation Project books. Refer
to Where
Is the Documentation?.
If you're a Unix or Linux newbie, read the FAQ for news:comp.unix.questions,
news:news.announces.newusers,
and those for any of the other news:comp.unix
groups that may be relevant.
Linux has so much in common with commercial unices, that almost
everything you read there will apply to Linux. The FAQ's, like
all FAQ's, be found on ftp://rtfm.mit.edu/pub/usenet/ (the mail-server@rtfm.mit.edu
can send you these files, if you don't have FTP access). There
are mirrors of rtfm's FAQ archives on various sites.
Check the Introduction to *.answers posting, or look in news-answers/introduction
in the directory above.
Check the relevant HOWTO for the subject in question, if there
is one, or an appropriate old style sub-FAQ document. Check the
FTP sites.
Try experimenting - that's the best way to get to know Unix
and Linux.
Read the documentation. Check the manual pages (type man
man if you don't know about manual pages. Also try man
-k subject and apropos subject. They often list
useful and relevant, but not very obvious, manual pages.
Check the Info documentation (type F1-i, i.e.
the F1 function key followed by "i" in Emacs).
This isn't just for Emacs. For example, the GCC documentation
lives here as well.
There will also often be a README file with a package
that gives installation and/or usage instructions.
Make sure you don't have a corrupted or out-of-date copy of
the program in question. If possible, download it again and re-install
ityou probably made a mistake the first time.
Read news:comp.os.linux.announce.
It often contains very important information for all Linux users.
General X Window System questions belong in news:comp.windows.x.i386unix, not in news:comp.os.linux.x.
But read the group first (including the FAQ), before you post.
Only if you have done all of these things and are still stuck,
should you post to the appropriate news:comp.os.linux newsgroup. Make sure
you read the next question first. "( What to put in a request
for help. )"
19.2. What
to Put in a Request for Help
Please read the following advice carefully about how to write
your posting or E-mail. Making a complete posting will greatly
increase the chances that an expert or fellow user reading it
will have enough information and motivation to reply.
This advice applies both to postings asking for advice and
to personal E-mail sent to experts and fellow users.
Make sure you give full details of the problem, including:
- What program, exactly, you are having problems with. Include
the version number if known and say where you got it. Many standard
commands tell you their version number if you give them a --version
option.
- Which Linux release you're using (Red Hat, Slackware, Debian,
or whatever) and what version of that release.
- The exact and complete text of any error messages printed.
- Exactly what behavior you expected, and exactly what behavior
you observed. A transcript of an example session is a good way
to show this.
- The contents of any configuration files used by the program
in question and any related programs.
- What version of the kernel and shared libraries you have
installed. The kernel version can be found by typing uname
-a, and the shared library version by typing ls -l /lib/libc*.
- Details of what hardware you're running on, if it seems appropriate.
You are in little danger of making your posting too long unless
you include large chunks of source code or uuencoded files, so
err on the side of giving too much information.
Use a clear, detailed Subject line. Don't put things like
"doesn't work", "Linux", "help",
or "question" in it we already know that. Save the
space for the name of the program, a fragment of an error message,
or summary of the unusual behavior.
Put a summary paragraph at the top of your posting.
At the bottom of your posting, ask for responses by email
and say you'll post a summary. Back this up by using Followup-To:
poster. Then, actually post the summary in a few days or
a week or so. Don't just concatenate the replies you received,
summarize them. Putting the word "SUMMARY" in your
summary's Subject line is also a good idea. Consider submitting
the summary to news:comp.os.linux.announce.
Make sure your posting doesn't have an inappropriate References:
header line. This marks your article as part of the thread of
the article referred to, which will often cause it to be junked
by readers, along with the rest of a boring thread.
You might like to say in your posting that you've read this
FAQ and the appropriate HOWTO'sthis may make people less likely
to skip your posting.
Remember that you should not post E-mail sent to you personally
without the sender's permission.
19.3.
How To Email Someone about Your Problem
Try to find the author or developer of whatever program or
component is causing you difficulty. If you have a contact point
for your Linux distribution, you should use it.
Please put everything in your E-mail message that you would
put in a posting asking for help.
Finally, remember that, despite the fact that most of the
Linux community are very helpful and responsive to E-mailed questions,
you're likely asking for help from unpaid volunteers, so you
have no right to expect an answer.