在爬文測試過後，發現有幾個前提要先釐清：

1. 文件上常被提到的指令：
   a.  LangEngine   on|off
   b. LangPath  /path/to/your/locale
   c. LangDefault
   d. UseEncoding   on|off|local_charset client_charset
   e. UseUTF8  on|off    <--- 這指令在 1.3.3 並不支援
2. 編譯時的關鍵參數 --enable-nls  (Native Language Support, default=no)
   但在 FreeBSD 用 ports 安裝時，預設是打開的。
3. 系統端的使用字集 Charset
   現在越來越多系統是採用 unicode 了，這部份可以自訂，但目前我的習慣還是用 Big5。
4. 用戶端的使用字集
   雖然 unicode 推行很久了，但很多時候微軟的程式還是以當地字集來運作，對繁體中文使用者來說，那就是big5。而是否支援unicode則是個別軟體的問題。
5. 越來越多 FTP Client 支援自訂字集
   例如 FileZilla，而早期的 client 則是以用戶端的字集決定。

那麼，亂碼究竟是怎麼產生的？簡單來說，就是當 FTP Client 無法判別檔名字集時，它就會變成亂碼，或像 FileZilla 一樣自動隱藏。

因此，在 proftpd 1.3.3 之後，如果你啟用了 nls 功能，它就預設以 UTF-8 來處理所有的訊息，然後再依 UseEncoding 的設定來作 iconv。

這時，只要使用不支援自訂字集的 FTP Clients, 像早期的 FTP 程式或透過檔案總管，那麼它就會誤把 big5 的檔名解讀為 utf8，造成亂碼。

解決方式：

1. 重新編譯 proftpd
   把 NLS 功能關掉，讓 proftpd 用原生字集去運作。
2. 將 FileZilla 的字集強制設為 big5，確保檔名在雙向傳輸時不被誤解。（其實有點像是為了向下相容，配合其他舊程式的運作。）
   事實上，如果讓字集以自動偵測或強制使用 UTF-8，FileZilla 都能正確顯示檔案。（因為 proftpd 會如實顯示主機上的實體檔名，而 FileZilla 都能判讀。）
   但為了具備一致性，所以改成 big5 比較保險。
3. 以其它程式上傳，例如 UltraEditor，它也是用原生字集去運作的。所以檔名也都正常。

缺點：

1. 如果你是想跨區交換檔案，例如台灣和大陸分公司，那麼一邊用 big5，一邊用 gb2312，那一定是自找麻煩。這種情況下，應該以 utf8 方式運作才是王道。
2. 相反的，如果你想利用utf8來解決檔名亂碼的問題，那就不能用那些老掉牙的程式來傳檔，攪亂一池春水。這時，應該以能支援 utf8 的程式或 web-based 的介面來解決檔名編碼的問題。

1. CPU
   目前越來越多 CPU 已經採多核設計，也就是一顆可抵好幾顆。所以對於運算需求較高的主機而言，選擇多核的 CPU 是無庸置疑的。但若是模擬出來的假多核，如 intel 的 hyper thread 技術，就不見得有多大的實質助益。
2. RAM
   記憶體方面也有這樣的趨勢，由原本的單一通道，提昇到雙通道，甚至三通道。這就像高速公路的車道，數量越多，車流的容許量越大。對於資料量大的主機，就必須特別注意這點，像是資料庫很大，或影音系統。
3. 硬碟
   現在硬碟的容量越來越大，已經有單顆 3T 的產品問市了。然而，讀取的速度雖然也跟著加快，但最關鍵的寫入速度還是不盡理想，而成為最大的瓶頸。為了提昇硬碟的效率，多數人是採用 RAID、SAN 或 NAS 來處理。後二者要花的錢很多，在這裡暫不討論。但就 RAID 而言，並不是架了 RAID 就會變快，例如是架 RAID 0(合併)和 RAID 1(鏡射) 來說，寫入的動作並沒有被分擔掉，所以有架沒架都一樣慢。
   那麼，可以怎麼作呢？
   筆者的作法是用二顆硬碟，以主從的概念來使用。例如要進行系統壓縮備份時，由 A 備份到 B，那麼一讀一寫，速度會快很多。這樣作還有一個好處，就是硬碟磁區的混亂程度會最低。因為在單顆硬碟上作備份時，會把前方讀寫速度較快的空間佔掉，而造 成後續資料被寫入速度較慢的後段磁區。即使你把這些前方的大檔刪掉，後方的檔案也不會被移到前方。這表示硬碟讀取頭就必須有大幅度的擺盪才能讀到資料，這 都會影響到效率。
4. 網路卡
   現在雖然已經進步到 Gigabit 的網卡，但是如果硬碟讀取速度不夠，還是會受限。
   另外，當系統在進行大量資料傳輸時，網卡的頻寬還是可能被佔滿，而造成不同伺服器的延遲問題。
   針對這部份的作法是採用雙網卡，甚至多網卡的作法，再依實際需求來規劃網卡的用法。
   例如雙網卡的狀態，可以一張網卡對外，另一張對內供內網使用，這樣就可以避免內外網搶頻寬的現象發生。
5. 主從式主機架構
   也就是大家常聽到的 n-Tier 架構，它的概念也大同小異，就是簡單四個字：分工合作。
   目前來講，當網站越長越大之後，可以先考慮架設 CDN(Content Delivery Network)主機來負責網站檔案的傳輸，這些檔案通常變動性較低，但讀取頻率極高。
   等需求再大一些，就可以考慮架設專屬的資料庫伺服器，因為資料庫是整個系統的核心不能損?，獨立出來將有助於系統的穩定性，資源調配上也較明確。
   之後，就可以考慮架設 AP 伺服器，讓多台主機來處理使用者的需求，再結合 Load balance 的設定，把需求分配給不同的 AP 伺服器處理。概念上可以看成大賣場的結帳櫃台，人多時就全開，人少時就只保留部份櫃台即可。
6. 雲端系統
   國外的 Amazon 和 Google 等業者都有提供系統龐大、收費低廉的雲端系統可供租用，當需求大到無法自行解決時，雲端系統也是值得考慮的選項之一。但在使用上，還是要評估系統的距離，遠在天邊的網路系統往往不比隔壁的主機來得快。

總結來說，效能的瓶項往往來自通道數量和傳輸方式。盡可能增加通道量，控制行進方式，就能提高系統運作效能。

因為筆者有把 gmail 信箱裡特定信件自動轉寄到公司郵件主機備份的設定，而這個錯誤會造成不正常的退件。不只是 gmail, 只要任何寄信到公司郵件主機的人，都會收到退件。

一開始，從字面上的訊息，以為是 mail.local 這支程式出現異常。因為連 sendmail 官方網頁都說這訊息是 mail.local 在異常時回傳的錯誤代碼。

#define EX_OK           0       /* successful termination */

#define EX__BASE        64      /* base value for error messages */

#define EX_USAGE        64      /* command line usage error */
#define EX_DATAERR      65      /* data format error */
#define EX_NOINPUT      66      /* cannot open input */
#define EX_NOUSER       67      /* addressee unknown */
#define EX_NOHOST       68      /* host name unknown */
#define EX_UNAVAILABLE  69      /* service unavailable */
#define EX_SOFTWARE     70      /* internal software error */
#define EX_OSERR        71      /* system error (e.g., can't fork) */
#define EX_OSFILE       72      /* critical OS file missing */
#define EX_CANTCREAT    73      /* can't create (user) output file */
#define EX_IOERR        74      /* input/output error */
#define EX_TEMPFAIL     75      /* temp failure; user is invited to retry */
#define EX_PROTOCOL     76      /* remote error in protocol */
#define EX_NOPERM       77      /* permission denied */
#define EX_CONFIG       78      /* configuration error */

#define EX__MAX 78      /* maximum listed value */

但卻一直找不到問題點。139?? 該不會是不同錯誤的組合？

這種不易監控程式執行步驟的機制最難找bug....（汗）

最後，只有一步一步來。

由於轉寄進來的程式是先經 .forward 檔將它 pipe 給一支 php 程式來處理（編碼，並寫入資料庫，然後將信件轉存）。

所以就用 forward_mails.php < some_mail_from_gmail.eml  把剛才收到的 gmail 郵件倒給處理程式看看～～～

驚！

竟然出現 Segmentation fault (core dumped)

這就怪了，之前明明都運作正常，用很久了。因此，讓我想到該不會是升級時加載的外掛有問題吧？

目標就指向了最後加入的 memcached 這個外掛了。

但奇怪的是，用 pecl install memcached 一切正常，而在 phpinfo 裡也看到它被載入了。

然而執行程式時，卻是因為它而出現異常，而這支程式裡卻完全沒用到 memcached。移除這支外掛後，上述的 Segmentation fault 就消失了。

所以結論就是 php 的外掛加載可能造成 php 程式的異常，這點需要特別留意。

咦？這是什麼東西啊？怎麼見都沒見過....(我嫩)

原本慣用的 ./configure 設定模式不支援，只好耐著性子仔細爬文....

找到「Section 2.11, "Installing MySQL from Source."」才發現，原來改變長久以來的設定模式了.....=___=|||

This section describes how to build MySQL from source using CMake. Before MySQL 5.5, source builds used the GNU autotools on Unix-like systems.

說 5.5 以前用 GNU autotools 來編，以後就改 CMake 了。（大概是想把 MySQL 轉型為商用來搶錢吧？心中默默呼喊著瑪莉亞...）

In MySQL 5.5, CMake is used as the build framework on all platforms. For instructions beyond those given here on using CMake to build MySQL, see http://forge.mysql.com/wiki/CMake.

重點是這個，如果 MySQL 5.5 以後都改用 CMake 了，那要怎麼設定參數，就得看上述的網址。

不過，這裡我把自己的參數貼上來先，要看詳細的自己去查囉。

# cmake -DMYSQL_DATADIR=/base/MySQL/data
-DDEFAULT_CHARSET=utf8
-DDEFAULT_COLLATION=utf8_general_ci
-DEXTRA_CHARSETS=all
-DMYSQL_UNIX_ADDR=/base/MySQL/socket
-DMYSQL_TCP_PORT=3306
-DMYSQL_USER=mysql
-DCMAKE_INSTALL_PREFIX=/base/MySQL
-DINSTALL_SBINDIR=bin

CMake參數對照關係

--localstatedir=/base/MySQL/data     =========>   -DMYSQL_DATADIR=/base/MySQL/data
--with-charset=utf8    ====================>   -DDEFAULT_CHARSET=utf8
--with-collation=utf8_general_ci     ===========>   -DDEFAULT_COLLATION=utf8_general_ci
--with-extra-charsets=all      ================>   -DEXTRA_CHARSETS=all
--with-unix-socket-path=/base/MySQL/socket    ==>    -DMYSQL_UNIX_ADDR=/base/MySQL/socket
--with-tcp-port=3306      ==================>     -DMYSQL_TCP_PORT=3306
--with-mysqld-user=mysql    ===============>     -DMYSQL_USER=mysql
--prefix=/usr    ========================>     -DCMAKE_INSTALL_PREFIX=/base/MySQL
--sbindir=EPREFIX/sbin     ================>     -DINSTALL_SBINDIR=bin

其實我發現這個 cmake 笨笨的，它的 prefix 路徑替換和參數的使用方式有問題，應該是它並沒有依據個別的平台去修正慣用的安裝路徑。以 FreeBSD 慣用的 /usr/local/sbin 或 /usr/local/bin 來看，它的預設安裝是把全部東西裝入 /usr/local/mysql。但是，如果用 -DCMAKE_INSTALL_PREFIX=/usr 的話，最後安裝的位置就在 /usr 裡面（跟用 ./configure 方式作的結果不同）。最後，就乾脆把程式裝入自己慣用的資料庫區域去算了。

另外，如果去研究 cmake 之後所產生的 CMakeCache.txt 也會發現，文件裡講的一些對應參數，在這個設定檔中，卻被標注成

//No help, variable specified on the command line.
DEFAULT_CHARSET:UNINITIALIZED=utf8

真讓人懷疑這個 CMake 到底有沒有搞懂安裝的人想要什麼狀態呢？

總之，繼續觀察後續發展～～還有瑪莉亞的動向。

@font-face {
  font-family: "Kimberley";
  src: url(http://www.princexml.com/fonts/larabie/kimberle.ttf) format("truetype");
}
h1 { font-family: "Kimberley", sans-serif }

Those familiar with CSS syntax will recognize the last line. The @font-face construct may not be familiar, however it’s easy to explain: as the “Kimberley” font is requested, the font file is fetched from the specified URL. The syntax is described in the CSS2 specification.

To avoid long lists of @font-face declarations in the style sheet, they can be hidden using @import :

@import url(http://www.princexml.com/fonts/larabie/index.css) all;
h1 { font-family: Goodfish, serif }

The TrueType files used in the examples above are designed by Ray Larabie. He is a renowned font designer who has made hundreds of interesting TrueType fonts freely available for use on the web. His fonts are elegant, decorative, and playful.

Dieter Steffmann is another great font designer. He, too, has made many beautiful fonts available for anyone to use.