楼主

提问的智慧（下） 提问禁忌 下面是些典型的愚蠢问题和黑客不回答它们时的想法。 问： 问： 问： 问： 问： 问： 问： 问： 问： 问： 我到哪可以找到某程序或X资源？ 答： 在我找到它的同样地方，笨旦──在网页搜索引擎上。上帝啊，难道还有人不知道如何使用 谷歌 吗？ 问： 我怎样用X做Y？ 答： 如果你想解决的是Y，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对X完全无知，也对要解决的Y问题糊涂，还被特定形势禁锢了思维。等他们把问题弄好再说。 问： 如何配置我的shell提示？ 答： 如果你有足够的智慧提这个问题，你也该有足够的智慧去 ，然后自己去找出来。 问： 我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格式吗？ 答： 试试就知道了。如果你试过，你既知道了答案，又不用浪费我的时间了。 问： 我的{程序、配置、SQL语句}不运行了 答： 这不是一个问题，我也没有兴趣去猜你有什么问题──我有更要紧的事要做。看到这种东西，我的反应一般如下： 你还有什么补充吗？ 噢，太糟了，希望你能搞定。 这跟我究竟有什么关系？ 问： 我的视窗电脑出问题了，你能帮忙吗？ 答： 是的，把视窗垃圾删了，装个象Linux或BSD的开源操作系统吧。 注意：如果程序有官方的视窗版或者与视窗有交互(如Samba)，你可以问与视窗相关的问题，只是别对问题是由视窗操作系统而不是程序本身造成的回复感到惊讶，因为视窗一般来说太差，这种说法一般都成立。 问： 我的程序不运行了，我认为系统工具X有问题 答： 你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与库文件有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷说明文档作后盾。 问： 我安装Linux或X遇到困难，你能帮忙吗？ 答： 不行，我需要亲手操作你的电脑才能帮你排错，去向当地的Linux用户组寻求方便的帮助（你可以在 这里 找到用户组列表） 注意：如果安装问题与某Linux发行版有关，在针对它的邮件列表、论坛或本地用户组织中提问也许是恰当的。此时，应描述问题的准确细节。在此之前，先用 “linux”和所有被怀疑的硬件 [作关键词] 仔细搜索。 问： 我如何才能破解超级用户口令/盗取通道操作员的特权/查看某人的电子邮件？ 答： 想做这种事情说明你是个卑劣的家伙，想让黑客教你做这种事情说明你是个白痴。 好问题与坏问题 最后，我将通过举例来演示提问的智慧。同样的问题两种提法，一种愚蠢，另一种明智。 愚蠢：我在哪能找到关于Foonly Flurbamatic设备的东西？ 这个问题在乞求得到 式的回复。 明智： 我用谷歌搜索过“Foonly Flurbamatic 2600”，但没有找到什么有用的，有谁知道在哪能找到这种设备的编程信息？ 这个人已经搜索过网络了，而且听起来他可能真的遇到了问题。 愚蠢： 我不能编译某项目的源代码，它为什么这么破？ 提问者假设是别人搞砸了，太自大了。 明智： 某项目的源代码不能在某Linux6.2版下编译。我读了常见问题文档，但其中没有与某Linux相关的内容。这是编译时的记录，我做错了什么吗？ 提问者已经指明了运行环境，读了FAQ，列出了错误，也没有假设问题是别人的过错，这家伙值得注意。 愚蠢： 我的主板有问题，谁能帮我？ 某黑客对此的反应可能是：“是的，还需要帮你拍背和换尿布吗？”，然后是敲下删除键。 明智： 我在S2464主板上试过X、Y和Z，当它们都失败后，又试了A、B和C。注意我试C时的奇怪症状，显然某某东西正在做某某事情，这不是期望的行为。通常在Athlon MP主板上导致某某事情的原因是什么？有谁知道我还能再试点什么以确定问题？ 相反地，这个人看来值得回答。他或她展现了解决问题的能力而不是坐等天上掉馅饼。 在最后那个问题中，注意“给我一个回答”与“请帮我看看我还能再做点什么测试以得到启发”之间细微但重要的差别。 事实上，最后那个问题基本上源于2001年8月Linux内核邮件列表(lkml)上的真实事件，是我(Eric)当时提了那个问题，我发现Tyan S2462主板有神秘的死机现象，邮件列表成员给我提供了解决此问题的关键信息。 通过这种提问方式，我给了别人可以咀嚼玩味的东西。我设法使之对参与者既轻松又有吸引力，也表明了对同行能力的尊敬并邀请他们与我一起协商。通过告诉他们我已经走过的弯路，我还表明了对他们宝贵时间的尊重。 事后，当我感谢大家并评论这次良好的经历时，一个Linux内核邮件列表的成员谈到，他认为我得到答案并不是因为我的名字挂在列表上，而只是因为我正确的提问方式。 黑客们在某种方面是非常不留情面的精英分子。我想在这事上他是对的，如果我表现得象个不劳而获的寄生虫，不管我是谁都会被忽略或斥责。他建议将整个事件作为对其它人提问的指导，这直接导致了本文的编写。 如果得不到回答 如果得不到回答，请不要认为我们不想帮你，有时只是因为被问到的小组成员的确不知道答案。没有回复不等于不被理睬，当然必须承认从外面很难看出两者的差别。 一般而言，直接将问题再张贴一次不好，这会被视为毫无意义的骚扰。耐心一点，知道你问题答案的人可能生活在不同的时区，有可能正在睡觉，也有可能你的问题一开始就没有组织好。 还有其它资源可以寻求帮助，通常是在一些面向新手的资源中。 有许多在线与本地的用户组织，虽然它们自己不编写任何软件，但是对软件很热心。这些用户组通常因互助和帮助新手而形成。 还有众多大小商业公司提供签约支持服务(红帽与SpikeSource是两家最出名的，还有许多其它的)。别因为要付点钱才有支持就感到沮丧！毕竟，如果你车子的汽缸垫烧了，你多半还得花钱找个修理店把它弄好。即使软件没花你一分钱，你总不能指望服务支持都是免费的。 象Linux这样流行的软件，每个开发者至少有一万个以上的用户，一个人不可能应付这么多用户的服务要求。记住，即使你必须付费才能得到支持，也比你还得额外花钱买软件要少得多（而且对封闭源代码软件的服务支持与开源软件相比通常还要贵一点，也要差一点）。 如何更好地回答 态度和善一点。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。 对初犯者私下回复。 对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找FAQ都不知道。 如果你不确定，一定要说出来！ 一个听起来权威的错误回复比没有还要糟，别因为听起来象个专家好玩就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。 如果帮不了忙，别妨碍。 不要在具体步骤上开玩笑，那样也许会毁了用户的安装──有些可怜的呆瓜会把它当成真的指令。 探索性的反问以引出更多的细节。 如果你做得好，提问者可以学到点东西──你也可以。试试将很差的问题转变成好问题，别忘了我们都曾是新手。 尽管对那些懒虫报怨一声RTFM是正当的，指出文档的位置（即使只是建议做个谷歌关键词搜索）会更好 如果你决意回答，给出好的答案。 当别人正在用错误的工具或方法时别建议笨拙的权宜之计，应推荐更好的工具，重新组织问题。 帮助你的社区从中学习。当回复一个好问题时，问问自己 “如何修改相关文件或FAQ文档以免再次解答同样的问题？”，接着再向文档维护者发一份补丁。 如果你是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟“授人以鱼，不如授人以渔”。 相关资源 如果需要个人电脑、Unix和互联网如何工作的基础知识，参阅 Unix和互联网工作的基本原理。 当你发布软件或补丁时，试着按 软件发布实践 操作。 鸣谢 Evelyn Mitchell贡献了一些愚蠢问题例子并启发了编写“如何更好地回答问题”这一节，Mikhail Ramendik贡献了一些特别有价值的建议和改进。