325 lines
13 KiB
Text
325 lines
13 KiB
Text
<!-- $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>
|
||
|