如何可能正确的以大部分人可能会接受的方式提出电脑相关的问题

汝问咱为啥标题起得这么长，那是因为咱不敢保证所有的人都乐于接受这种提问方法啊……
以及似乎能衍生到其它领域？那就靠汝自己斟酌了。

本文参考了下面几篇文章的观点，某些文章可能正在经常的被提起。

• 提问的智慧，原文作者 Eric S. Raymond，以开放源代码运动（不是自由软件运动，这个的领导者是 Richard Stallman）的提出者和主要领导者为人所知的黑客。本指南将教你如何正确的提问以获得你满意的答案。
• 如何有效的报告 Bug，以程序员的视角阐述如何提交一份足够准确的 Bug 报告
• X-Y 问题，一种常见的令人疑惑的提问方式，至于为啥令人疑惑嘛……
• 真的，再这样提问就没人理你了，以提问的智慧的方法提出不一定是电脑相关的问题的方法，大概吧。

提问真的有那么多讲究的地方嘛？

大多数时候如此，因为有一个大前提：

“我们（在很大程度上）是自愿的，从繁忙的生活中抽出时间来解答疑惑，而且时常被提问淹没。所以我们无情的滤掉一些话题，特别是拋弃那些看起来像失败者的家伙，以便更高效的利用时间来回答赢家（winner）的问题。”

大多数人其实都是出于各种志愿目的回答来自不知道何处的提问的，除非……（“我本来想这样拒绝他的，但是他给的钱实在是太多了……”）

所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你变得在行的特质 -- 机敏、有想法、善于观察、乐于主动参与解决问题。如果你做不到这些使你与众不同的事情，我们建议你花点钱找家商业公司签个技术支持服务合同，而不是要求黑客个人无偿地帮助你。

于是换做汝自己来回答的话，下面两种问题汝更倾向于回答哪一种？（假设汝有回答这个问题所需的能力的话）：

• 我从 foo 项目找来的源码没法编译。它怎么这么烂？
• foo 项目代码在 Nulix 6.2 版下无法编译通过。我读过了 FAQ，但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记录，我有什么做的不对的地方吗？

可能不那么显然的，后面的提问者已经指明了环境，也读过了 FAQ，还列出了错误，并且他没有把问题的责任推到别人头上，他的问题值得被关注。

除此之外，对于黑客来说，如果能回答一个有挑战性的问题，或者能激发他们思维的好问题。对他们来说可能就不再是负担，而成了他们的一种乐趣。对黑客而言，"好问题！"是诚挚的大力称赞。（当然放在其它领域里也差不多啦。）

因为时间有限，所以不要活在别人的生活里。也是因为时间有限，于是大家都习惯的去忽略那些不愿思考、或者在发问前不做他们该做的事的人。汝在提问的时候一定不想被这样忽略，对吧？

如果你决定向我们求助，当然你也不希望被视为失败者，更不愿成为失败者中的一员。能立刻得到快速并有效答案的最好方法，就是像赢家那样提问 -- 聪明、自信、有解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助。

在汝遇到问题并决定提出问题之前

于是首先汝在什么地方有了麻烦……是呗？

据完全不可靠的实践发现，大多数的问题都能在这几步方法全运用完之前得到解决……

尝试阅读硬件或软件的说明文档找到答案

硬件设计者和开发者遇到的问题大多数时候不会比汝少，有一部分他们曾经遇到的问题可能的解决方法都被他们写进了自己硬件或软件的说明书或其它地方里。

对于硬件的话，最常见的是说明书或者网站上的教学手册以及常见问题解答一类的。

对于常见的的桌面软件的话，可以在菜单中寻找“帮助”菜单，或者去软件的网站查找说明。

如果是有点那么不常见的命令行软件的话，比较常用的获得说明的方法有两种：

一种是在后面加上 --help 再运行，会列出像是可以添加的参数一类的信息。

部分程序也有可能是 -h 之类的短参数，或者其它别的（例如 Windows 里的 /? ）

$ python3 --help
usage: /usr/local/bin/python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...
Options and arguments (and corresponding environment variables):
-b  : issue warnings about str(bytes_instance), str(bytearray_instance)
    and comparing bytes/bytearray with str. (-bb: issue errors)
-B  : don't write .pyc files on import; also PYTHONDONTWRITEBYTECODE=x
-c cmd : program passed in as string (terminates option list)
-d  : debug output from parser; also PYTHONDEBUG=x
-E  : ignore PYTHON* environment variables (such as PYTHONPATH)
-h  : print this help message and exit (also --help)
...

另一种做法是查阅相应的手册页，这里需要用到 man 命令。最简单的用法像这样：

$ man 要查询的命令的名称

这个 man 是男人还是 manual 的缩写呢……

典型的手册页大概像这个样子（还是拿刚才的 python 来举例），这里再加上一些解释？

实际上 man 会调用系统设置的分页程序来打开手册页（比较常见的是 less），至于 less 的用法嘛……大家可以去查阅 less 的手册页，溜了溜了……

PYTHON(1)                                                                        PYTHON(1)


# 程序的名字和一行简介
NAME
       python - an interpreted, interactive, object-oriented programming language

# 这里的 python 是一个命令，于是描述它如何运行，以及需要什么样的命令行参数。
# 如果查阅的是函数的手册页，可以看到函数所需的参数，以及哪个头文件包含该函数的定义。
SYNOPSIS
       python [ -B ] [ -b ] [ -d ] [ -E ] [ -h ] [ -i ] [ -I ]
              [ -m module-name ] [ -q ] [ -O ] [ -OO ] [ -s ] [ -S ] [ -u ]
              [ -v ] [ -V ] [ -W argument ] [ -x ] [ [ -X option ] -?  ]
              [ --check-hash-based-pycs default | always | never ]
              [ -c command | script | - ] [ arguments ]

# 更长的描述
DESCRIPTION
       Python  is  an  interpreted, interactive, object-oriented programming language that
       combines remarkable power with very clear syntax.  For an introduction to  program-
       ming  in  Python,  see the Python Tutorial.  The Python Library Reference documents
       built-in and standard types, constants, functions and modules.  Finally, the Python
       Reference  Manual  describes the syntax and semantics of the core language in (per-
       haps too) much detail.  (These documents may be located via the INTERNET  RESOURCES
       below; they may be installed on your system as well.)

# 可以在命令行下使用的参数以及参数
COMMAND LINE OPTIONS
       -B     Don't write .pyc files on import. See also PYTHONDONTWRITEBYTECODE.

       -b     Issue  warnings  about str(bytes_instance), str(bytearray_instance) and com-
              paring bytes/bytearray with str. (-bb: issue errors)

       -c command
              Specify the command to execute (see  next  section).   This  terminates  the
              option list (following options are passed as arguments to the command).

（下面其实还有很多的为了节省空间就省掉了……）

# 这一部分是 Python 的手册页特别的，介绍了解释器的接口
INTERPRETER INTERFACE
       The  interpreter interface resembles that of the UNIX shell: when called with stan-
       dard input connected to a tty device, it prompts for  commands  and  executes  them
       until an EOF is read; when called with a file name argument or with a file as stan-
       dard input, it reads and executes a script from that file; when called with -c com-
       mand,  it executes the Python statement(s) given as command.  Here command may con-
       tain multiple statements separated by newlines.  Leading whitespace is  significant
       in  Python  statements!  In non-interactive mode, the entire input is parsed before
       it is executed.

# 安装的文件和目录
FILES AND DIRECTORIES
       These are subject to difference depending on local installation conventions; ${pre-
       fix} and ${exec_prefix} are installation-dependent and should be interpreted as for
       GNU software; they may be the same.  The default for both is /usr/local.

# 可以设置的环境变量
ENVIRONMENT VARIABLES
       PYTHONHOME
              Change the location of the  standard  Python  libraries.   By  default,  the
              libraries  are  searched  in  ${prefix}/lib/python<version>  and ${exec_pre-
              fix}/lib/python<version>, where ${prefix} and ${exec_prefix}  are  installa-
              tion-dependent directories, both defaulting to /usr/local.  When $PYTHONHOME
              is set to  a  single  directory,  its  value  replaces  both  ${prefix}  and
              ${exec_prefix}.   To  specify different values for these, set $PYTHONHOME to
              ${prefix}:${exec_prefix}.

# 手册页的作者
AUTHOR
       The Python Software Foundation: https://www.python.org/psf/

# 一些在网上的资源的链接
INTERNET RESOURCES
       Main website:  https://www.python.org/
       Documentation:  https://docs.python.org/
       Developer resources:  https://devguide.python.org/
       Downloads:  https://www.python.org/downloads/
       Module repository:  https://pypi.org/
       Newsgroups:  comp.lang.python, comp.lang.python.announce

# 许可协议信息
LICENSING
       Python is distributed under an Open Source license.  See the file "LICENSE" in  the
       Python  source distribution for information on terms & conditions for accessing and
       otherwise using Python and for a DISCLAIMER OF ALL WARRANTIES.



                                                                                 PYTHON(1)

偶尔汝会在手册页见到 malloc(3) 这样的描述，这表示了特定区块的手册页。在 BSD 和 GNU/Linux 中，手册页通常被分作八个区块：

1 一般命令
2 系统调用
3 库函数，涵盖C标准函数库
4 特殊文件（通常是/dev中的设备）和驱动程序
5 文件格式和约定
6 游戏和屏保
7 杂项
8 系统管理命令和守护进程

于是要查阅特定区块的手册页的话，大概是这个样子（例如刚才的 malloc(3) ）：

$ man 3 malloc

尝试上网搜索找到答案

有很多的问题也许不是第一次发生，那大抵汝也不会是第一次遇到的家伙。也许有人留下过类似的解决过程，如果汝找到了而且能成功地解决汝目前的问题，那这世界上就可能少了一个蠢问题（？）

可以搜索的地方也有很多，例如汝正在使用的软件或操作系统发行版的网站（如果汝没在上一步试图寻找的话）、论坛（有可能是官方名义的，或者是社区建立的）和邮件列表的存档，或者某个曾经解决过类似问题的家伙留下的文章等等。

至于搜索引擎要咋用，这个实在是太复杂了，咱也只能给出一些建议：

• 选对一个好的搜索引擎就差不多成功了一半，嗯。
• 把程序提示汝的消息作为搜索关键词可能有奇效，例如 Permission denied (publickey). （当然太长的话可能会被搜索引擎剪掉，于是尝试一下找出关键的部分吧。
• 如果要自己决定关键词的话，首先不要用提问的方式，比如「我的电脑上不了网怎么办」，要寻找问题的线索，将线索变成关键词去搜索，一个关键词找不到就换另一个。啥？汝连这一步都懒得做？那么汝大抵有足够的资金找一个或者一群人帮汝解决汝现在遇到的问题，这就不在讨论范围内了……
• 介于现在的硬件和软件都大量使用英语，有时也可以试试用英文搜索。
• ……

尝试问一下汝身边熟悉的朋友？

这个有很大一部分是感性原因，因为某个完全不可靠的证据表明，汝身边最亲近的朋友大抵是最能忍受来自汝自己的看着很蠢的问题的。至少会比一无所知的陌生人容忍度大一点点。

不过朋友毕竟也是人，耐性也是有限的。（汝要是来问咱的话大概耐性会更低）于是为了避免发生像是喋血街头一类的惨剧，还是不负责的建议先把功课做一做了再提问。

天有不测风云？

不过要是汝已经做过了之前的尝试但是问题还是没解决的话……

• 坐下来放松，然后再来一次（？）。

不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前，再阅读一下常见问题文件（FAQ）、放轻松、坐舒服一些，再花点时间思考一下这个问题。相信我们，他们能从你的提问看出你做了多少阅读与思考，如果你是有备而来，将更有可能得到解答。不要将所有问题一股脑拋出，只因你的第一次搜索没有找到答案（或者找到太多答案）

• 再次思考汝将要提出的问题。有不可靠的统计显示出寻求帮助前汝为解决问题所付出的努力程度和汝获得实质性的帮助的机率很大概率成正相关。

另一方面，表明你愿意在找答案的过程中做点什么是一个非常好的开端。谁能给点提示？、我的这个例子里缺了什么？以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向，你就有完成它的能力和决心。

• 再收集一些更详细的信息。例如 POST 画面的提示，主板七划显示器上的字形，软件弹出的提示，汝在之前做了些什么等等。

https://wiki.archlinux.org/index.php/Bug_reporting_guidelines#Gather_useful_information 上也列出了哪些信息可能是有用的。

• 然后多想一下汝要在哪里提问。

我要在哪里提问？

在网上比较常见的发问场所，大抵有聊天群组，论坛和邮件列表。不过无论在哪里，下面的建议似乎都非常实用。（但未经过详细的检验）

• 不要在与主题不合的地方贴出汝的问题。例如在绘画群组里提问游戏技巧，多半没人会搭理。
• 不要在探讨进阶技术问题的论坛张贴非常初级的问题；反之亦然。至于怎么样算进阶怎么样算初级嘛，这个要自己掂量一下了。
• 不要在太多的不同地方上重复转贴同样的问题。有很大一部分原因是不同的地方有可能都是同一群人（大雾）。
• 别像机关枪似的一次"扫射"所有的帮助渠道，这就像大喊大叫一样会使人不快。要一个一个地来。
• 先特定后通用，例如先去特定发行版的论坛或邮件列表中提问，再到程序本身的论坛或邮件列表提问。
• 有些软件的网站上可能记载有官方支持和提交 Bug 报告的规则，如果有看到的话，照做就是了。
• 通过论坛或聊天群组来提供使用者支持服务有增长的趋势，电子邮件则大多为项目开发者间的交流而保留。所以最好先在论坛或聊天群组中寻求与该项目相关的协助。

别问蠢问题！以及……

最常见的蠢问题大概有这么几种，至于为什么这些问题被觉得蠢……

• 我能在哪找到 X 程序或 X 资源？

就在咱找到它的地方啊，大笨驴 —— 搜索引擎的那一头。天哪！难道还有人不会用 Google 吗？

• 我怎样用 X 做 Y ？

如果汝想解决的是 Y ，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知，也对 Y 要解决的问题糊涂，还被特定形势禁锢了思维。最好忽略这种家伙，等他们把问题搞清楚了再说。

• 如何设定我的 shell 提示？？

如果汝有足够的智慧提这个问题，汝也该有足够的智慧去 RTFM，然后自己去找出来。

• 我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗？

试试看就知道了。如果汝有试过的话，汝既知道了答案，也不用浪费我的时间了。

• 我的{程序/设定/SQL 语句}不工作

这不算是问题吧，咱有更有意思的事要做呢，对汝这还要再问二十句才能知道问题在哪的问题完全提不起劲。

在看到这类问题的时候，大多数人的反应通常不外如下三种：

你还有什么要补充的吗？| 真糟糕，希望你能搞定。| 这关我屁事？

• 我的 Windows 电脑有问题，你能帮我吗？

能啊，扔掉微软的辣鸡，换个像 GNU/Linux 或 BSD 的开放源代码的操作系统吧。

注意：如果程序有官方 Windows 版本或者与 Windows 有互动（如 Samba），你可以问与 Windows 相关的问题， 只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶， 因为 Windows 对一般开发者来说实在太烂，这种说法通常都是对的。

• 我的程序不会动了，我认为系统工具 X 有问题

汝完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库档案有明显缺陷的家伙，或者汝完全没有根据。
不同凡响的说法需要不同凡响的证据，当汝这样声称的时候，汝大概已经有了清楚而详尽的报告作后盾了吧？

• 我在安装 Linux（或者 X ）时有问题，你能帮我吗？

不能。咱只有亲自在汝自己的电脑上动手才能找到毛病。要么试试寻求汝附近的 GNU/Linux 使用者群组的实际指导？

注意：如果安装问题与某 Linux 的发行版有关，在它的邮件列表、论坛或本地使用者群组中提问也许是恰当的。此时，应描述问题的准确细节。在此之前，先用 Linux 和所有被怀疑的硬件作关键词仔细搜索。

• 问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？

想要这样做，说明了汝是个卑鄙小人；想找个黑客帮忙，说明汝是个不折不扣的大笨驴！

以及不要问那种看着就很像家庭作业的问题，这些问题很明显要汝自己找到答案。尽管汝也许需要点提示，但不要指望能从别人那里得到完整答案。

保持一个平和的正确态度

• 虽然骄傲是不行的，但是也不要走向另一个极端。尽可能清楚地描述背景条件和问题情况，这比低声下气更好地定位了汝自己的位置。
• 彬彬有礼，多用请和谢谢您的关注，或谢谢你的关照。让大家都知道汝对他们花时间免费提供帮助心存感激。当然这不是汝可以把报告写的粗心又含糊的借口。

使用有意义且描述明确的标题

在这个领域，卖惨大概是最没有作用的行为之一，宣称紧急极有可能事与愿违：大多数黑客会直接删除无礼和自私地企图即时引起关注的问题。更严重的是，紧急这个字（或是其他企图引起关注的标题）通常会被垃圾信过滤器过滤掉 —— 这样汝所希望能看到汝的问题的人可能永远都看不到汝那看似紧急的问题。

于是来看一下下面的例子：

救命啊！我的笔记本电脑不能正常显示了！

X.org 6.8.1 的鼠标光标会变形，某牌显卡 MV1005 芯片组。

现在用上面的想法思考一下哪一个问题更蠢？再小声的说一句，大家都觉得“目标-差异”格式的标题往往最能吸引黑客，因为这样他们马上就能知道汝的环境和遇到的问题。试试看用更聪明的方法改写上面提问的标题？

用清晰、正确、精准且语法正确的语句仔细组织汝的提问

从经验中大家得出了一个结论，粗心的提问者通常也会粗心的写程序与思考。（真的如此吗，欢迎来证实或证伪）

• 正确的拼写、标点符号和大小写是很重要的。汝说关注这个很麻烦？那好咱们也觉得思考汝那错词百出的问题很麻烦，于是就不回答了。
• 如果在非母语的论坛发问，尽管拼写错误之类的会宽容些，但还是不能怠于思考。以及拿不懂回复者使用的语言的话就用英文撰写问题。
• 清楚的表达汝的问题以及需求。繁忙的人往往厌恶那种漫无边际的空泛提问。

要理解专家们所处的世界，请把专业技能想像为充裕的资源，而回复的时间则是稀缺的资源。你要求他们奉献的时间越少，你越有可能从真正专业而且很忙的专家那里得到解答。

• 仔细、清楚地描述你的问题或 Bug 的症状。

来看看这句话：“我运行了FooApp，它弹出一个警告窗口，我试着关掉它，它就崩溃了。”这种表述并不清晰，用户究竟关掉了哪个窗口？是警告窗口还是整个FooApp程序？如果这样说，“我运行FooApp程序时弹出一个警告窗口，我试着关闭警告窗口，FooApp崩溃了。”这样虽然罗嗦点，但是很清晰不容易产生误解。

• 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供发行版和版本号。
• 描述在提问前汝是怎样去研究和理解这个问题的。以及确定问题而采取的诊断步骤。

简单介绍一下汝来提问之前都做了些什么，我在 Google 中搜过下列句子但没有找到什么有用的东西 之类的反馈也是有用的参考意见。

• 描述最近做过什么可能相关的硬件或软件变更。

问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。

• 尽可能的提供一个可以重现这个问题的可控环境的方法。

报告bug的最好的方法之一是“演示”给程序员看。让程序员站在电脑前，运行他们的程序，指出程序的错误。让他们看着您启动电脑、运行程序、如何进行操作以及程序对您的输入有何反应。

如果您必须报告bug，而此时程序员又不在您身边，那么您就要想办法让bug重现在他们面前。当他们亲眼看到错误时，就能够进行处理了。

确切地告诉程序员您做了些什么。如果是一个图形界面程序，告诉他们您按了哪个按钮，依照什么顺序按的。如果是一个命令行程序，精确的告诉他们您键入了什么命令。您应该尽可能详细地提供您所键入的命令和程序的反应。

• 如果汝做完前一步后发现整个问题显得太长（特别是复现的方法和样例太过复杂时），尽量将它剪裁得越小越好。

这样做的用处至少有三点。
第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；
第二，简化问题使你更有可能得到有用的答案；
第三，在精炼你的 bug 报告的过程中，你很可能就自己找到了解决方法或权宜之计。

• 除非汝非常、非常的有根据（例如有可以证明的测试或者修复的补丁），不要动辄声称找到了 Bug。最好写得像是自己做错了什么。

如果真的有 Bug，你会在回复中看到这点。这样做的话，如果真有 Bug，维护者就会向你道歉，这总比你惹恼别人然后欠别人一个道歉要好一点。

• 描述目标而不是过程。在一开始就清楚的表示出来汝想做什么，然后再描述问题在哪里。

经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。

所谓的 X-Y Problem 大抵如此，提出这种问题就是在一个根本错误的方向上浪费他人大量的时间和精力。这里有一个来自 CoolShell 的例子：

Q）问一下大家，我如何得到一个文件的大小*
A1) size = ls -l $file | awk ‘{print $5}’
Q) 哦，要是这个文件名是个目录呢？
A2) 用du吧
A3) 不好意思，你到底是要文件的大小还是目录的大小？你到底要干什么？
Q) 我想把一个目录下的每个文件的每个块（第一个块有512个字节）拿出来做md5，并且计算他们的大小 ……
A1) 哦，你可以使用dd吧。
A2) dd不行吧。
A3) 你用md5来计算这些块的目的是什么？你究竟想干什么啊？
Q) 其实，我想写一个网盘，对于小文件就直接传输了，对于大文件我想分块做增量同步。
A2) 用rsync啊，你妹！

• 描述症状，而不是汝的猜测。（如果汝的推断如此有效的话，那汝还用向别人求助吗？）

因此要确信你原原本本告诉了他们问题的症状，而不是你的解释和理论；让黑客们来推测和诊断。如果你认为陈述自己的猜测很重要，清楚地说明这只是你的猜测，并描述为什么它们不起作用。

针对诊断者而言，这并不是一种怀疑，而只是一种真实而有用的需求，以便让他们看到的是与你看到的原始证据尽可能一致的东西，而不是你的猜测与归纳的结论。所以，大方的展示给我们看吧！

• 然后去掉无意义的提问句，例如有人能帮我吗？或者这有答案吗？。除非汝想得到这样的回答：没错，有人能帮你或者不，没答案。

使用易于读取且标准的文件格式发送易于回复的问题

没有人喜欢自找麻烦，难以阅读的问题让人没有阅读的欲望，难于回复的问题让人没有回答的热情。

首先不管在哪里提问，绝对，永远不要指望黑客们阅读使用封闭格式编写的文档，像微软公司的 Word 或 Excel 文件等。即便他们能够处理，他们也很厌恶这么做。

如果汝在邮件中提问，下面的建议可以参考：

• 使用纯文字而不是 HTML (关闭 HTML 并不难）。
• 使用 MIME 附件通常是可以的，前提是真正有内容（譬如附带的源代码或 patch），而不仅仅是邮件程序生成的模板（譬如只是信件内容的拷贝）。
• 不要发送一段文字只是一行句子但自动换行后会变成多行的邮件（这使得回复部分内容非常困难）。设想你的读者是在 80 个字符宽的终端机上阅读邮件，最好设置你的换行分割点小于 80 字。
• 但是，对一些特殊的文件不要设置固定宽度（譬如日志档案拷贝或会话记录）。数据应该原样包含，让回复者有信心他们看到的是和你看到的一样的东西。

如果汝在论坛中提问，下面的建议可以参考：

• 一两个表情符号和彩色文本通常没有问题，但是不要滥用。

花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来像个傻笑的小姑娘。这通常不是个好主意，除非你只是对性而不是对答案感兴趣。

• 别要求通过电子邮件回复。

要求通过电子邮件回复是非常无礼的，除非你认为回复的信息可能比较敏感（有人会为了某些未知的原因，只让你而不是整个论坛知道答案）。如果你只是想在有人回复讨论串时得到电子邮件提醒，可以要求网页论坛发送给你。几乎所有论坛都支持诸如追踪此讨论串、有回复时发送邮件提醒等功能。

古老和神圣的传统和它的亲戚 - RTFM 和 STFW

有一个古老而神圣的传统：如果你收到RTFM （Read The Fucking Manual）的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。

RTFM 有一个年轻的亲戚。如果你收到STFW（Search The Fucking Web）的回应，回答者认为你应该到他妈的网上搜索。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 Google 是你的朋友！有时也许是别的样式，例如 LMGTFY 的链接或者“本群已和 Google 达成战略合作”等等。）

通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为

• 你需要的信息非常容易获得；
• 你自己去搜索这些信息比灌给你，能让你学到更多。

你不应该因此不爽；依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见。你应该对他祖母般的慈祥表示感谢。

其实如果汝有努力的在提问前做好功课的话，应该不会收到这样的回复的吧……

我得到一个回复，但这是啥？

看来似乎是 zentry 卡住了；你应该先清除它。

如果汝看不懂回应，别立刻要求对方解释。先像以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果真的需要对方解释，记得表现出汝已经从中学到了点什么。

哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？

我没得到答案，怎么办？

如果仍得不到回答，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。
总的来说，简单的重复张贴问题是个很糟的点子。这将被视为无意义的喧闹。有点耐心，知道你问题答案的人可能生活在不同的时区，可能正在睡觉，也有可能你的问题一开始就没有组织好。
你可以通过其他渠道获得帮助，这些渠道通常更适合初学者的需要。
有许多网上的以及本地的使用者群组，由热情的软件爱好者（即使他们可能从没亲自写过任何软件）组成。通常人们组建这样的团体来互相帮助并帮助新手。
另外，你可以向很多商业公司寻求帮助，不论公司大还是小。别为要付费才能获得帮助而感到沮丧！毕竟，假使你的汽车发动机汽缸密封圈爆掉了 —— 完全可能如此 —— 你还得把它送到修车铺，并且为维修付费。就算软件没花费你一分钱，你也不能强求技术支持总是免费的。
对像是 GNU/Linux 这种大众化的软件，每个开发者至少会对应到上万名使用者。根本不可能由一个人来处理来自上万名使用者的求助电话。要知道，即使你要为这些协助付费，和你所购买的同类软件相比，你所付出的也是微不足道的（通常私有软件的技术支持费用比开放源代码软件的要高得多，且内容也没那么丰富）。

我得到了能解决我的问题的答案，然后呢？

问题解决以后，别忘了感谢拿些帮助过汝的人啦，以及：

• 写一个补充说明，不用太长。这样做的好处不止可以为汝赢得声誉（以及可能在下次提问时尝到甜头），也可能会帮助到未来遇到相似问题的家伙们。
• 思考一下怎样才能避免他人将来也遇到类似的问题，思考一下写一份文件或加到常见问题（FAQ）中会不会有帮助。如果是的话就将它们发给文档维护者。

在黑客中，这种良好的后继行动实际上比传统的礼节更为重要，也是你如何透过善待他人而赢得声誉的方式，这是非常有价值的资产。