這個我不確定算是 mencoder 還是 Linux kernel 3.9 的問題. 反正兩者放一起就是有問題就對了.
發生的原因是在 Linux kernel 3.9 中, 對於 V4L2 的時間取得改成使用 monotonic timestamp (透過 v4l2_get_timestamp() 來處理), 但是在 mencoder 中, 似乎沒辦法正確去判斷是一般的 timestamp 還是 monotonic timestamp 就直接當成一般的時間來處理, 所以在計算時間上就有問題. (閱讀全文)
由於方便管理, 基本上安裝 Linux 時, 應該都會用 LVM 來管理, 當然我也不例外. 不過... 這一年多來, 我碰到了不少次在每天備分時當機的問題 (備份沒全部完成, 機器仍有回應, 不過 load average 會高達數百到數千, 打個指令也不知道要多久才能回應... 通常碰到就只能重開機), 由於頻率不算太多 (三台機器, 每天備份, 可能兩個月碰到一次吧), 所以一直沒去找原因. (閱讀全文)
最近幫別人裝了一台伺服器, 裝上了 Horde/IMP, 發現目前已經升到 Horde 5 的版本了. 畫面似乎比 4 的版本好一些, 所以.... 就把家裡的 Horde 也做了升級的動作. (閱讀全文)
印象中這個問題出現很久了, 不過因為我也很少用到 ncurses 的程式 (應該也只有偶而用用 aptitude 與 build kernel 時可能會用到 make menuconfig 這兩個吧), 所以就將就著用.
不過最近幫人裝了一台新的伺服器, 用的還是 Debian Squeeze 的版本, 突然發現用到的 screen 是正常的.... 看來是自從我把機器由 Squeeze 升級到 Wheezy 的時候, 就把 screen 由 4.0.3 升到 4.1.0 後就出現這個問題了. (閱讀全文)
不久前發現, 一直以來用來與 SciTE 搭配使用的 wscitecm.dll 在並無法處理 unicode 的路徑與檔名 (用了這麼多年才發現, 也算不容易....). (閱讀全文)
如同之前 Win7 一樣, 我們可以把 Win8 的所有版本, 合併到同一張光碟片中, 安裝時再選擇需要的版本就可以了. (閱讀全文)
最近因為有些程式所在的環境, 對外連線有些麻煩, 所以... 就想加上 proxy 的支援, 而目前最常用的 proxy, 大概就是 SOCKS5 或 HTTP Proxy 了.
一般 php 的程式, 對於 socket 的處理, 通常都是使用 fsockopen() 來處理. 而上頭兩類的 proxy, 都是在一開始連線時, 處理一些 handshake 的動作之後, 就不用再做任何處理了, 後續的動作與你直接連線都一樣. 所以... 我們只要寫一個 function, 用來取代 fsockopen(), 就可以簡單的加上 proxy 的支援了. (閱讀全文)
FileZilla 本身雖然支援 HTTP CONNECT 方式的 proxy, 不過, 它只使用 Basic 方式來認證, 如果碰到 Digest 方式的 proxy server, 就會得到 407 的錯誤而無法連線. (閱讀全文)
一直以來, 都是使用 tdm-gcc 來編譯 win32 或 win64 的程式 (當然, 還是有很多是用 Microsoft 的 Visual Studio 來處理). 不久前, 因為某些 function 在 tdm-gcc 的 4.7.2 所附的 win32/64 sdk 中, 並沒有被納入 (看了一下 mingw64 的 changelog, 是剛被加上沒多久), 所以就自己試著更新 mingw64 runtime, 結果... 越弄越多, 最後.... 就整個都自己編譯出來了. (閱讀全文)
由於我習慣用 SciTE 來取代原本 Notepad 的工作, 所以... 多數在 Windows 底下打開文字檔的時候, 都是去執行 SciTE. 不過... 前幾天在打開 Sandboxies 的設定檔時, 發現無法正常顯示. 出現的畫面看起來是 Unicode 編碼 (UTF16-LE), 不過, SciTE 並沒有辦法判斷出正確的編碼.
Google 找了一下, 發現有人問過作者了, 原來 SciTE 只能打開有 BOM 的 Unicode 編碼檔案. (閱讀全文)
原本在 cygwin 中, 是透過 mintty 來執行 shell, 不過... mintty 並沒有 tab 的功能, 所以, 要執行不同的 shell, 就要再打開一個視窗來用. 所以... 就使用 console 這個程式來取代. (閱讀全文)
由於在 msys 中碰到的 make freeze 問題, 所以就將開發的環境由 msys 轉到 cygwin 來使用了. (閱讀全文)
最近因為要更新所用的 TDM64-GCC 中的 mingw64-runtime-crt (有些 function 在最近的版本才有), 結果, 玩著玩著就自己 build 起 mingw64 用的 gcc 4.7.2 來了 (這中間也有些心得, 有空再說) .
結果, 在 build gcc 的過程 (使用 MSYS 環境), 使用 make -jN 來加速編譯的速度時, 發現常常跑到一半, make 就停住了 (不過仍佔用不少 CPU 時間), 每次都要 kill 之後再重跑. (閱讀全文)
在 Lenovo 的文件上頭, ThinkPad W510 應該最多只能裝到 16G (4G x 4) 的記憶體. 不過.... 前幾天看到網路上有網友試著裝上 32G (8G x 4) 的記憶體, 也可以正常使用.
所以.... 就直接網路上訂了 4 條 8G 的記憶體回來升級..... 結果, 試著拿下原本的一條 4G, 換上新的 8G (變成 4G x 2 + 8G) 之後, 居然只變成抓到 8G (難道我買的不能用嗎?)....
接著把所有的 RAM 都移除, 只裝上一條 8G 的試看看, 結果... 再開機居然開始 beep beep 叫.... 完全開不起來....
不信邪的我.... 先拿吸塵器清一清, 再試一次, 這次總算正常開機也抓到那條 8G 的記憶體了. 接著再裝上另外 3 條 8G 的記憶體, 都可以正常抓到了.
看來, 我的 W510 升級後, 又可以撐很久了.
前幾天在有人新增 comment 之後, 發現整個網站的顯示格式大亂. 找了一下, 發現是在顯示最近留言功能裡頭, 會把留言截短之後再透過 strip_tags 處理. 像是這樣:
<li><a title="View comments by {$comment->getUsername()}" href="{$url->postPermalink($commentpost)}#{$comment->getId()}"><b>{$comment->getUsername()}¡G</b>{$comment->getText()|truncate:100:"..."|strip_tags}</a></li>
但是, 先做 truncate, 就可能造成 tag 變成有頭沒有尾, 所以後面的 strip_tags 也就沒什麼作用了.
改成先做 strip_tags 再去處理 truncate 就應該可以避免這個問題了.
<li><a title="View comments by {$comment->getUsername()}" href="{$url->postPermalink($commentpost)}#{$comment->getId()}"><b>{$comment->getUsername()}¡G</b>{$comment->getText()|strip_tags|truncate:100:"..."}</a></li>
改好後看起來就正常了. (如果怕有其它的情形... 也許後面再加上一個 escap 來濾掉一些字元也可以)
最近突然發現在 Windows 8 底下, 每次接上 USB 硬碟之後, 都沒辦法正常的移除. 每次要移除都說有程式在使用中, 不過用 unlocker 看又看不出有什麼程式在使用中.
記得剛裝好 Windows 8 的時候, 並沒有這個問題啊? 應該與我後來安裝或執行的程式有關吧.
一個個把目前執行的程式關閉試看看, 終於發現把 TaskMgr.exe 關閉之後就可以正常把 USB 硬碟給移除了. 我想應該是一個 bug 吧.
最近開始用 C# 寫 .Net 的程式, 發現就寫程式的方便性來說, 比起直接用 C/C++ 寫要方便許多. 所以... 原本有些為了方便, 使用 php 來寫的 script, 也都順便改用 C# 來寫. (閱讀全文)
前不久升級到 Firefox 13 之後, flashblock 的白名單就無法正常使用 (與 AdBlock Plus 搭配時). 作者的建議是停用那些相衝突的 extension.... 不過, 在我的使用上, 我覺得就不管它, 一起用會比較合理些, 頂多是多按一下去跑那些需要的 flash 就可以了.
前兩天, 作者放出了 1.5.16 的新版本, 號稱解決了這個問題. 可以我試的結果, 有些站台可以 (如 NBA), 但有些站台不 (如 MLB). 把 Error Console 打開會發現, 有問題的站台會在 flashblock.js 240 行出現錯誤.
所以我試著改了一下這個地方:
diff --strip-trailing-cr -Nur flashblock.old/content/flashblock/flashblock.js flashblock/content/flashblock/flashblock.js
--- flashblock.old/content/flashblock/flashblock.js 2012-06-18 18:17:50 +0800
+++ flashblock/content/flashblock/flashblock.js 2012-06-19 13:29:01 +0800
@@ -237,7 +237,12 @@
baseURI = ios.newURI(codeBase, node.ownerDocument.characterSet, baseURI);
} catch (e) {} // Ignore invalid codebase attribute
}
- targetURI = ios.newURI(relativeURI, node.ownerDocument.characterSet, baseURI);
+ if (node.ownerDocument) {
+ targetURI = ios.newURI(relativeURI, node.ownerDocument.characterSet, baseURI);
+ }
+ else {
+ targetURI = ios.newURI(relativeURI, null, baseURI);
+ }
}
catch (e) {
Components.utils.reportError(e);
改了之後, 在我這兒會用到的站台似乎都沒有問題了.
如果你有類似的問題, 可以把 profile 下的 extensions\{3d7eb24f-2740-49df-8937-200b1cc08f8a}\chrome 底下的 flashblock.jar 解開來 (這是個 zip 檔案), 然後改 裡頭的 content\flashblock\flashblock.js 內容 (如上), 然後再把檔案壓縮回去 (zip 格式, 再改名為 .jar).
如果不想自己改, 可以等作者更新或抓這個回去: http://www.teatime.com.tw/~tommy/files/flashblock.jar
PS. 記得把 Firefox 關了再改.
最近發現在安裝新的 kernel 時, Debian 在安裝之後, 會去處理 dkms 的模組, 但是當同一個模組有多個版本存在時, /usr/lib/dkms/dkms_autoinstaller 這個 script 就會回報這個錯誤:
Apr 25 17:09:33 mail dkms_autoinstaller: e1000e: Multiple versions in DKMS. Unsure what to do. Resolve manually.
Apr 25 17:09:33 mail dkms_autoinstaller: igb: Multiple versions in DKMS. Unsure what to do. Resolve manually.
由於舊的版本通常是在目前或舊的 kernel 仍在使用, 所以也無法馬上就移除. 所以每次有新的版本時, 就有這個問題. (有其他的解決方法嗎?)
使用這個 patch, 可以直接選擇最大的版本來用, 這樣就可以允許多個版本存在 (這應該是多數情況下的選擇):
--- dkms_autoinstaller.orig 2012-04-26 10:03:51.235070429 +0800
+++ dkms_autoinstaller 2012-04-26 10:03:50.691733326 +0800
@@ -79,7 +79,10 @@
version_count=0
already_installed=""
already_installed_version=""
- for versioned_path in $(find "$modulepath" -maxdepth 1 -mindepth 1 -type d -a -not -name original_module); do
+ for versioned_path in $(find "$modulepath" -maxdepth 1 -mindepth 1 -type d -a -not -name original_module | sort -r); do
+ if [ "$version_count" -gt 0 ]; then
+ continue
+ fi
version_count=$(($version_count + 1))
version_in_tree="${versioned_path##*/}"
這樣以後更換新的版本時, 就應該會自動處理了.
昨天把 kernel 裡頭關於 xz 的支援打開後, 就把 kernel 改用 xz 來壓縮, 解壓縮的速度比 bzip2 快, 壓起來又比 bzip2 小. 所以就想把 initramfs 也改用 xz 來壓縮.
由於 Debian Squeeze 的 initramfs-tools 並沒有支援 xz, 不過... 看那個 script, 並沒有要求 /etc/initramfs-tools/initramfs.conf 這個檔案內的 COMPRESS 設定只能設它所列的那一個, 而是把這個設定當成指令來執行壓縮的動作, 所以... 我原本以為就直接改成 xz, 這樣就可以了.
執行 mkinitramfs 或 update-initramfs 之後, 雖然是產生了一個 xz 壓縮的檔案, 不過.... 重開機後, 發現 kernel 沒辦法正確載入那個檔案....
後來看到這篇, 提到要用這樣的參數才可以:
find . | cpio -H newc -o | xz --check=crc32 --x86 --lzma2 > /usr/src/initram.igz
所以... 還是要去改 /usr/sbin/mkinitramfs 這個 script 的內容, 對 xz 特別去處理才可以.
後來看到 Debian 有這個 patch 可以用:
diff -uNr initramfs-tools-0.98.8/conf/initramfs.conf initramfs-tools-0.98.8.new/conf/initramfs.conf
--- initramfs-tools-0.98.8/conf/initramfs.conf 2010-08-26 03:32:27.000000000 +0800
+++ initramfs-tools-0.98.8.new/conf/initramfs.conf 2011-05-12 09:49:57.000000000 +0800
@@ -36,7 +36,7 @@
KEYMAP=n
#
-# COMPRESS: [ gzip | bzip2 | lzma | lzop ]
+# COMPRESS: [ gzip | bzip2 | lzma | lzop | xz ]
#
COMPRESS=gzip
diff -uNr initramfs-tools-0.98.8/mkinitramfs initramfs-tools-0.98.8.new/mkinitramfs
--- initramfs-tools-0.98.8/mkinitramfs 2011-01-28 22:09:09.000000000 +0800
+++ initramfs-tools-0.98.8.new/mkinitramfs 2011-05-12 09:49:27.000000000 +0800
@@ -149,6 +149,8 @@
[ "${compress}" = lzop ] && compress="lzop -9"
+[ "${compress}" = xz ] && compress="xz -9 --check=crc32"
+
if [ -d "${outfile}" ]; then
echo "${outfile} is a directory" >&2
exit 1
加上 --check=crc32 就可以了.
這樣子處理後的檔案, 果然可以正常開機了.
最近發現每天使用 LVM snapshot 備份的時候, 總會有些 snapshot 無法被移除, 找了一下, 應該是 LVM 與 udisks 搭配時發生的問題.
解決方法也很簡單, 就是一直試到可以移除為止. (上頭連結有人說用 lvchange 先改狀態再移除就可以, 不過我試的結果, 也是有無法移除的時候, 所以.... 弄個 loop 來移除, 試到可以移除為止, 這是目前比較可行的方法)
我把原本移除的動作改用 for loop 處理, 目前看起來多試在試了兩三次後就會被移除了.
btrfs 是 Oracle 為 linux 所做的一個 open source filesystem, 其主要目標應該是 ZFS (因為授權的關係, 無法直接納入 linux kernel 中) 吧. (閱讀全文)
我用 heartbeat 應該有好幾年了, 好像有 0.x 版開始就用到現在的 3.x 版. 記得剛開始的時候, 功能不多, 不過也沒什麼問題... 現在用的 3.x 版, 最近常常碰到 standby 的機器重新開機 (應該說 heartbeat 的程式停掉再跑), 讓原本正在運作的機器的 heartbeat 突然佔用所有的 CPU, 然後一堆 log 在 ha-log 或 ha-debug 裡頭, 接著... 原本應該正常運作的 heartbeat 就停了.
由於 heartbeat 的 maillist 中看到不少人有類似的情形, 不過... 看起來似乎沒有什麼解決方法. 由於次數越來越多, 所以就想把 heartbeat 換掉. (閱讀全文)