在发帖之前，请阅读此答案的全部内容。我知道这有点长，但您可能即将在 50,000 人面前出丑，并浪费他们数百小时的时间。您不认为花一些时间阅读并遵循这些说明是值得的吗？
如果您认为某个答案不完整或不准确，请发送电子邮件给 David Merrill。请参阅《提问和发送评论》。
阅读相关的 Linux 文档项目书籍。请参考《文档在哪里？》。
如果您是 Unix 或 Linux 新手，请阅读 news:comp.unix.questions、news:news.announces.newusers 以及任何其他可能相关的 news:comp.unix 新闻组的常见问题解答。
Linux 与商业 Unix 有很多共同之处，您在那里读到的大部分内容都适用于 Linux。常见问题解答，像所有常见问题解答一样，可以在 ftp://rtfm.mit.edu/pub/usenet/ 上找到（如果您无法访问 FTP，mail-server@rtfm.mit.edu 可以向您发送这些文件）。在各个站点上有rtfm的常见问题解答档案镜像。查看 *.answers 帖子的简介，或查看news-answers/introduction在上面的目录中。
如果有相关主题的 HOWTO 文档，或者旧式的子 FAQ 文档，请查看。查看 FTP 站点。
尝试实验——这是了解 Unix 和 Linux 的最佳方式。
阅读文档。查看手册页（输入man man如果您不了解手册页。也可以尝试man -k subject和apropos subject。它们通常会列出有用且相关的，但不太明显的手册页。
查看 Info 文档（在 Emacs 中输入 F1-i，即 F1 功能键，后跟 “i”）。这不仅仅适用于 Emacs。例如，GCC 文档也在这里。
通常还会有一个README文件，其中包含软件包的安装和/或使用说明。
确保您没有程序已损坏或过时的副本。如果可能，请重新下载并重新安装——您可能第一次犯了错误。
阅读 news:comp.os.linux.announce。它通常包含对所有 Linux 用户都非常重要的信息。
一般的 X Window 系统问题属于 news:comp.windows.x.i386unix，而不是 news:comp.os.linux.x。但在您发帖之前，请先阅读该组（包括 FAQ）。
只有当您完成所有这些操作并且仍然遇到困难时，才应该发布到适当的 news:comp.os.linux 新闻组。请务必先阅读下一个问题。（“在求助请求中应包含什么。”）
请仔细阅读以下关于如何撰写帖子或电子邮件的建议。撰写完整的帖子将大大增加专家或同伴用户在阅读时有足够的信息和动机回复的机会。
此建议既适用于寻求建议的帖子，也适用于发送给专家和同伴用户的个人电子邮件。
请务必提供问题的完整详细信息，包括
您遇到的问题究竟是哪个程序。如果已知，请包含版本号，并说明您从哪里获得的。许多标准命令在您给它们--version选项时会告诉您它们的版本号。
您正在使用的 Linux 发行版（Red Hat、Slackware、Debian 或其他任何发行版）以及该发行版的版本。
打印的任何错误消息的准确和完整文本。
您期望的确切行为，以及您观察到的确切行为。示例会话的记录是展示这一点的有效方式。
问题程序和任何相关程序使用的任何配置文件的内容。
您安装的内核和共享库的版本。内核版本可以通过输入uname -a找到，共享库版本可以通过输入ls -l /lib/libc*.
找到。如果您认为合适，请提供您运行的硬件的详细信息。
除非您包含大量的源代码或 uuencoded 文件，否则您几乎不可能使您的帖子太长，因此请尽量提供过多的信息。
使用清晰、详细的主题行。不要在其中放入诸如“无法工作”、“Linux”、“帮助”或“问题”之类的内容——我们已经知道了。将空间留给程序名称、错误消息片段或异常行为摘要。
在帖子的顶部放一个摘要段落。
在帖子的底部，请求通过电子邮件回复，并说您将发布摘要。通过使用Followup-To: poster来支持这一点。然后，在几天或一周左右的时间内实际发布摘要。不要只是连接您收到的回复，而是对它们进行总结。在摘要的主题行中放入“SUMMARY”一词也是一个好主意。考虑将摘要提交给 news:comp.os.linux.announce。
确保您的帖子没有不适当的 References: 标头行。这会将您的文章标记为所引用文章线程的一部分，这通常会导致读者将其与无聊线程的其余部分一起丢弃。
您不妨在帖子中说明您已阅读此 FAQ 和相关的 HOWTO 文档——这可能会使人们不太可能跳过您的帖子。
请记住，未经发件人许可，您不应发布发送给您的个人电子邮件。