[華語, cmn-Hant-TW]
之前因為某個需求，要暫時擋掉一台 postfix mail server 寄外部信的功能。找了一下發現其實並不會很困難。在這一篇有提到直接修改 master.cf 即可，把他改成這樣：
smtp unix - - - - - local relay unix - - - - - local local unix - n n - - local
重點在改最後一行，smtp, relay 本來都是 smtp，通通改成 local 後就會寄不出去了，這樣的設定不會影響收信 (因為收信就是 local)，local 寄 local 當然也沒問題，不過對外發信會用到的 smtp 或是要 relay 的話那就完全出不去了，完全符合只擋寄外部信的要求。
不過要注意的是雖然暫時是寄不出去沒錯，不過其實信也只是暫時擋到，等你重新開放後 postfix 就會一次一起寄出去，如果剛好有大量信件卡住的話要特別注意就是了。
[客家話, hak-Hant-TW]
FreeBSD 下是講要看麼介 process 用了麼介 port，最簡單的方式就是 sockstat，毋過這隻是 FreeBSD 限定，Linux 下就做不得用了。好在還有其他替代方案： lsof
講實在的 lsof 主要不是拿來看開麼介 port 的，是拿來看 process 開了麼介檔案，是講也有看用了麼介 port 的功能就是。 lsof -i 就可以看到那隻 process 開了那隻 port，同 sockstat，也當方便啦。
[客家話, hak-Hant-TW]
有一台的 multimedia/kdemultimedia4 毋知哪下開始就編不過，毋過那台咩沒用到這邊的功能，就沒特別去看是什麼問題，就放著。後來有閒那下去看才知說是要編 kscd 時節，很像是尋不到 alsa 這種的問題，毋重新編過 audio/alsa-* 咩沒用，共樣編不過。 看一下別台有 kde 的有堵到共樣的問題沒，結局那台是根本就沒裝 alsa，按仔就是說 alsa 是沒一定要用到的， 正經反安裝 alsa 後這台就編過了，問題解決。
[客家話, hak-Hant-TW]
有兩條連外的線行沒共條路出去，有一條是給 NAT 底肚的電腦連出去，有一條就是伺服器專用的，毋過有 NAT 那條較快，有一些服務咩是走那條，有一隻網址的信箱咩是用這條來收信。
毋過堵到一隻太問題，就是 gmail 寄來的信收毋到(很像 facebook 的咩收毋到)，其他的又沒問題，是講寄行別條線那隻信箱咩是沒問題，看一下 /var/log/maillog 底肚看到按仔的東西：
Jul 28 02:12:25 mail postfix/smtpd[40005]: connect from mail-iw0-f173.google.com[209.85.214.173] Jul 28 02:17:25 mail postfix/smtpd[40005]: timeout after EHLO from mail-iw0-f173.google.com[209.85.214.173] Jul 28 02:17:25 mail postfix/smtpd[40005]: disconnect from mail-iw0-f173.google.com[209.85.214.173]
看起來是 gmail 連上來，postfix 等 5 分鐘等毋到 gmail 餵東西給他，他就切斷連線了，尋了一下看到這篇 postfix mailing-list 有寫到共樣的問題，他講問題是防火牆 (firewall) 擋掉，按仔聽起來當有道理，毋過這條線主要是 NAT 用的，改 firewall 規則較麻煩，解決方法就變作換一條線來用較快了，改一下 DNS 的 MX 就換好了，毋會影響太大。
改過以後 gmail 就收的到了，facebook 就不知了看有閒再來試看看。
[華語, cmn-Hant-TW]
賀米國政府認定 iPhone 破解 (jailbreak) 合法，升級 iOS 4 慶祝一下！
沒有啦，其實就跟上次等 MobileLog 推出後才升級的情況一樣，這次也是等到 MobileLog 4.0 出之後才考慮升級到 iOS 4.0。
iPhone 3G 破解的方式和從前並沒有什麼太大的不同，抓了新的 PwnageTool 做好軔體之後，一樣是用 iTunes 塞進去即可。
結果除了歌以外的東西都復原之後，重開機居然就吃白鳳梨了？！ 經過幾次嘗試後發現問題是卡在 /etc/group， iOS 3.x 和 4.0 的 group 有些許差異，不要動到這個檔案問題就不大。
iOS 4 有兩個重要的功能 (桌布和多工) 是不給 iPhone 3G 跑的，不過其實只是封印起來而已，破解之後可以安裝 zToggle 這個程式來開啟關閉這兩個功能，當然了這是 iPhone 3G 限定， 3GS/4 不需要這個。 實際使用後發現那個多工真的很虛，應該要正名為「最近開啟之程式」才對，所以就把他關掉回去用 backgrounder 了。
有人建議 iPhone 3G 可以把 Spotlight 關掉，這樣會比較不耗資源，跑的比較順。沒有實際去測量對照，不過 Spotlight 本來就是在背景掃描檔案內容，理論上確實會比較省資源，所以就把他掃描的子項目通通都關掉，可惜主畫面的頁面消不掉就是。
輸入法的部份變化不小，首先是鍵盤可以用長按來跳選，這對使用不只一個輸入法的人來說方便不少，然後每種輸入法的排列又分成軟體鍵盤和硬體鍵盤，看起來是為了外接鍵盤做準備，不過手上沒有適合的藍芽鍵盤，就沒特別研究下去了。
[華語, cmn-Hant-TW]
Windows 7 的工作列 (Task Bar) 和之前幾代有相當大的差異，簡單講就是更有 Mac OS X 的味道了。 在 Mac OS X 下執行的軟體會顯示在 Dock 上，一些常用的軟體也可以用「保留在 Dock 上」的選項讓他常駐於 Dock ，方便下次要執行的時候直接點一下就可以執行。 Window 7 的工作列也有類似的設計，微軟把他叫做釘選 (pin)，如果要刪掉的話則是解除釘選 (unpin)。 在某些未知情況下，有些釘選的圖示會不能執行，但是也無法解除釘選，很礙眼。
找了一下發現 geek.com 有教怎麼移掉這種連結，簡單講就是到使用者自己目錄下面放釘選捷徑的地方把不要的砍掉就好了，位置如下：
C:\Users\$USERNAME\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar
把 $USERNAME 換成自己的使用者名稱，如果需要的話 C: 也要換成 %SYSTEM_ROOT%，把裡面不要的東西砍掉後登出，再登入後會在工作列上看到原本清不掉那個圖示變白紙，這時候就可以解除釘選了。 (有一說法是要清空垃圾筒，還有一說法是要重開機才有效，如果上面的做法失敗的話再加碼這些吧)
比較起來，還是 Mac OS X 「直接拉到空氣中」輕鬆寫意多了……
[客家話, hak-Hant-TW]
FreeBSD 用 dhclient 去抓 IP 那下，DHCP Server 是講有給 domain name 相關資料，resolve.conf 就會被他重寫蓋掉自家寫的設定。 是想自訂又想要用 DHCP 抓 IP，就要用其他的方法來設定，毋會太麻煩就是。
在 /etc/dhclient.conf 加這兩行
supersede domain-name "$domain_name"; supersede domain-name-servers $ip1, $ip2;
$domain_name, $ip1, $ip2 自家代換，重開 dhclient 後就會寫好了，例：頭前三隻變數各別是 pighead.cc, 10.0.0.1, 10.0.0.2，/etc/resolve.conf 會被 dhclient 寫作
search pighead.cc nameserver 10.0.0.1 nameserver 10.0.0.2
詳細的設定請 man dhclient.conf
[華語, cmn-Hant-TW]
要把一些舊東西壓一壓，正好可以來測一下哪種格式壓起來效果最好。
原始檔案是事先打包好的 tar 檔，大小為 1,089,927 KB。
| 格式 | 參數 | 大小 |
|---|---|---|
| zip | 預設值 | 464,597 KB |
| 7z | 預設值 | 286,850KB |
| gzip | 預設值 | 473,692KB |
| bz2 | 預設值 | 453,056KB |
| lzma (lzma1) | 預設值 | 314,828KB |
| xz (lzma2) | 預設值 | 314,199KB |
| xz (lzma2) | -9, –extreme | 217,252KB |
其中 7z 和 zip 是在 windows 7/x64 下壓的結果，而 gzip, bzip2, lzma 及 xz 是在 FreeBSD 8.0/amd64 得到的結果，
因為測試的機器及平台相差有大到，所以也就沒有特別去算壓縮解壓縮的時間了。不過下 -9 –extreme 這個極限壓縮參數花的時間很明顯比用預設值長很多，雖然說壓縮比的差異也很明顯就是。
[客家話, hak-Hant-TW]
有些時節會用 ultravnc 連到某台舊的 Mac OS X Leopard 的機器操作 iTunes，可以用，毋過過一下就會斷掉了。斷掉的時間沒一定，較麻煩的是斷掉過後就連毋上去了，要到機器頭前去重新打開 (System Preferences->Share)。
網路上看到咩有人看到這隻問題，關鍵找到對應的重開指令，按仔就可以用 ssh 連入下指令重開，毋始走到機器頭前用 GUI 了。
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent
ssh 到那台機器後用 root 權限下這隻指令，要等一下 (差毋多十過秒)，等他走完就可以重新用 ultravnc 連入去了。
[華語, cmn-Hant-TW]
Time Machine 跑一跑突然跳出來說無法備份，查了一下 /var/log/system.log 發現長這樣 (重點部位打馬賽克)
May 24 14:04:52 Panther com.apple.backupd[25334]: Starting standard backup
May 24 14:04:52 Panther com.apple.backupd[25334]: Attempting to mount network destination using URL: smb://whsyu@10.9.1.120/backup_panther
May 24 14:04:56 Panther com.apple.backupd[25334]: Mounted network destination using URL: smb://whsyu@10.9.1.120/backup_panther
May 24 14:04:56 Panther com.apple.backupd[25334]: Backup verification failed for image /Volumes/backup_panther-1/Panther_${MAC_ADDR}.sparsebundle!
May 24 14:04:56 Panther com.apple.backupd[25334]: Error 513 changing immutability for /Volumes/backup_panther-1/Panther_${MAC_ADDR}_2010-05-24-140456.sparsebundle
May 24 14:04:56 Panther com.apple.backupd[25334]: Unable to make /Volumes/backup_panther-1/Panther_${MAC_ADDR}_2010-05-24-140456.sparsebundle immutable!
May 24 14:04:56 Panther com.apple.backupd[25334]: Creating disk image /Volumes/backup_panther-1/Panther.sparsebundle
May 24 14:04:58 Panther com.apple.backupd[25334]: Error -5000 creating backup disk image
May 24 14:04:58 Panther com.apple.backupd[25334]: Failed to create disk image /Volumes/backup_panther-1/Panther.sparsebundle, status: -5000
May 24 14:05:03 Panther com.apple.backupd[25334]: Backup failed with error: 20
May 24 14:05:03 Panther com.apple.backupd[25334]: Ejected Time Machine network volume.這個映像檔是放在遠端透過 smb 連線，所以 backupd 會自動嘗試掛載，然後似乎是因為映像檔檢查失敗所他嘗試要做一些處理來修復，結果修不好就噴錯誤訊息了。而且不只是噴錯誤訊息，連映像檔的檔名都被改了，看起來像是附加時間標記，應該是做到一半爛掉吧。
備份是放在一台 FreeBSD 的某個 zfs 磁碟上，因為有做每日的 snapshot，所以試著從之前幾天的備份撈看看，錯誤依然存在；先人工 fsck 再讓 Time Machine 讀，結果還是一樣，最後就決定直接去碰映像檔裡面看看有沒有什麼地方可以動的。
雖然說 .sparsebundle 在 Finder 下看到是一個映像檔，不過其實底層就跟 .app 一樣只是一個目錄，也因此要看內容很方便，只要切到目錄內即可。 經過了一些嘗試發現裡面有一個檔案叫 com.apple.TimeMachine.MachineID.plist 裡面有記錄一些前次備份的資訊，包括驗證結果等等 (從檔案內的 xml 標記來猜測)。 對照錯誤訊息的紀錄可看出 backupd 幾乎是瞬間判定驗證失敗，那就很有可能是直接參考這個檔案後立刻做出反應。 把這個檔砍掉之後開 Time Machine 再叫他備份一次，果然這次 backupd 就乖乖的重新跑 fcsk_ufs 來驗證，驗證完之後又可以正常備份了。
在測試的過程中 zfs 的 snapshot 幫了不少忙，因為在試這個檔案之前有先惡搞映像檔內的其他檔案過，結果當然是失敗了，不過一失敗後就立刻用 zfs rollback 把實驗前剛打的 snapshot 還原回來重測別的檔案，這個回溯幾乎是瞬間完成，省了不少時間跟指令。
