<!-- $FreeBSD$ -->
<!-- The FreeBSD Documentation Project -->
<!-- Translate into Chinese by zmx@mail.CDPA.nsysu.edu.tw -->
<!-- English Version: 1.16 -->

  <sect>
    <heading>其它各式各樣的問題<label id="misc"></heading>

    <sect1>
      <heading>
	為甚麼 FreeBSD 用的 swap 空間比 Linux 多？
      </heading>

      <p>不是這樣的。如果你的意思是： ``為甚麼我的 swap 看起來滿了？''
      那是因為把東西放在 swap 裡後拿回來的速度會比 pager 經由檔案系
      統拿回(未修改)的執行碼快。


      <p>事實上，記憶體中 dirty pages 的量並未減少； clean pages 則在需
      要的時候移走。

    <sect1>
      <heading>
        為甚麼要用(甚麼是) a.out 和 ELF 執行檔格式？
      </heading>

      <p>要了解為甚麼 FreeBSD 使用 <tt>a.out</tt> 格式，首先你要知道一些
      目前 Unix 中使用最廣泛的三種格式：

      <itemize>
        <item><htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?a.out(5)"
        name="a.out">

	<p>最早和`古典'的 unix 目的檔格式。使用一種短而緊密的檔頭,
	伴隨一個通常用來辨認格式的魔術數字(參考
        <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?a.out(5)"
        name="a.out(5)"> 有更多細節)。具有三個節區：.text，.data，和.bss
	加上一個符號表和字串表。

        <item><bf>COFF</bf>
        <p>SVR3 目的檔格式。檔頭包含了一個節區表，所以可以具備比
	.text，.data，.bss 還多的節區。</item>
        
        <item><bf>ELF</bf>
        <p><tt/COFF/ 的後繼者，具有多個節區以及 32-bit 或 64-bit 的
        possible values。主要的缺點：<tt/ELF/ 是在每個系統架構只
        會有一種 ABI 的假設下設計出來的。事實上這個假設錯的離譜，
	即使是商業的 SYSV 世界，也至少有 SVR4，Solaris，SCO 三種 ABI。

        <p>FreeBSD 藉由一個工具，把程式需要那種 ABI 的資訊 <em>烙印</em>
        在 <tt/ELF/ 執行檔上。
        參考 man page
        <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?brandelf"
        name="brandelf"> 取得更多資訊。
      </itemize>

      <p>FreeBSD 來自 "古典" 陣營，傳統上都使用
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?a.out(5)"
      name="a.out"> 格式，這是在好幾代的 BSD 中證明可靠的計術。
      雖然可以在 FreeBSD 上可以建立以及執行原生的 <tt/ELF/ 執行檔(
      以及核心)，剛開始 FreeBSD 反對轉換到以 <tt/ELF/ 做為預設的
      格式。為甚麼？ 嗯，當 Linux 開始痛苦地轉換至 <tt/ELF/，並非因為
      要逃離 <tt/a.out/ 格式，而是因為他們沒有彈性的，以跳躍表為基礎
      的共享程式庫機制。那是一種非常難以使用，發展者不喜歡的東西. 既
      然已經存在的 <tt/ELF/ 工具提供了共享程式庫的解決方案，而且看來
      是 "前衛的方法"，所需的代價就可接受因而轉換。

      <p>在 FreeBSD 的狀況中，我們的共享程式庫機制更接近 <tt>SunOS</tt> 的
      型式，也就是，易於使用。
	  然而，從 3.0 開始，FreeBSD 正式支援 <tt/ELF/ 為預設格式。即使
	  <tt/a.out/ 格式仍然非常好，我們編譯工具的撰寫者，GNU 的成員，
	  已中止了對，<tt/a.out/ 格式的支援。這迫使我們維護另一份版本的
	  compiler 和 linker，也使得我們不能從最新的 GNU 發展成果中獲得
	  好處. 此外對 ISO-C++ 的需求，尤其是建構者和解構者，也帶動未來
	  版本中對 <tt/ELF/ 的原生支援。

    <sect1>
      <heading>好吧，但為甚麼會有這麼多種不同的格式？</heading>

      <p>在黑暗的過去，只有簡單的硬體. 簡單的硬體支援小型、簡單的系統.
      a.out 在簡單的系統上勝任愉快 (PDP-11). 當 unix 移植到其他平台時，
      a.out 保留了下來，因為對早期的 Motorola 68K，VAX 之類的架構已經
      夠用了。

      <p>然後有些硬體工程師覺得讓軟體多做點事，那 CPU 的電晶體就能少
      一點而跑的更快. 要在這種新式硬體上工作(現在稱為RISC)，<tt/a.out/ 就
      不適合了，所以需多的格式就發展出來以提供比受限、簡單的<tt/a.out/ 更
      好的效能. 像是 <tt/COFF/，<tt/ECOFF/，以及一些不有名的格式，每一種
      都有限制直到 <tt/ELF/。

      <p>此外，當程式越來越大而磁碟(以及主記憶體)相對來說較小時，共享
      程式庫的概念就發展出來了，虛擬記憶體系統也變得越來越精巧。當每一
      種進步都在 <tt/a.out/ 上完成時，它的可用性也越來越低。另外，人們
      還要在執行時期可以動態載入，或是丟棄執行過的初始化程式以節省記憶
      體。程式語言也變得更精巧而且人們想要在在 main 之前執行別的程式碼
      。許多繁雜的技巧用在 <tt/a.out/ 上以解決這些問題。<tt/a.out/ 要
      解決這些問題需要越來越多額外的負擔和複雜度。<tt/ELF/ 可以輕易的解
      決這些問題，但是從基本上可以工作的系統轉換成 <tt/ELF/ 卻很棘手。
      所以要等到維護 <tt/a.out/ 比轉換到 <tt/ELF/ 棘手。

      <p>然而，隨著時間過去， FreeBSD 的 build tools 形成了平行的兩支
      (尤其是組譯器和 loader)。FreeBSD 這支加進了共享程式庫以及修正了
      一些錯誤。原來撰寫這些程式的 GNU 成員則重寫了這些程式，以更簡單
      的方式支援跨平台編譯、多種格式等等。許多人想要做出以 FreeBSD 為
      目的平台的跨平台編譯器，不幸的是 FreeBSD 的 as 和 ld 不能做這項
      工作。新的 GNU 工具(binutils)加入了跨平台編譯、<tt/ELF/、共享程
      式庫、 C++ 擴充，等等。此外，許多廠商以 <tt/ELF/ 格式發行產品，
      而能夠在 FreeBSD 上跑的話當然很好。而且如果能跑 <tt/ELF/ 格式的
      執行檔，為甚麼還要理 <tt/a.out/ ？牠是一匹又累又老的馬，過去非常
      有用，但是時候讓牠退休了。

      <p><tt/ELF/ 比 a.out 更應有表達力(expressive？)而且具有更多的
      擴充性. <tt/ELF/ 工具維護的比較好，而且提供跨平台編譯的支援,
      這對許多人來說是很重要的。<tt/ELF/ 可能比 a.out 慢一點，但差異
      非常難測量出來。這兩者之間還有許多細節上的不同，例如分頁的對應
      方式，初始化程式碼的作法等等。這些並不是很重要，但就是不同。在
      以後 GENERIC 核心不會支援 <tt/a.out/ ，當不再有執行傳統 <tt/a.out/
      程式的需要時，會從核心移除。

    <sect1>
      <heading>為甚麼 chmod 不會改變符號連結(symlink)的存取權限？</heading>

      <p>你必須把 ``<tt/-H/'' 或是 ``<tt/-L/'' 與 ``<tt/-R/'' 選項一起使用.
      參考<htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?chmod"
      name="chmod">
      及<htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?symlink" 
      name="symlink"> man pages 以取得更多資訊.

      <p><bf/警告/ ``<tt/-R/'' 選項會讓 <tt/chmod/ 做<bf/遞迴/。用在目錄
      或是連結到目錄的符號連結時要小心。如果你要改變一個符號連結參考到
      的目錄的存取權限，使用 <htmlurl 
      url="http://www.FreeBSD.org/cgi/man.cgi?chmod" name="chmod"> 且不要
      加任何選項，並且在 symlink 的結尾加上斜線(``<tt>/</tt>'')。舉例來說
      ，如果 ``<tt/foo/'' 連結到 ``<tt/bar/''，而你要更改 ``<tt/foo/'' 的
      權限 (事實上是 ``<tt/bar/'')，那就用：


      <verb>
        chmod 555 foo/
      </verb>

      <p>結尾的斜線，會讓 <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?chmod" name="chmod"> 
      改變 ``<tt/foo/'' 指向的 ``<tt/bar/'' 目錄的權限。

    <sect1>
      <heading>
        為甚麼帳號 <bf/仍然/ 限制為八個字元？
      </heading>

      <p>你會認為修改 <bf/UT_NAMESIZE/ 然後重建系統是很簡單的事情，而且
      每件事都可以運作地很好。不辛的是有許多的程式和工具(包含系統工具)
      把數字寫死在程式裡(並非總是 8 或 9，有時是古怪的 15、20等等)。
      這不只會把你的記錄檔弄壞(來自於變動長度和固定長度記錄的差異)，也
      會破壞 Sun 的 NIS 客戶端的運做，和其它 UNIX 系統的交互作用也可能
      有潛在的問題。

      <p>在 FreeBSD 3.0 以及之後的版本，帳號的最大長度增加到16個字元,
      而那些寫死長度的程式也找出來修正. 正因為影響系統的部份很到，直到
      3.0 才做修改。</p>

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

    <sect1>
      <heading>我能在 FreeBSD 下跑 DOS 程式嗎？</heading>

      <p>是的，從 3.0 版開始可以使用已經整合並加強的 BSDI <tt/rundos/
      DOS 模擬器。如果你最這個東西有興趣，送封信到
      <url url="mailto:freebsd-emulation@FreeBSD.org"
      name="The FreeBSD emulation discussion list">

      <p>對 3.0 之前的系統，在 port 中有一個極佳的工具程式
      <htmlurl url="http://www.FreeBSD.org/cgi/ports.cgi?^pcemu" name="pcemu">
      可以模擬 8088 和足夠的 BIOS 服務以執行 DOS 文字模式程式。它須要 X Window
      System(由 XFree86 提供)。

    <sect1>
      <heading>
        甚麼是 ``<tt/sup/''，如何使用？
      </heading>

      <p><htmlurl url="http://www.FreeBSD.org/cgi/ports.cgi?^sup" name="SUP">
      意思是 Software Update Protocol，由 CMU 發展以維持發展的同步，
      我們利用他來保持遠端的站台和原始站台同步。

      <p>SUP 對頻寬的使用不友善，而且已經不使用了。目前建議維持原始碼更新的方法是
      <url url="../../handbook/cvsup.html" name="Handbook entry on CVSup">


    <sect1>
      <heading>How cool is FreeBSD？</heading>

      <p>問：有人做過 FreeBSD 執行時的溫度測試嗎？我知道 Linux 比 DOS 涼，
      但沒聽人提過 FreeBSD，似乎很熱。

      <p>答：沒有，但是在味覺上有做過無數次測試。我們矇上自願受試者的
      眼睛，事先再給他們服用 250 毫克的 LSD-25 迷幻藥。35% 的受試者說
      FreeBSD 嘗起來像橘子，而 Linux 則是紫色的榛樹果實。據我所知，沒
      有一組提到溫度上特別的差異。後來發現，有太多受試者在測試時夢遊走
      出房間影響到數據，最後只得放棄整個調查。我想大部份的受試者現在在
      Apple 工作，繼 Drag and Drop 之後，研究全新的 Scratch and Sniff
      圖形界面。It's a funny old business we're in！

      <p>不開玩笑了，FreeBSD 和 Linux 都使用 ``<tt/HLT/'' (halt) 指令
      以在系統閒置時降低電力的使用也減少了熱的產生。如果有設定 APM
      (automatic power management)，FreeBSD 也可以讓 CPU 進入低電力
      模式。

    <sect1>
      <heading>誰在我的記憶體插槽中沙沙作響？？</heading>

      <p>問：FreeBSD 編譯核心時有做甚麼 "奇特" 的事讓記憶體沙沙作響嗎？
      當編譯時(還有開機時確認軟碟後的短暫時間)，也種似乎來自記憶體插槽
      的奇怪聲音。

      <p>答：是的！在 BSD 的文件中你會常常看到 ``背後靈''，大部份的人
      都不知道那是一種實際存在的精神體 --- 掌控著你的電腦. 你聽到的聲音
      是這些背後靈以高音口哨在溝通怎樣做許多的系統管理工作。

      <p>如果這些聲音很困擾你，來自 DOS 的 ``<tt>fdisk /mbr</tt>'' 就
      能擺脫，但如果有相反的效果也不要驚訝。事實上，如果在儀式中聽到
      Bill Gates 恐怖的聲音從內建的喇叭傳來，馬上逃而且不要回頭！
      從 BSD 背後靈不平衡的影響中解放，DOS 和 Windows 背後靈通常都能
      重新控制整台機器並對你的靈魂詛咒。如果有選擇，我想我寧願習慣奇
      怪的聲音。

    <sect1>
      <heading>MFC 是甚麼意思？</heading>

      <p>MFC 是 'Merged From -CURRENT' 的縮寫。使用在 CVS 記錄中以
      表示從 CURRENT 中整合進 STABLE 分支的改變。

    <sect1>
      <heading>'BSD' 是什麼意思？</heading>

      <p>在只有會員知道的秘密語言中，它用來表示某種東西。我們無法作文字上直
      接的翻譯，只能說它的意思大概在 '一級方程式賽車'、'企鵝是好吃的小點心'、
      和 '我們比 Linux 來得有幽默感' 這三者之間。:-)

      <p>正經點，BSD 是 'Berkeley Software Distribution' 的縮寫，由當時的
      Berkeley CSRG(Computer Systems Research Group)選來當作他們所發行 Unix
      版本的名稱。

    <sect1>
      <heading>要幾個 FreeBSD hacker 才能換掉一個電燈泡？</heading>

      <p>一千一百七十二個：

      <p>二十三個在 -current 上抱怨看不到光了；

      <p>四個宣稱這是設定上的問題，所以像這樣的 email 應該放在 -questions；

      <p>三個 submit PR，其中一個送錯到 doc 下，並且內容只有”這裡好暗”；

      <p>一個 commit 尚未測試的電燈泡，造成不能 buildworld，五分鐘後他把原來
      的燈泡換回來；

      <p>八個煽起 flame war，責怪送出 PR 的人沒有包括 patch；

      <p>五個埋怨 buildworld 爛掉了；

      <p>三十一個說 buildworld 可以用，不能用的人一定是 cvsup 的時機不對；

      <p>一個把換成新燈泡的 patch 丟到 -hackers 上；

      <p>一個說他三年前就做出了 patch，但送到 -current 後卻被忽略掉，所以他
      對整個 PR 系統有很不好的印象。此外，他也認為拿出的新燈泡無法反光；

      <p>三十七個咆哮說電燈泡不屬於基本系統的一部份，所以 committer 不能不先
      諮詢整個 Community 的意見就這樣做下去。還有，-CORE 到底和這件事有什麼
      關係？！

      <p>兩百人抱怨換燈泡之後，腳踏車棚的顏色變得好奇怪；

      <p>三個指出，用來換燈泡的 patch 不符合 style(9) 的規定；

      <p>十七個埋怨拿出來的新燈泡為什麼是用 GPL；

      <p>五百八十六人陷入一場 flame war，在 GPL、BSD、MIT、NPL 各個 license
      和 FSF 某位不具名創辦人士個人衛生之間，比較彼此的優勢；

      <p>七個將這一串討論的不同部份分別移到 -chat 和 -advocacy；

      <p>就算提出的新燈泡比舊的暗，還是有一個把它 commit 進來；

      <p>兩個換回原先的燈泡，並且留下極為憤怒的 commit 訊息。他們認為與其讓
      FreeBSD 用暗燈泡，還不如乾脆待在黑暗中算了；

      <p>四十六人對取消不用暗燈泡這件事大聲疾呼，要求 -core 立刻提出澄清；

      <p>十一個要求換成小一點的電燈泡，以便未來 FreeBSD 如果移植到電子雞上後
      會更為方便；

      <p>七十三人抱怨 -hackers 和 -chat 上的 SNR，藉 unsubscribe 來表示抗議；

      <p>十三個送出 "unsubscribe"、”我要如何 unsubscribe”或”拜託把我從
      list 名單中刪掉”，信的最後面則是一般由 majordomo 加上去的 footer；

      <p>當每個人忙於彼此叫罵時，有個傢伙趁沒人注意，把可以用的燈泡偷偷換上
      去；

      <p>三十一個指出如果用 TenDRA 編譯新的燈泡，會比舊的來得亮 0.364%（雖然
      燈泡會被編譯成正六面體），所以 FreeBSD 內定的編譯器應該是 TenDRA，而不
      是 EGCS；

      <p>有個人說新燈泡缺乏美感；

      <p>九個人（包括原先送 PR 的人）問”什麼是 MFC？”；

      <p>五十七個抱怨自從換了燈泡後，兩個星期都沒有光出現。

      <p><em><url url="mailto:nik@FreeBSD.org" name="Nik Clayton">
      補注：</em>

      <p><em/剛看到時，我快笑翻了。/

      <p><em/然後想到，”等一下，不是應該還有一個要將這些記在 list 上嗎？”/

      <p><em/接著終於了解我的使命 :-)/

  </sect>

