diff options
Diffstat (limited to 'zh_TW.Big5/FAQ/misc.sgml')
| -rw-r--r-- | zh_TW.Big5/FAQ/misc.sgml | 242 |
1 files changed, 242 insertions, 0 deletions
diff --git a/zh_TW.Big5/FAQ/misc.sgml b/zh_TW.Big5/FAQ/misc.sgml new file mode 100644 index 0000000000..3f9ac79e5d --- /dev/null +++ b/zh_TW.Big5/FAQ/misc.sgml @@ -0,0 +1,242 @@ +<!-- $Id: misc.sgml,v 1.1.1.1 1999-01-30 23:20:34 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/'' (hald) 指令 + 以在系統閒置時降低電力的使用也減少了熱的產生. 如果有設定 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> + |