diff --git a/README.md b/README.md index c970205..2934180 100644 --- a/README.md +++ b/README.md @@ -58,24 +58,24 @@ __本指南不提供此專案的實際支援服務！__ 1. 嘗試在你準備提問的論壇的舊文章中搜索答案 1. 嘗試上網搜索答案 1. 嘗試通讀手冊以找到答案。 - 1. 嘗試閱讀“常見問題”（FAQ）以找到答案。 + 1. 嘗試閱讀"常見問題"（FAQ）以找到答案。 1. 嘗試自己檢查或試驗以找到答案 1. 向你身邊懂行的朋友打聽。 1. 如果你是程式開發者，請嘗試閱讀原始碼以找到答案 **當你提出問題的時候，請先表明你已經做了上述的努力**，這將有助於樹立你並不是一個妄圖不勞而獲的乞討者的形象，而且不會浪費別人的時間。 如果你能一併表達在做了上述努力的過程中所學到的東西會更好，因為我們更樂於回答那些表現出能從答案中學習的人的問題。 -運用某些策略，比如用Google先搜索你所遇到的各種錯誤提示訊息（既搜索Google論壇，也搜索網頁），這樣很可能直接就找到了能解決問題的文件或郵件列表線索。 即使沒有結果，在郵件列表或新聞組尋求幫助時提一句“我在谷歌中搜過下列句子但沒有找到什麼有用的東西” 也是件好事，即使它只是表明了搜索引擎不能提供哪些幫助。 這麼做（加上搜尋過的字串）也讓遇到相似問題的其他人能被搜尋引擎引導到你的提問來。 +運用某些策略，比如用Google先搜索你所遇到的各種錯誤提示訊息（既搜索Google論壇，也搜索網頁），這樣很可能直接就找到了能解決問題的文件或郵件列表線索。 即使沒有結果，在郵件列表或新聞組尋求幫助時提一句"我在谷歌中搜過下列句子但沒有找到什麼有用的東西" 也是件好事，即使它只是表明了搜索引擎不能提供哪些幫助。 這麼做（加上搜尋過的字串）也讓遇到相似問題的其他人能被搜尋引擎引導到你的提問來。 別著急，不要指望幾秒鐘的Google搜尋就能解決一個複雜的問題。 先閱讀並看懂常見問題（FAQ）文件。在向專家求助之前，先放鬆、坐舒服一些，再花點時間思考一下這個問題。 相信我們，他們能從你的提問看出你做了多少閱讀與思考，如果你是有備而來，將更有可能得到解答。 不要將所有問題一股腦拋出，只因你的第一次搜索沒有找到答案（或者找到太多答案）。 準備好你的問題，**全面地將問題思考數遍**，因為草率的發問只能得到草率的回答，或者根本得不到任何答案。 越是表現出在尋求幫助前你為解決問題所付出的努力，你越有可能得到實質性的幫助。 -小心別問錯了問題。如果你的問題基於錯誤的假設，某個普通黑客（J. Random Hacker）多半會一邊在心裏想著“蠢問題…”， 一邊用無意義的字面解釋來答覆你，希望著你會從問題的回答（而非你想得到的答案）中汲取教訓。 +小心別問錯了問題。如果你的問題基於錯誤的假設，某個普通黑客（J. Random Hacker）多半會一邊在心裏想著"蠢問題…"， 一邊用無意義的字面解釋來答覆你，希望著你會從問題的回答（而非你想得到的答案）中汲取教訓。 -絕不要自以為夠資格得到答案，你沒這種資格。畢竟你沒有為這種服務支付任何報酬。 **你需要自己去“掙到”一個答案**，你能靠提出有內涵的，有趣的，有思維激勵作用的問題– 那些對社區的經驗有潛在貢獻的問題，而不僅僅是被動的從他人處索要知識。 +絕不要自以為夠資格得到答案，你沒這種資格。畢竟你沒有為這種服務支付任何報酬。 **你需要自己去"掙到"一個答案**，你能靠提出有內涵的，有趣的，有思維激勵作用的問題– 那些對社區的經驗有潛在貢獻的問題，而不僅僅是被動的從他人處索要知識。 -另一方面，**表明你願意在找答案的過程中做點什麼，**是一個非常好的開端。 “誰能給點提示？”、“我的這個例子裏缺了什麼？”以及“我應該檢查什麼地方？”比“請把我需要的確切的過程貼出來”更容易得到答復。 因為你表現出只要有人能指個正確方向，你就有完成它的能力和決心。# 如何提問 # +另一方面，**表明你願意在找答案的過程中做點什麼，**是一個非常好的開端。 "誰能給點提示？"、"我的這個例子裏缺了什麼？"以及"我應該檢查什麼地方？"比"請把我需要的確切的過程貼出來"更容易得到答復。 因為你表現出只要有人能指個正確方向，你就有完成它的能力和決心。# 如何提問 # ## 慎選提問的論壇 ## @@ -94,7 +94,7 @@ __本指南不提供此專案的實際支援服務！__ 在選擇論壇、新聞組或郵件列表時，別太相信名字，先看看FAQ或者許可書以明確你的問題是否切題。 發文前先翻翻已有的話題，這樣可以讓你感受一下那裡行事的方式。 事實上，事先在新聞組或郵件列表的歷史記錄中搜尋與你問題相關的關鍵詞是個極好的主意，也許這樣就找到答案了。 即使沒有，也能幫助你歸納出更好的問題。 -別像機關槍似的一次性“掃射”所有的幫助渠道，這就像大喊大叫一樣會使人不快。要一個一個地來。 +別像機關槍似的一次性"掃射"所有的幫助渠道，這就像大喊大叫一樣會使人不快。要一個一個地來。 搞清楚你的主题！最典型的錯誤之一是在某種致力於跨平台可移植的語言、庫或工具的論壇中提關於Unix或Windows操作系統程序接口的問題。 如果你不明白為什麼這是大錯，最好在搞清楚這之間差異之前什麼也別問。 @@ -106,7 +106,7 @@ __本指南不提供此專案的實際支援服務！__ 你當地的使用者群組，或者你所用的Linux發行版本也許正在宣傳他們的網頁論壇或IRC頻道，並提供新手幫助（在一些非英語國家，新手論壇很可能還是郵件列表）， 這些地方是開始提問的好去處，特別是當你覺得遇到的也許只是相對簡單或者很普通的問題時。 經過宣傳的IRC頻道是公開歡迎提問的地方，通常可以即時得到回應。 -事實上，如果程式出的問題只發生在某 Linux 發行版提供的版本（這很常見），最好先去該發行版的論壇或郵件列表中提問，再到程式本身的論壇或郵件列表提問。 （否則）該項目的黑客可能僅僅回复“用我們提供的版本”。 +事實上，如果程式出的問題只發生在某 Linux 發行版提供的版本（這很常見），最好先去該發行版的論壇或郵件列表中提問，再到程式本身的論壇或郵件列表提問。 （否則）該項目的黑客可能僅僅回复"用我們提供的版本"。 在任何論壇發文以前，先確認一下有沒有搜尋功能。如果有，就試著搜尋一下問題的幾個關鍵詞，也許這會有幫助。 如果在此之前你已做過全面的網頁搜尋（你應該這樣去做），還是再搜尋一下論壇，搜尋引擎有可能沒來得及索引此論壇的全部內容。 @@ -121,26 +121,26 @@ __本指南不提供此專案的實際支援服務！__ * 大多數郵件列表都會被保存，那些被保存的內容將被搜尋引擎索引。如果你向列表提問並得到解答，將來其它人可以通過網頁搜尋找到你的問題和答案，也就不用再次發問了。 * 如果某些問題經常被問到，開發者可以利用此資訊來改進說明文件或軟體本身，以使其更清楚。 如果只是私下提問，就沒有人能看到最常見問題的完整場景。 -如果一個項目既有“使用者” 也有“開發者”（或“黑客”）郵件列表或論壇，而你又不會動到那些原始碼，那麼就向“使用者”列表或論壇提問。 不要假設自己會在開發者列表中受到歡迎，那些人多半會將你的提問視為干擾他們開發的噪音。 +如果一個項目既有"使用者" 也有"開發者"（或"黑客"）郵件列表或論壇，而你又不會動到那些原始碼，那麼就向"使用者"列表或論壇提問。 不要假設自己會在開發者列表中受到歡迎，那些人多半會將你的提問視為干擾他們開發的噪音。 -然而，如果你確信你的問題很特別，而且在“使用者” 列表或論壇中幾天都沒有回覆，可以試試前往“開發者”列表或論壇發問。 建議你在張貼前最好先暗暗地觀察幾天以了解那裡的行事方式（事實上這是參與任何私有或半私有列表的好主意） +然而，如果你確信你的問題很特別，而且在"使用者" 列表或論壇中幾天都沒有回覆，可以試試前往"開發者"列表或論壇發問。 建議你在張貼前最好先暗暗地觀察幾天以了解那裡的行事方式（事實上這是參與任何私有或半私有列表的好主意） 如果你找不到一個專案的郵件列表，而只能查到專案維護者的電子郵件地址，儘管向他發信。 即使是在這種情況下，也別假設（專案）郵件列表不存在。 在你的電子郵件中，請陳述你已經試過但沒有找到合適的郵件列表，也提及你不反對將自己的郵件轉發給他人（許多人認為，即使沒什麼秘密，私人電子郵件也不應該被公開。通過允許將你的電子郵件轉發他人，你給了相應人員處置你郵件的選擇）。 ## 使用有意義且描述明確的標題 ## -在郵件列表、新聞群組或論壇中，大約50字以內的標題是抓住資深專家注意力的黃金時機。 別用喋喋不休的“幫幫忙”、“跪求”、“急”（更別說“救命啊！ ！！！”這樣讓人反感的話，用這種標題會被條件反射式地忽略）來浪費這個機會。 不要妄想用你的痛苦程度來打動我們，相反，要在這點空間中使用最簡明扼要的描述方式來提出問題。 +在郵件列表、新聞群組或論壇中，大約50字以內的標題是抓住資深專家注意力的黃金時機。 別用喋喋不休的"幫幫忙"、"跪求"、"急"（更別說"救命啊！ ！！！"這樣讓人反感的話，用這種標題會被條件反射式地忽略）來浪費這個機會。 不要妄想用你的痛苦程度來打動我們，相反，要在這點空間中使用最簡明扼要的描述方式來提出問題。 -使用主題的好慣例是“目標──偏差”（式的描述），許多技術支持組織就是這樣做的。 在“目標”部分指明是哪一個或哪一組東西有問題，在“偏差”部分則描述與期望的行為不一致的地方。 +使用主題的好慣例是"目標──偏差"（式的描述），許多技術支持組織就是這樣做的。 在"目標"部分指明是哪一個或哪一組東西有問題，在"偏差"部分則描述與期望的行為不一致的地方。 蠢問題：救命啊！我的筆電不能正常顯示了！ 聰明問題：X.org 6.8.1的滑鼠游標會變形，某牌顯示卡 MV1005 晶片組。 更聰明：X.org 6.8.1的滑鼠游標，在 某牌顯示卡 MV1005 晶片組環境下 - 會變形 -編寫“目標──偏差”式描述的過程有助於你組織對問題的細緻思考。是什麼被影響了？ 僅僅是滑鼠游標或者還有其它圖形？只在X.org的X版中出現？或只是出現在6.8.1版中？ 是針對某牌顯示卡晶片組？或者只是其中的MV1005型號？ 一個黑客只需描一眼就能夠立即明白什麼是你遇到的問題，什麼是你自己的問題。 +編寫"目標──偏差"式描述的過程有助於你組織對問題的細緻思考。是什麼被影響了？ 僅僅是滑鼠游標或者還有其它圖形？只在X.org的X版中出現？或只是出現在6.8.1版中？ 是針對某牌顯示卡晶片組？或者只是其中的MV1005型號？ 一個黑客只需描一眼就能夠立即明白什麼是你遇到的問題，什麼是你自己的問題。 總而言之，請想像一下你正在一個只顯示標題的文件索引中查尋。 讓你的標題更好地反映問題，可使下一個搜索類似問題的人能夠在文件中直接就找到答案的線索，而不用再次提問相同的問題。 -如果你想在話題回覆中提出問題，記得要修改內容標題，以表明你是在問一個問題， 一個看起來像“Re: 測試” 或者“Re: 新bug”的問題很難引起足夠重視。另外，引用並刪減前文的內容，給新來的讀者留下線索。 +如果你想在話題回覆中提出問題，記得要修改內容標題，以表明你是在問一個問題， 一個看起來像"Re: 測試" 或者"Re: 新bug"的問題很難引起足夠重視。另外，引用並刪減前文的內容，給新來的讀者留下線索。 對於問題列表，不要直接點擊回覆（按鈕）來開始一個全新的話題（Thread），這將限縮你的觀眾。 因為有些郵件閱讀程序，比如mutt，允許使用者按話題排序並通過折疊話題來隱藏消息，這樣做的人永遠看不到你發的消息。 @@ -150,9 +150,9 @@ __本指南不提供此專案的實際支援服務！__ ## 使問題容易回覆 ## -以“請向……回复”來結束問題多半會使你得不到回答。如果你覺得花幾秒鐘在郵件客戶端設置一下回复地址都麻煩，我們也覺得花幾秒鐘考慮你的問題更麻煩。 如果你的郵件程式不支持這樣做，換個好點的；如果是作業系統不支持這種郵件程式，也換個好點的。 +以"請向……回复"來結束問題多半會使你得不到回答。如果你覺得花幾秒鐘在郵件客戶端設置一下回复地址都麻煩，我們也覺得花幾秒鐘考慮你的問題更麻煩。 如果你的郵件程式不支持這樣做，換個好點的；如果是作業系統不支持這種郵件程式，也換個好點的。 -在論壇，要求通過電子郵件回覆是非常無禮的， 除非你確信回覆的信息也許是敏感的（而且有人會為了某些未知的原因，只讓你而不是整個論壇知道答案）。 如果你只是想在有人回覆線索時得到電子郵件提醒，可以要求網頁論壇發送給你。 幾乎所有論壇都支持諸如“追蹤此話題”、“有回覆發送郵件提醒”等功能。 +在論壇，要求通過電子郵件回覆是非常無禮的， 除非你確信回覆的信息也許是敏感的（而且有人會為了某些未知的原因，只讓你而不是整個論壇知道答案）。 如果你只是想在有人回覆線索時得到電子郵件提醒，可以要求網頁論壇發送給你。 幾乎所有論壇都支持諸如"追蹤此話題"、"有回覆發送郵件提醒"等功能。 ## 用辭貼切，語法正確，拼寫無誤 ## @@ -160,9 +160,9 @@ __本指南不提供此專案的實際支援服務！__ 正確的拼寫，標點符號和大小寫很重要。一般來說，如果你覺得這樣做很麻煩，不想在乎這些，那我們也可以覺得麻煩，不在乎你的提問。 花點額外的精力斟酌一下字句，用不著太僵硬與正式──事實上，黑客文化很看重能準確地使用非正式、俚語和幽默的語句。 但它必須很準確，而且有跡象表明你是在思考和關注問題。 -正確地拼寫、使用標點和大小寫，不要將“its”混淆為“it's”，“loose”搞成“lose”或者將“discrete”弄成“discreet”。 不要全部用大寫，這會被視為無禮的大聲嚷嚷（全部小寫也好不到哪去，因為不易閱讀。Alan Cox[注：著名黑客，Linux內核的重要參與者]也許可以這樣做，但你不行。） +正確地拼寫、使用標點和大小寫，不要將"its"混淆為"it's"，"loose"搞成"lose"或者將"discrete"弄成"discreet"。 不要全部用大寫，這會被視為無禮的大聲嚷嚷（全部小寫也好不到哪去，因為不易閱讀。Alan Cox[注：著名黑客，Linux內核的重要參與者]也許可以這樣做，但你不行。） -一般而言，如果你寫得像是個[小白]（http://zh.wikipedia.org/zh-tw/小白），那多半得不到理睬。也不要使用即時通訊中的簡寫或[火星文]（http://zh.wikipedia.org/zh-tw/火星文），如將“的”簡化為“ㄉ”會使你看起來像一個為了少打幾個鍵而省字的小白。 更糟的是，如果像個小孩似地鬼畫符那絕對是在找死，可以肯定沒人會理你（或者最多是給你一大堆指責與挖苦）。 +一般而言，如果你寫得像是個[小白]（http://zh.wikipedia.org/zh-tw/小白），那多半得不到理睬。也不要使用即時通訊中的簡寫或[火星文]（http://zh.wikipedia.org/zh-tw/火星文），如將"的"簡化為"ㄉ"會使你看起來像一個為了少打幾個鍵而省字的小白。 更糟的是，如果像個小孩似地鬼畫符那絕對是在找死，可以肯定沒人會理你（或者最多是給你一大堆指責與挖苦）。 如果在使用非母語的論壇提問，**你可以犯點拼寫和語法上的小錯，但決不能在思考上馬虎**（沒錯，我們能弄清兩者的分別）。 同時，除非你知道回覆者使用的語言，否則請使用英語書寫。繁忙的黑客一般會直接刪除用他們看不懂語言寫的消息。 在網路上英語是通用語言，用英語書寫可以將你的問題在尚未被閱讀就被直接刪除的可能性降到最低。 @@ -174,17 +174,17 @@ __本指南不提供此專案的實際支援服務！__ * 使用MIME附件通常沒有問題，前提是真正有內容（譬如附帶的原始碼或patch），而不僅僅是郵件程式生成的模板（譬如只是消息內容的拷貝）。 * 不要發送整段只是單行句子但多次折回的郵件（這使得回复部分內容非常困難）。設想你的讀者是在80個字符寬的終端機上閱讀郵件，最好設置你的行折回點小於80字。 * 但是，也不要用任何固定列折回資料（譬如日誌檔案拷貝或會話記錄）。檔案應該原樣包含，使回复者確信他們看到的是與你看到的一樣的東西。 - * 在英語論壇中，不要使用'Quoted-Printable' MIME編碼發送消息。這種編碼對於張貼非ASCII語言可能是必須的，但很多郵件程式並不支援這種編碼。 當它們分斷時，那些文本中四處散佈的“=20”符號既難看也分散注意力，甚至有可能破壞內容的語意。 + * 在英語論壇中，不要使用'Quoted-Printable' MIME編碼發送消息。這種編碼對於張貼非ASCII語言可能是必須的，但很多郵件程式並不支援這種編碼。 當它們分斷時，那些文本中四處散佈的"=20"符號既難看也分散注意力，甚至有可能破壞內容的語意。 * 永遠不要指望黑客們閱讀使用封閉的專用格式編寫的文檔，諸如微軟公司的Word或Excel文件等。 大多數黑客對此的反應就像有人將還在冒熱氣的豬糞倒在你門口時你的反應一樣。 即使他們能夠處理，他們也很厭惡這麼做。 - * 如果你從使用Windows的電腦發送電子郵件，關閉微軟愚蠢的“聰明引用”功能，以免在你的郵件中到處散佈垃圾字符。 - * 在論壇，勿濫用“表情符號”和“HTML”功能（當它們提供時）。一兩個表情符號通常沒有問題，但花哨的彩色文本傾向於使人認為你是個無能之輩。 過濫地使用表情符號、色彩和字體會使你看來像個傻笑的小姑娘。 這通常不是個好主意，除非你只是對性而不是有用的回覆更有興趣。 + * 如果你從使用Windows的電腦發送電子郵件，關閉微軟愚蠢的"聰明引用"功能，以免在你的郵件中到處散佈垃圾字符。 + * 在論壇，勿濫用"表情符號"和"HTML"功能（當它們提供時）。一兩個表情符號通常沒有問題，但花哨的彩色文本傾向於使人認為你是個無能之輩。 過濫地使用表情符號、色彩和字體會使你看來像個傻笑的小姑娘。 這通常不是個好主意，除非你只是對性而不是有用的回覆更有興趣。 -如果你使用圖形用戶界面的郵件程式（如微軟公司的Outlook或者其它類似的），注意它們的預設配置不一定滿足這些要求。 大多數這類程式有基於選單的“查看原始碼”命令，用它來檢查發送文件夾中的消息，以確保發送的是沒有多餘雜質的純文本文件。 +如果你使用圖形用戶界面的郵件程式（如微軟公司的Outlook或者其它類似的），注意它們的預設配置不一定滿足這些要求。 大多數這類程式有基於選單的"查看原始碼"命令，用它來檢查發送文件夾中的消息，以確保發送的是沒有多餘雜質的純文本文件。 ## 準確描述問題並言之有物 ## * 仔細、清楚地描述問題的症狀。 - * 描述問題發生的環境（機器配置、作業系統、應用程式以及別的什麼），提供銷售商的發行版和版本號（如：“Fedora Core 4”、“Slackware 9.1”等）。 + * 描述問題發生的環境（機器配置、作業系統、應用程式以及別的什麼），提供銷售商的發行版和版本號（如："Fedora Core 4"、"Slackware 9.1"等）。 * 描述在提問前你是怎樣去研究和理解這個問題的。 * 描述在提問前為確定問題而採取的診斷步驟。 * 描述最近做過什麼可能有影響的硬體、軟體變更。 @@ -202,17 +202,17 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre ## 別動輒聲稱找到Bug ## -當你在使用軟體中遇到問題，除非你非常、非常的有根據，不要動輒聲稱找到了Bug。 提示：除非你能提供解決問題的源代碼補丁，或者對前一版本的回歸測試表現出不正確的行為，否則你都多半不夠完全確信。 對於網頁和文件也如此，如果你（聲稱）發現了文件的“Bug”，你應該能提供相應位置的替代文件。 +當你在使用軟體中遇到問題，除非你非常、非常的有根據，不要動輒聲稱找到了Bug。 提示：除非你能提供解決問題的源代碼補丁，或者對前一版本的回歸測試表現出不正確的行為，否則你都多半不夠完全確信。 對於網頁和文件也如此，如果你（聲稱）發現了文件的"Bug"，你應該能提供相應位置的替代文件。 請記得，還有許多其它使用者未經歷你遇到的問題，否則你在閱讀文件或搜尋網頁時就應該發現了（你在報怨前已經做了這些，是吧？）。 這也意味著很有可能是你弄錯了而不是軟體本身有問題。 -編寫軟體的人總是非常辛苦地使它盡可能完美。如果你聲稱找到了Bug，也就置疑了他們的能力，即使你是對的，也有可能會使其中的部分人感到不快。 此外，在主題中嚷嚷“Bug”也是特別不禮貌的。 +編寫軟體的人總是非常辛苦地使它盡可能完美。如果你聲稱找到了Bug，也就置疑了他們的能力，即使你是對的，也有可能會使其中的部分人感到不快。 此外，在主題中嚷嚷"Bug"也是特別不禮貌的。 提問時，即使你私下非常確信已經發現一個真正的臭蟲，最好寫得像是你做錯了什麼。 如果真的有臭蟲，你會在回復中看到這點。這樣做的話，如果真有蟲子，維護者就會向你道歉，這總比你搞砸了然後欠別人一個道歉要強。 ## 低聲下氣前還是要先做功課 ## -有些人明白他們不應該粗魯或傲慢地行事並要求得到答覆，但他們退到相反的低聲下氣的極端：“我知道我只是個可憐的新手，一個失敗者，但... ...”。 這既使人困擾，也沒有用，當伴隨著對實際問題含糊的描述時還特別令人反感。 +有些人明白他們不應該粗魯或傲慢地行事並要求得到答覆，但他們退到相反的低聲下氣的極端："我知道我只是個可憐的新手，一個失敗者，但... ..."。 這既使人困擾，也沒有用，當伴隨著對實際問題含糊的描述時還特別令人反感。 別用原始靈長類動物的把戲來浪費你我的時間，相對地，盡可能清楚地描述背景情況和你的問題。 這比低聲下氣更好地擺正了你的位置。 @@ -225,13 +225,13 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre 蠢問題： 我在編譯內核時接連遇到SIG11錯誤，我懷疑某條飛線搭在主板的走線上了，這種情況應該怎樣檢查最好？ 聰明問題： 我組裝的電腦（K6/233 CPU，FIC-PA2007主機板+威盛 Apollo VP2晶片組，256MB Corsair PC133 SDRAM）， 在編譯內核時，從開機20分鐘以後就頻頻產生SIG11錯誤，但是在頭20分鐘內從沒發生過相同的問題。 重新啟動也沒有用，但是關機一晚上就又能工作20分鐘。所有記憶體都換過了，沒有效果。相關部分的典型編譯記錄如下…。 -由於以上這點許多人似乎難以掌握，這裡有句話可以提醒你：“所有的診斷專家都來自密蘇里州。” 美國國務院的官方座右銘則是：“讓我看看”（出自國會議員威勒德。範迪弗在1899年時的講話：“我來自一個出產玉米，棉花，牛蒡和民主黨人的國家，滔滔雄辯既不能說服我，也不會讓我滿意。我來自密蘇里州，你必須讓我看看。“） 針對診斷者而言，這並不是懷疑，而只是一種真實而有用的需求，以便讓他們看到的是與你看到的原始證據盡可能一致的東西，而不是你的猜測與總結。所以，展示給我們看吧。 +由於以上這點許多人似乎難以掌握，這裡有句話可以提醒你："所有的診斷專家都來自密蘇里州。" 美國國務院的官方座右銘則是："讓我看看"（出自國會議員威勒德。範迪弗在1899年時的講話："我來自一個出產玉米，棉花，牛蒡和民主黨人的國家，滔滔雄辯既不能說服我，也不會讓我滿意。我來自密蘇里州，你必須讓我看看。"） 針對診斷者而言，這並不是懷疑，而只是一種真實而有用的需求，以便讓他們看到的是與你看到的原始證據盡可能一致的東西，而不是你的猜測與總結。所以，展示給我們看吧。 ## 按發生時間先後列出問題症狀 ## 問題發生前的一系列操作，往往就是對找出問題最有幫助的線索。因此，你的說明裡應該包含你的操作步驟，以及機器和軟體的反應，直到問題產生。 在命令行處理的情況下，提供一段操作記錄（如運行腳本工具所生成的），並引用相關的若干行（如20行）記錄會非常有幫助。 -如果當掉的程式有診斷選項（如-V的詳述開關），試著選擇這些能在記錄中增加除錯資訊的選項。 記住，“多”不等於“好”。試著選取適當的除錯級別以便提供有用的信息而不是將閱讀者淹沒在垃圾中。 +如果當掉的程式有診斷選項（如-V的詳述開關），試著選擇這些能在記錄中增加除錯資訊的選項。 記住，"多"不等於"好"。試著選取適當的除錯級別以便提供有用的信息而不是將閱讀者淹沒在垃圾中。 如果你的說明很長（如超過四個段落），在開頭簡述問題，接下來再按時間順序詳述會有所幫助。這樣黑客們在讀你的記錄時就知道該注意哪些內容了。 @@ -252,7 +252,7 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre 當你要求私下回覆時，此過程和回報都被中止。別這樣做，讓回覆者來決定是否私下回答──如果他真這麼做了，通常是因為他認為問題編寫太差或者太膚淺，以至於對其它人毫無意義。 -對這條規則存在一條有限的例外，如果你確信提問可能會引來大量雷同的回覆時，那麼“向我發電郵，我將為論壇歸納這些回覆”將是神奇的句子。 試著將郵件列表或新聞組從洪水般雷同的回覆中解救出來是非常有禮貌的──但你必須信守諾言。 +對這條規則存在一條有限的例外，如果你確信提問可能會引來大量雷同的回覆時，那麼"向我發電郵，我將為論壇歸納這些回覆"將是神奇的句子。 試著將郵件列表或新聞組從洪水般雷同的回覆中解救出來是非常有禮貌的──但你必須信守諾言。 ## 提問應清楚明確 ## @@ -262,11 +262,11 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre 要理解專家們所處的世界，請把專業技能想像為充裕的資源，而回覆的時間則是很珍稀的資源。 你暗中要求他們奉獻的時間越少，你越有可能從這些真正懂行而且真正很忙的專家那裡得到解答。 -所以，限定一下你的問題，以使專家辨識你的問題並回答時所需要付出的時間減到最少，這技巧對你取得答案相當有幫助–這技巧通常和簡化問題有所區別。 因此，問“我想更好的理解X，可否指點一下哪有好一點說明？”通常比問“你能解釋一下X嗎？”更好。 如果你的程式碼不能運作，通常請別人看看哪裡有問題，比要求別人替你改正要明智得多。 +所以，限定一下你的問題，以使專家辨識你的問題並回答時所需要付出的時間減到最少，這技巧對你取得答案相當有幫助–這技巧通常和簡化問題有所區別。 因此，問"我想更好的理解X，可否指點一下哪有好一點說明？"通常比問"你能解釋一下X嗎？"更好。 如果你的程式碼不能運作，通常請別人看看哪裡有問題，比要求別人替你改正要明智得多。 ## 當詢問有關程式碼的問題時 ## -別要求他人給你有問題的代碼除錯而不提示一下應該從何入手。 張貼幾百行的代碼，然後說一聲：“它不能運行”會讓你得不到理睬。 只貼幾十行代碼，然後說一句：“在第七行以後，本應該顯示 的，但實際出現的是鍵”比較有可能讓你得到回應。 +別要求他人給你有問題的代碼除錯而不提示一下應該從何入手。 張貼幾百行的代碼，然後說一聲："它不能運行"會讓你得不到理睬。 只貼幾十行代碼，然後說一句："在第七行以後，本應該顯示 的，但實際出現的是鍵"比較有可能讓你得到回應。 最有效描述程式問題的方式是提供最精簡的Bug展示測試用例。什麼是最精簡的測試示例? 那是問題的速寫;一小段程式片段剛好展示出程式不正常的行為，而不包含其他分散注意力的內容。 怎麼製作最精簡的測試示例?如果你知道哪一行或哪一段程式碼會造成產生問題的行為，複製下來並加入充足的程式碼以重現這個示例 （例如，足以讓這段程式碼能被編譯/直譯/被應用程式處理）。 如果你無法將問題縮減到一段特定的區塊，複製並開始移除不影響產生問題行為的程式碼。測試示例越小越好（查看話不在多而在精一節）. @@ -278,43 +278,43 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre 黑客們總是善於分辨哪些問題應該由你自己解決；因為我們中的大多數都曾自己解決這類問題。 同樣，這些問題得由你來搞定，你會從中學到東西。你可以要求給點提示，但別要求得到完整的解決方案。 -如果你懷疑自己碰到了一個家庭作業式的問題，但仍然無法解決， 試試在使用者群組，論壇或（作為最後一招）在專案的“使用者”郵件列表或論壇中提問。 儘管黑客們會看出來，但一些有經驗的使用者也許仍會給你提示。 +如果你懷疑自己碰到了一個家庭作業式的問題，但仍然無法解決， 試試在使用者群組，論壇或（作為最後一招）在專案的"使用者"郵件列表或論壇中提問。 儘管黑客們會看出來，但一些有經驗的使用者也許仍會給你提示。 ## 去除無意義的疑問 ## -避免用無意義的話結束提問，例如“有人能幫我嗎？”或者“有答案嗎？”。 +避免用無意義的話結束提問，例如"有人能幫我嗎？"或者"有答案嗎？"。 首先：如果你對問題的描述不很合適，這樣問更是畫蛇添足。 -其次：由於這樣問是畫蛇添足，黑客們會很厭煩你–而且通常會用邏輯上正確，但毫無意義的回答來表示他們的蔑視， 例如：“沒錯，有人能幫你”或者“不，沒答案”。 -一般來說，避免提“是或否”類型的問題，除非你想得到“[是或否]（http://homepages.tesco.net/~J.deBoynePollard/FGA/questions-with-yes-or-no-answers.html）”類型的回答。 +其次：由於這樣問是畫蛇添足，黑客們會很厭煩你–而且通常會用邏輯上正確，但毫無意義的回答來表示他們的蔑視， 例如："沒錯，有人能幫你"或者"不，沒答案"。 +一般來說，避免提"是或否"類型的問題，除非你想得到"[是或否]（http://homepages.tesco.net/~J.deBoynePollard/FGA/questions-with-yes-or-no-answers.html）"類型的回答。 -## 不要把問題標記為“急”，即使對你而言確實如此 ## +## 不要把問題標記為"急"，即使對你而言確實如此 ## -這是你的問題，而不是我們的。宣稱“緊急”（或“線上等”）極有可能事與願違：大多數黑客會直接刪除這種消息，他們認為這是無禮和自私地企圖得到即時與特殊的關照。 +這是你的問題，而不是我們的。宣稱"緊急"（或"線上等"）極有可能事與願違：大多數黑客會直接刪除這種消息，他們認為這是無禮和自私地企圖得到即時與特殊的關照。 有半個例外的情況是，如果你是在一些知名度很高，會使黑客們激動的地方使用程式，也許值得這樣去做。 在這種情況下，如果你有期限壓力，也很有禮貌地提到這點，人們也許會有足夠的興趣快一點回答。 -當然，這是非常冒險的，因為黑客們對什麼是令人激動的標準多半與你的不同。 譬如從國際空間站這樣張貼沒有問題，但代表感覺良好的慈善或政治原因這樣做幾乎肯定不行。 事實上，張貼諸如“緊急：幫我救救這個毛絨絨的小海豹！”肯定會被黑客迴避或光火，即使他們認為毛絨絨的小海豹很重要。 +當然，這是非常冒險的，因為黑客們對什麼是令人激動的標準多半與你的不同。 譬如從國際空間站這樣張貼沒有問題，但代表感覺良好的慈善或政治原因這樣做幾乎肯定不行。 事實上，張貼諸如"緊急：幫我救救這個毛絨絨的小海豹！"肯定會被黑客迴避或光火，即使他們認為毛絨絨的小海豹很重要。 如果你覺得這點很不可思議，最好再把剩下的內容多讀幾遍，直到你弄懂了再發任何文章也不遲。 ## 有禮貌絕沒有害處，而且有時是有益的 ## -彬彬有禮，多用“請”和“謝謝你的關注”，或“謝謝你的關照”。讓大家都知道你對他們花費時間義務提供幫助心存感激。 +彬彬有禮，多用"請"和"謝謝你的關注"，或"謝謝你的關照"。讓大家都知道你對他們花費時間義務提供幫助心存感激。 坦率地講，這一點沒有語法正確，文字清晰，準確，有內容和避免使用專用格式重要（同時也不能替代它們）。 黑客們一般寧可讀有點唐突但技術鮮明的臭蟲報告，而不是那種有禮但含糊的報告。 （如果這點讓你不解，記住我們是按問題能教我們什麼來評價問題的價值的） 然而，如果你有一串的問題待解決，客氣一點肯定會增加你得到有用回應的機會。 -（我們注意到，自從本指南發佈後，從資深黑客處得到的唯一嚴重缺陷反饋，就是對預先道謝這一條。 一些黑客覺得“先謝了”的言外之意是事後就不用再感謝任何人的暗示。我們的建議是要麼先說“先謝了”，事後再對回复者表示感謝， 要么換種方式表達，譬如用“謝謝你的關注”或“謝謝你的關照”。） +（我們注意到，自從本指南發佈後，從資深黑客處得到的唯一嚴重缺陷反饋，就是對預先道謝這一條。 一些黑客覺得"先謝了"的言外之意是事後就不用再感謝任何人的暗示。我們的建議是要麼先說"先謝了"，事後再對回复者表示感謝， 要么換種方式表達，譬如用"謝謝你的關注"或"謝謝你的關照"。） ## 問題解決後，加個簡短說明 ## 問題解決後，向所有幫助過你的人發個說明，讓他們知道問題是怎樣解決的，並再一次向他們表示感謝。 如果問題在新聞組或者郵件列表中引起了廣泛關注，應該在那裏貼一個補充說明比較恰當。 -最理想的方式是向最初提問的話題回覆此消息，並在標題中包含“已解決”，“已搞定”或其它同等含義的明顯標記。 在人來人往的郵件列表裡，一個看見線索“問題 X“號和”問題的X -已解決“的潛在回覆者就明白不用再浪費時間了（除非他個人覺得”問題 X“的有趣），因此可以利用此時間去解決其它問題。 +最理想的方式是向最初提問的話題回覆此消息，並在標題中包含"已解決"，"已搞定"或其它同等含義的明顯標記。 在人來人往的郵件列表裡，一個看見線索"問題 X"號和"問題的X -已解決"的潛在回覆者就明白不用再浪費時間了（除非他個人覺得"問題 X"的有趣），因此可以利用此時間去解決其它問題。 -補充說明不必很長或是很深入；簡單的一句“你好，原來是網線出了問題！謝謝大家–Bill”比什麼也不說要強。 事實上，除非結論真的很有技術含量，否則簡短可愛的小結比長篇學術論文更好。 說明問題是怎樣解決的，但大可不必將解決問題的過程複述一遍。 +補充說明不必很長或是很深入；簡單的一句"你好，原來是網線出了問題！謝謝大家–Bill"比什麼也不說要強。 事實上，除非結論真的很有技術含量，否則簡短可愛的小結比長篇學術論文更好。 說明問題是怎樣解決的，但大可不必將解決問題的過程複述一遍。 對於有深度的問題，張貼除錯記錄的摘要是有幫助的。 描述問題的最終狀態，說明是什麼解決了問題，在此之後才指明可以避免的彎路。 應避免的彎路部分應放在正確的解決方案和其它總結材料之後，而不要將此訊息搞成偵探推理小說。 列出那些幫助過你的名字，那樣你會交到朋友的。 @@ -328,9 +328,9 @@ Simon Tatham寫過一篇名為《[如何有效的報告Bug]（http://go2.wordpre ## RTFM和STFW：如何知道你已完全搞砸 ## -有一個古老而神聖的傳統：如果你收到“RTFM （Read The Fxxking Manual）”的回應，回答者認為你應該去讀讀該死的手冊。當然，基本上他是對的，你應該去讀一讀。 +有一個古老而神聖的傳統：如果你收到"RTFM （Read The Fxxking Manual）"的回應，回答者認為你應該去讀讀該死的手冊。當然，基本上他是對的，你應該去讀一讀。 -RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web）”的回應，回答者認為你應該已經到該死的網路上搜索過了。那人多半也是對的，去搜尋一下吧。 （更溫和一點的說法是“[Google是你的朋友]（http://lmgtfy.com/）！”） +RTFM有一個年輕的親戚。如果你收到"STFW （Search The Fxxking Web）"的回應，回答者認為你應該已經到該死的網路上搜索過了。那人多半也是對的，去搜尋一下吧。 （更溫和一點的說法是"[Google是你的朋友]（http://lmgtfy.com/）！"） 在論壇，你也可能被要求去爬爬論壇的舊文。事實上，有人甚至可能熱心地為你提供以前解決此問題的線索。 但不要依賴這種關照，提問前應該先搜索一下舊文。 @@ -345,7 +345,7 @@ RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web 如果你看不懂回應，別立刻要求對方解釋。像你以前試著自己解決問題時那樣（利用手冊，FAQ，網路，身邊的高手），先試著去搞懂他的回應。 如果你真的需要對方解釋，記得表現出你已經從中學到了點什麼。 -比方說，如果我回答你：“看來似乎是zentry被擋住了；你應該先清除它。”，然後，這是一個很糟的後續問題回應：“zentry是什麼？” 聰明的問法應該是這樣：“哦~~~我看過說明了但是只有-z和-p兩個參數中提到了zentry，而且還都沒有清楚的解釋:<你是指這兩個中的哪一個嗎？還是我看漏了什麼？”~~ +比方說，如果我回答你："看來似乎是zentry被擋住了；你應該先清除它。"，然後，這是一個很糟的後續問題回應："zentry是什麼？" 聰明的問法應該是這樣："哦~~~我看過說明了但是只有-z和-p兩個參數中提到了zentry，而且還都沒有清楚的解釋:<你是指這兩個中的哪一個嗎？還是我看漏了什麼？"~~ ## 應對粗魯的回應 ## @@ -355,9 +355,9 @@ RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web 另一方面，你偶而真的會碰到無禮和無聊的言行。與上述相反，對真正的冒犯者狠狠地打擊，用犀利的語言將其駁得體無完膚都是可以接受的。 然而，在行事之前一定要非常非常的有根據。糾正無禮的言論與開始一場毫無意義的口水戰僅一線之隔，黑客們自己莽撞地越線的情況並不鮮見。如果你是新手或外來者，避開這種莽撞的機會並不高。 如果你想得到的是信息而不是消磨時光，這時最好不要把手放在鍵盤上以免冒險。 -（有些人斷言很多黑客都有輕度的自閉症或阿斯伯格綜合症，缺少用於潤滑人類社會“正常”交往所需的神經。 這既可能是真也可能是假的。如果你自己不是黑客，興許你認為我們腦袋有問題還能幫助你應付我們的古怪行為。 只管這麼幹好了，我們不在乎。我們喜歡我們現在這個樣子，並且一般都對病號標記有站得住腳的懷疑。） +（有些人斷言很多黑客都有輕度的自閉症或阿斯伯格綜合症，缺少用於潤滑人類社會"正常"交往所需的神經。 這既可能是真也可能是假的。如果你自己不是黑客，興許你認為我們腦袋有問題還能幫助你應付我們的古怪行為。 只管這麼幹好了，我們不在乎。我們喜歡我們現在這個樣子，並且一般都對病號標記有站得住腳的懷疑。） -在下一節，我們會談到另一個問題，當你行為不當時所會受到的“冒犯”。# 如何避免扮演失敗者 # +在下一節，我們會談到另一個問題，當你行為不當時所會受到的"冒犯"。# 如何避免扮演失敗者 # 在黑客社區的論壇中有那麼幾次你可能會搞砸──以本指南所描述到的或類似的方式。 而你會在公開場合中被告知你是如何搞砸的，也許攻擊的言語中還會帶點夾七夾八的顏色。 @@ -367,9 +367,9 @@ RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web 社區的標準不會自行維持，它們是通過參與者積極而公開地執行來維持的。 不要哭嚎所有的批評都應該通過私下的郵件傳送，這不是事情運作的方式。 當有人評論你的一個說法有誤或者提出不同看法時，堅持聲稱受到個人攻擊也毫無益處，這些都是失敗者的態度。 -也有其它的黑客論壇，受過高禮節要求的誤導，禁止參與者張貼任何對別人帖子挑毛病的消息，並聲稱“如果你不想幫助用戶就閉嘴。” 結果造成有想法的參與者紛紛離開，這麼做只會使它們淪為毫無意義的嘮叨與無用的技術論壇。 +也有其它的黑客論壇，受過高禮節要求的誤導，禁止參與者張貼任何對別人帖子挑毛病的消息，並聲稱"如果你不想幫助用戶就閉嘴。" 結果造成有想法的參與者紛紛離開，這麼做只會使它們淪為毫無意義的嘮叨與無用的技術論壇。 -誇張的講法是：你要的是“友善”（以上述方式）還是有用？兩個裡面挑一個。 +誇張的講法是：你要的是"友善"（以上述方式）還是有用？兩個裡面挑一個。 記著：當黑客說你搞砸了，並且（無論多麼刺耳地）告訴你別再這樣做時，他正在為關心你和他的社區而行動。 對他而言，不理你並將你從他的生活中濾除要容易得多。 如果你無法做到感謝，至少要表現地有點尊嚴，別大聲哀嚎，也別因為自己是個有戲劇性超級敏感的靈魂和自以為有資格的新來者，就指望別人像對待脆弱的洋娃娃那樣對你。 @@ -462,7 +462,7 @@ RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web 問題：我在安裝Linux（或者X）時有問題，你能幫我嗎？ 回答：不能，我只有親自在你的電腦上動手才能找到毛病。還是去找你當地的Linux使用者群組尋求手把手的指導吧（你能在這兒找到用戶組的清單）。 -注意：如果安裝問題與某Linux的發行版有關，在針對它的郵件列表，論壇或本地使用者群組中提問也許是恰當的。 此時，應描述問題的準確細節。在此之前，先用“的Linux”和所有被懷疑的硬體[作關鍵詞]仔細搜索。 +注意：如果安裝問題與某Linux的發行版有關，在針對它的郵件列表，論壇或本地使用者群組中提問也許是恰當的。 此時，應描述問題的準確細節。在此之前，先用"的Linux"和所有被懷疑的硬體[作關鍵詞]仔細搜索。 --- @@ -480,9 +480,9 @@ RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web 蠢問題：我可以在哪兒找到關於Foonly Flurbamatic的資料？ -這種問法無非想得到“STFW”這樣的回答。 +這種問法無非想得到"STFW"這樣的回答。 -聰明問題：我用Google搜索過“Foonly Flurbamatic 2600”，但是沒找到有用的結果。誰知道上哪兒去找對這種設備編程的資料？ +聰明問題：我用Google搜索過"Foonly Flurbamatic 2600"，但是沒找到有用的結果。誰知道上哪兒去找對這種設備編程的資料？ 這個問題已經STFW過了，看起來他真的遇到了麻煩。 --- @@ -498,7 +498,7 @@ RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web 蠢問題：我的主板有問題了，誰來幫我？ -某黑客對這類問題的回答通常是：“好的，還要幫你拍拍背和換尿布嗎？”，然後按下刪除鍵。 +某黑客對這類問題的回答通常是："好的，還要幫你拍拍背和換尿布嗎？"，然後按下刪除鍵。 聰明問題：我在S2464主機板上試過了X、Y和Z，但沒什麼作用，我又試了A、B和C。 請注意當我嘗試C時的奇怪現象。顯然邊帶傳輸中出現了收縮，但結果出人意料。 通常在Athlon多處理器主機板上引起邊帶洩漏的通常原因是什麼？有誰知道接下來我該做些什麼測試才能找出問題？ 這個傢伙，從另一個角度來看，值得去回答他。他表現出了解決問題的能力，而不是坐等天上掉答案。 @@ -506,13 +506,13 @@ RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web --- -在最後一個問題中，注意“告訴我答案”和“給我啟示，指出我還應該做什麼診斷工作”之間微妙而又重要的區別。 +在最後一個問題中，注意"告訴我答案"和"給我啟示，指出我還應該做什麼診斷工作"之間微妙而又重要的區別。 事實上，後一個問題源自於2001年8月在Linux內核郵件列表上的一個真實的提問。我（Eric）就是那個提出問題的人。 我在Tyan S2464主板上觀察到了這種無法解釋的鎖定現象，列表成員們提供了解決這一問題的重要資訊。 通過我的提問方法，我給了別人可以咀嚼玩味的東西；我設法讓人們很容易參與並且被吸引進來。 我顯示了自己具備和他們同等的能力，並邀請他們與我共同探討。通過告訴他們我所走過的彎路，以避免他們再浪費時間，我也表明了對他們寶貴時間的尊重。 -事後，當我向每個人表示感謝，並且讚賞這次良好的討論經歷的時候， 一個Linux內核郵件列表的成員表示，他覺得我的問題得到解決並非由於我是這個列表中的“名人”，而是因為我用了正確的方式來提問。 黑客從某種角度來說是擁有豐富知識但缺乏人情味的傢伙；我相信他是對的，如果我像個乞討者那樣提問，不論我是誰，一定會惹惱某些人或者被他們忽視。 他建議我記下這件事，這直接導致了本指南的出現。# 如果得不到回答 # +事後，當我向每個人表示感謝，並且讚賞這次良好的討論經歷的時候， 一個Linux內核郵件列表的成員表示，他覺得我的問題得到解決並非由於我是這個列表中的"名人"，而是因為我用了正確的方式來提問。 黑客從某種角度來說是擁有豐富知識但缺乏人情味的傢伙；我相信他是對的，如果我像個乞討者那樣提問，不論我是誰，一定會惹惱某些人或者被他們忽視。 他建議我記下這件事，這直接導致了本指南的出現。# 如果得不到回答 # 如果仍得不到回答，請不要以為我們覺得無法幫助你。 有時只是看到你問題的人不知道答案罷了。沒有回應不代表你被忽視，雖然不可否認這種差別很難區分。 @@ -540,14 +540,14 @@ RTFM有一個年輕的親戚。如果你收到“STFW （Search The Fxxking Web 如果你決定回答，就請給出好的答案。當別人正在用錯誤的工具或方法時別建議笨拙的權宜之計，應推薦更好的工具，重新組織問題。 -幫助你的社群從中學習。當回覆一個好問題時，問問自己“如何修改相關文件或常見問題文件以免再次解答同樣的問題？”，接著再向文件維護者發一份patch。 +幫助你的社群從中學習。當回覆一個好問題時，問問自己"如何修改相關文件或常見問題文件以免再次解答同樣的問題？"，接著再向文件維護者發一份patch。 -如果你是在研究一番後才做出的回答，展現你的技巧而不是直接端出結果。畢竟“授人以魚，不如授人以漁”。# 相關資源 # +如果你是在研究一番後才做出的回答，展現你的技巧而不是直接端出結果。畢竟"授人以魚，不如授人以漁"。# 相關資源 # 如果需要個人電腦，Unix系統和網路如何工作的基礎知識，參閱[Unix系統和網路基本原理]（http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/）。 當你發布軟體或patch時，試著按[軟體發布實踐]（http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html）操作。 ## 鳴謝 -Evelyn Mitchel貢獻了一些愚蠢問題例子並啟發了編寫“如何更好地回答問題”這一節， Mikhail Ramendik貢獻了一些特別有價值的建議和改進。 +Evelyn Mitchel貢獻了一些愚蠢問題例子並啟發了編寫"如何更好地回答問題"這一節， Mikhail Ramendik貢獻了一些特別有價值的建議和改進。