Chapter 16 其它各式各樣的問題

FreeBSD僅是看起來置換空間(swap)用的比Linux多而已。在事實上， 並不然。主要的差異是在於，FreeBSD積極的將閒置無用的主記憶體內容 推入置換空間(swap)中，以使得主記憶體可以更為有效率的被使用。而 Linux的策略是將置換空間(swap)用來作為解決記憶體問題的最終手段。 較頻繁的使用置換空間(swap)。是一種更有效率的使用主記憶體的手段。

註：當一方面FreeBSD積極的使用置換空間(swap)的同時，你必需注 意到，FreeBSD並不會任意的將所有的東西都推入置換空間(swap)中。如此， 你才不會在一夜宿醉起床後發現，整個系統都被倒進了置換空間(swap)之中。

簡單的答案是，所有未使用到的閒置記憶體都是被浪費的記憶體， 任何未被你的程式所利用到的記憶體將被核心(kernel)用來當 作磁碟快取(disk cache)。而這種記憶體被 top(1) 標記為 閒置的(Inact)，快取(Cache)， 以及 緩衝區(Buf)，並負責在各個不同的位置負責 暫存資料。被暫存(cached)的資料代表系統不需要去存取較慢的磁碟裝置 就可以得到資料，如此，可以提升系統的效能。總而言之，top(1) 顯示出較少的 閒置(Free) 記憶體是好的，只要顯示 出來的值不是 非常 的低。

要了解為什麼Freebsd使用 ELF 格式，你有必 要先認識一下三種在目前 Unix 系統中最被廣泛應用到的執行檔格式：

• a.out(5)

  這是最早，同是也是 “最典型” 的Unix目的檔 格式。這種格式的檔案使用一種短且緊密的檔頭，同時，伴隨著一 個魔術數字用來辨識格式。(參考 a.out(5) 有更多詳細的說 明)。它包含有三個節區： .text .data 及 .bss 加上一個符號表 及字串表。

• COFF

  SVR3目的檔格式。檔頭包含了一個節區表，所以可以具備比 .text .data .bss 還多的節區。

• ELF

  ELF為 COFF 格式的後繼者，主要的特徵為 可以具有複數節區段，並可以使用32-bits或是64-bits的數值。 主要的缺點為： ELF 格式是在每個系統中只 會有一種 ABI 的假設為前題被設計出來的。但是，在事實上，這個 假設錯的離譜。因為，縱使在商用的 SYSV 世界裡，也至少有 SVR4， Solaris 和 SCO 三種 ABI。

  譯註：ABI(Application Binary Interface)。如果一定要翻譯， 就叫它 應用程式二進位介面 好了。 ABI被發 展出來的用意，是為了促使在相同CPU所發展出來的應用程式，能夠 在不同的系統上，作到二元檔(Binary Code)相容。比方說， Sun 所提出的 Solaris ABI ，保證執行檔能夠在相同 CPU 的 Solaris 系統上執行，另一個例子是 Windows 系統。同屬於 Intel x86 版本的執行檔能夠自由的在Windows 9x/me及Windows NT/2k/XP之間執行。

  FreeBSD提供一個公用程式將程式所需的ABI資訊烙上，藉此試著 去解決這個問題。請參考 brandelf(1) 以取得更多資訊。i

FreeBSD 來自 “傳統” 的陣營。在傳統上，FreeBSD都 使用 a.out(5) 格式，這樣的技術在好幾代的 BSD 都被證明是可靠的。 雖然，在FreeBSD上可以建立以及正確的執行原生 ELF 格式檔案(包含核心)。然而, FreeBSD在一開始反對將預設格式轉換為 ELF， 為什麼呢？當Linux開始痛苦的轉換至 ELF 格式時， 並非是為了要逃離 a.out 格式。相反的，這是因 為之前 Linux的共享函式庫(shared libraries)採用以跳躍表格 (jump-table)為基礎的技術去設計。這是一種讓發展者感到困擾，且非常 難以使用，不具足夠彈性的方法。既然，已經存在的 ELF 工具提供了共享函式庫(shared libraries)的解 決方案，而且，那看起來是個 “前衛的方法”，因此，所需 的轉換代價就可接受因而轉換。

在FreeBSD的狀況中，我們的共享函式庫(shared libraries)機制和 SunOS 的型式非常相近，且易於使用。然而， 從 3.0 開始，FreeBSD 正式將 ELF 改為預設格式。 雖然，a.out 格式依舊如以往般的好，但是，我們 編譯工具的撰寫者，GNU 的成員，他們中止了對 a.out 格式的支援與維護。在這種狀況下，迫使 我們必須自行維護另一份版本的 compiler 和 linker，也使得我們無法 從最新的 GNU 發展成果中獲得好處。此外，對 ISO-C++ 的需求，尤其是 建構子(constructors)和解構子(destructors)，也帶動未來版本中對 ELF 的原生支援。

在黑暗而遙遠的過去，僅有簡陋的硬體存在。而因為硬體簡陋，當然也 只能執行小而簡單的系統。a.out 格式是基於那個時代所需要，而被創造 出來的(例如像PDP-11)。在這之後，許多人試著將 Unix 移植到其他平台 時，他們也保留了 a.out 格式的執行檔。因為，這對早期的 Motorola 68k， VAXen 之類的系統已經足夠使用了。

然而，人並不會滿足於現狀。一些聰明的硬體工程師想到了，如果能 讓軟體多處理一些事，那 CPU 的電晶體數就能少一點，並且跑得更快。要 在這種新式的硬體上工作(現在稱為RISC)，a.out 這種格式就不合適了。基於這樣的現實所需，更多的執行檔格式被發展出 來，以提供比簡單且受到許多限制的 a.out 格式 更好的效能。比方像是 COFF， ECOFF，已及一些較不為人所周知的格式紛紛被創造 出來。但是，這些格式都已達到各自的極限，直到有一天 ELF 的出現。

此外，當程式的體積越來越大，而磁碟空間和主記憶體相對來說都較 小時，共享函式庫(shared libraries)的觀念被發展出來了。在這同時， 虛擬記憶體系統(VM System)也變得越來越精巧。當每一種進步都在 a.out格式上被發展出來時，它的可用性也同時變 得越來越低。另外，人們還希望程式能在執行期間動態載入，或是將已經 執行過且沒有用的初始化程式碼丟棄，藉以節省更多的記憶。程式語言在 這個時期也便得更精巧，人們也希望在 main 之前自動的執行更多的東西。 因此，許多繁雜且另人嘆為觀止的技巧被用在 a.out 格式上去解決這些問題。但是，由於 a.out 格式 先天的限制，要解決這些問題必需付出更多的代價及時間成本，並讓程式 的複雜度大為提升。而 ELF 格式可以一舉解決這一 切問題。但是，要將整個系統從根本轉換過去，將會有不短的陣痛期，因 此， ELF格式將會有一陣子與 a.out 並存。

然而，隨著時間的過去，FreeBSD的 build tools 演化成平行的兩個 支線(尤其是組譯器和載入器)。FreeBSD這條路加進了共享函式庫 (shared libraries)並修正了一些錯誤。而原來發展這些程式的 GNU 成員 則為了因應現況，重寫了這些程式，以更簡單的方式對跨平台編譯 (building cross compilers)，以及多種格式 (plugging in different formats) 作出了支援。許多人想作出以 FreeBSD 為目的平台的跨平台編譯器。但不幸的是，FreeBSD 的 as 和 ld 不能作 這項工作。新的 GNU 工具程式加入了跨平台編譯 (Cross Compiler)， ELF格式支援，共享函式庫(shared libraries)， C++ 的擴充... 等等。此外，許多廠商以 ELF 格式 發行其產品，如果這些東西能在 FreeBSD 上執行的話當然是最好的。既然， 能夠執行 ELF 格式的執行檔了，為什麼還須要 a.out 呢？它已經是一匹垂垂老矣的馬了，在竭力 盡忠的奉獻這麼多年之後，該是讓它在牧場肥沃的草地上好好休息的時候 了。

ELF 格式比 a.out 具有更良好的展現能力，並 且在底層系統中具有更多的可擴展性。ELF 工具程式 更容易被維護，且提供跨平台編譯的支援，這一點對很多人來說是很重要 的。ELF 格式可能比 a.out 慢一點，但是其差異非 常難測量出來。這兩者間還有許多細節上的不同，比方說分頁對應的方式， 程式碼初始化的方法...等等。這些並不是很重要，但是，兩者就是不同。 以後，GENERIC 核心(kernel)將會移除對 a.out 格式。當不在有執行傳統 a.out 程式的須要時， 將會從核心(kernel)中移除。

Symlinks 本身並沒有存取權限，同時，在預設的狀況下， chmod(1) 將不會跟隨著 symlinks 去改便目標檔案的存取權限。因此， 如果你有一個檔案 foo，同時，有一個 symlink bar 指向這個檔案，以下這個命令將永遠會成功 的被執行。

% chmod g-w bar

然而，在 foo 上的存取權限將不會被改 變。

你必需使用 -H 或是將 -L 與 -R 選項一起使用，參考 chmod(1) 以及 symlink(7) 以取得更多的資訊。

你可能認為修改 UT_NAMESIZE 後在重新編譯整個 系統是很容易的事。而且在這之後，每件事都可以運作的很好。不幸的是， 有許多的程式和工具(包含系統工具)把數字寫死在程式裡頭(並非總是 8 或 9，有時可能是古怪的 15 或 20)。這不僅僅是會將 你的系統記錄檔弄壞而已(來自於變動長度和固定長度記錄的差異)，同時 也會破壞 Sun 的 NIS Client 的運作。同時，和其他的Unix系統之間也 有可能會產生未知的問題。

在FreeBSD 3.0 及之後的版本，帳號的最大長度增加到16個字元， 同時，那些將長度寫死的程式也被找出來並作了適當的修正。正因為影響 系統的範圍很廣，所以直到3.0版之後才算大致修正完成。

如果你有自信在出問題的時後能自行解決，你可以利用下面的方法讓 較早期的版本支援較長的帳號。首先，修改 /usr/include/utmp.h 中的UT_NAMESIZE。 然後，你必須把 /usr/include/sys/param.h 中的 MAXLOGNAME 改成跟 UT_NAMESIZE 相同。最後，如果你是從原始程 式建立系統, 別忘了 /usr/include 每次都會被更新。 修改 /usr/src/.. 中適當的檔案。

是的，自3.0版起你可以使用BSDI的 doscmd DOS 模擬器，如果你對這個東西 有興趣，或是想加入發展行列，請寄一封電子郵件到 FreeBSD-emulation mailing list 。

對於3.0之前的系統，在 ports 中有一套軟體可以模儗 8088，並提 供足夠的BIOS中斷服務以執行DOS文字模式的程式，這套軟體叫做 pcemu，同時，運行它須要 X Windows(由XFree86提供)。

參閱FreeBSD文件中的 翻譯常見問答。

FreeBSD.org 的郵件系統對於進來的郵件採取嚴格的檢查，並且退回 所有設定不正確，或是潛在的垃圾郵件。你的郵件被退回可能是因為下列 原因所引起：

• 這封電子郵件來自已知的垃圾郵件區域或是IP中。

  FreeBSD郵件伺服器將拒絕接收已知的垃圾郵件來源的電子郵件。 如果提供你網路服務的公司或是網域中有產生過垃圾郵件或是有垃圾 郵件轉播站，請你換一個服務提供者，或是乾脆放棄。

• 電子郵件的本文僅有HTML。

  郵件應該已純文字格式發送，請設定你的電子郵件軟體送出純文 字格式。

• FreeBSD的郵件處理程式無法由IP反查送件主機的IP。

  設置 DNS 反查是接受一台主機郵件的一個標準要求，請為您的郵件 主機設置 DNS 反查。許多提供家庭網路服務 (DSL，cable，dialup 等) 的公司並不提供這樣的服務。在這種情況下，請透過網路服務提供者的 郵件伺服器送出您的電子郵件。

• 在 SMTP 使用 EHLO/HELO 命令時所給予的 hostname 無法被解析到 一個 IP 位置。

  在郵件被接受以前，一個充分合格，且可被解析的主機名稱在 SMTP 協定的對談中是必要的。如果你沒有在 DNS 伺服器中登記你 的主機名稱，請透過網路服務提供者的郵件伺服器送出您的電子郵 件。

• 你的訊息中夾帶著一個 message ID 以 “localhost” 字串結束。

  某些郵件軟體產生某些不正確的 message ID，這將不被接受。 你必需更改設定讓你的郵件軟體產生正確的 message ID，如果這無 法解決，考慮說服你的郵件軟體作者更新程式以處理這個問題。

FreeBSD的伺服器本身不提供任何對外的服務，其他的單位中， 有人提供開放的 Unix 系統服務。其中有些可能要收取些許費用。

Arbornet, Inc， 也被稱為 M-Net，自 1983 年起就開始提供 Unix 系統服務。一開始， 他們使用 Altos 並執行 System III。他們在 1991 年轉換系統成為 BSD/OS。在 2000 年六月，他們再度更換成為 FreeBSD。M-Net 能讓使 用者透過 SSH 及 telnet 連線到主機，並提供完整的 FreeBSD 軟體以 供使用。然而，M-Net 作為一個非盈利組織運行，存取權只限於成員和 贊助者，M-Net 也提供 BBS 系統和網路聊天服務。

Grex 提供了非常 類似 M-Net 的服務，包括了 BBS 系統和網路聊天。然而，機器是使用 Sun 4M，並執行 SunOS。

SUP 的意思是 Software Update Protocol，由 CMU 發展， 用來維持整個發展的同步。我們利用它保持遠端的站台和原始站台之間 的同步工作。

然而，SUP 在頻寬的使用上並不太友善，同時，目前也不再使用了。 目前建議維持原始碼同步更新的方法是 CVSup。

似乎，他並沒有一個正式的名字，姑且就稱其為 “BSD 小惡魔” 吧。如果你執意要使用一個名字。那就叫他 “小動物(beastie)” 吧。註：“beastie” 在讀音上跟 “BSD” 很接近。

你可以在BSD小惡魔的 主頁 上取得更多的資訊。

也許吧，我也不確定。BSD小惡魔圖案的版權是屬於馬歇爾蘇格蘭教會的 Marshall Kirk McKusick 所擁有。你可以試著去查看網頁關於BSD小惡魔肖像 以取得更詳細的使用細節。

總而言之，如果你純粹為了自己想要鑑賞，那麼，你可以自由的使用肖像。如果你是個人使用，只要情況適當，應該都會被許可。 如果你想在商業上使用，則你必需聯繫蘇格蘭教會的 Kirk McKusick 以取得許可。 如果你需要更進一步詳細的資訊，請參考 BSD小惡魔的首頁。

你可以在 /usr/share/examples/BSD_daemon/ 找到 Xfig 及 eps 兩種格式的圖檔。

請參閱 FreeBSD 字彙表。

最短最短的答案是：『不用在意』。稍微長一點的答案是：『雖然你有能力自己去建造一座腳踏車車棚，但是， 這不代表因為你不喜歡現在這個車棚的顏色，就要中止他的建築。』這個比喻的意思是， 你不需要去爭論每一個細項特徵，只因為你有辦法去作它。 某些人的評論是：『雜音的程度，與變化的複雜性是成反比』。

更長且較完整的答案是，在經過長時間爭論關於是否該將 sleep(1) 的秒參數移除，Poul-Henning Kamp <phk@FreeBSD.org>發表了一篇長論 “ 在青翠草地上的腳踏車車棚(任何顏色的)...”。以下，僅摘要該則文章部分內容：