FreeBSD Mailing Lists 常見問答集

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 發文時，請保持一行約 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 們十分不爽。

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

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

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

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

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

  • 答： Because it reverses the logical flow of conversation.

  • 問： Why is top posting frowned upon?

  (感謝 Randy Bush 提供笑話)