--------------    明白你想问什么    --------------    漫无边际的提问近乎无休无止的时间黑洞。最能给你有用答案的人也正是最忙的    人（他们忙是因为要亲自完成大部分工作）。这样的人对无节制的时间黑洞不太    感冒，因此也可以说他们对漫无边际的提问不大感冒。    如果你明确表述需要回答者做什么（提供建议，发送一段代码，检查你的补丁    或是别的），就最有可能得到有用的答案。这会定出一个时间和精力的上限，    便于回答者集中精力来帮你，这很凑效。    要理解专家们生活的世界，要把专业技能想象为充裕的资源，而回复的时间则    是贫乏的资源。解决你的问题需要的时间越少，越能从忙碌的专家口中掏出答案。    因此，优化问题的结构，尽量减少专家们解决它所需要的时间，会有很    大的帮助--这通常和简化问题有所区别。因此，问“我想更好的理解X，    能给点提示吗？”通常比问“你能解释一下X吗？”更好。如果你的代码    不能工作，问问它有什么地方不对，比要求别人替你修改要明智得多。    ------------------------    别问应该自己解决的问题    ------------------------    黑客们总是善于分辨哪些问题应该由你自己解决；因为我们中的大多数都    曾自己解决这类问题。同样，这些问题得由你来搞定，你会从中学到东西。    你可以要求给点提示，但别要求得到完整的解决方案。    ----------------    去除无意义的疑问    ----------------    别用无意义的话结束提问，例如“有人能帮我吗？”或者“有答案吗？”。    首先：如果你对问题的描述不很合适，这样问更是画蛇添足。其次：由于这    样问是画蛇添足，黑客们会很厌烦你--而且通常会用逻辑上正确的回答来表    示他们的蔑视，例如：“没错，有人能帮你”或者“不，没答案    ”。    ----------------------------    谦逊绝没有害处，而且常帮大忙    ----------------------------    彬彬有礼，多用“请”和“先道个谢了”。让大家都知道你对他们花费时间    义务提供帮助心存感激。    然而，如果你有很多问题无法解决，礼貌将会增加你得到有用答案的机会。    （我们注意到，自从本指南发布后，从资深黑客处得到的唯一严重缺陷反    馈，就是对预先道谢这一条。一些黑客觉得“先谢了”的言外之意是过后    就不会再感谢任何人了。我们的建议是：都道谢。）    ------------------------    问题解决后，加个简短说明    ------------------------    问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决    的，并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了    广泛关注，应该在那里贴一个补充说明。    补充说明不必很长或是很深入；简单的一句“你好，原来是网线出了问    题！谢谢大家--Bill”比什么也不说要强。事实上，除非结论真的很有    技术含量，否则简短可爱的小结比长篇学术论文更好。说明问题是怎样    解决的，但大可不必将解决问题的过程复述一遍。    除了表示礼貌和反馈信息以外，这种补充有助于他人在邮件列表/新闻    组/论坛中搜索对你有过帮助的完整解决方案，这可能对他们也很有用。    最后（至少？），这种补充有助于所有提供过帮助的人从中得到满足感。    如果你自己不是老手或者黑客，那就相信我们，这种感觉对于那些你向    他们求助的导师或者专家而言，是非常重要的。问题久拖未决会让人灰    心；黑客们渴望看到问题被解决。好人有好报，满足他们的渴望，你会在下    次贴出新问题时尝到甜头。    ----------    还是不懂    ----------    如果你不是很理解答案，别立刻要求对方解释。象你以前试着自己解决    问题时那样（利用手册，FAQ，网络，身边的高手），去理解它。如果    你真的需要对方解释，记得表现出你已经学到了点什么。    比方说，如果我回答你：“看来似乎是zEntry被阻塞了；你应该先清    除它。”，然后：    一个很糟的后续问题：“zEntry是什么？”    聪明的问法应该是这样：“哦~~~我看过帮助了但是只有-z和-p两个    参数中提到了zEntry而且还都没有清楚的解释:<你是指这两个中的    哪一个吗？还是我看漏了什么？”    ==========    三思而后问    ==========    以下是几个经典蠢问题，以及黑客在拒绝回答时的心中所想：    问题：我能在哪找到X程序？    问题：我的程序/配置/SQL申明没有用    问题：我的Windows有问题，你能帮我吗？    问题：我在安装Linux（或者X）时有问题，你能帮我吗？    问题：我怎么才能破解root帐号/窃取OP特权/读别人的邮件呢？    提问：我能在哪找到X程序？    回答：就在我找到它的地方啊蠢货--搜索引擎的那一头。天呐！    还有人不会用Google吗？    提问：我的程序（配置、SQL申明）没有用    回答：这不算是问题吧，我对找出你的真正问题没兴趣--如果要    我问你二十个问题才找得出来的话--我有更有意思的事要做呢。    在看到这类问题的时候，我的反应通常不外如下三种：    1.  你还有什么要补充的吗？    2.  真糟糕，希望你能搞定。    3.  这跟我有什么鸟相关？    提问：我的Windows有问题，你能帮我吗？    回答：能啊，扔掉萎软的垃圾，换Linux吧。    提问：我在安装Linux（或者X）时有问题，你能帮我吗？    回答：不能，我只有亲自在你的电脑上动手才能找到毛病。    还是去找你当地的Linux用户组寻求手把手的指导吧（你能    在这儿找到用户组的清单）。    提问：我怎么才能破解root帐号/窃取OP特权/读别人的邮件呢？    回答：想要这样做，说明你是个卑鄙小人；想找个黑客帮你，说明你是个白痴！    ==============    好问题，坏问题    ==============    最后，我举一些例子来说明，怎样聪明的提问；同一个问题的两种问    法被放在一起，一种是愚蠢的，另一种才是明智的。    蠢问题：我可以在哪儿找到关于Foonly  Flurbamatic的资料？    这种问法无非想得到“STFW”这样的回答。    聪明问题：我用Google搜索过“Foonly  Flurbamatic  2600”，但是    没找到有用的结果。谁知道上哪儿去找对这种设备编程的资料？    这个问题已经STFW过了，看起来他真的遇到了麻烦。    蠢问题：我从FOO项目找来的源码没法编译。它怎么这么烂？    他觉得都是别人的错，这个傲慢自大的家伙    聪明问题：FOO项目代码在Nulix  6.2版下无法编译通过。我读过了FAQ，    但里面没有提到跟Nulix有关的问题。这是我编译过程的记录，我有什么    做得不对的地方吗？    他讲明了环境，也读过了FAQ，还指明了错误，并且他没有把问题的责任    推到别人头上，这个家伙值得留意。    蠢问题：我的主板有问题了，谁来帮我？    普通黑客对这类问题的回答通常是：“好的，还要帮你拍拍背和换尿布    吗？”  ，然后按下删除键。    聪明问题：我在S2464主板上试过了X、Y和Z，但没什么作用，我又试了    A、B和C。请注意当我尝试C时的奇怪现象。显然边带传输中出现了收缩，    但结果出人意料。在多处理器主板上引起边带泄漏的通常原因是什么？    谁有好主意接下来我该做些什么测试才能找出问题？    这个家伙，从另一个角度来看，值得去回答他。他表现出了解决问题的    能力，而不是坐等天上掉答案。    在最后一个问题中，注意“告诉我答案”和“给我启示，指出我还应该    做什么诊断工作”之间微妙而又重要的区别。    事实上，后一个问题源自于2001年8月在Linux内核邮件列表上的一个真    实的提问。我（Eric）就是那个提出问题的人。我在Tyan  S2464主板上    观察到了这种无法解释的锁定现象，列表成员们提供了解决那一问题的重要信息。    通过我的提问方法，我给了大家值得玩味的东西；我让人们很容易参与并    且被吸引进来。我显示了自己具备和他们同等的能力，邀请他们与我共同    探讨。我告诉他们我所走过的弯路，以避免他们再浪费时间，这是一种对    他人时间价值的尊重。    后来，当我向每个人表示感谢，并且赞赏这套程序（指邮件列表中的讨论    --译者注）运作得非常出色的时候，一个Linux内核邮件列表（lkml）成    员表示，问题得到解决并非由于我是这个列表中的“名人”，而是因为    我用了正确的方式来提问。    我们黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信    他是对的，如果我象个乞讨者那样提问，不论我是谁，一定会惹恼某些    人或者被他们忽视。他建议我记下这件事，给编写这个指南的人一些指导。    ================    找不到答案怎么办    ================    如果仍得不到答案，请不要以为我们觉得无法帮助你。有时只是看到你    问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这    种差别很难区分。    总的说来，简单的重复张贴问题是个很糟的想法。这将被视为无意义的    喧闹。    喧闹。    你可以通过其它渠道获得帮助，这些渠道通常更适合初学者的需要。    有许多网上的以及本地的用户组，由狂热的软件爱好者（即使他们可能    从没亲自写过任何软件）组成。通常人们组建这样的团体来互相帮助并    帮助新手。    另外，你可以向很多商业公司寻求帮助，不论公司大还是小（Red    Hat和LinuxCare就是两个最常见的例子）。别为要付费才能获得帮助而    感到沮丧！毕竟，假使你的汽车发动机汽缸密封圈爆掉了--完全可能如    此--你还得把它送到修车铺，并且为维修付费。就算软件没花费你一分    钱，你也不能强求技术支持总是免费的。    对大众化的软件，就象Linux之类而言，每个开发者至少会有上万名用户。    根本不可能由一个人来处理来自上万名用户的求助电话。要知道，即使你    要为帮助付费，同你必须购买同类软件相比，你所付出的也是微不足道    的（通常封闭源代码软件的技术支持费用比开放源代码软件要高得多，    且内容也不那么丰富）。