提問的智慧

原文出處： Eric S. Raymond   譯文出處： 王剛   

引言

在黑客的世界裏，你所提技術問題的解答很大程度上取決於你提問的方式與解決此問題的難度，本文將教你如何提問才更有可能獲得滿意的答覆。

開源程序的應用已經很廣，你一般能夠從其餘更有經驗的用戶而不是黑客那裏獲得解答。

這是好事，他們通常對新手常有的毛病更容忍一點。然而，使用咱們推薦的方法，象對待黑客那樣對待這些有經驗的用戶，一般能最有效地獲得問題的解答。

第一件須要明白的事是黑客喜歡難題和激發思考的好問題。假如不是這樣，咱們也不會寫本文了。若是你能提出一個有趣的問題讓咱們咀嚼玩味，咱們會感激你。好問題是種激勵與禮物，幫助咱們發展認知，揭示沒有注意或想到的問題。在黑客中，「好問題！」 是很是熱烈而真摯的讚許。

此外，黑客還有遇到簡單問題就表現出敵視或傲慢的名聲。有時，咱們看起來還對新手和愚蠢的傢伙有條件反射式的無禮，但事情並不真是這樣。

咱們只是毫無歉意地敵視那些提問前不肯思考、不作本身家庭做業的人。這種人就象時間無底洞──他們只知道索取，不肯意付出，他們浪費了時間，這些時 間本可用於其它更有趣的問題或更值得回答的人。咱們將這種人叫作 「失敗者（loser）」 （因爲歷史緣由，咱們有時將「loser」拼寫爲「lusers」 。）

咱們意識到許多人只是想使用咱們寫的軟件，他們對學習技術細節沒有興趣。對大多數人而言，計算機只是種工具，是種達到目的的手段而已。他們有本身的 生活而且有更要緊的事要作，咱們認可這點，也從不期望每一個人都對這些讓咱們着迷的技術問題感興趣。不過，咱們回答問題的風格是爲了適應那些真正對此有興趣並願意主動參與解決問題的人，這一點不會變，也不應變。若是連這都變了，咱們就會在本身能作得最好的事情上再也不那麼犀利。

咱們（大多數）是自願者， 從本身繁忙的生活中抽時間來回答問題，有時會力不從心。所以，咱們會絕不留情地濾除問題，特別是那些看起來象是失敗者提的，以便更有效地把回答問題的時間留給那些勝利者。

若是你認爲這種態度使人反感、以施惠者自居或傲慢自大，請檢查你的假設，咱們並未要求你屈服──事實上，假如你作了該作的努力，咱們中的大多數將非 常樂意平等地與你交流，並歡迎你接納咱們的文化。試圖去幫助那些不肯自救的人對咱們簡直沒有效率。不懂沒有關係，但愚蠢地作事不行。

因此，你沒必要在技術上很在行才能吸引咱們的注意，但你 必須 表現出能引導你在行的姿態──機 敏、有想法、善於觀察、樂於主動參與問題的解決。若是你作不到這些使你不同凡響的事情，咱們建議你付錢跟別人籤商業服務合同，而不是要求黑客無償幫助。

若是你決定向咱們求助，你不會想成爲一名失敗者，你也不想被當作一個失敗者。獲得快速有效回答的最好方法是使提問者看起來象個聰明、自信和有想法的人，而且暗示只是碰巧在某一特別問題上須要幫助。

（歡迎對本文指正，能夠將建議發至 esr@thyrsus.com 或 respond-auto@linuxmafia.com。 請注意，本文不想成爲通常性的 網絡禮儀 指南，我通常會拒絕那些與引出技術論壇中有用的回答不特別相關的建議。）

提問前

在經過電郵、新聞組或論壇提技術問題之前，作如下事情：

1.嘗試在你準備提問論壇的歷史文檔中搜索答案

2.嘗試搜索互聯網以找到答案

3.嘗試閱讀手冊以找到答案

4.嘗試閱讀「常見問題文檔」（FAQ）以找到答案

5.嘗試本身檢查或試驗以找到答案

6.嘗試請教懂行的朋友以找到答案

7.若是你是程序員，嘗試閱讀源代碼以找到答案

提問時，請先代表你已作了上述事情，這將有助於創建你不是寄生蟲與浪費別人時間的印象。最好再表述你從中 學到的東西 ，咱們喜歡回答那些表現出能從答案中學習的人。

運用某些策略，好比用谷歌（Google）搜索你遇到的各類錯誤提示（既搜索 谷歌論壇， 也搜索網頁）， 這樣極可能直接就找到了解決問題的文檔或郵件列表線索。 即便沒有結果，在郵件列表或新聞組尋求幫助時提一句「我在谷歌中搜過下列句子但沒有找到什麼有用的東西」 也是件好事，至少它代表了搜索引擎不能提供哪些幫助。將搜索關鍵詞與你的問題及可能的解決方案聯繫起來，還有助於引導其餘有相似問題的人。

彆着急，不要期望幾秒鐘的谷歌搜索就能解決一個複雜的問題。讀一下常見問題文檔。在向專家提問以前，先向後靠靠放鬆一下，再思考一下問題。相信我 們，他們能從你的提問看出你作了多少閱讀與思考，若是你是有備而來，將更有可能獲得解答。不要將全部問題一股腦拋出，只因你的第一次搜索沒有結果（或者結 果太多）。

認真地思考，準備好你的問題。輕率的提問只能獲得輕率的回答，或者壓根沒有。在提問時，你越是表現出在此前作過思考與努力去解決本身的問題，你越有可能獲得真正的幫助。

注意別提錯問題。若是提問基於錯誤的假設，某黑客多半會一邊想 「愚蠢的問題……」，一邊按將錯就錯的答案回覆你，而且但願這種只是獲得你本身「問的問題」而非真正所需的解答，給你一個教訓。

永遠不要假設你 有資格 獲得解答。你沒有這種資格，畢竟你沒有爲此服務付費。若是你可以提出有內容、有趣和激勵思考的問題──那種毫無疑問可以向社區貢獻經驗，而不只僅是消極地要求從別人那獲取知識的問題，你將「掙到」答案。

另外一方面，代表你有能力也樂意參與問題的解決是個很好的開端。「有沒有人能指個方向？」，我這還差點什麼？」，「我應該查哪一個網站？」，一般要比 「請給出我能夠用的完整步驟」更容易獲得回覆，由於你代表了只要有人能指個方向，你就很樂意完成剩下的過程。

提問時

仔細挑選論壇

要對在哪提問留心，若是你作了下述事情，多半會被一筆勾銷或被當作「失敗者」：

● 張貼與論壇主題無關的問題

● 在面向高級技術問題的論壇上張貼膚淺的問題，或者反之。

● 在太多不一樣的新聞組同時張貼

● 給既非熟人也沒有義務解決你問題的人發送你私人的電郵

爲保護通訊的渠道不被無關的東西淹沒，黑客會除掉那些沒有找對地方的問題，你不會想讓這種事落到本身頭上的。

所以，第一步是找對論壇。谷歌和其它搜索引擎仍是你的朋友，能夠用它們搜索你遇到困難的軟硬件問題最相關的項目網站。那裏一般都有項目的常見問題（FAQ）、郵件列表及文檔的連接。若是你的努力（包括 閱讀FAQ）都沒有結果，這些郵件列表就是最後能取得幫助的地方。項目的網站也許還有報告臭蟲的流程或連接，若是是這樣，去看看。

向陌生的人或論壇發送郵件極有多是在冒險。譬如，不要假設一個內容豐富的網頁的做者想充當你的免費顧問，不要對你的問題是否會受到歡迎作太樂觀的估計──若是你不肯定，向別處發或者壓根別發。

在選擇論壇、新聞組或郵件列表時，別太相信名字，先看看 FAQ 或者許可書以明確你的問題是否切題。發貼前先翻翻已有的帖子，這樣可讓你感覺一下那裏行事的方式。事實上，張貼前在新聞組或郵件列表的歷史文檔中搜索與 你問題相關的關鍵詞是個極好的主意，也許就找到答案了。即便沒有，也能幫助你概括出更好的問題。

別象機關槍似的一次性「掃射」全部的幫助渠道，這就象大喊大叫同樣會使人不快，溫柔地一個一個來。

弄懂主題！最典型的錯誤之一是在某種致立於跨平臺可移植的語言、庫或工具的論壇中提關於 Unix 或 Windows 操做系統程序接口的問題。若是你不明白爲何這是大錯，最好在搞清楚概念前什麼也別問。

通常來講，在仔細挑選的公共論壇中提問比在私有論壇中提一樣的問題更容易獲得有用的回答。有幾個道理支持這點，一是看潛在的回覆者有多少，二是看論壇的參與者有多少，黑客更願回答能啓發多數人的問題。

能夠理解，老練的黑客和一些流行軟件的做者正在承受過多的不當消息。就象那根最後壓垮駱駝背的稻草同樣，你的加入也有可能使狀況走向極端──已經好幾回了，一些流行軟件的做者退出了對本身軟件的支持，由於伴隨而來的涌入其私人郵箱的垃圾郵件變得沒法忍受。

面向新手的論壇和互聯網中繼聊天（IRC）一般響應最快

本地的用戶組織或者你所用的 Linux 發行版也許正在宣傳新手取得幫助的論壇或 IRC 通道（在一些非英語國家，新手論壇極可能仍是郵件列表），這些地方是開始提問的好去處，特別是當你以爲遇到的也許只是相對簡單或者很普通的問題時。通過宣 傳的 IRC 通道是公開邀請提問的地方，一般能夠獲得實時的回覆。

事實上，若是出問題的程序來自某發行版（這很常見），最好先去該發行版的論壇或郵件列表中提問，再到程序自己的項目論壇或郵件列表，（不然）該項目的黑客可能僅僅回覆「用 咱們的 代碼」。

在任何論壇發貼之前，先看看有沒有搜索功能。若是有，就試着用問題的幾個關鍵詞搜索一下，也許就有幫助。若是在此以前你已作過全面的網頁搜索（你應該這樣去作），仍是再搜索一下論壇，搜索引擎有可能沒來得及索引此論壇的所有內容。

經過論壇或 IRC 通道提供項目的用戶支持有增加的趨勢，電子郵件交流則更多地爲項目開發者保留。因此先在論壇或 IRC 中尋求與該項目相關的幫助。

第二步，使用項目的郵件列表

當某個項目存在開發者郵件列表時，要向列表而不是其中的個別成員提問，即便你確信他能最好地回答你的問題。查一查項目的文檔和主頁，找到項目的郵件列表並使用它。採用這種辦法有幾個很好的理由：

● 向個別開發者提的問題（若是）足夠好，也將對整個項目組有益。相反，若是你認爲本身的問題對整個項目組來講太愚蠢，這也不能成爲騷擾個別開發者的理由。

● 向列表提問能夠分散開發者的負擔，個別開發者（尤爲是項目領導）也許太忙以致於無法回答你的問題。

● 大多數郵件列表都要存檔，那些存檔將被搜索引擎索引，若是你向列表提問並獲得解答，未來其它人能夠經過網頁搜索找到你的問題和答案，也就不用再次發問了。

● 若是某些問題常常被問到，開發者能夠利用此信息改進文檔或軟件自己，以使其更清楚。若是隻是私下提問，就沒有人能看到最多見問題的完整場景。

若是一個項目既有 「用戶」 也有「開發者」（或 「黑客」）郵件列表或論壇，而你又不擺弄那些代碼，向「用戶」列表或論壇提問。不要假設本身會在開發者列表中受到歡迎，那些人多半會遭受你的噪音干擾。

然爾，若是你 確信 你的問題不通常，並且在「用戶」 列表或論壇中幾天都沒有回覆，能夠試試「開發者」列表或論壇。建議你在張貼前最好先暗暗地觀察幾天以瞭解那的行事方式（事實上這是參與任何私有或半私有列表的好主意）

若是你找不到一個項目的郵件列表，而只能查到項目維護者的地址，只管向其發信。即使在這種狀況下，也別假設（項目）郵件列表不存在。在你的電子郵件 中陳述你已經試過但沒有找到合適的郵件列表，也說起你不反對將本身的郵件轉發給他人（許多人認爲，即便沒什麼祕密，私人電子郵件也不該該被公開。經過容許 將你的電子郵件轉發他人，你給了相應人員處置你郵件的選擇）。

使用有意義且明確的主題

在郵件列表、新聞組或論壇中，主題是你在五十個或更少的字之內吸引有資格專家注意的黃金機會，不要用諸如 「請幫我」 （更別提大寫的 「請幫我！！！！」，這種主題的消息會被條件反射式地刪掉）之類的嘮叨浪費機會。不要用你痛苦的深度來打動咱們，相反，要在這點空間中使用超級簡明扼要的 問題描述。

使用主題的好慣例是「對象──誤差」（式的描述），許多技術支持組織就是這樣作的。在「對象」部分指明是哪個或哪一組東西有問題，在「誤差」部分則描述與指望的行爲不一致的地方。

愚蠢：

救命啊！個人筆記本視頻工做不正常！

明智：

X.org 6.8.1 扭曲鼠標光標，MV1005 型號的某顯卡芯片組

更明智：

使用 MV1005 型號的某顯卡芯片組在 X.org 6.8.1 的鼠標光標被扭曲

編寫 「對象──誤差」式描述的過程有助於你組織對問題的細緻思考。是什麼被影響了？僅僅是鼠標光標或者還有其它圖形？只在 X.org 中出現？或只是在其 6.8.1 版中？是針對某顯卡芯片組？或者只是其中的 MV1005 型號？一個黑客只需描一眼就可以當即明白什麼是你遇到的問題，什麼是你本身的問題。

更通常地，想象一下在一個只顯示主題的文檔索引中查找。讓你的主題更好地反映問題，能夠使下一個搜索相似問題的人可以在文檔中直接就找到答案的線索，而不用再次發貼提問。

若是你想在回覆中提問，確保改變主題以代表你是在問一個問題，一個主題象 「Re: 測試」 或者 「Re: 新臭蟲」的消息不太可能引發足夠的注意。同時，將回復中與新主題不甚相關的引用內容儘可能刪除。

對於列表消息，不要直接點擊回覆（按鈕）來開始一個全新的線索，這將限制你的觀衆。有些郵件閱讀程序，好比 mutt，容許用戶按線索排序並經過摺疊線索來隱藏消息，這樣作的人永遠看不到你發的消息。

僅僅改變主題還不夠。mutt 和其它一些郵件閱讀程序還要檢查郵件頭主題之外的其它信息，以便爲其指定線索，因此寧肯發一個全新的郵件。

在論壇，由於消息與特定的線索緊密結合，而且一般在線索以外不可見，好的提問方式略有不一樣，經過回覆提問並沒關係。不是全部論壇都容許在回覆中出現 分離的主題，並且這樣作了基本上沒有人會去看。不過，經過回覆提問自己就是使人懷疑的作法，由於它們只會被正在查看該線索的人讀到。因此，除非你 只想 在該線索當前活躍的人羣中提問，仍是另起爐竈比較好。

使問題容易回覆

以「請向……回覆」來結束問題多半會使你得不到回答。若是你以爲花幾秒鐘在郵件客戶端設置一下回復地址都麻煩，咱們也以爲花幾秒鐘考慮你的問題更麻煩。若是你的郵件客戶端程序不支持這樣作，換個好點的；若是是操做系統不支持全部這種郵件客戶端程序，也換個好點的。

在論壇，要求經過電子郵件回覆是徹底無禮的，除非你確信回覆的信息也許是敏感的（並且有人會爲了某些未知的緣由，只讓你而不是整個論壇知道答案）。 若是你只是想在有人回覆線索時獲得電子郵件提醒，能夠要求論壇發送。幾乎全部論壇都支持諸如「留意本線索」、「有回覆發送郵件」等功能。

用清晰、語法、拼寫正確的語句書寫

經驗告訴咱們，粗心與草率的做者一般也粗心與草率地思考和編程（我敢打賭）。爲這些粗心與草率的思考者回答問題沒有什麼好處，咱們寧肯將時間花在其它地方。

清楚、良好地表達你的問題很是重要。若是你以爲這樣作麻煩，咱們也以爲注意（你的問題）麻煩。花點額外的精力斟酌一下字句，用不着太僵硬與正式──事實上，黑客文化很看重能準確地使用非正式、俚語和幽默的語句。但它 必須 很準確，並且有跡象代表你是在思考和關注問題。

正確地拼寫、使用標點和大小寫，不要將「its」混淆爲「it’s」，「loose」搞成「lose」或者將「discrete」弄成 「discreet」。不要所有用大寫，這會被視爲無禮的大聲嚷嚷 （所有小寫也好不到哪去，由於不易閱讀。Alan Cox [注：著名黑客，Linux 內核的重要參與者] 也許能夠這樣作，但你不行。）

通常而言，若是你寫得象個半文盲似的傻子，多半得不到理睬。也不要使用即時通信中的簡寫，如將「you」簡化爲「u」會使你看起來象一個爲了節約二 次擊鍵的半文盲式的傻子。更糟的是，若是象個小孩似地鬼畫桃符那絕對是在找死，能夠確定沒人會理你（或者最可能是給你一大堆指責與挖苦）。

若是在非母語論壇提問，你的拼寫與語法錯誤會獲得有限的寬容，但懶惰徹底不會被容忍（是的，咱們一般看得出其中的差異）。同時，除非你知道回覆者使 用的語言，請使用英語書寫。繁忙的黑客通常會直接刪除用他們看不懂語言寫的消息。在互聯網上英語是工做語言，用英語書寫能夠將你的問題不被閱讀就被直接刪 除的可能性降到最低。

使用易於讀取且標準的文件格式發送問題

若是你人爲地將問題搞得難以閱讀，它多半會被忽略，人們更願讀易懂的問題，因此：

● 使用純文本而不是 HTML（超文本標註語言）（ 關閉HTML 並不難）

● 使用 MIME（多用途互聯網郵件擴展）附件一般沒有問題，前提是真正有內容（譬如附帶的源文件或補丁），而不只僅是郵件客戶端程序生成的模板（譬如只是消息內容的拷貝）。

● 不要發送整段只是單行句子但屢次折回的郵件（這使得回覆部份內容很是困難）。設想你的讀者是在80個字符寬的文本終端閱讀郵件，設置你的行折回點小於 80 列。

● 可是，也 不要 用任何固定列折回數據（譬如日誌文件拷貝或會話記錄）。數據應該原樣包含，使回覆者確信他們看到的是與你看到的同樣的東西。

● 在英語論壇中，不要使用’Quoted-Printable’ MIME 編碼發送消息。這種編碼對於張貼非 ASCII 語言多是必須的，但不少郵件程序並不支持。當它們分斷時，那些文本中四處散佈的 「=20」符號既難看也分散注意力，甚至有可能破壞內容的語意。

● 永遠不要 期望黑客們閱讀使用封閉的專用格式編寫的文檔，諸如微軟公司的 Word 或 Excel 文件等。大多數黑客對此的反應就象有人將還在冒熱氣的豬糞倒在你門口時你的反應同樣。即便他們可以處理，也很厭惡這麼作。

● 若是你從使用視窗的電腦發送電子郵件，關閉微軟愚蠢的「聰明引用」功能，以避免在你的郵件中處處散佈垃圾字符。

● 在論壇，勿濫用「表情符號」和「HTML」功能(當它們提供時)。一兩個表情符號一般沒有問題，但花哨的彩色文本傾向於令人認爲你是個無能之 輩。過濫地使用表情符號、色彩和字體會使你看來象個傻笑的小姑娘。這一般不是個好主意，除非你只是對性而不是有用的回覆更有興趣。

若是你使用圖形用戶界面的郵件客戶端程序(如網景公司的 Messenger、微軟公司的 Outlook 或者其它相似的)，注意它們的缺省配置不必定知足這些要求。大多數這類程序有基於菜單的「查看源碼」命令，用它來檢查發送文件夾中的消息，以確保發送的是 沒有多餘雜質的純文本文件。

描述問題應準確且有內容

● 仔細、清楚地描述問題的症狀

● 描述問題發生的環境(主機、操做系統、應用程序，任何相關的)，提供銷售商的發行版和版本號（如：「Fedora Core 7」、「Slackware 9.1」等）● 描述提問前作過的研究及其理解。

● 描述提問前爲肯定問題而採起的診斷步驟

● 描述最近對計算機或軟件配置的任何相關改變。

● 若是可能，提供在可控環境下重現問題的方法。

盡最大努力預測黑客會提到的問題，並提早備好答案。

若是你認爲是代碼有問題，向黑客提供在可控環境下重現問題的方法尤爲重要。當你這麼作時，獲得有用且及時回覆的可能性將大大增長。

西蒙.泰瑟姆（Simon Tatham）寫過一篇《如何有效報告Bug》的文章，我強烈推薦各位閱讀。

量不在多，精煉則靈

你應該（寫得）精煉且有內容，簡單地將一大堆代碼或數據羅列在求助消息中達不到目的。若是你有一個很大且複雜的測試樣例讓程序崩潰，嘗試將其裁剪得越小越好。

至少有三個理由支持這點。第一，讓別人看到你在努力簡化問題使你更有可能獲得回覆。第二，簡化問題使你更有可能獲得 有用的 回覆。第三，在提純臭蟲報告的過程當中，你可能本身就找到了解決辦法或權宜之計。

別急於宣稱找到臭蟲

當你在一個軟件中遇到問題，除非你 很是、很是 的有根據，不要動輒聲稱找到了臭蟲。提示：除非你能提供解決問題的源代碼補丁，或者對前一版本的迴歸測試表現出不正確的行爲，不然你都多半不夠徹底確信。對於網頁和文檔也如此，若是你（聲稱）發現了文檔的「臭蟲」，你應該能提供相應位置的替代文本。

記住，還有許多其它用戶並未經歷你遇到的問題，不然你在閱讀文檔或搜索網頁時就應該發現了（你在報怨前已經作了這些，是吧 ？）。這也意味着頗有多是你弄錯了而不是軟件自己有問題。

編寫軟件的人老是很是辛苦地使它儘量完美。若是你聲稱找到了臭蟲，也就置疑了他們的能力，即便你是對的，也有可能會使其中的部分人感到不快。（此外，）在主題中嚷嚷「臭蟲」也是特別不老練的。

提問時，即便你私下很是確信已經發現一個真正的臭蟲，最好寫得象是 你 作錯了什麼。若是真的有臭蟲，你會在回覆中看到這點。這樣作的話，若是真有蟲子，維護者就會向你道歉，這總比你弄砸了而後欠別人一個道歉要強。

低三下四代替不了作本身的家庭做業

有些人明白他們不該該粗魯或傲慢地行事並要求獲得答覆，但他們退到相反的低三下四的極端：「我知道我只是個可憐的新丁，一個失敗者，但……」。這既令人困擾，也沒有用，當伴隨着對實際問題含糊的描述時還特別使人反感。

別用低級靈長類動物的辦法浪費你個人時間，相反，儘量清楚地描述背景狀況和你的問題，這比低三下四更好地擺正了你的位置。

有時，論壇設有單獨的初學者提問版面，若是你真的認爲遇到了膚淺的問題，到那去就是了，但同樣別低三下四。

描述問題症狀而不是猜想

告訴黑客是什麼致使了問題是沒用的（若是你的診斷理論是了不得的東西，你還會向別人諮詢求助嗎？）。因此，確保只是告訴他們問題的原始症狀，而不是 你的解釋和理論，讓他們來解釋和診斷。若是你認爲陳述本身的猜想很重要，應清楚地說明這只是你的猜想並描述爲何它們不起做用。

愚蠢：

我在編譯內核時接連遇到 SIG11 錯誤，懷疑主板上的某根電路絲斷了，找到它們的最好辦法是什麼？

明智：

我組裝的電腦（K6/233 CPU、FIC-PA2007 主板[威盛 Apollo VP2 芯片組]、Corsair PC133 SDRAM 256Mb 內存）最近在開機 20 分鐘左右、作內核編譯時頻繁地報 SIG11 錯，但在頭 20 分鐘內從不出問題。重啓動不會復位時鐘，但整夜關機會。更換全部內存未解決問題，相關的典型編譯會話日誌附後。

因爲以上這點許多人彷佛難以掌握，這裏有句話能夠提醒你：「全部的診斷專家都來自密蘇里州」。美國國務院的官方座右銘則是「讓我看看」（出自國會議 員威勒德.D.範迪弗［Willard D. Vandiver］在1899年時的講話：「我來自一個出產玉米、棉花、牛蒡和民主黨人的國家，滔滔雄辯既不能說服我，也不會讓我滿意。我來自密蘇里州， 你必須讓我看看。」）針對診斷者而言，這並非懷疑，而只是一種真實而有用的需求，以便讓他們看到與你看到的原始證據儘量一致的東西，而不是你的猜想與 總結。（因此，）讓咱們看看。

按時間前後羅列問題症狀

剛出問題以前發生的事情一般包含有解決問題最有效的線索。因此，記錄中應準確地描述你、電腦和軟件在崩潰前都作了什麼。在命令行處理的狀況下，有會話日誌（如運行腳本工具生成的）並引用相關的若干（如20）行記錄會很是有幫助。

若是崩潰的程序有診斷選項（如-v詳述開關），試着選擇這些能在記錄中增長排錯信息的選項。記住，「多」不等於「好」。試着選取適當的排錯級別以便提供有用的信息而不是將閱讀者淹沒在垃圾中。

若是你的記錄很長（如超過四段），在開頭簡述問題隨後按時間前後羅列詳細過程也許更有用。這樣，黑客在讀你的記錄時就知道該注意哪些內容了。

描述目標而不是過程

若是你想弄清楚如何作某事（而不是報告一個臭蟲），在開頭就描述你的目標，而後才陳述遇到問題的特定步驟。

常常出現這種狀況，尋求技術幫助的人在腦殼裏有個更高層次的目標，他們在自覺得能達到目標的特定道路上被卡住了，而後跑來問該怎麼走，但沒有意識到這條路自己有問題，結果要費很大的勁才能經過。

愚蠢：

我怎樣才能讓某圖形程序的顏色拾取器取得十六進制的 RGB 值？

明智：

我正試着用本身選定數值的顏色替換一幅圖片的色表，我如今知道的惟一方法是編輯每一個表槽，但卻沒法讓某圖形程序的顏色拾取器取得十六進制的 RGB 值。

第二種提法是明智的，它使得建議採用更合適的工具以完成任務的回覆成爲可能。

別要求私下回覆電郵

黑客們認爲問題的解決過程應該公開、透明，此過程當中若是更有才能的人注意到不完整或者不當之處，最初的回覆纔可以、也應該被糾正。同時，做爲回覆者也由於能力和學識被其它同行看到而獲得某種回報。

當你要求私下回復時，此過程和回報都被停止。別這樣作，讓 回覆者 來決定是否私下回答──若是他真這麼作了，一般是由於他認爲問題編寫太差或者太膚淺，以致於對其它人毫無心義。

對這條規則存在一條有限的例外，若是你確信提問可能會引來大量雷同的回覆時，那麼「向我發電郵，我將爲論壇概括這些回覆」將是神奇的句子。試着將郵件列表或新聞組從洪水般雷同的回覆中解救出來是很是有禮貌的──但你必須信守諾言。

提問應明確

漫無邊際的問題一般也被視爲沒有明確限制的時間無底洞。最有可能給你有用答案的人一般也是最忙的人（假如只是由於他們承擔了太多工做的話），這些人對於沒有止境的時間無底洞極其敏感，因此他們也傾向於討厭那些漫無邊際的問題。

若是你明確了想讓回覆者作的事（如指點方向、發送代碼、檢查補丁或其它），你更有可能獲得有用的回覆。（由於）這樣可讓他們集中精力並間接地設定了他們爲幫助你須要花費的時間和精力上限，這很好。

要想理解專家生活的世界，能夠這樣設想：那裏有豐富的專長資源但稀缺的響應時間。你暗中要求他們奉獻的時間越少，你越有可能從這些真正懂行也真正很忙的專家那裏獲得解答。

因此限定你的問題以使專家回答時須要付出的時間最少──這一般與簡化問題還不太同樣。舉個例，「請問能否指點一下哪有好一點的 X 解釋？」一般要比「請解釋一下 X」明智。若是你的代碼不運行了，一般請別人看看哪有問題比叫他們幫你改正更明智。

關於代碼的問題

別要求他人給你出問題的代碼排錯而不說起應該從何入手。張貼幾百行的代碼，而後說一聲「它不能運行」會讓你得不到理睬。只貼幾十行代碼，而後說一句「在第七行之後，本應該顯示<x>，但實際出現的是<y>」很是有可能讓你獲得回覆。

最精確描述代碼問題的方法是提供一個能展現問題的最小測試樣例。什麼是最小測試樣例？它是對問題的展示，只須要恰好可以重現非預期行爲的代碼便可。 如何生成一個最小測試樣例？若是你知道哪一行或哪一段代碼會產生問題，將其複製並提供恰好夠用的外圍支撐代碼以構成一個完整的樣例（夠用是指源碼恰好能被 編譯器、解釋器或任何處理它的程序所接受）。若是你不能將問題縮小到特定的段落，複製源碼並去除那些與問題無關的代碼段。你能提供的最小測試樣例越小越好 （參見 量不在多，精煉則靈 ）。

生成一個很是小的最小測試樣例並不老是可能，但盡力去作是很好的鍛練，這有可能幫助你找到須要本身解決的問題。即便你找不到，黑客們喜歡看到你努力過，這將使他們更合做。

若是你只是想讓別人幫忙審一下代碼，在最開頭就要說出來，而且必定要提到你認爲哪一部分特別須要關注以及爲何。

別張貼家庭做業式問題

黑客們善於發現「家庭做業」式的問題。咱們中的大多數人已經作了本身的家庭做業，那是該 你 作的，以便從中學到東西。問一下提示沒有關係，但不是要求完整的解決方案。

若是你懷疑本身碰到了一個家庭做業式的問題，但仍然沒法解決，試試在用戶組、論壇或（做爲最後一招）在項目的「用戶」郵件列表或論壇中提問。儘管黑客們 會 看出來，一些老用戶也許仍會給你提示。

刪除無心義的要求

抵制這種誘惑，即在求助消息末尾加上諸如「有人能幫我嗎？」或「有沒有答案？」之類在語義上毫無心義的東西。第一，若是問題描述還不完整，這些附加 的東西最多也只能是多餘的。第二，由於它們是多餘的，黑客們會認爲這些東西煩人──就頗有可能用邏輯上無誤但打發人的回覆，諸如「是的，你能夠獲得幫助」 和「不，沒有給你的幫助」。

通常來講，避免提「是或否」類型的問題，除非你想獲得 「是或否」類型的回答。

 

不要把問題標記爲「緊急」， 即便對你而言的確如此

這是你的問題，不要咱們的。宣稱「緊急」極有可能事與願違：大多數黑客會直接刪除這種消息，他們認爲這是無禮和自私地企圖獲得即時與特殊的關照。

有一點點局部的例外，若是你是在一些知名度很高、會使黑客們激動的地方使用程序，也許值得這樣去作。在這種狀況下，若是你有期限壓力，也頗有禮貌地提到這點，人們也許會有足夠的興趣快一點回答。

固然，這是很是冒險的，由於黑客們對什麼是使人激動的標準多半與你的不一樣。譬如從國際空間站這樣張貼沒有問題，但表明感受良好的慈善或政治緣由這樣 作幾乎確定不行。事實上，張貼諸如「緊急：幫我救救這個毛絨絨的小海豹！」確定會被黑客迴避或光火，即便他們認爲毛絨絨的小海豹很重要。

若是你以爲這難以想象，再把剩下的內容多讀幾遍，直到弄懂了再發貼也不遲。

禮貌老是有益的

禮貌一點，使用「請」和「謝謝你的關注」或者「謝謝你的關照」，讓別人明白你感謝他們無償花時間幫助你。

坦率地講，這一點沒有語法正確、文字清晰、準確、有內容和避免使用專用格式重要（同時也不能替代它們）。黑客們通常寧肯讀有點唐突但技術鮮明的臭蟲報告，而不是那種有禮但含糊的報告。（若是這點讓你不解，記住咱們是按問題能教咱們什麼來評價它的）

然爾，若是你已經談清楚了技術問題，客氣一點確定會增長你獲得有用回覆的機會。

（咱們必須指出，本文惟一受到一些老黑客認真反對的地方是之前曾經推薦過的「提早謝了」，一些黑客認爲這隱含着過後不用再感謝任何人的暗示。咱們的建議是要麼先說 「提早謝了」，過後 再 對回覆者表示感謝，要麼換種方式表達，譬如用「謝謝你的關注」或「謝謝你的關照」）。

問題解決後追加一條簡要說明

問題解決後向全部幫助過的人追加一條消息，讓他們知道問題是如何解決的並再次感謝。若是問題在郵件列表或新聞組中受到普遍關注，在那裏追加此消息比較恰當。

最理想的方式是向最初提問的線索回覆此消息，並在主題中包含「已解決」、「已搞定」或其它同等含義的明顯標記。在人來人往的郵件列表裏，一個看見線 索 「問題 X」和「問題 X-已解決」的潛在回覆者就明白不用再浪費時間了（除非他我的以爲「問題 X」有趣），所以能夠利用此時間去解決其它問題。

追加的消息用不着太長或太複雜，一句簡單的「你好──是網線壞了！謝謝你們──比爾」就比什麼都沒有要強。事實上，除非解決問題的技術真正高深，一條簡短而親切的總結比長篇大論要好。說明是什麼行動解決了問題，用不着重演整個排錯的故事。

對於有深度的問題，張貼排錯歷史的摘要是恰當的。描述問題的最終狀態，說明是什麼解決了問題，在此以後 才指明能夠避免的彎路。應避免的彎路部分應放在正確的解決方案和其它總結材料以後，而不要將此消息搞成偵探推理小說。列出那些幫助過你的名字，那樣你會交到朋友的。

除了有禮貌、有內容之外，這種類型的追帖將幫助其餘人在郵件列表、新聞組或論壇文檔中搜索到真正解決你問題的方案，從而也讓他們受益。

最後，此類追帖還讓每位參與協助的人因問題的解決而產生一種知足感。若是你本身不是技術專家或黑客，相信咱們，這種感受對於你尋求幫助的老手和專家 是很是重要的。問題敘述到最後不知所終老是使人沮喪的，黑客們癢癢地渴望它們被解決。「撓癢癢」爲你掙到的信譽將對你下次再次張貼提問很是很是的有幫助。

考慮一下怎樣才能避免他人未來也遇到相似的問題，問問本身編一份文檔或 FAQ 補丁會不會有幫助，若是是的話就將補丁發給維護者。

在黑客中，這種良好的後繼行動實際上比傳統的禮貌更重要，也是你善待他人而贏得聲譽的方式，這是很是有價值的財富。

如何解讀回答

「讀讀該死的手冊」（RTFM）和「搜搜該死的網絡」（STFW）：如何明白你已徹底搞砸

有一個古老而神聖的傳統：若是你收到「讀讀該死的手冊」（RTFM） 的回覆，發信人認爲你應該去「讀讀該死的手冊」。他或她多半是對的，去讀一下吧。

「讀讀該死的手冊」（RTFM）有個年輕一點的親戚，若是你收到「搜搜該死的網絡」（STFW）的回覆，發信人認爲你應該「搜搜該死的網絡」。那人多半也是對的，去搜一下吧。(更溫和一點的說法是「谷歌是你的朋友！」)

在論壇，你也可能被要求去搜索論壇的文檔。事實上，有人甚至可能熱心地爲你提供之前解決此問題的線索。但不要依賴這種關照，提問前應該先搜索一下文檔。

一般，叫你搜索的人已經打開了能解決你問題的手冊或網頁，正在一邊看一邊敲鍵盤。這些回覆意味着他認爲：第一，你要的信息很容易找到。第二，自已找要比別人喂到嘴裏能學得更多。

你不該該以爲這樣就被冒犯了，按黑客的標準，回覆者沒有不理你就是在向你表示某種尊敬，你反而應該感謝他熱切地想幫助你。

 

若是還不明白……

若是你看不懂回答，不要立刻回覆一個要求說明的消息，先試試那些最初提問時用過的相同工具（如手冊、FAQ、網頁、懂行的朋友等）試着搞懂回答。若是仍是須要說明，展示你已經明白的。

譬如，假如我告訴你：「看起來象是某輸入項有問題，你須要清除它」，接着是個 很差 的回帖：「什麼是某輸入項？」。而這是一個 很好 的跟帖：「是的，我讀了手冊，某某輸入項只在 -z 和 -p 開關中被提到，但都沒有涉及到如何清除它們，你指的是哪個仍是我弄錯了什麼？」

 

對待無禮

不少黑客圈子中看似無禮的行爲並非存心冒犯。相反，它是直接了當、一針見血式的交流風格，這種風格對於更關注解決問題而不是使別人感受舒服而混亂的人是很天然的。

若是你以爲被冒犯了，試着平靜地反應。若是有人真的作了過格的事，郵件列表、新聞組或論壇中的前輩多半會招呼他。若是這 沒有 發生而你卻光火了，那麼你發火對象的言語可能在黑客社區中看起來是正常的，而 你 將被視爲有錯的一方，這將傷害到你獲取信息或幫助的機會。

另外一方面，你會偶而真的碰到無禮和無聊的言行。與上述相反，對真正的冒犯者狠狠地打擊、用犀利的語言將其駁得體無完膚都是能夠接受的。然爾，在行事 以前必定要很是很是的有根據。糾正無禮的言論與開始一場毫無心義的口水戰僅一線之隔，黑客們本身莽撞地越線的狀況並不鮮見。若是你是新手或外來者，避開這 種莽撞的機會並不高。若是你想獲得的是信息而不是消磨時光，這時最好不要把手放在鍵盤上以避免冒險。

（有些人斷言不少黑客都有輕度的自閉症或阿斯伯格綜合症，缺乏用於潤滑人類社會「正常」交往所需的腦電路。這既多是真也多是假。若是你本身不是黑客，興許你認爲咱們腦殼有問題還能幫助你應付咱們的古怪行爲。只管這麼幹好了，咱們不在意。咱們 喜歡 如今這個樣子，而且通常都對病號標記有站得住腳的懷疑。）

在下一節，咱們會談到另外一個問題，當 你 行爲不當時會受到的「冒犯」。

別象失敗者那樣反應

在黑客社區的論壇中有那麼幾回你可能會搞砸──以本文描述或相似的方式。你會被示衆是如何搞砸的，也許言語中還會帶點顏色。

這種事發生之後，你能作的最糟糕的事莫過於哀嚎你的遭遇、宣稱被口頭攻擊、要求道歉、高聲尖叫、憋悶氣、威脅訴諸法律、向其僱主報怨、忘了關馬桶蓋等等。相反，你該這樣去作：

熬過去，這很正常。事實上，它是有益健康與恰當的。

社區的標準不會本身維持，它們是經過參與者積極而 公開 地執行來維持的。不要哭嚎全部的批評都應該經過私下的郵件傳送，這不是事情運做的方式。當有人評論你的一個說法有誤或者提出不一樣見解時，堅持聲稱受到我的攻擊也毫無益處，這些都是失敗者的態度。

也有其它的黑客論壇，受太高禮節要求的誤導，禁止參與者張貼任何對別人帖子挑毛病的消息，並聲稱「若是你不想幫助用戶就閉嘴」。有思路的參與者紛紛離開的結果只會使它們變成了毫無心義的嘮叨與無用的技術論壇。

是誇張的「友誼」（以上述方式）仍是有用？挑一個。

記着：當黑客說你搞砸了，而且(不管多麼刺耳地)告訴你別再這樣作時，他正在爲關心你和他的社區而行動。對他而言，不理你並將你從他的生活中濾除要 容易得多。若是你沒法作到感謝，至少要有點尊嚴，別大聲哀嚎，也別由於本身是個有戲劇性超級敏感的靈魂和自覺得有資格的新來者，就期望別人象對待脆弱的洋 娃娃那樣對你。

有時候，即便你沒有搞砸（或者只是別人想象你搞砸了）， 有些人也會平白無故地攻擊你本人。在這種狀況下，報怨卻是 真的 會把問題搞砸。

這些找茬者要麼是毫無辦法但自覺得是專家的不中用傢伙，要麼就是測試你是否真會搞砸的心理專家。其它讀者要麼不理睬，要麼用本身的方式對付他們。這些找茬者在給本身找麻煩，這點你不用操心。

也別讓本身捲入口水戰，大多數口水戰最好不要理睬──固然，是在你覈實它們只是口水戰、沒有指出你搞砸的地方，並且沒有巧妙地將問題真正的答案藏於其中以後（這也是可能的）。

 

提問禁忌

下面是些典型的愚蠢問題和黑客不回答它們時的想法。

問：我到哪能夠找到某程序或 X 資源？

問：我怎樣用 X 作 Y？

問：如何配置個人 shell 提示？

問：我能夠用 Bass-o-matic 文件轉換工具將 AcmeCorp 文檔轉爲 TeX 格式嗎？

問：個人{程序、配置、SQL 語句}不運行了

問：個人視窗電腦出問題了，你能幫忙嗎？

問：個人程序不運行了，我認爲系統工具X有問題

問：我安裝 Linux 或 X 遇到困難，你能幫忙嗎？

問：我如何才能破解超級用戶口令/盜取通道操做員的特權/查看某人的電子郵件？

 

問： 我到哪能夠找到某程序或 X 資源？

答： 在我找到它的一樣地方，笨旦──在網頁搜索引擎上。上帝啊，難道還有人不知道如何使用 谷歌 嗎？

問： 我怎樣用 X 作 Y？

答： 若是你想解決的是 Y，提問時別給出可能並不恰當的方法。這種問題說明提問者不但對 X 徹底無知，也對要解決的 Y 問題糊塗，還被特定形勢禁錮了思惟。等他們把問題弄好再說。

問： 如何配置個人 shell 提示？

答： 若是你有足夠的智慧提這個問題，你也該有足夠的智慧去 「讀讀該死的手冊」（RTFM），而後本身去找出來。

問： 我能夠用 Bass-o-matic 文件轉換工具將 AcmeCorp 文檔轉爲 TeX 格式嗎？

答： 試試就知道了。若是你試過，你既知道了答案，又不用浪費個人時間了。

問： 個人{程序、配置、SQL 語句}不運行了

答： 這不是一個問題，我也沒有興趣去猜你有什麼問題──我有更要緊的事要作。看到這種東西，個人反應通常以下：

你還有什麼補充嗎？

噢，太糟了，但願你能搞定。

這跟我究竟有什麼關係？

問： 個人視窗電腦出問題了，你能幫忙嗎？

答： 是的，把視窗垃圾刪了，裝個象 Linux 或 BSD 的開源操做系統吧。

注意：若是程序有官方的視窗版或者與視窗有交互(如 Samba)，你 能夠 問與視窗相關的問題，只是別對問題是由視窗操做系統而不是程序自己形成的回覆感到驚訝，由於視窗通常來講差，這種說法通常都成立。

問： 個人程序不運行了，我認爲系統工具 X 有問題

答： 你徹底有多是第一個注意到被成千上萬用戶反覆使用的系統調用與庫文件有明顯缺陷的人，更有可能的是你徹底沒有根據。與衆不同的說法須要與衆不同的證據，當你這樣聲稱時，你必須有清楚而詳盡的缺陷說明文檔做後盾。

問： 我安裝 Linux 或 X 遇到困難，你能幫忙嗎？

答： 不行，我須要親手操做你的電腦才能幫你排錯，去向當地的 Linux 用戶組尋求方便的幫助（你能夠在 這裏 找到用戶組列表）

注意：若是安裝問題與某 Linux 發行版有關，在針對 它 的郵件列表、論壇或本地用戶組織中提問也許是恰當的。此時，應描述問題的準確細節。在此以前，先用 「linux」和 全部 被懷疑的硬件 [做關鍵詞] 仔細搜索。

問： 我如何才能破解超級用戶口令/盜取通道操做員的特權/查看某人的電子郵件？

答： 想作這種事情說明你是個卑劣的傢伙，想讓黑客教你作這種事情說明你是個白癡。

 

好問題與壞問題

最後，我將經過舉例來演示提問的智慧。一樣的問題兩種提法，一種愚蠢，另外一種明智。

愚蠢：我在哪能找到關於 Foonly Flurbamatic 設備的東西？

這個問題在乞求獲得 「搜搜該死的網絡」（STFW） 式的回覆。

明智： 我用谷歌搜索過「Foonly Flurbamatic 2600」，但沒有找到什麼有用的，有誰知道在哪能找到這種設備的編程信息？

這我的已經搜索過網絡了，並且聽起來他可能真的遇到了問題。

愚蠢： 我不能編譯某項目的源代碼，它爲何這麼破？

提問者假設是別人搞砸了，太自大了。

明智： 某項目的源代碼不能在某 Linux 6.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）貢獻了一些特別有價值的建議和改進。