diff options
Diffstat (limited to 'zh/FAQ/misc.sgml')
| -rw-r--r-- | zh/FAQ/misc.sgml | 242 |
1 files changed, 0 insertions, 242 deletions
diff --git a/zh/FAQ/misc.sgml b/zh/FAQ/misc.sgml deleted file mode 100644 index 7c40086478..0000000000 --- a/zh/FAQ/misc.sgml +++ /dev/null @@ -1,242 +0,0 @@ -<!-- $Id: misc.sgml,v 1.3 1999-02-16 14:20:18 vanilla Exp $ --> -<!-- The FreeBSD Documentation Project --> -<!-- Translate into Chinese by zmx@mail.CDPA.nsysu.edu.tw --> -<!-- English Version: 1.8 --> - - <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/遞迴/. 指定目錄 - 或是連結到目錄的 symlink 時要小心. 如果你要改變一個符號連結參考到 - 的目錄的存取權限, 使用 <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>A. No, but we have done numerous taste tests on blindfolded - volunteers who have also had 250 micrograms of LSD-25 - administered beforehand. 35% of the volunteers said that FreeBSD - tasted sort of orange, whereas Linux tasted like purple haze. - Neither group mentioned any particular variances in temperature - that I can remember. We eventually had to throw the results of - this survey out entirely anyway when we found that too many - volunteers were wandering out of the room during the tests, thus - skewing the results. I think most of the volunteers are at Apple - now, working on their new ``scratch and sniff'' GUI. 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 分支的改變. - - </sect> - |