不是這樣的。如果你的意思是： ``為甚麼我的 swap 看起來滿了？'' 那是因為把東西放在 swap 裡後拿回來的速度會比 pager 經由檔案系 統拿回(未修改)的執行碼快。
事實上，記憶體中 dirty pages 的量並未減少； clean pages 則在需 要的時候移走。
要了解為甚麼 FreeBSD 使用 a.out 格式，首先你要知道一些 目前 Unix 中使用最廣泛的三種格式：
最早和`古典'的 unix 目的檔格式。使用一種短而緊密的檔頭， 伴隨一個通常用來辨認格式的魔術數字(參考 a.out(5) 有更多細節)。具有三個節區：.text，.data，和.bss 加上一個符號表和字串表。
COFF
SVR3 目的檔格式。檔頭包含了一個節區表，所以可以具備比 .text，.data，.bss 還多的節區。
ELF
COFF 的後繼者，具有多個節區以及 32-bit 或 64-bit 的 possible values。主要的缺點：ELF 是在每個系統架構只 會有一種 ABI 的假設下設計出來的。事實上這個假設錯的離譜， 即使是商業的 SYSV 世界，也至少有 SVR4，Solaris，SCO 三種 ABI。
FreeBSD 藉由一個工具，把程式需要那種 ABI 的資訊 烙印 在 ELF 執行檔上。 參考 man page brandelf 取得更多資訊。
FreeBSD 來自 "古典" 陣營，傳統上都使用 a.out 格式，這是在好幾代的 BSD 中證明可靠的計術。 雖然可以在 FreeBSD 上可以建立以及執行原生的 ELF 執行檔( 以及核心)，剛開始 FreeBSD 反對轉換到以 ELF 做為預設的 格式。為甚麼？嗯，當 Linux 開始痛苦地轉換至ELF，並非因為要逃離 a.out格式，而是因為他們沒有彈性的，以跳躍表為基礎的共享程式庫機制。那是一種非常難以使用，發展 者不喜歡的東西。既然已經存在的ELF工具提供了共享程式庫的解決方案，而且看來是"前衛的方法" ，所需的代價就可接受因而轉換。
在 FreeBSD 的狀況中，我們的共享程式庫機制更接近 SunOS 的 型式，也就是，易於使用。然而，從 3.0 開始，FreeBSD 正式支援 ELF 為預設格式。 即使a.out 格式仍然非常好，我們編譯工具的撰寫者，GNU 的成員， 已中止了對，a.out 格式的支援。這迫使我們維護另一份版本的 compiler 和 linker ，也使得我們不能從最新的 GNU 發展成果中獲得好處。此外對 ISO-C++ 的需求，尤其是建構者和解構 者，也帶動未來版本中對 ELF 的原生支援。
在黑暗的過去，只有簡陋的硬體。簡陋的硬體僅支援小型、簡單的系統。 a.out 在簡單的系統上勝任愉快 (PDP-11)。當 unix 移植到其他平台時， a.out 保留了下來，因為對早期的 Motorola 68K，VAX 之類的架構已經 夠用了。
然後有些聰明的硬體工程師覺得讓軟體多做點事，那 CPU 的電晶體就能少一點而跑的更快。要在這種 新式硬體上工作(現在稱為RISC)， a.out 就不適合了，所以許多的格式就發 展出來，以提供比受限制而又簡單的 a.out 更好的效能。像是 COFF， ECOFF，以及一些比較不出名的格式，每一種 都被創造出來，但是卻都達到各自的極限，直到 ELF 出面解決這一切。
此外，當程式越來越大而磁碟(以及主記憶體)相對來說較小時，共享程式庫的概念就發展出來了， 虛擬記憶體系統也變得越來越精巧。當每一種進步都在 a.out 上完成時， 它的可用性也越來越低。另外，人們還要在執行時期可以動態載入，或是丟棄執行過的初始化程式 以節省記憶體。程式語言也變得更精巧而且人們想要在 main 之前執行別的程式碼。許多繁雜的技巧 用在a.out 上以解決這些問題。a.out 要解決這些 問題需要越來越多額外的負擔和複雜度。ELF可以輕易的解決這些問題，但是 從基本上可以工作的系統轉換成 ELF 卻很棘手。所以要等到維護 a.out 比轉換到 ELF 棘手。
然而，隨著時間過去， FreeBSD 的 build tools 形成了平行的兩支 (尤其是組譯器和 loader)。FreeBSD 這支加進了共享程式庫以及修正了 一些錯誤。原來撰寫這些程式的 GNU 成員則重寫了這些程式，以更簡單 的方式支援跨平台編譯、多種格式等等。許多人想要做出以 FreeBSD 為 目的平台的跨平台編譯器，不幸的是 FreeBSD 的 as 和 ld 不能做這項 工作。新的 GNU 工具(binutils)加入了跨平台編譯、ELF、共享程 式庫、 C++ 擴充，等等。此外，許多廠商以 ELF 格式發行產品， 而能夠在 FreeBSD 上跑的話當然很好。而且如果能跑 ELF 格式的 執行檔，為甚麼還要理 a.out ？牠是一匹又累又老的馬，過去非常 有用，但是時候讓牠退休了。
ELF 比 a.out 更應有表達力(expressive？)而且具有更多的 擴充性。ELF工具維護的比較好，而且提供跨平台編譯的支援， 這對許多人來說是很重要的。ELF 可能比 a.out 慢一點，但差異 非常難測量出來。這兩者之間還有許多細節上的不同，例如分頁的對應方式，初始化程 式碼的作法等等。這些並不是很重要，但就是不同。在以後 GENERIC 核心不會支援 a.out ，當不再有執行傳統 a.out 程式 的需要時，會從核心移除。
你必須把 ``-H'' 或是 ``-L'' 與 ``-R'' 選項一起使用. 參考 chmod 及 symlink man pages 以取得更多資訊.
警告： ``-R'' 選項會讓 chmod 做遞迴。用在目錄或是連結到目錄的符號連結時要小心。如果你要改變一個符號連結參 考到的目錄之存取權限，使用 chmod 且不要 加任何選項，並且在 symlink 的結尾加上斜線(``/'')。舉例來說 ，如果 ``foo'' 連結到 ``bar''，而你要更改 ``foo'' 的 權限 (事實上是 ``bar'')，那就用：
chmod 555 foo/
結尾的斜線，會讓 chmod 改變 ``foo'' 指向的 ``bar'' 目錄的權限。
你會認為修改 UT_NAMESIZE然後重建系統是很簡單的事情，而且每件事都可以運作地很好。不幸的是， 有許多的程式和工具(包含系統工具)把數字寫死在程式裡(並非總是 8 或 9，有時是古怪的 15、20等等)。 這不只會把你的記錄檔弄壞(來自於變動長度和固定長度記錄的差異)，也會破壞 Sun 的 NIS 客戶端的運作，和其它 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 rundos DOS 模擬器。如果你對這個東西有興趣，送封信到 The FreeBSD emulation 討論區。
對 3.0 之前的系統，在 port 中有一個極佳的工具程式 pcemu 可以模擬 8088 和足夠的 BIOS 服務以執行 DOS 文字模式程式。它須要 X Window System(由 XFree86 提供)。
SUP 意思是 Software Update Protocol，由 CMU 發展以維持發展的同步， 我們利用他來保持遠端的站台和原始站台同步。
SUP 對頻寬的使用不友善，而且已經不使用了。目前建議維持原始碼更新的方法是 使用手冊中的 CVSup。
問：有人做過 FreeBSD 執行時的溫度測試嗎？我知道 Linux 比 DOS 涼， 但沒聽人提過 FreeBSD，似乎很熱。
答：沒有，但是在味覺上有做過無數次測試。我們矇上自願受試者的 眼睛，事先再給他們服用 250 毫克的 LSD-25 迷幻藥。35% 的受試者說 FreeBSD 嘗起來像橘子，而 Linux 則是紫色的榛樹果實。據我所知，沒 有一組提到溫度上特別的差異。後來發現，有太多受試者在測試時夢遊走 出房間影響到數據，最後只得放棄整個調查。我想大部份的受試者現在在 Apple 工作，繼 Drag and Drop 之後，研究全新的 Scratch and Sniff 圖形界面。It's a funny old business we're in！
不開玩笑了，FreeBSD 和 Linux 都使用 ``HLT'' (halt) 指令 以在系統閒置時降低電力的使用也減少了熱的產生。如果有設定 APM (automatic power management)，FreeBSD 也可以讓 CPU 進入低電力 模式。
問：FreeBSD 編譯核心時有做甚麼 "奇特" 的事讓記憶體沙沙作響嗎？ 當編譯時(還有開機時確認軟碟後的短暫時間)，也種似乎來自記憶體插槽 的奇怪聲音。
答：是的！在 BSD 的文件中你會常常看到 ``背後靈''，大部份的人 都不知道那是一種實際存在的精神體 --- 掌控著你的電腦。你聽到的聲音 是這些背後靈以高音口哨在溝通怎樣做許多的系統管理工作。
如果這些聲音很困擾你，來自 DOS 的 ``fdisk /mbr'' 就 能擺脫，但如果有相反的效果也不要驚訝。事實上，如果在儀式中聽到 Bill Gates 恐怖的聲音從內建的喇叭傳來，馬上逃而且不要回頭！ 從 BSD 背後靈不平衡的影響中解放，DOS 和 Windows 背後靈通常都能 重新控制整台機器並對你的靈魂詛咒。如果有選擇，我想我寧願習慣奇 怪的聲音。
在只有會員知道的秘密語言中，它用來表示某種東西。我們無法作文字上直接的翻譯， 只能說它的意思大概在 '一級方程式賽車'、'企鵝是好吃的小點心'、和 '我們比 Linux 來得有幽默感' 這三者之間。:-)
正經點，BSD 是 'Berkeley Software Distribution' 的縮寫，由當時的 Berkeley CSRG(Computer Systems Research Group)選來當作他們所發行 Unix 版本的名稱。
一千一百七十二個：
二十三個在 -current 上抱怨看不到光了；
四個宣稱這是設定上的問題，所以像這樣的 email 應該放在 -questions；
三個 submit PR，其中一個送錯到 doc 下，並且內容只有”這裡好暗”；
一個 commit 尚未測試的電燈泡，造成不能 buildworld，五分鐘後他把原來 的燈泡換回來；
八個煽起 flame war，責怪送出 PR 的人沒有包括 patch；
五個埋怨 buildworld 爛掉了；
三十一個說 buildworld 可以用，不能用的人一定是 cvsup 的時機不對；
一個把換成新燈泡的 patch 丟到 -hackers 上；
一個說他三年前就做出了 patch，但送到 -current 後卻被忽略掉，所以他 對整個 PR 系統有很不好的印象。此外，他也認為拿出的新燈泡無法反光；
三十七個咆哮說電燈泡不屬於基本系統的一部份，所以 committer 不能不先 諮詢整個 Community 的意見就這樣做下去。還有，-CORE 到底和這件事有什麼 關係？！
兩百人抱怨換燈泡之後，腳踏車棚的顏色變得好奇怪；
三個指出，用來換燈泡的 patch 不符合 style(9) 的規定；
十七個埋怨拿出來的新燈泡為什麼是用 GPL；
五百八十六人陷入一場 flame war，在 GPL、BSD、MIT、NPL 各個 license 和 FSF 某位不具名創辦人士個人衛生之間，比較彼此的優勢；
七個將這一串討論的不同部份分別移到 -chat 和 -advocacy；
就算提出的新燈泡比舊的暗，還是有一個把它 commit 進來；
兩個換回原先的燈泡，並且留下極為憤怒的 commit 訊息。他們認為與其讓 FreeBSD 用暗燈泡，還不如乾脆待在黑暗中算了；
四十六人對取消不用暗燈泡這件事大聲疾呼，要求 -core 立刻提出澄清；
十一個要求換成小一點的電燈泡，以便未來 FreeBSD 如果移植到電子雞上後 會更為方便；
七十三人抱怨 -hackers 和 -chat 上的 SNR，藉 unsubscribe 來表示抗議；
十三個送出 "unsubscribe"、”我要如何 unsubscribe”或”拜託把我從 list 名單中刪掉”，信的最後面則是一般由 majordomo 加上去的 footer；
當每個人忙於彼此叫罵時，有個傢伙趁沒人注意，把可以用的燈泡偷偷換上 去；
三十一個指出如果用 TenDRA 編譯新的燈泡，會比舊的來得亮 0.364%（雖然 燈泡會被編譯成正六面體），所以 FreeBSD 內定的編譯器應該是 TenDRA，而不 是 EGCS；
有個人說新燈泡缺乏美感；
九個人（包括原先送 PR 的人）問”什麼是 MFC？”；
五十七個抱怨自從換了燈泡後，兩個星期都沒有光出現。
Nik Clayton 補注：
剛看到時，我快笑翻了。
然後想到，”等一下，不是應該還有一個要將這些記在 list 上嗎？”
接著終於了解我的使命 :-)
本節笑話之著作權屬於 Copyright (c) 1999 Dag-Erling Coïdan Smørgrav。 為避免喪失原意請勿任意重置上述任一字句。