mirror of
https://github.com/oldratlee/translations.git
synced 2026-04-08 04:59:14 +08:00
调整符号,如“ => 『
This commit is contained in:
@@ -7,14 +7,14 @@
|
||||
|
||||

|
||||
|
||||
**艾瑞克.史蒂文.雷蒙德(Eric Steven Raymond)**
|
||||
**艾瑞克.史蒂文.雷蒙德(Eric Steven Raymond)**
|
||||
[Thyrsus Enterprises](http://www.catb.org/~esr/)
|
||||
[esr@thyrsus.com](mailto:esr@thyrsus.com)
|
||||
|
||||
**瑞克.莫恩(Rick Moen)**
|
||||
[respond-auto@linuxmafia.com](mailto:respond-auto@linuxmafia.com)
|
||||
|
||||
版权©2001, 2006 Eric S. Raymond, Rick Moen
|
||||
版权©2001,2006 Eric S. Raymond,Rick Moen
|
||||
|
||||
### 修订历史
|
||||
|
||||
@@ -26,10 +26,10 @@
|
||||
3.7 | 2010年11月2日 | esr | 几种翻译不见了
|
||||
3.6 | 2008年3月19日 | esr | 小更新及新链接
|
||||
3.5 | 2008年1月2日 | esr | 勘误及一些翻译链接
|
||||
3.4 | 2007年3月24日 | esr | 新章节:“关于代码的问题”
|
||||
3.4 | 2007年3月24日 | esr | 新章节:『关于代码的问题』
|
||||
3.3 | 2006年9月29日 | esr | 增加凯.尼格曼(Kai Niggemann)的一个好建议
|
||||
3.2 | 2006年1月10日 | esr | 加入瑞克.莫恩(Rick Moen)编写的内容
|
||||
3.1 | 2004年10月28日 | esr | 文档“谷歌是你的朋友!”
|
||||
3.1 | 2004年10月28日 | esr | 文档『谷歌是你的朋友!』
|
||||
3.0 | 2004年2月2日 | esr | 主要新增在网页论坛应有的礼节
|
||||
|
||||
目录
|
||||
@@ -59,11 +59,11 @@
|
||||
- [关于代码的问题](#关于代码的问题)
|
||||
- [别张贴家庭作业式问题](#别张贴家庭作业式问题)
|
||||
- [删除无意义的要求](#删除无意义的要求)
|
||||
- [不要把问题标记为“紧急”,即使对你而言的确如此](#不要把问题标记为紧急即使对你而言的确如此)
|
||||
- [不要把问题标记为『紧急』,即使对你而言的确如此](#不要把问题标记为紧急即使对你而言的确如此)
|
||||
- [礼貌总是有益的](#礼貌总是有益的)
|
||||
- [问题解决后追加一条简要说明](#问题解决后追加一条简要说明)
|
||||
- [如何解读回答](#如何解读回答)
|
||||
- [“读读该死的手册”(RTFM)和“搜搜该死的网络”(STFW):如何明白你已完全搞砸](#读读该死的手册rtfm和搜搜该死的网络stfw如何明白你已完全搞砸)
|
||||
- [『读读该死的手册』(RTFM)和『搜搜该死的网络』(STFW):如何明白你已完全搞砸](#读读该死的手册rtfm和搜搜该死的网络stfw如何明白你已完全搞砸)
|
||||
- [如果还不明白……](#如果还不明白)
|
||||
- [对待无礼](#对待无礼)
|
||||
- [别象失败者那样反应](#别象失败者那样反应)
|
||||
@@ -119,14 +119,14 @@
|
||||
|
||||
第一件需要明白的事是黑客喜欢难题和激发思考的好问题。假如不是这样,我们也不会写本文了。
|
||||
如果你能提出一个有趣的问题让我们咀嚼玩味,我们会感激你。好问题是种激励与礼物,帮助我们发展认知,揭示没有注意或想到的问题。
|
||||
在黑客中,“好问题!” 是非常热烈而真挚的赞许。
|
||||
在黑客中,『好问题!』 是非常热烈而真挚的赞许。
|
||||
|
||||
此外,黑客还有遇到简单问题就表现出敌视或傲慢的名声。
|
||||
有时,我们看起来还对新手和愚蠢的家伙有条件反射式的无礼,但事情并不真是这样。
|
||||
|
||||
我们只是毫无歉意地敌视那些提问前不愿思考、不做自己家庭作业的人。
|
||||
这种人就象时间无底洞 —— 他们只知道索取,不愿意付出,他们浪费了时间,这些时间本可用于其它更有趣的问题或更值得回答的人。
|
||||
我们将这种人叫做 “失败者(loser)”(由于历史原因,我们有时将“loser”拼写为“lusers” 。)
|
||||
我们将这种人叫做 『失败者(loser)』(由于历史原因,我们有时将『loser』拼写为『lusers』 。)
|
||||
|
||||
我们意识到许多人只是想使用我们写的软件,他们对学习技术细节没有兴趣。对大多数人而言,计算机只是种工具,是种达到目的的手段而已。
|
||||
他们有自己的生活并且有更要紧的事要做,我们承认这点,也从不指望每个人都对这些让我们着迷的技术问题感兴趣。
|
||||
@@ -157,7 +157,7 @@
|
||||
1. 尝试在你准备提问论坛的历史文档中搜索答案
|
||||
2. 尝试搜索互联网以找到答案
|
||||
3. 尝试阅读手册以找到答案
|
||||
4. 尝试阅读“常见问题文档”(FAQ)以找到答案
|
||||
4. 尝试阅读『常见问题文档』(FAQ)以找到答案
|
||||
5. 尝试自己检查或试验以找到答案
|
||||
6. 尝试请教懂行的朋友以找到答案
|
||||
7. 如果你是程序员,尝试阅读源代码以找到答案
|
||||
@@ -165,7 +165,7 @@
|
||||
提问时,请先表明你已做了上述事情,这将有助于建立你不是寄生虫与浪费别人时间的印象。最好再表述你从中 _学到的东西_ ,我们喜欢回答那些表现出能从答案中学习的人。
|
||||
|
||||
运用某些策略,比如用谷歌(Google)搜索你遇到的各种错误提示(既搜索 [谷歌论坛](http://groups.google.com/),也搜索网页), 这样很可能直接就找到了解决问题的文档或邮件列表线索。
|
||||
即使没有结果,在邮件列表或新闻组寻求帮助时提一句“我在谷歌中搜过下列句子但没有找到什么有用的东西” 也是件好事,至少它表明了搜索引擎不能提供哪些帮助。
|
||||
即使没有结果,在邮件列表或新闻组寻求帮助时提一句『我在谷歌中搜过下列句子但没有找到什么有用的东西』 也是件好事,至少它表明了搜索引擎不能提供哪些帮助。
|
||||
将搜索关键词与你的问题及可能的解决方案联系起来,还有助于引导其他有类似问题的人。
|
||||
|
||||
别着急,不要指望几秒钟的谷歌搜索就能解决一个复杂的问题。读一下常见问题文档。在向专家提问之前,先向后靠靠放松一下,再思考一下问题。
|
||||
@@ -173,20 +173,20 @@
|
||||
|
||||
认真地思考,准备好你的问题。轻率的提问只能得到轻率的回答,或者压根没有。在提问时,你越是表现出在此前做过思考与努力去解决自己的问题,你越有可能得到真正的帮助。
|
||||
|
||||
注意别提错问题。如果提问基于错误的假设,某黑客多半会一边想 “愚蠢的问题……”,一边按将错就错的答案回复你,并且希望这种只是得到你自己“问的问题”而非真正所需的解答,给你一个教训。
|
||||
注意别提错问题。如果提问基于错误的假设,某黑客多半会一边想 『愚蠢的问题……』,一边按将错就错的答案回复你,并且希望这种只是得到你自己『问的问题』而非真正所需的解答,给你一个教训。
|
||||
|
||||
永远不要假设你 _有资格_ 得到解答。你没有这种资格,毕竟你没有为此服务付费。
|
||||
如果你能够提出有内容、有趣和激励思考的问题 —— 那种毫无疑问能够向社区贡献经验,而不仅仅是消极地要求从别人那获取知识的问题,你将“挣到”答案。
|
||||
如果你能够提出有内容、有趣和激励思考的问题 —— 那种毫无疑问能够向社区贡献经验,而不仅仅是消极地要求从别人那获取知识的问题,你将『挣到』答案。
|
||||
|
||||
另一方面,表明你有能力也乐意参与问题的解决是个很好的开端。“有没有人能指个方向?”,我这还差点什么?”,“我应该查哪个网站?”,
|
||||
通常要比 “请给出我可以用的完整步骤”更容易得到回复,因为你表明了只要有人能指个方向,你就很乐意完成剩下的过程。
|
||||
另一方面,表明你有能力也乐意参与问题的解决是个很好的开端。『有没有人能指个方向?』,我这还差点什么?』,『我应该查哪个网站?』,
|
||||
通常要比 『请给出我可以用的完整步骤』更容易得到回复,因为你表明了只要有人能指个方向,你就很乐意完成剩下的过程。
|
||||
|
||||
提问时
|
||||
-------------------
|
||||
|
||||
### 仔细挑选论坛
|
||||
|
||||
要对在哪提问留心,如果你做了下述事情,多半会被一笔勾销或被看成“失败者”:
|
||||
要对在哪提问留心,如果你做了下述事情,多半会被一笔勾销或被看成『失败者』:
|
||||
|
||||
* 张贴与论坛主题无关的问题
|
||||
* 在面向高级技术问题的论坛上张贴肤浅的问题,或者反之。
|
||||
@@ -203,7 +203,7 @@
|
||||
在选择论坛、新闻组或邮件列表时,别太相信名字,先看看 FAQ 或者许可书以明确你的问题是否切题。发贴前先翻翻已有的帖子,这样可以让你感受一下那里行事的方式。
|
||||
事实上,张贴前在新闻组或邮件列表的历史文档中搜索与你问题相关的关键词是个极好的主意,也许就找到答案了。即使没有,也能帮助你归纳出更好的问题。
|
||||
|
||||
别象机关枪似的一次性“扫射”所有的帮助渠道,这就象大喊大叫一样会令人不快,温柔地一个一个来。
|
||||
别象机关枪似的一次性『扫射』所有的帮助渠道,这就象大喊大叫一样会令人不快,温柔地一个一个来。
|
||||
|
||||
弄懂主题!最典型的错误之一是在某种致立于跨平台可移植的语言、库或工具的论坛中提关于 Unix 或 Windows 操作系统程序接口的问题。如果你不明白为什么这是大错,最好在搞清楚概念前什么也别问。
|
||||
|
||||
@@ -216,7 +216,7 @@
|
||||
|
||||
本地的用户组织或者你所用的 Linux 发行版也许正在宣传新手取得帮助的论坛或 IRC 通道(在一些非英语国家,新手论坛很可能还是邮件列表),这些地方是开始提问的好去处,特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。经过宣传的 IRC 通道是公开邀请提问的地方,通常可以得到实时的回复。
|
||||
|
||||
事实上,如果出问题的程序来自某发行版(这很常见),最好先去该发行版的论坛或邮件列表中提问,再到程序本身的项目论坛或邮件列表,(否则)该项目的黑客可能仅仅回复“用 _我们的_ 代码”。
|
||||
事实上,如果出问题的程序来自某发行版(这很常见),最好先去该发行版的论坛或邮件列表中提问,再到程序本身的项目论坛或邮件列表,(否则)该项目的黑客可能仅仅回复『用 _我们的_ 代码』。
|
||||
|
||||
在任何论坛发贴以前,先看看有没有搜索功能。如果有,就试着用问题的几个关键词搜索一下,也许就有帮助。如果在此之前你已做过全面的网页搜索(你应该这样去做),还是再搜索一下论坛,搜索引擎有可能没来得及索引此论坛的全部内容。
|
||||
|
||||
@@ -231,10 +231,10 @@
|
||||
* 大多数邮件列表都要存档,那些存档将被搜索引擎索引,如果你向列表提问并得到解答,将来其它人可以通过网页搜索找到你的问题和答案,也就不用再次发问了。
|
||||
* 如果某些问题经常被问到,开发者可以利用此信息改进文档或软件本身,以使其更清楚。如果只是私下提问,就没有人能看到最常见问题的完整场景。
|
||||
|
||||
如果一个项目既有 “用户” 也有“开发者”(或 “黑客”)邮件列表或论坛,而你又不摆弄那些代码,向“用户”列表或论坛提问。不要假设自己会在开发者列表中受到欢迎,那些人多半会遭受你的噪音干扰。
|
||||
如果一个项目既有 『用户』 也有『开发者』(或 『黑客』)邮件列表或论坛,而你又不摆弄那些代码,向『用户』列表或论坛提问。不要假设自己会在开发者列表中受到欢迎,那些人多半会遭受你的噪音干扰。
|
||||
|
||||
然尔,如果你 _确信_ 你的问题不一般,而且在“用户” 列表或论坛中几天都没有回复,可以试试“开发者”列表或论坛。
|
||||
建议你在张贴前最好先暗暗地观察几天,至少看看最近几天保存的帖子,以了解那的行事方式(事实上这是参与任何私有或半私有列表的好主意)
|
||||
然尔,如果你 _确信_ 你的问题不一般,而且在『用户』 列表或论坛中几天都没有回复,可以试试『开发者』列表或论坛。
|
||||
建议你在张贴前最好先暗暗地观察几天,至少看看最近几天保存的帖子,以了解那的行事方式(事实上这是参与任何私有或半私有列表的好主意)
|
||||
|
||||
如果你找不到一个项目的邮件列表,而只能查到项目维护者的地址,只管向其发信。
|
||||
即便在这种情况下,也别假设(项目)邮件列表不存在。在你的电子邮件中陈述你已经试过但没有找到合适的邮件列表,也提及你不反对将自己的邮件转发给他人
|
||||
@@ -242,10 +242,10 @@
|
||||
|
||||
### 使用有意义且明确的主题
|
||||
|
||||
在邮件列表、新闻组或论坛中,主题是你在五十个或更少的字以内吸引有资格专家注意的黄金机会,不要用诸如 “请帮我” (更别提大写的 “请帮我!!!!”,这种主题的消息会被条件反射式地删掉)之类的唠叨浪费机会。
|
||||
在邮件列表、新闻组或论坛中,主题是你在五十个或更少的字以内吸引有资格专家注意的黄金机会,不要用诸如 『请帮我』 (更别提大写的 『请帮我!!!!』,这种主题的消息会被条件反射式地删掉)之类的唠叨浪费机会。
|
||||
不要用你痛苦的深度来打动我们,相反,要在这点空间中使用超级简明扼要的问题描述。
|
||||
|
||||
使用主题的好惯例是“对象 —— 偏差”(式的描述),许多技术支持组织就是这样做的。在“对象”部分指明是哪一个或哪一组东西有问题,在“偏差”部分则描述与期望的行为不一致的地方。
|
||||
使用主题的好惯例是『对象 —— 偏差』(式的描述),许多技术支持组织就是这样做的。在『对象』部分指明是哪一个或哪一组东西有问题,在『偏差』部分则描述与期望的行为不一致的地方。
|
||||
|
||||
**愚蠢:**
|
||||
|
||||
@@ -259,12 +259,12 @@
|
||||
|
||||
> 使用 MV1005 型号的某显卡芯片组在 X.org 6.8.1 的鼠标光标被扭曲
|
||||
|
||||
编写 “对象 —— 偏差”式描述的过程有助于你组织对问题的细致思考。是什么被影响了?仅仅是鼠标光标或者还有其它图形?
|
||||
编写 『对象 —— 偏差』式描述的过程有助于你组织对问题的细致思考。是什么被影响了?仅仅是鼠标光标或者还有其它图形?
|
||||
只在 X.org 中出现?或只是在其 6.8.1 版中?是针对某显卡芯片组?或者只是其中的 MV1005 型号?一个黑客只需描一眼就能够立即明白什么是你遇到的问题,什么是你自己的问题。
|
||||
|
||||
更一般地,想象一下在一个只显示主题的文档索引中查找。让你的主题更好地反映问题,可以使下一个搜索类似问题的人能够在文档中直接就找到答案的线索,而不用再次发贴提问。
|
||||
|
||||
如果你想在回复中提问,确保改变主题以表明你是在问一个问题,一个主题象 “Re: 测试” 或者 “Re: 新臭虫”的消息不太可能引起足够的注意。同时,将回复中与新主题不甚相关的引用内容尽量删除。
|
||||
如果你想在回复中提问,确保改变主题以表明你是在问一个问题,一个主题象 『Re: 测试』 或者 『Re: 新臭虫』的消息不太可能引起足够的注意。同时,将回复中与新主题不甚相关的引用内容尽量删除。
|
||||
|
||||
对于列表消息,不要直接点击回复(按钮)来开始一个全新的线索,这将限制你的观众。有些邮件阅读程序,比如 mutt,允许用户按线索排序并通过折叠线索来隐藏消息,这样做的人永远看不到你发的消息。
|
||||
|
||||
@@ -275,11 +275,11 @@
|
||||
|
||||
### 使问题容易回复
|
||||
|
||||
以“请向……回复”来结束问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦,我们也觉得花几秒钟考虑你的问题更麻烦。
|
||||
以『请向……回复』来结束问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦,我们也觉得花几秒钟考虑你的问题更麻烦。
|
||||
如果你的邮件客户端程序不支持这样做,[换个好点的](http://linuxmafia.com/faq/Mail/muas.html);如果是操作系统不支持所有这种邮件客户端程序,也换个好点的。
|
||||
|
||||
在论坛,要求通过电子邮件回复是完全无礼的,除非你确信回复的信息也许是敏感的(而且有人会为了某些未知的原因,只让你而不是整个论坛知道答案)。
|
||||
如果你只是想在有人回复线索时得到电子邮件提醒,可以要求论坛发送。几乎所有论坛都支持诸如“留意本线索”、“有回复发送邮件”等功能。
|
||||
如果你只是想在有人回复线索时得到电子邮件提醒,可以要求论坛发送。几乎所有论坛都支持诸如『留意本线索』、『有回复发送邮件』等功能。
|
||||
|
||||
### 用清晰、语法、拼写正确的语句书写
|
||||
|
||||
@@ -288,10 +288,10 @@
|
||||
清楚、良好地表达你的问题非常重要。如果你觉得这样做麻烦,我们也觉得注意(你的问题)麻烦。
|
||||
花点额外的精力斟酌一下字句,用不着太僵硬与正式 —— 事实上,黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它 _必须_ 很准确,而且有迹象表明你是在思考和关注问题。
|
||||
|
||||
正确地拼写、使用标点和大小写,不要将“its”混淆为“it's”,“loose”搞成“lose”或者将“discrete”弄成 “discreet”。不要全部用大写,这会被视为无礼的大声嚷嚷
|
||||
正确地拼写、使用标点和大小写,不要将『its』混淆为『it's』,『loose』搞成『lose』或者将『discrete』弄成 『discreet』。不要全部用大写,这会被视为无礼的大声嚷嚷
|
||||
(全部小写也好不到哪去,因为不易阅读。Alan Cox [注:著名黑客,Linux 内核的重要参与者] 也许可以这样做,但你不行。)
|
||||
|
||||
一般而言,如果你写得象个半文盲似的傻子,多半得不到理睬。也不要使用即时通讯中的简写,如将“you”简化为“u”会使你看起来象一个为了节约二次击键的半文盲式的傻子。
|
||||
一般而言,如果你写得象个半文盲似的傻子,多半得不到理睬。也不要使用即时通讯中的简写,如将『you』简化为『u』会使你看起来象一个为了节约二次击键的半文盲式的傻子。
|
||||
更糟的是,如果象个小孩似地鬼画桃符那绝对是在找死,可以肯定没人会理你(或者最多是给你一大堆指责与挖苦)。
|
||||
|
||||
如果在非母语论坛提问,你的拼写与语法错误会得到有限的宽容,但懒惰完全不会被容忍(是的,我们通常看得出其中的差别)。
|
||||
@@ -315,20 +315,20 @@
|
||||
* 不要发送整段只是单行句子但多次折回的邮件(这使得回复部分内容非常困难)。设想你的读者是在80个字符宽的文本终端阅读邮件,设置你的行折回点小于 80 列。
|
||||
* 但是,也 _不要_ 用任何固定列折回数据(譬如日志文件拷贝或会话记录)。数据应该原样包含,使回复者确信他们看到的是与你看到的一样的东西。
|
||||
* 在英语论坛中,不要使用'Quoted-Printable' MIME 编码发送消息。这种编码对于张贴非 ASCII 语言可能是必须的,但很多邮件程序并不支持。
|
||||
当它们分断时,那些文本中四处散布的 “=20”符号既难看也分散注意力,甚至有可能破坏内容的语意。
|
||||
当它们分断时,那些文本中四处散布的 『=20』符号既难看也分散注意力,甚至有可能破坏内容的语意。
|
||||
* _永远不要_ 指望黑客们阅读使用封闭的专用格式编写的文档,诸如微软公司的 Word 或 Excel 文件等。
|
||||
大多数黑客对此的反应就象有人将还在冒热气的猪粪倒在你门口时你的反应一样。即使他们能够处理,也很厌恶这么做。
|
||||
* 如果你从使用视窗的电脑发送电子邮件,关闭问题颇多的微软“聪明引用”功能(在“工具” -> “自动纠正选项”的“输入时自动格式化”下去掉聪明引用的选框),以免在你的邮件中到处散布垃圾字符。
|
||||
* 在论坛,勿滥用“表情符号”和“HTML”功能(当它们提供时)。一两个表情符号通常没有问题,但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来象个傻笑的小姑娘。
|
||||
* 如果你从使用视窗的电脑发送电子邮件,关闭问题颇多的微软『聪明引用』功能(在『工具』 -> 『自动纠正选项』的『输入时自动格式化』下去掉聪明引用的选框),以免在你的邮件中到处散布垃圾字符。
|
||||
* 在论坛,勿滥用『表情符号』和『HTML』功能(当它们提供时)。一两个表情符号通常没有问题,但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来象个傻笑的小姑娘。
|
||||
这通常不是个好主意,除非你只是对性而不是有用的回复更有兴趣。
|
||||
|
||||
如果你使用图形用户界面的邮件客户端程序(如网景公司的 Messenger、微软公司的 Outlook 或者其它类似的),注意它们的缺省配置不一定满足这些要求。
|
||||
大多数这类程序有基于菜单的“查看源码”命令,用它来检查发送文件夹中的消息,以确保发送的是没有多余杂质的纯文本文件。
|
||||
大多数这类程序有基于菜单的『查看源码』命令,用它来检查发送文件夹中的消息,以确保发送的是没有多余杂质的纯文本文件。
|
||||
|
||||
### 描述问题应准确且有内容
|
||||
|
||||
* 仔细、清楚地描述问题的症状
|
||||
* 描述问题发生的环境(主机、操作系统、应用程序,任何相关的),提供销售商的发行版和版本号(如:“Fedora Core 7”、“Slackware 9.1”等)
|
||||
* 描述问题发生的环境(主机、操作系统、应用程序,任何相关的),提供销售商的发行版和版本号(如:『Fedora Core 7』、『Slackware 9.1』等)
|
||||
* 描述提问前做过的研究及其理解。
|
||||
* 描述提问前为确定问题而采取的诊断步骤。
|
||||
* 描述最近对计算机或软件配置的任何相关改变。
|
||||
@@ -351,13 +351,13 @@
|
||||
|
||||
当你在一个软件中遇到问题,除非你 _非常、非常_ 的有根据,不要动辄声称找到了臭虫。
|
||||
提示:除非你能提供解决问题的源代码补丁,或者对前一版本的回归测试表现出不正确的行为,否则你都多半不够完全确信。
|
||||
对于网页和文档也如此,如果你(声称)发现了文档的“臭虫”,你应该能提供相应位置的替代文本。
|
||||
对于网页和文档也如此,如果你(声称)发现了文档的『臭虫』,你应该能提供相应位置的替代文本。
|
||||
|
||||
记住,还有许多其它用户并未经历你遇到的问题,否则你在阅读文档或搜索网页时就应该发现了(你在报怨前已经做了这些,[是吧](#提问前) ?)。
|
||||
这也意味着很有可能是你弄错了而不是软件本身有问题。
|
||||
|
||||
编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了臭虫,也就置疑了他们的能力,即使你是对的,也有可能会使其中的部分人感到不快。
|
||||
(此外,)在主题中嚷嚷“臭虫”也是特别不老练的。
|
||||
(此外,)在主题中嚷嚷『臭虫』也是特别不老练的。
|
||||
|
||||
提问时,即使你私下非常确信已经发现一个真正的臭虫,最好写得象是 _你_ 做错了什么。如果真的有臭虫,你会在回复中看到这点。
|
||||
这样做的话,如果真有虫子,维护者就会向你道歉,这总比你弄砸了然后欠别人一个道歉要强。
|
||||
@@ -365,7 +365,7 @@
|
||||
### 低声下气代替不了做自己的家庭作业
|
||||
|
||||
有些人明白他们不应该粗鲁或傲慢地行事并要求得到答复,但他们退到相反的低声下气的极端:
|
||||
“我知道我只是个可怜的新丁,一个失败者,但……”。这既使人困扰,也没有用,当伴随着对实际问题含糊的描述时还特别令人反感。
|
||||
『我知道我只是个可怜的新丁,一个失败者,但……』。这既使人困扰,也没有用,当伴随着对实际问题含糊的描述时还特别令人反感。
|
||||
|
||||
别用低级灵长类动物的办法浪费你我的时间,相反,尽可能清楚地描述背景情况和你的问题,这比低声下气更好地摆正了你的位置。
|
||||
|
||||
@@ -385,9 +385,9 @@
|
||||
> 我组装的电脑(K6/233 CPU、FIC-PA2007 主板[威盛 Apollo VP2 芯片组]、Corsair PC133 SDRAM 256Mb 内存)最近在开机 20 分钟左右、做内核编译时频繁地报 SIG11 错,但在头 20 分钟内从不出问题。
|
||||
> 重启动不会复位时钟,但整夜关机会。更换所有内存未解决问题,相关的典型编译会话日志附后。
|
||||
|
||||
由于以上这点许多人似乎难以掌握,这里有句话可以提醒你:“所有的诊断专家都来自密苏里州”。
|
||||
美国国务院的官方座右铭则是“让我看看”(出自国会议员威勒德.D.范迪弗[Willard D. Vandiver]在1899年时的讲话:
|
||||
“我来自一个出产玉米、棉花、牛蒡和民主党人的国家,滔滔雄辩既不能说服我,也不会让我满意。我来自密苏里州,你必须让我看看。”)
|
||||
由于以上这点许多人似乎难以掌握,这里有句话可以提醒你:『所有的诊断专家都来自密苏里州』。
|
||||
美国国务院的官方座右铭则是『让我看看』(出自国会议员威勒德.D.范迪弗[Willard D. Vandiver]在1899年时的讲话:
|
||||
『我来自一个出产玉米、棉花、牛蒡和民主党人的国家,滔滔雄辩既不能说服我,也不会让我满意。我来自密苏里州,你必须让我看看。』)
|
||||
针对诊断者而言,这并不是怀疑,而只是一种真实而有用的需求,以便让他们看到与你看到的原始证据尽可能一致的东西,而不是你的猜测与总结。(所以,)让我们看看。
|
||||
|
||||
### 按时间先后罗列问题症状
|
||||
@@ -396,7 +396,7 @@
|
||||
在命令行处理的情况下,有会话日志(如运行脚本工具生成的)并引用相关的若干(如20)行记录会非常有帮助。
|
||||
|
||||
如果崩溃的程序有诊断选项(如-v详述开关),试着选择这些能在记录中增加排错信息的选项。
|
||||
记住,“多”不等于“好”。试着选取适当的排错级别以便提供有用的信息而不是将阅读者淹没在垃圾中。
|
||||
记住,『多』不等于『好』。试着选取适当的排错级别以便提供有用的信息而不是将阅读者淹没在垃圾中。
|
||||
|
||||
如果你的记录很长(如超过四段),在开头简述问题随后按时间先后罗列详细过程也许更有用。这样,黑客在读你的记录时就知道该注意哪些内容了。
|
||||
|
||||
@@ -422,7 +422,7 @@
|
||||
|
||||
当你要求私下回复时,此过程和回报都被中止。别这样做,让 _回复者_ 来决定是否私下回答 —— 如果他真这么做了,通常是因为他认为问题编写太差或者太肤浅,以至于对其它人毫无意义。
|
||||
|
||||
对这条规则存在一条有限的例外,如果你确信提问可能会引来大量雷同的回复时,那么“向我发电邮,我将为论坛归纳这些回复”将是神奇的句子。
|
||||
对这条规则存在一条有限的例外,如果你确信提问可能会引来大量雷同的回复时,那么『向我发电邮,我将为论坛归纳这些回复』将是神奇的句子。
|
||||
试着将邮件列表或新闻组从洪水般雷同的回复中解救出来是非常有礼貌的 —— 但你必须信守诺言。
|
||||
|
||||
### 提问应明确
|
||||
@@ -436,12 +436,12 @@
|
||||
要想理解专家生活的世界,可以这样设想:那里有丰富的专长资源但稀缺的响应时间。你暗中要求他们奉献的时间越少,你越有可能从这些真正懂行也真正很忙的专家那里得到解答。
|
||||
|
||||
所以限定你的问题以使专家回答时需要付出的时间最少 —— 这通常与简化问题还不太一样。
|
||||
举个例,“请问可否指点一下哪有好一点的 X 解释?”通常要比“请解释一下 X”明智。如果你的代码不运行了,通常请别人看看哪有问题比叫他们帮你改正更明智。
|
||||
举个例,『请问可否指点一下哪有好一点的 X 解释?』通常要比『请解释一下 X』明智。如果你的代码不运行了,通常请别人看看哪有问题比叫他们帮你改正更明智。
|
||||
|
||||
### 关于代码的问题
|
||||
|
||||
别要求他人给你出问题的代码排错而不提及应该从何入手。张贴几百行的代码,然后说一声“它不能运行”会让你得不到理睬。
|
||||
只贴几十行代码,然后说一句“在第七行以后,本应该显示<x>,但实际出现的是<y>”非常有可能让你得到回复。
|
||||
别要求他人给你出问题的代码排错而不提及应该从何入手。张贴几百行的代码,然后说一声『它不能运行』会让你得不到理睬。
|
||||
只贴几十行代码,然后说一句『在第七行以后,本应该显示<x>,但实际出现的是<y>』非常有可能让你得到回复。
|
||||
|
||||
最精确描述代码问题的方法是提供一个能展示问题的最小测试样例。什么是最小测试样例?
|
||||
它是对问题的展现,只需要刚好能够重现非预期行为的代码即可。如何生成一个最小测试样例?
|
||||
@@ -455,50 +455,50 @@
|
||||
|
||||
### 别张贴家庭作业式问题
|
||||
|
||||
黑客们善于发现“家庭作业”式的问题。我们中的大多数人已经做了自己的家庭作业,那是该 _你_ 做的,以便从中学到东西。问一下提示没有关系,但不是要求完整的解决方案。
|
||||
黑客们善于发现『家庭作业』式的问题。我们中的大多数人已经做了自己的家庭作业,那是该 _你_ 做的,以便从中学到东西。问一下提示没有关系,但不是要求完整的解决方案。
|
||||
|
||||
如果你怀疑自己碰到了一个家庭作业式的问题,但仍然无法解决,试试在用户组、论坛或(作为最后一招)在项目的“用户”邮件列表或论坛中提问。尽管黑客们 _会_ 看出来,一些老用户也许仍会给你提示。
|
||||
如果你怀疑自己碰到了一个家庭作业式的问题,但仍然无法解决,试试在用户组、论坛或(作为最后一招)在项目的『用户』邮件列表或论坛中提问。尽管黑客们 _会_ 看出来,一些老用户也许仍会给你提示。
|
||||
|
||||
### 删除无意义的要求
|
||||
|
||||
|
||||
抵制这种诱惑,即在求助消息末尾加上诸如“有人能帮我吗?”或“有没有答案?”之类在语义上毫无意义的东西。
|
||||
第一,如果问题描述还不完整,这些附加的东西最多也只能是多余的。第二,因为它们是多余的,黑客们会认为这些东西烦人 —— 就很有可能用逻辑上无误但打发人的回复,诸如“是的,你可以得到帮助”和“不,没有给你的帮助”。
|
||||
抵制这种诱惑,即在求助消息末尾加上诸如『有人能帮我吗?』或『有没有答案?』之类在语义上毫无意义的东西。
|
||||
第一,如果问题描述还不完整,这些附加的东西最多也只能是多余的。第二,因为它们是多余的,黑客们会认为这些东西烦人 —— 就很有可能用逻辑上无误但打发人的回复,诸如『是的,你可以得到帮助』和『不,没有给你的帮助』。
|
||||
|
||||
一般来说,避免提“是或否”类型的问题,除非你想得到 “[是或否”类型的回答](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/questions-with-yes-or-no-answers.html)。
|
||||
一般来说,避免提『是或否』类型的问题,除非你想得到 『[是或否』类型的回答](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/questions-with-yes-or-no-answers.html)。
|
||||
|
||||
### 不要把问题标记为“紧急”,即使对你而言的确如此
|
||||
### 不要把问题标记为『紧急』,即使对你而言的确如此
|
||||
|
||||
这是你的问题,不要我们的。宣称“紧急”极有可能事与愿违:
|
||||
大多数黑客会直接删除这种消息,他们认为这是无礼和自私地企图得到即时与特殊的关照。而且“紧急”或其它有类似含义的主题有可能触发垃圾过滤规则,潜在的回复者可能永远看不到你的问题!
|
||||
这是你的问题,不要我们的。宣称『紧急』极有可能事与愿违:
|
||||
大多数黑客会直接删除这种消息,他们认为这是无礼和自私地企图得到即时与特殊的关照。而且『紧急』或其它有类似含义的主题有可能触发垃圾过滤规则,潜在的回复者可能永远看不到你的问题!
|
||||
|
||||
有一点点局部的例外,如果你是在一些知名度很高、会使黑客们激动的地方使用程序,也许值得这样去做。在这种情况下,如果你有期限压力,也很有礼貌地提到这点,人们也许会有足够的兴趣快一点回答。
|
||||
|
||||
当然,这是非常冒险的,因为黑客们对什么是令人激动的标准多半与你的不同。
|
||||
譬如从国际空间站这样张贴没有问题,但代表感觉良好的慈善或政治原因这样做几乎肯定不行。事实上,张贴诸如“紧急:帮我救救这个毛绒绒的小海豹!”肯定会被黑客回避或光火,即使他们认为毛绒绒的小海豹很重要。
|
||||
譬如从国际空间站这样张贴没有问题,但代表感觉良好的慈善或政治原因这样做几乎肯定不行。事实上,张贴诸如『紧急:帮我救救这个毛绒绒的小海豹!』肯定会被黑客回避或光火,即使他们认为毛绒绒的小海豹很重要。
|
||||
|
||||
如果你觉得这不可思议,再把剩下的内容多读几遍,直到弄懂了再发贴也不迟。
|
||||
|
||||
### 礼貌总是有益的
|
||||
|
||||
礼貌一点,使用“请”和“谢谢你的关注”或者“谢谢你的关照”,让别人明白你感谢他们无偿花时间帮助你。
|
||||
礼貌一点,使用『请』和『谢谢你的关注』或者『谢谢你的关照』,让别人明白你感谢他们无偿花时间帮助你。
|
||||
|
||||
坦率地讲,这一点没有语法正确、文字清晰、准确、有内容和避免使用专用格式重要(同时也不能替代它们)。
|
||||
黑客们一般宁可读有点唐突但技术鲜明的臭虫报告,而不是那种有礼但含糊的报告。(如果这点让你不解,记住我们是按问题能教我们什么来评价它的)
|
||||
|
||||
然尔,如果你已经谈清楚了技术问题,客气一点肯定会增加你得到有用回复的机会。
|
||||
|
||||
(我们必须指出,本文唯一受到一些老黑客认真反对的地方是以前曾经推荐过的“提前谢了”,一些黑客认为这隐含着事后不用再感谢任何人的暗示。
|
||||
我们的建议是要么先说 “提前谢了”,事后 _再_ 对回复者表示感谢,要么换种方式表达,譬如用“谢谢你的关注”或“谢谢你的关照”)。
|
||||
(我们必须指出,本文唯一受到一些老黑客认真反对的地方是以前曾经推荐过的『提前谢了』,一些黑客认为这隐含着事后不用再感谢任何人的暗示。
|
||||
我们的建议是要么先说 『提前谢了』,事后 _再_ 对回复者表示感谢,要么换种方式表达,譬如用『谢谢你的关注』或『谢谢你的关照』)。
|
||||
|
||||
### 问题解决后追加一条简要说明
|
||||
|
||||
问题解决后向所有帮助过的人追加一条消息,让他们知道问题是如何解决的并再次感谢。如果问题在邮件列表或新闻组中受到广泛关注,在那里追加此消息比较恰当。
|
||||
|
||||
最理想的方式是向最初提问的线索回复此消息,并在主题中包含“已解决”、“已搞定”或其它同等含义的明显标记。
|
||||
在人来人往的邮件列表里,一个看见线索 “问题 X”和“问题 X-已解决”的潜在回复者就明白不用再浪费时间了(除非他个人觉得“问题 X”有趣),因此可以利用此时间去解决其它问题。
|
||||
最理想的方式是向最初提问的线索回复此消息,并在主题中包含『已解决』、『已搞定』或其它同等含义的明显标记。
|
||||
在人来人往的邮件列表里,一个看见线索 『问题 X』和『问题 X - 已解决』的潜在回复者就明白不用再浪费时间了(除非他个人觉得『问题 X』有趣),因此可以利用此时间去解决其它问题。
|
||||
|
||||
追加的消息用不着太长或太复杂,一句简单的“你好 —— 是网线坏了!谢谢大家 —— 比尔”就比什么都没有要强。
|
||||
追加的消息用不着太长或太复杂,一句简单的『你好 —— 是网线坏了!谢谢大家 —— 比尔』就比什么都没有要强。
|
||||
事实上,除非解决问题的技术真正高深,一条简短而亲切的总结比长篇大论要好。说明是什么行动解决了问题,用不着重演整个排错的故事。
|
||||
|
||||
对于有深度的问题,张贴排错历史的摘要是恰当的。描述问题的最终状态,说明是什么解决了问题,_在此之后_ 才指明可以避免的弯路。
|
||||
@@ -507,19 +507,20 @@
|
||||
除了有礼貌、有内容以外,这种类型的追帖将帮助其他人在邮件列表、新闻组或论坛文档中搜索到真正解决你问题的方案,从而也让他们受益。
|
||||
|
||||
最后,此类追帖还让每位参与协助的人因问题的解决而产生一种满足感。如果你自己不是技术专家或黑客,相信我们,这种感觉对于你寻求帮助的老手和专家是非常重要的。
|
||||
问题叙述到最后不知所终总是令人沮丧的,黑客们痒痒地渴望它们被解决。“挠痒痒”为你挣到的信誉将对你下次再次张贴提问非常非常的有帮助。
|
||||
问题叙述到最后不知所终总是令人沮丧的,黑客们痒痒地渴望它们被解决。『挠痒痒』为你挣到的信誉将对你下次再次张贴提问非常非常的有帮助。
|
||||
|
||||
考虑一下怎样才能避免他人将来也遇到类似的问题,问问自己编一份文档或 FAQ 补丁会不会有帮助,如果是的话就将补丁发给维护者。
|
||||
|
||||
在黑客中,这种良好的后继行动实际上比传统的礼貌更重要,也是你善待他人而赢得声誉的方式,这是非常有价值的财富。
|
||||
|
||||
## 如何解读回答
|
||||
如何解读回答
|
||||
-----------------------
|
||||
|
||||
### “读读该死的手册”(RTFM)和“搜搜该死的网络”(STFW):如何明白你已完全搞砸
|
||||
### 『读读该死的手册』(RTFM)和『搜搜该死的网络』(STFW):如何明白你已完全搞砸
|
||||
|
||||
有一个古老而神圣的传统:如果你收到“读读该死的手册”(RTFM) 的回复,发信人认为你应该去“读读该死的手册”。他或她多半是对的,去读一下吧。
|
||||
有一个古老而神圣的传统:如果你收到『读读该死的手册』(RTFM) 的回复,发信人认为你应该去『读读该死的手册』。他或她多半是对的,去读一下吧。
|
||||
|
||||
“读读该死的手册”(RTFM)有个年轻一点的亲戚,如果你收到“搜搜该死的网络”(STFW)的回复,发信人认为你应该“搜搜该死的网络”。那人多半也是对的,去搜一下吧。(更温和一点的说法是“谷歌是你的朋友!”)
|
||||
『读读该死的手册』(RTFM)有个年轻一点的亲戚,如果你收到『搜搜该死的网络』(STFW)的回复,发信人认为你应该『搜搜该死的网络』。那人多半也是对的,去搜一下吧。(更温和一点的说法是『谷歌是你的朋友!』)
|
||||
|
||||
在论坛,你也可能被要求去搜索论坛的文档。事实上,有人甚至可能热心地为你提供以前解决此问题的线索。但不要依赖这种关照,提问前应该先搜索一下文档。
|
||||
|
||||
@@ -531,8 +532,8 @@
|
||||
|
||||
如果你看不懂回答,不要马上回复一个要求说明的消息,先试试那些最初提问时用过的相同工具(如手册、FAQ、网页、懂行的朋友等)试着搞懂回答。如果还是需要说明,展现你已经明白的。
|
||||
|
||||
譬如,假如我告诉你:“看起来象是某输入项有问题,你需要清除它”,接着是个 _不好_ 的回帖:“什么是某输入项?”。
|
||||
而这是一个 _很好_ 的跟帖:“是的,我读了手册,某某输入项只在 -z 和 -p 开关中被提到,但都没有涉及到如何清除它们,你指的是哪一个还是我弄错了什么?”
|
||||
譬如,假如我告诉你:『看起来象是某输入项有问题,你需要清除它』,接着是个 _不好_ 的回帖:『什么是某输入项?』。
|
||||
而这是一个 _很好_ 的跟帖:『是的,我读了手册,某某输入项只在 -z 和 -p 开关中被提到,但都没有涉及到如何清除它们,你指的是哪一个还是我弄错了什么?』
|
||||
|
||||
### 对待无礼
|
||||
|
||||
@@ -544,12 +545,13 @@
|
||||
另一方面,你会偶而真的碰到无礼和无聊的言行。与上述相反,对真正的冒犯者狠狠地打击、用犀利的语言将其驳得体无完肤都是可以接受的。
|
||||
然尔,在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔,黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外来者,避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光,这时最好不要把手放在键盘上以免冒险。
|
||||
|
||||
(有些人断言很多黑客都有轻度的自闭症或阿斯伯格综合症,缺少用于润滑人类社会“正常”交往所需的脑电路。这既可能是真也可能是假。
|
||||
(有些人断言很多黑客都有轻度的自闭症或阿斯伯格综合症,缺少用于润滑人类社会『正常』交往所需的脑电路。这既可能是真也可能是假。
|
||||
如果你自己不是黑客,兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了,我们不在乎。我们 _喜欢_ 现在这个样子,并且一般都对病号标记有站得住脚的怀疑。)
|
||||
|
||||
在下一节,我们会谈到另一个问题,当 _你_ 行为不当时会受到的“冒犯”。
|
||||
在下一节,我们会谈到另一个问题,当 _你_ 行为不当时会受到的『冒犯』。
|
||||
|
||||
## 别象失败者那样反应
|
||||
别象失败者那样反应
|
||||
------------------------
|
||||
|
||||
在黑客社区的论坛中有那么几次你可能会搞砸 —— 以本文描述或类似的方式。你会被示众是如何搞砸的,也许言语中还会带点颜色。
|
||||
|
||||
@@ -560,10 +562,10 @@
|
||||
社区的标准不会自己维持,它们是通过参与者积极而 _公开_ 地执行来维持的。
|
||||
不要哭嚎所有的批评都应该通过私下的邮件传送,这不是事情运作的方式。当有人评论你的一个说法有误或者提出不同看法时,坚持声称受到个人攻击也毫无益处,这些都是失败者的态度。
|
||||
|
||||
也有其它的黑客论坛,受过高礼节要求的误导,禁止参与者张贴任何对别人帖子挑毛病的消息,并声称“如果你不想帮助用户就闭嘴”。
|
||||
也有其它的黑客论坛,受过高礼节要求的误导,禁止参与者张贴任何对别人帖子挑毛病的消息,并声称『如果你不想帮助用户就闭嘴』。
|
||||
有思路的参与者纷纷离开的结果只会使它们变成了毫无意义的唠叨与无用的技术论坛。
|
||||
|
||||
是夸张的“友谊”(以上述方式)还是有用?挑一个。
|
||||
是夸张的『友谊』(以上述方式)还是有用?挑一个。
|
||||
|
||||
记着:当黑客说你搞砸了,并且(无论多么刺耳地)告诉你别再这样做时,他正在为关心你和他的社区而行动。
|
||||
对他而言,不理你并将你从他的生活中滤除要容易得多。如果你无法做到感谢,至少要有点尊严,别大声哀嚎,也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者,就指望别人象对待脆弱的洋娃娃那样对你。
|
||||
@@ -574,8 +576,8 @@
|
||||
|
||||
也别让自己卷入口水战,大多数口水战最好不要理睬 —— 当然,是在你核实它们只是口水战、没有指出你搞砸的地方,而且没有巧妙地将问题真正的答案藏于其中之后(这也是可能的)。
|
||||
|
||||
## 提问禁忌
|
||||
|
||||
提问禁忌
|
||||
------------------------
|
||||
|
||||
下面是些典型的愚蠢问题和黑客不回答它们时的想法。
|
||||
|
||||
@@ -605,7 +607,7 @@
|
||||
**问:**
|
||||
如何配置我的 shell 提示?
|
||||
**答:**
|
||||
如果你有足够的智慧提这个问题,你也该有足够的智慧去 [“读读该死的手册”(RTFM)](#读读该死的手册rtfm和搜搜该死的网络stfw如何明白你已完全搞砸),然后自己去找出来。
|
||||
如果你有足够的智慧提这个问题,你也该有足够的智慧去 [『读读该死的手册』(RTFM)](#读读该死的手册rtfm和搜搜该死的网络stfw如何明白你已完全搞砸),然后自己去找出来。
|
||||
|
||||
<a id="id265994">
|
||||
**问:**
|
||||
@@ -618,9 +620,9 @@
|
||||
我的{程序、配置、SQL 语句}不运行了
|
||||
**答:**
|
||||
这不是一个问题,我也没有兴趣去猜你有什么问题 —— 我有更要紧的事要做。看到这种东西,我的反应一般如下:
|
||||
* 你还有什么补充吗?
|
||||
* 噢,太糟了,希望你能搞定。
|
||||
* 这跟我究竟有什么关系?
|
||||
* 你还有什么补充吗?
|
||||
* 噢,太糟了,希望你能搞定。
|
||||
* 这跟我究竟有什么关系?
|
||||
|
||||
<a id="id266052">
|
||||
**问:**
|
||||
@@ -643,7 +645,7 @@
|
||||
**答:**
|
||||
不行,我需要亲手操作你的电脑才能帮你排错,去向当地的 Linux 用户组寻求方便的帮助(你可以在 [这里](http://www.linux.org/groups/index.html) 找到用户组列表)
|
||||
注意:如果安装问题与某 Linux 发行版有关,在针对 _它_ 的邮件列表、论坛或本地用户组织中提问也许是恰当的。
|
||||
此时,应描述问题的准确细节。在此之前,先用 “linux”和 _所有_ 被怀疑的硬件 [作关键词] 仔细搜索。
|
||||
此时,应描述问题的准确细节。在此之前,先用 『linux』和 _所有_ 被怀疑的硬件 [作关键词] 仔细搜索。
|
||||
|
||||
<a id="id266136"></a>
|
||||
**问:**
|
||||
@@ -651,14 +653,15 @@
|
||||
**答:**
|
||||
想做这种事情说明你是个卑劣的家伙,想让黑客教你做这种事情说明你是个白痴。
|
||||
|
||||
## 好问题与坏问题
|
||||
好问题与坏问题
|
||||
------------------------
|
||||
|
||||
最后,我将通过举例来演示提问的智慧。同样的问题两种提法,一种愚蠢,另一种明智。
|
||||
|
||||
**愚蠢:** 我在哪能找到关于 Foonly Flurbamatic 设备的东西?
|
||||
这个问题在乞求得到 [“搜搜该死的网络”(STFW)](#rtfm "RTFM and STFW: How To Tell You've Seriously Screwed Up") 式的回复。
|
||||
这个问题在乞求得到 [『搜搜该死的网络』(STFW)](#rtfm "RTFM and STFW: How To Tell You've Seriously Screwed Up") 式的回复。
|
||||
|
||||
**明智:** 我用谷歌搜索过“Foonly Flurbamatic 2600”,但没有找到什么有用的,有谁知道在哪能找到这种设备的编程信息?
|
||||
**明智:** 我用谷歌搜索过『Foonly Flurbamatic 2600』,但没有找到什么有用的,有谁知道在哪能找到这种设备的编程信息?
|
||||
这个人已经搜索过网络了,而且听起来他可能真的遇到了问题。
|
||||
|
||||
**愚蠢:** 我不能编译某项目的源代码,它为什么这么破?
|
||||
@@ -668,13 +671,13 @@
|
||||
提问者已经指明了运行环境,读了常见问题文档(FAQ),列出了错误,也没有假设问题是别人的过错,这家伙值得注意。
|
||||
|
||||
**愚蠢:** 我的主板有问题,谁能帮我?
|
||||
某黑客对此的反应可能是:“是的,还需要帮你拍背和换尿布吗?”,然后是敲下删除键。
|
||||
某黑客对此的反应可能是:『是的,还需要帮你拍背和换尿布吗?』,然后是敲下删除键。
|
||||
|
||||
**明智:** 我在 S2464 主板上试过 X、Y 和 Z,当它们都失败后,又试了 A、B 和 C。注意我试 C 时的奇怪症状,显然某某东西正在做某某事情,这不是期望的行为。
|
||||
通常在 Athlon MP 主板上导致某某事情的原因是什么?有谁知道我还能再试点什么以确定问题?
|
||||
相反地,这个人看来值得回答。他或她展现了解决问题的能力而不是坐等天上掉馅饼。
|
||||
|
||||
在最后那个问题中,注意“给我一个回答”与“请帮我看看我还能再做点什么测试以得到启发”之间细微但重要的差别。
|
||||
在最后那个问题中,注意『给我一个回答』与『请帮我看看我还能再做点什么测试以得到启发』之间细微但重要的差别。
|
||||
|
||||
事实上,最后那个问题基本上源于 2001 年 8 月 Linux 内核邮件列表(lkml)上的真实事件,是我(Eric)当时提了那个问题,我发现 Tyan S2462 主板有神秘的死机现象,邮件列表成员给我提供了解决此问题的关键信息。
|
||||
|
||||
@@ -686,7 +689,8 @@
|
||||
黑客们在某种方面是非常不留情面的精英分子。我想在这事上他是对的,如果我 _表现得_ 象个不劳而获的寄生虫,不管我是谁都会被忽略或斥责。
|
||||
他建议将整个事件作为对其它人提问的指导,这直接导致了本文的编写。
|
||||
|
||||
## 如果得不到回答
|
||||
如果得不到回答
|
||||
------------------------
|
||||
|
||||
如果得不到回答,请不要认为我们不想帮你,有时只是因为被问到的小组成员的确不知道答案。
|
||||
没有回复不等于不被理睬,当然必须承认从外面很难看出两者的差别。
|
||||
@@ -705,7 +709,8 @@
|
||||
象 Linux 这样流行的软件,每个开发者至少有一万个以上的用户,一个人不可能应付这么多用户的服务要求。
|
||||
记住,即使你必须付费才能得到支持,也比你还得额外花钱买软件要少得多(而且对封闭源代码软件的服务支持与开源软件相比通常还要贵一点,也要差一点)。
|
||||
|
||||
## 如何更好地回答
|
||||
如何更好地回答
|
||||
------------------------
|
||||
|
||||
_态度和善一点。_问题带来的压力常使人显得无礼或愚蠢,其实并不是这样。
|
||||
|
||||
@@ -717,23 +722,25 @@ _如果帮不了忙,别妨碍。_ 不要在具体步骤上开玩笑,那样
|
||||
|
||||
_探索性的反问以引出更多的细节。_ 如果你做得好,提问者可以学到点东西 —— 你也可以。试试将很差的问题转变成好问题,别忘了我们都曾是新手。
|
||||
|
||||
尽管对那些懒虫报怨一声“读读该死的手册”(RTFM)是正当的,指出文档的位置(即使只是建议做个谷歌关键词搜索)会更好
|
||||
尽管对那些懒虫报怨一声『读读该死的手册』(RTFM)是正当的,指出文档的位置(即使只是建议做个谷歌关键词搜索)会更好
|
||||
|
||||
_如果你决意回答,给出好的答案。_ 当别人正在用错误的工具或方法时别建议笨拙的权宜之计,应推荐更好的工具,重新组织问题。
|
||||
|
||||
请回答真正的问题!如果提问者已经做了自己该做的研究,并且说明尝试过X,Y,Z,A,B与C都没有得到想要的結果,
|
||||
那么回复“试试A或B” 或者给出一个内容为 “试一下X,Y,Z,A,B或C”的链接将极其无益!
|
||||
那么回复『试试A或B』 或者给出一个内容为 『试一下X,Y,Z,A,B或C』的链接将极其无益!
|
||||
|
||||
_帮助你的社区从中学习_。当回复一个好问题时,问问自己 “如何修改相关文件或 FAQ 文档以免再次解答同样的问题?”,接着再向文档维护者发一份补丁。
|
||||
_帮助你的社区从中学习_。当回复一个好问题时,问问自己 『如何修改相关文件或 FAQ 文档以免再次解答同样的问题?』,接着再向文档维护者发一份补丁。
|
||||
|
||||
如果你是在研究一番后才做出的回答,_展现你的技巧而不是直接端出结果_。毕竟“授人以鱼,不如授人以渔”。
|
||||
如果你是在研究一番后才做出的回答,_展现你的技巧而不是直接端出结果_。毕竟『授人以鱼,不如授人以渔』。
|
||||
|
||||
## 相关资源
|
||||
相关资源
|
||||
------------------------
|
||||
|
||||
如果需要个人电脑、Unix 和互联网如何工作的基础知识,参阅 [Unix 和互联网工作的基本原理](http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/)。
|
||||
|
||||
当你发布软件或补丁时,试着按 [软件发布实践](http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html) 操作。
|
||||
|
||||
## 鸣谢
|
||||
鸣谢
|
||||
------------------------
|
||||
|
||||
伊夫林.米切尔(Evelyn Mitchell)贡献了一些愚蠢问题例子并启发了编写“如何更好地回答问题”这一节,米哈伊尔.罗门迪克(Mikhail Ramendik)贡献了一些特别有价值的建议和改进。
|
||||
伊夫林.米切尔(Evelyn Mitchell)贡献了一些愚蠢问题例子并启发了编写『如何更好地回答问题』这一节,米哈伊尔.罗门迪克(Mikhail Ramendik)贡献了一些特别有价值的建议和改进。
|
||||
|
||||
Reference in New Issue
Block a user