FreeBSD Mailing Lists 常見問答集

The FreeBSD Documentation Project

修訂: 44974

版權 © 2004-2006 FreeBSD 文件計畫

2014-05-29 16:48:07 由 lwhsu.

摘要

這是有關 FreeBSD mailing lists 的 FAQ。如果您對協助本文件/翻譯計畫的進行有興趣的話，請寄 e-mail 到 FreeBSD documentation project 郵遞論壇。此外，隨時可從 FreeBSD 網站 拿到這份文件的最新版本。也可以利用 HTTP 來下載 HTML 文件，或是經由 FreeBSD FTP 站 下載純文字、PostScript®、或 PDF 版本的檔案。您也可以在這裡使用搜尋 FAQ 資料的功能。

[ 章節模式 / 完整模式 ]

1. 前言

如同其他 FAQs 一樣，本文主要目的是希望涵蓋在 FreeBSD mailing lists 上面的常見問題(當然，包括答案)。雖然，原本構想是希望能降低這些重複問題的網路流量，但如今已被公認 FAQs 也是相當好用的資源之一。

本文主要是描述社群之間所培養的一些禮儀(或默契)，但本文本身並非『聖旨』般的權威。若發現本文內有任何技術瑕疵，或者是想建議可以增加哪些部分的話，請送 PR，或是 email 到 FreeBSD documentation project 郵遞論壇。謝囉！

1.1.

FreeBSD mailing lists 的目的為何？

FreeBSD mailing lists 主要是提供 FreeBSD 社群間的溝通管道，這裡有各式專題領域的探討，以及興趣交流。

1.2.

FreeBSD mailing lists 的參與者有哪些?

這個問題，要看各個 list 的『版規(charter)』定位而有所不同。有些 lists 主要是 developers 在參與討論的；而有些則主要是幾乎整體 FreeBSD 社群都可以隨意參與討論的。請看 這份清單 上面有目前所有 list 的摘要說明。

1.3.

FreeBSD mailing lists 對任何人都是開放參與的嗎？

再重複一次，這要看各個 list 的『版規(charter)』定位而有所不同。請在發文前，先注意閱讀該 list 的『版規(charter)』，並遵守相關原則。如此一來，才會讓大家都能溝通更無礙。

如果看了上一個問答內的清單之後，還是不清楚要到哪個 list 去發問的話，那麼可以試著把問題丟到 freebsd-questions 看看(但請先看下面講的補充)。

請注意：習慣上所有 mailing lists 都是開放發表討論的，也不必得先成為訂閱會員才行。這是相當審慎的選擇，來讓參與 FreeBSD 社群更輕鬆容易，並鼓勵互相分享彼此的想法。然而，由於過去有些人的濫用，有些 lists 現在開始限制參與討論的部分，以避免不必要的困擾。

1.4.

要怎麼訂閱呢？

可以用 Mailman 網頁介面 來訂閱任何公開的 lists。

1.5.

要怎麼退訂？

一樣請用剛上面說的網頁介面，或者 mailing list 上面每封信結尾處都會有相關 URL 連結的指示說明。

千萬請不要直接寫信到這些公開的 mailing lists 說你要退訂。首先呢..因為本來就不是這樣退訂的，其次你會惹來眾怒而招來圍剿、筆戰。這是很典型的退訂錯誤示範，請不要這樣做。

1.6.

可以找到舊信的資料庫嗎？

嗯，有！可以在 這邊找到相關的舊信資料庫(archive)。

1.7.

mailing lists 可有摘要版呢？

當然也有，請看 Mailman 網頁介面。

2. Mailing List 的參與禮儀

在 mailing lists 上參與討論，就像在其他社群一樣，我們都需要一些溝通上的共識。發言請注重禮儀(或默契)，切勿無的放矢。

2.1.

在發文之前，有什麼注意事項呢？

最重要的是你已經看了這篇文章，然而，若您對 FreeBSD 不熟的話，可能需要先廣泛閱讀相關書籍及文章來先熟悉這套作業系統和一些典故，尤其是其中的 FreeBSD 常見問答集 (FAQ) 文件， FreeBSD 使用手冊(Handbook)，以及相關文章： How to get best results from the FreeBSD-questions mailing list、 Explaining BSD、以及 FreeBSD First Steps。

此外，對上述文件內已有解答的部份又提出來問的話，會被認為是相當不禮貌的。這並不是因為這群志工是相當吝於回答的，而是一再被相同的問題不斷疲勞轟炸之後，所產生的挫折感很重。尤其是現成答案明明就在眼前，卻仍同樣問題滿天飛，這實在是...。請注意：這些 FreeBSD 相關文件幾乎都是由一群無薪志工的好心成果，而他們也是人。

2.2.

如何避免不當發文呢？

發文時，請務必遵守該 mailing list 的遊戲規則。

不要作人身攻擊。好的網路公民，應該要有更高的言行標準。

請不要試圖作 Spam 行為(廣告、轉貼多處等不請自來行為)。所有 mailing lists 都會積極禁止這些違規者，一旦有的話，那麼後果請自行負責。

2.3.

發文時，有什麼該注意的嗎？

發文時，請保持一行約 75 個字元就自動斷行，因為並不是每個看的人都有很炫的圖形介面(GUI)看信軟體。

請注意：事實上，網路頻寬並不是無限的。並非每個讀者的頻寬都很大，所以若想貼一些像是 config.log 之類的設定檔內容，或是大量的 stack trace 紀錄，那麼請把它放在自己網站上，然後貼出該網址 URL 就行了。還有一件事，請記住，這些信件都會被舊信資料庫保存下來，所以這樣作會造成保存的資料庫會很快被塞到很大，甚至可能塞爆 Server 的硬碟空間。

文章是要讓人看得懂，所以請注意版面編排的可讀性，還有.. 千　萬　不　要　大　聲　嚷　叫!!!!! 這點可不只 FreeBSD mailing lists 才需如此注意，請勿低估文章『基本編排』的重要性、連鎖效應。信中的表達方式通常就代表著別人眼中的你，若文章讓人看了很吃力(霧煞煞)、拼字錯誤百出、充滿語意或邏輯錯誤、或是文內充滿一堆驚嘆號，這會讓人對你印象觀感極差。

在一些特定的 list 場合，請用適當的語言來溝通。許多非英語系的mailing lists 可以到這邊 查看看。

對於許多母語不是英語的人，我們都能諒解他們的苦楚，並且試著儘量多多包涵。英文非母語的人，我們會儘量不惡意批評拼字或文法錯誤之處。 FreeBSD 在這方面，一直有相當優秀的紀錄，請讓我們繼續保持這傳統吧。

寫信時，請用相容標準的 Mail User Agent (MUA)程式。不良的(或設定錯誤的)寄信程式這裡列有許多信件格式的錯誤示範。以下是一些已知的寄信程式的不良示範：

cc:Mail

(舊版的)Eudora®

exmh

Microsoft® Exchange

Microsoft® Internet Mail

Microsoft® Outlook®

(舊版的)Netscape®

如同上述所見，Microsoft 出的一堆寄信程式通常都是不相容標準格式的。請儘量改用 UNIX® 上的寄信程式。若必須在 Microsoft 環境下使用寄信程式的話，請記得確認設定是否正確。請儘量不要用 MIME 格式：因為有一堆人都在濫用 MIME 信件格式。

請確認：時間與時區設定是否正確。這問題看起來有點蠢，因為你寄出的信還是會到達 mailing list 上，但是呢，每位 mailing lists 上的訂戶每天都會看數百封的信，他們通常會把信件以標題跟時間作為排序依據。若你的信沒有在第一篇正解之前就先出現的話，他們就會假設可能是漏收你這封信，然後就沒再去看你那封信了。

請提供程式出現的相關訊息，像是 dmesg(8) 或者 console messages 也就是通常會出現在 /var/log/messages 出現的。請不要用手打，因為這不僅很苦，而且也可能打錯字或亂掉原有格式。請直接把相關的 log 檔丟出來，或是用編輯器來剪裁、或是用滑鼠複製/貼上來完成。舉個例子，如果是要把像是 dmesg 的程式訊息倒入到某個檔案去的話，那麼作法如下：

% dmesg > /tmp/dmesg.out

這樣子會把訊息送到 /tmp/dmesg.out 檔內。

在用滑鼠剪貼時，請注意是否有犯一些細節的剪貼壞習慣。尤其是像貼 Makefiles 之類檔案時，由於 tab 鍵所打出來的分格，是屬於特殊字元。因此，在 GNATS PR 資料庫 上很常看到這類很常見的惱人問題： Makefiles 內的 tab 經過剪貼後，變成『空白(white space)』或是困擾的 =3B escape sequence，這些會讓 committers 們十分不爽。

2.4.

在 mailing lists 上回文的話，有什麼要特別注意的嗎？

請適當調整文章引言長度。回文時，引言部份請引『有談到的』部分為主，但請不要過與不及。應該保留涉及討論範圍的原文，這樣子才能讓沒看過前面文章的人知道是在講什麼，而非一頭霧水。

還有一點也很重要，原文若是幅度相當長的話，記得註明 "yes, I see this too"。

善用技巧來確認原文與自己寫的部份：通常會在原文的每行前面加上 “> ” 以作記號。請記得保留 “> ” 符號後面的空白，並且在原文以及你所寫的段落之間加上空行，以便閱讀。

請不要斷章取義、穿鑿附會：通常對原始文章『斷章取義』、『穿鑿附會』會讓大家很不爽，因為他們原意並非如此，卻被曲解。

回文時，不要寫在原文上面(top post)。這個意思是：若要回文時，請寫在原文下方，不要寫在原文上面，以免讓人有時空錯置的錯亂混淆。

答： Because it reverses the logical flow of conversation.

問： Why is top posting frowned upon?

(感謝 Randy Bush 提供笑話)

3. Mailing Lists 上的重複性問題

在 mailing lists 上參與討論，就像在其他社群一樣，我們都需要一些溝通上的共識。許多 mailing lists 都會假設參與討論者都大致知道 FreeBSD 計劃的一些歷史淵源。尤其是社群的新手總是定期會不斷重複問類似問題。每個發文的人，都有責任來避免掉入這樣的惡性循環輪迴內。因此，應儘可能讓 mailing list 上能正常討論，而避免讓自己陷入筆戰泥沼。

要怎麼避免呢？最好的方法就是善用這些 mailing list 舊信資料庫(archives)，來瞭解相關背景。正由於這原因，所以 mailing list 搜尋介面 就顯得非常好用。 (若這方法仍無法找到有用的答案，那麼請改用自己愛用的搜尋引擎吧)

透過這些舊信資料庫，不只可瞭解先前討論過哪些話題，也可以知道：是怎麼討論的、哪些人參與討論過、主要看的人又是哪些人。入境隨俗這些原則不只是 FreeBSD mailing list 上才這樣，一樣可以適合其他地方。

archives 的內容無疑地相當廣泛，而且會有些問題不斷反覆出現，有時討論到後面總會離題。無論如何，在發問前的義務就是先做好功課，以避免這類的月經文惡性循環，尤其是令人反感的 bikeshed（打嘴砲)。

4. 什麼是 "Bikeshed" 呀？

單就字面上意思解釋的話，bikeshed 是指專門給腳踏車、機車之類的兩輪交通工具使用的遮雨棚，然而呢，在 FreeBSD 這邊的說法卻有其他意思(帶有貶抑)指的是：某些特定話題的重複討論，尤其是指在 FreeBSD 社群內絕不會有共識，且有爭議的話題。 (這字彙的起源在這份文件 內有更多說明)。你只要在發信到任一 FreeBSD mailing lists 之前，知道這個基本概念就行了。

一般來講，『bikeshed』是很容易產生許多波的筆戰與額外討論的爭議話題，如果事先不知道這些背景的話。

拜託，請幫個忙讓討論回歸正常，而不要只是到處打嘴砲而已。感恩！

5. 致謝

Greg Lehey

How to get best results from the FreeBSD-questions mailing list 一文的原作者，我們從他這文內獲得許多 mailing list 上的禮儀(或默契)寫作題材。

Mark Linimon

本 FAQ 雛形的原作