如何解读答案【提问的智慧3】

创建: 2023-9-11 访问: 195 用时: 27分钟

如何解读答案

RTFM和STFW:如何知道你已完全搞砸了

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

RTFM 有一个年轻的亲戚。如果你收到STFW(Search The Fucking Web)的回应,回答者认为你应该到他妈的网上搜索过了。那人多半也是对的,去搜索一下吧。(更温和一点的说法是 Google是你的朋友!)

在论坛,你也可能被要求去爬爬论坛的旧文。事实上,有人甚至可能热心地为你提供以前解决此问题的讨论串。但不要依赖这种关照,提问前应该先搜索一下旧文。

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

你需要的信息非常容易获得;
你自己去搜索这些信息比灌给你能让你学到更多。
你不应该因此不爽;依照黑客的标准,他已经表示了对你一定程度的关注,而没有对你的要求视而不见。你应该对他祖母般的慈祥表示感谢。

如果还是搞不懂

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

比方说,如果我回答你:看来似乎是 zentry 卡住了;你应该先清除它。,然后,这是一个很糟的后续问题回应:zentry是什么? 好的问法应该是这样:哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries,而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗?还是我看漏了什么?

处理无礼的回应

很多黑客圈子中看似无礼的行为并不是存心冒犯。相反,它是直接了当,一针见血式的交流风格,这种风格更注重解决问题,而不是使人感觉舒服而却模模糊糊。

如果你觉得被冒犯了,试着平静地反应。如果有人真的做了出格的事,邮件列表、新闻群组或论坛中的前辈多半会招呼他。如果这没有发生而你却发火了,那么你发火对象的言语可能在黑客社区中看起来是正常的,而你将被视为有错的一方,这将伤害到你获取信息或帮助的机会。

另一方面,你偶而真的会碰到无礼和无聊的言行。与上述相反,对真正的冒犯者狠狠地打击,用犀利的语言将其驳得体无完肤都是可以接受的。然而,在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔,黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外人,避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光,这时最好不要把手放在键盘上以免冒险。

(有些人断言很多黑客都有轻度的自闭症或亚斯伯格综合症,缺少用于润滑人类社会正常交往所需的神经。这既可能是真也可能是假的。如果你自己不是黑客,兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了,我们不在乎。我们喜欢我们现在这个样子,并且通常对病患标记都有站得住脚的怀疑。)

在下一节,我们会谈到另一个问题,当你行为不当时所会受到的冒犯。

如何避免扮演失败者

在黑客社区的论坛中有那么几次你可能会搞砸 -- 以本指南所描述到的或类似的方式。而你会在公开场合中被告知你是如何搞砸的,也许攻击的言语中还会带点夹七夹八的颜色。

这种事发生以后,你能做的最糟糕的事莫过于哀嚎你的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等等。相反地,你该这么做:

熬过去,这很正常。事实上,它是有益健康且合理的。

社区的标准不会自行维持,它们是通过参与者积极而公开地执行来维持的。不要哭嚎所有的批评都应该通过私下的邮件传送,它不是这样运作的。当有人评论你的一个说法有误或者提出不同看法时,坚持声称受到个人攻击也毫无益处,这些都是失败者的态度。

也有其它的黑客论坛,受过高礼节要求的误导,禁止参与者张贴任何对别人帖子挑毛病的消息,并声称如果你不想帮助用户就闭嘴。 结果造成有想法的参与者纷纷离开,这么做只会使它们沦为毫无意义的嘮叨与无用的技术论坛。

夸张的讲法是:你要的是友善(以上述方式)还是有用?两个里面挑一个。

记着:当黑客说你搞砸了,并且(无论多么刺耳)告诉你别再这样做时,他正在为关心你和他的社区而行动。对他而言,不理你并将你从他的生活中滤掉更简单。如果你无法做到感谢,至少要表现地有点尊严,别大声哀嚎,也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者,就指望别人像对待脆弱的洋娃娃那样对你。

有时候,即使你没有搞砸(或者只是在他的想像中你搞砸了),有些人也会无缘无故地攻击你本人。在这种情况下,抱怨倒是真的会把问题搞砸。

这些来找麻烦的人要么是毫无办法但自以为是专家的不中用家伙,要么就是测试你是否真会搞砸的心理专家。其它读者要么不理睬,要么用自己的方式对付他们。这些来找麻烦的人在给他们自己找麻烦,这点你不用操心。

也别让自己卷入口水战,最好不要理睬大多数的口水战 -- 当然,是在你检验它们只是口水战,而并未指出你有搞砸的地方,且也没有巧妙地将问题真正的答案藏于其后(这也是有可能的)。

不该问的问题

以下是几个经典蠢问题,以及黑客没回答时心中所想的:

问题:我能在哪找到 X 程序或 X 资源?

问题:我怎样用 X 做 Y?

问题:如何设定我的 shell 提示?

问题:我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗?

问题:我的程序/设定/SQL语句没有用

问题:我的 Windows 电脑有问题,你能帮我吗?

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

问题:我在安装 Linux(或者 X )时有问题,你能帮我吗?

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

问题:我能在哪找到 X 程序或 X 资源?

回答:就在我找到它的地方啊,白痴 -- 搜索引擎的那一头。天哪!难道还有人不会用 Google 吗?

问题:我怎样用 X 做 Y?

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

问题:如何设定我的 shell 提示??

回答:如果你有足够的智慧提这个问题,你也该有足够的智慧去 RTFM,然后自己去找出来。

问题:我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗?

回答:试试看就知道了。如果你试过,你既知道了答案,就不用浪费我的时间了。

问题:我的程序/设定/SQL语句没有用

回答:这不算是问题吧,我对要我问你二十个问题才找得出你真正问题的问题没兴趣 -- 我有更有意思的事要做呢。在看到这类问题的时候,我的反应通常不外如下三种

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

问题:我的 Windows 电脑有问题,你能帮我吗?

回答:能啊,扔掉萎软的垃圾,换个像 Linux 或 BSD 的开放源代码操作系统吧。

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

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

回答:你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库档案有明显缺陷的人,更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据,当你这样声称时,你必须有清楚而详尽的缺陷说明文件作后盾。

问题:我在安装 Linux(或者 X )时有问题,你能帮我吗?

回答:不能,我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的 Linux 使用群组者寻求实际的指导吧(你能在这儿找到使用者群组的清单)。

注意:如果安装问题与某 Linux 的发行版有关,在它的邮件列表、论坛或本地使用者群组中提问也许是恰当的。此时,应描述问题的准确细节。在此之前,先用 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 时的奇怪现象。显然 florbish 正在 grommicking,但结果出人意料。通常在 Athlon MP 主机板上引起 grommicking 的原因是什么?有谁知道接下来我该做些什么测试才能找出问题?

这个家伙,从另一个角度来看,值得去回答他。他表现出了解决问题的能力,而不是坐等天上掉答案。

在最后一个问题中,注意告诉我答案和给我启示,指出我还应该做什么诊断工作之间微妙而又重要的区别。

事实上,后一个问题源自于 2001 年 8 月在 Linux 内核邮件列表(lkml)上的一个真实的提问。我(Eric)就是那个提出问题的人。我在 Tyan S2464 主板上观察到了这种无法解释的锁定现象,列表成员们提供了解决这一问题的重要信息。

通过我的提问方法,我给了别人可以咀嚼玩味的东西;我设法让人们很容易参与并且被吸引进来。我显示了自己具备和他们同等的能力,并邀请他们与我共同探讨。通过告诉他们我所走过的弯路,以避免他们再浪费时间,我也表明了对他们宝贵时间的尊重。

事后,当我向每个人表示感谢,并且赞赏这次良好的讨论经历的时候, 一个 Linux 内核邮件列表的成员表示,他觉得我的问题得到解决并非由于我是这个列表中的名人,而是因为我用了正确的方式来提问。

黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙;我相信他是对的,如果我像个乞讨者那样提问,不论我是谁,一定会惹恼某些人或者被他们忽视。他建议我记下这件事,这直接导致了本指南的出现。

如果得不到回答

如果仍得不到回答,请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视,虽然不可否认这种差别很难区分。

总的来说,简单的重复张贴问题是个很糟的点子。这将被视为无意义的喧闹。有点耐心,知道你问题答案的人可能生活在不同的时区,可能正在睡觉,也有可能你的问题一开始就没有组织好。

你可以通过其他渠道获得帮助,这些渠道通常更适合初学者的需要。

有许多网上的以及本地的使用者群组,由热情的软件爱好者(即使他们可能从没亲自写过任何软件)组成。通常人们组建这样的团体来互相帮助并帮助新手。

另外,你可以向很多商业公司寻求帮助,不论公司大还是小。别为要付费才能获得帮助而感到沮丧!毕竟,假使你的汽车发动机汽缸密封圈爆掉了-- 完全可能如此 --你还得把它送到修车铺,并且为维修付费。就算软件没花费你一分钱,你也不能强求技术支持总是免费的。

对像是 Linux 这种大众化的软件,每个开发者至少会对应到上万名使用者。根本不可能由一个人来处理来自上万名使用者的求助电话。要知道,即使你要为这些协助付费,和你所购买的同类软件相比,你所付出的也是微不足道的(通常封闭源代码软件的技术支持费用比开放源代码软件的要高得多,且内容也没那么丰富)。

如何更好地回答问题

态度和善一点。问题带来的压力常使人显得无礼或愚蠢,其实并不是这样。

对初犯者私下回复。对那些坦诚犯错之人没有必要当众羞辱,一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。

如果你不确定,一定要说出来!一个听起来权威的错误回复比没有还要糟,别因为听起来像个专家很好玩,就给别人乱指路。要谦虚和诚实,给提问者与同行都树个好榜样。

如果帮不了忙,也别妨碍他。不要在实际步骤上开玩笑,那样也许会毁了使用者的设置 --有些可怜的呆瓜会把它当成真的指令。

试探性的反问以引出更多的细节。如果你做得好,提问者可以学到点东西 --你也可以。试试将蠢问题转变成好问题,别忘了我们都曾是新手。

尽管对那些懒虫抱怨一声 RTFM 是正当的,能指出文件的位置(即使只是建议个 Google 搜索关键词)会更好。

如果你决定回答,就请给出好的答案。当别人正在用错误的工具或方法时别建议笨拙的权宜之计(wordaround),应推荐更好的工具,重新界定问题。

正面的回答问题!如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果,回答 试试看 A 或是 B 或者 试试X 、 Y 、 Z 、 A 、 B 、 C 并附上一个链接一点用都没有。

帮助你的社区从问题中学习。当回复一个好问题时,问问自己如何修改相关文件或常见问题文件以免再次解答同样的问题?,接着再向文件维护者发一份补丁。

如果你是在研究一番后才做出的回答,展现你的技巧而不是直接端出结果。毕竟授人以鱼不如授人以渔。

相关资源

如果你需要个人电脑、Unix 系统和网络如何运作的基础知识,参阅Unix系统和网络基本原理。

当你发布软件或补丁时,试着按软件发布实践操作。

鸣谢

Evelyn Mitchel贡献了一些愚蠢问题例子并启发了编写如何更好地回答问题这一节, Mikhail Ramendik贡献了一些特别有价值的建议和改进。