上星期買印表機時, 送了一個 1G 的 USB 隨身碟. 由於容量不小, 自己每天也都是筆記型電腦帶來帶去的, 也沒什麼東西要用這個來存放. 最後想說, 這玩意也可以拿來開機, 我只要把一些常用的程式放到上頭去, 就可以取代原本的一堆緊急救援的光碟片了, 這樣子應該會方便許多. 不過這些光碟, 有些是 DOS, 有些是 Linux, 也有些是 XPE 的程式, 如果要都放在一個隨身碟上頭, 就必須要有個開機管理的程式, 能夠在開機時選擇要進到那一個系統才可以. 所以就想到了在 Linux 中常用的 grub 這個 boot loader, 剛好也有個 DOS 版本的 grub4dos 可以使用. 所以... 就決定使用 grub4dos 來處理了. (閱讀全文)
這個問題在去年底剛買這台 T60 時就碰過了, 只要在 MinGW/MSYS 裡頭, 一跑 shell script 去做編譯的動作, 就會出現一堆 sh.exe stackdump 的錯誤訊息. 不過後來我把 T60 還原成出廠的狀態後, 這個問題就不見了. 直到最近, 又進到 MSYS 去要自行編譯程式時, 又碰到了這個問題. (閱讀全文)
隨著資料量的增加, 通常資料庫的重要性也就跟著增加, 這時, 我們要如何確保資料庫可以正常運作呢? 使用比較好的機器? 使用高級的 RAID? 把資料備份好? 這些做的再好, 也都還是有風險. 也就是, 只要是硬體, 就可能會壞. 機器就是那一台, 出了問題, 就得找台機器, 重新開始安裝, 然後由備份的資料還原. 資料一多, 這些動作可以短到幾小時, 也可能是兩三天才能處理好. 也就是, 在這段時間內, 如果你的公司運作, 對資料庫有極大的依賴性, 可能這段時間的運作完全停擺, 損失不可說不小. (閱讀全文)
我們大約是由 2003 年初開始使用 PostgreSQL 當做是公司內的資料庫系統. 當初在 ORACLE (9i), MySQL (3.x) 與 PostgreSQL (7.2) 之間選擇時, 先把當時還算很簡陋的 MySQL (那時應該還沒有支援 stored procedure, sub-query, transaction 等等的功能, 實在不適合商業使用, 不過因為快又小, 我們有些中介的資料庫, 還是使用 MySQL 來處理) 給排除掉. 在 ORACLE 與 PostgreSQL 的比較上, 在我們需要的功能上頭, 兩者都能提供, 當然, PostgreSQL 有絕對的價格優勢 (不過, 當初我們並沒有預算上的壓力, 雖然 ORALCE 不算便宜, 但我們決定要用時, 也不會說花不起這筆錢), 但是在複製, 備份與災難復原方面, 就遠遠比不上 ORACLE 了. 最後與老闆討論的結果, 是決定先用 PostgreSQL 試看看, 如果一年內有發生重大的當機或災難時, 我們就轉用 ORACLE. 結果... 當然 4 年多過去了... 我們還是在用 PostgreSQL. (閱讀全文)
前一陣子寫了一個 msn.class.php, 所以研究了一下 MSN 所使用的通訊協定, 主要的資訊, 當然都來自於這個網站上頭. 不過... 上頭對於 MSNP15 的說明有點不太詳細, 有些在 MSNP13 之後所使用的 SOAP 功能, 在我自己的實作上頭, 並不如網站所說的那麼順利, 有些指令怎麼送就是不會成功. 後來, 看到該網站提到的 oSpy 這個軟體, 就抓回來自己試了一下, 結果, 效果實在驚人. (閱讀全文)