小李blog

Contributed by Jordan Hubbard.
　　FreeBSD 項目起源於 1993 年早期， 部分作為 「Unofficial 386BSD Patchkit」 的副產物，patchkit 的最後 3 個協調維護人是：Nate Williams，Rod Grimes 和我。

　　我們最初的目標是做出一份 386BSD 的測試版以修正一些 Patchkit 機制無法解決的錯誤(bug)。 很多人可能還記得早期的項目名稱叫做 「386BSD 0.5」 或者 「386BSD Interim」 就是這個原因。

FreeBSD有許多非凡的特性。其中一些是：

搶佔式多任務與動態優先級調整確保在應用程序和用戶之間平滑公正的分享計算機資源，即使工作在最大的負載之下。

多用戶設備 使得許多用戶能夠同時使用同一 FreeBSD 系統做各種事情。 比如，像打印機和磁帶驅動器這樣的系統外設， 可以完全地在系統或者網絡上的所有用戶之間共享，可以對用戶或者用戶組進行個別的資源限制， 以保護臨界系統資源不被濫用。

符合業界標準的強大 TCP/IP 網絡 支持， 例如 SCTP、 DHCP、 NFS、 NIS、 PPP， SLIP， IPsec 以及 IPv6。 這意味著您的 FreeBSD 主機可以很容易地和其他系統互聯， 也可以作為企業的服務器，提供重要的功能， 比如 NFS(遠程文件訪問)以及 email 服務， 或將您的組織接入 Internet 並提供 WWW，FTP，路由和防火牆(安全)服務。

內存保護確保應用程序(或者用戶)不會相互干擾。一個應用程序崩潰不會以任何方式影響其他程序。

FreeBSD 是一個 32 位操作系統 (在 Alpha，Itanium，AMD64，和 UltraSPARC 上是64 位)， 並且從開始就是如此設計的。

FreeBSD 是一個支持 Intel (x86 和 ItaniumR)，AMD64，Alpha™，Sun UltraSPARCR 計算機的基於 4.4BSD-Lite 的操作系統。

      今天又破財了，為了更好地用宿舍里那臺服務器，去買了臺15寸的Mitsubishi液晶顯示器。
    估計這臺是日本的一級品，分量相當重，雖說是15寸，但重量居然是我們宿舍的一臺聯想19寸液晶顯示器的兩倍重量。重量重的可以解釋為用量不一樣了。我一般的電腦購買經驗也是越重的越好。就拿這臺三菱的液晶來說吧，顯示屏背面是穿孔的鋼板屏蔽，可別小看鋼板屏蔽，如果沒有屏蔽，任何電磁敢讓將導致顯示花屏。像我們宿舍有臺LG的顯示器，只要拿風扇放到旁邊，顯示器靠近風扇那部分頓時變成綠色。我記得99年時很看好LG795顯示器的，那款顯示器在當時用料非常足，也有鋼板屏蔽，莫非這幾年LG開始在低級市場偷工減料？

      趁著沒課去電腦城逛了逛，可沒想到電腦城里假貨挺多的，其中最泛濫的要數存儲卡了。
    奸商還是奸商，賣假貨一點不臉紅。更要緊的是明明是假貨，但價格還和正品的一樣。想想《消費者權益保護法》里的假貨須賠償一倍價錢的規定，但自己又沒那么多時間，不然買一批假貨回來，留好證據，找商家索賠的話，一來可以打擊賣假貨的商家，二來可以掙點小錢。可惜自己沒那時間，也沒那精力。

      今天上午兩節英語課純粹是無聊的。本來在教學計劃里就沒有這安排，之所以開設是學校為了迎接評估，又怕學生英語水平不行而設立的。
    如果真能提高英語水平，或許不會有非議，只是上課的方式真的很無趣。老師就是分好兩人一組，然后互相對話，老師不教授任何對話技巧和方式。說白了就是口語練習。無聊嗎？既然不教授一點知識或技巧，去那里能學到什么呢？這問題值得深思啊。

     本想宿舍里那臺服務器沒顯示器就算了，還能省下一筆錢，可今天服務器在沒接顯示器的情況下半天不能PING通，接上同學的顯示器一看是ARP地址綁定錯誤，這使得我不得不考慮再買臺顯示器的計劃。

     今天給服務器裝上了Freebsd6.2發行版，裝完后發現并不像網上很多人說的必須修改內核才能讓Freebsd6.2支持雙CPU。我得出的結論是只要在裝FREEBSD6.2時，系統是雙CPU的，則FREEBSD就會加入SMP來支持雙CPU。

     8月28號那幾天一直在DISCUZ論壇游蕩，為的是搶在第一時間更下服務器下所有論壇。7月24那天已經把自己運行下的論壇由DISCUZ5FINAL升級到DISCUZ6RC1，此次正式版就修正RC1版本中許多BUG。
   從6.0RC1版本，我就深深地被視頻功能所吸引。誠然在5.5中也可以通過代碼添加的方式增加視頻上傳功能，但此次6.0在程序底部預置代碼一方面看得出CC和DISCUZ展開合作，則相關的兼容問題將得到兩邊的共同解決；一方面預置代碼則更加方便發布視頻（這也是有利也有弊的，在DISCUZ6發布正式版那幾天，眾多站長一直在問視頻功能如何打開，這也是CC和DISCUZ服務的不足）。

    一時激動升級到MYSQL6.0測試版，昨天覺得BUG太多就降版本。沒想到中途一個操作失誤，數據庫掉了很多表。沒辦法，數據庫只好回檔了。數據現在回到7月28號的備份。一個教訓：一定要即時備份數據庫。
   可憐我的BLOG日志哦！

     DISCUZ6默認開啟QIHOO的站外帖子顯示功能，這不是我跟QIHOO說88的根本原因，而是QIHOO的收錄更新速度真是夠慢的，這還不說，QIHOO官方客戶支持自從上個月就近乎癱瘓了，現在在官方連個技術支持人影都找不到。
   在DISCUZ官方論壇，占絕大多數的站長也是對奇虎不抱希望了，如何替換QIHOO代碼的帖子滿天飛。在這里順便告訴想關閉QIHOO搜索功能的朋友一點，DISCUZ6單單關閉QIHOO功能是不完全的，那樣不顯示自己站點的帖子了，但還是顯示外站的帖子。DISCUZ6徹底的關閉奇虎的方法是1、在擴展設置里的奇虎搜索下的基本設置選“不啟用”；2、在相關主題設置欄目里選擇“顯示站外相關主題數量”為0才徹底關閉qihoo.

    專業課補課結束，接下來就是計算機補課。
  電腦室的機子裝了還原卡，開機自動還原C盤。學校的DNS明顯有問題，以前我在文科樓上機時就發現，根據IP段我判斷是教育網內的DNS，可能是網絡中心設置不當，很多域名無法正確解析。寫道這里，很多人會想到去修改本地電腦的DNS，但電腦室里的電腦是運行在USER級別，還裝了管理軟件，不允許用戶在網上鄰居那里修改DNS。這初衷是好，防止學生搗蛋，但一想想卻是個雞肋的辦法，既然開機後會還原系統，前面使用的洞穴再怎么亂設置，后面的同學只要一重啟還是可以一樣正常使用的啊。這真是裝了電子報警器卻沒有為其供電一樣，擺設吧。
   現在進入正題，既然不給進入網上鄰居設置，我就想到使用命令來修改。我先收集教育網內使用廣泛的DNS，然后寫一個bat批處理文件，我命名為dns.bat ，里面的內容是:

然后保存，退出。然后運行此dns.bat文件，系統自動修改本地DNS。
   上機的時候運行此文件，試訪問我的個人網站www.lilujun.com和博客 blog.lilujun.com ，成功了。先前不能解析的域名順利解析。
   后話，202.114.96.1和202.114.96.2是武漢大學的DNS，不是教育網的用戶請自行修改相應的ISP有效的DNS。此方法同樣適用于網吧上網限制破解。

     本人一向喜歡追求新技術，我也知道有時新技術會不成熟，相對老的東西會有很多BUG，但科學總是要前進的，隨著時間的流逝，技術會越來越成熟。
   今天大陸著名的論壇程序開發商DISCUZ發布了其最新版本 Discuz! 6.0.0 RC1 ，一直在關注其開發，今天一發布，我就立刻下來安裝進行更新。
   6.0版本的頁面風格相比以往有很大的改進，不過官方宣傳的有忽悠的嫌疑，說是采用XHTML+CSS架構，我看了源代碼，里面還大量充斥著表格排版的痕跡。不過人家現在在拿著風險投資，可能要向投資方交些成果吧。
   功能是越來越多了，但是CPU占用率直線上升，我現在是采用APACHE2.24+PHP5.23+MYSQL6.0架設服務器，在DISCUZ程序還是5.5時是Processed in 0.010538 second，現在飆升到Processed in 0.040538 second。功能的增加帶來的是硬件的開銷，魚和熊掌不能兼得。
   此次升級很幸運，沒出現很多網友反映的問題。接下來就看看6.0的運行情況了。反正我是抱著必死的決心了，一旦升級就不想去回到老版本，出了BUG就處理。

[quote]
IDN Technical Tests and Evaluations
Following the Autonomica laboratory test of A-labels (IDN TLDs) inserted into a replication of the DNS root zone system as NS-records, a plan for a test and evaluation facility based on the insertion of sample IDN TLDs (A-labels) in the root zone has been developed. This plan takes into consideration the recommendations provided to ICANN at many global IDN-related events. The following elements are all activities necessary to run and conduct the test and evaluations as described in the attached paper.

IDN TLD Application Evaluation Facility:

Description: A draft paper of ICANN’s plans for two IDN TLD evaluation facilities and activities related to the insertion of A-labels (IDN TLDs) into the root zone. The plan includes:

   新浪的搜索引擎棄用自家的IASK轉而用GOOGLE的搜索引擎的新聞已經是滿天飛了，但是從這幾天通過 www.brandhongkong.com 的apache日志來看，IASK的網絡蜘蛛還一直存在著，而且還想以往那樣來 www.brandhongkong.com 收錄網頁，根據在服務器上運行的Advanced Web Statistics 6.6統計器來看，從今天6月18日0時到現在6月18日23：30，Iaskspider共收錄了 www.brandhongkong.com 4938張網頁。這就很奇怪了，既然新浪已經棄用自家的IASK轉而用GOOGLE的搜索引擎，那么IASK的網絡蜘蛛還有什么存在意義呢？為什么IASK搜索引擎還像以往那樣取收錄網站呢？難道新浪保留IASK搜索引擎還有什么別的用途嗎？小李BLOG http://blog.lilujun.com 會繼續進行相關調查，及時報道。

    中國雅虎與6月5日推出了Omnisearch，此搜索平臺的特點是當你搜索一個關鍵字的時候，在得出網頁搜索結果之余，Omnisearch還會顯示出關鍵字相符的圖片、博客等。
  我不是很經常使用YAHOO的搜索，感覺他搜索結果太少了（不過這段時間確實有件事改變了我對YAHOO的看法，像 www.brandhongkong.com 這個論壇要數YAHOO的SPIDER是最氣氛的了，一天要收錄約7萬頁網頁，這只算一個網站而已啊。但不知道收錄那么多，幾乎把每個帖子都掃過幾回了，但得出的結果還是很匱乏，難道YAHOO想厚積薄發，一鳴驚人？）
  用YAHOO搜索最多的是YISOU的時代了，當時雅虎旗下的YISOU搞活動，搜索MP3歌曲會隨機得到抽獎券，結果我中了第一期的獎，得到了一個韓國現代產的MP3，這可是高中的時候啦，當時一個MP3還是1000多元呢，而且中的那個韓國現代MP3在報紙里可是號稱全世界最小體積的MP3（這事件居然現在在網上還能搜索到，不信自己去搜索下，我名字在中將榜上還榜上有名呢。）
  話題回到Omnisearch，6月5日傍晚一看到新聞，我馬上把 www.omnisearch.cn 和 www.omnisearch.com.cn  注冊了下來，時間是2007-06-05 18:06，之后過了十幾分鐘，索性把 www.omnisearch.net.cn 也注冊了下來。
  注冊玩了Omnisearch相關的域名，我才開始體驗Omnisearch的服務。首先第一印象是Omnisearch下面天氣預報的那卡通人物太難看了，建議換成比較可愛的。其次，還是YAHOO的根本問題，檢索量真的很少，如果YAHOO沒根本解決問題，Omnisearch是很難從量的角度跟谷歌和百度競爭的。最后，不得不說的是，YAHOO和GOOGLE在這WEB3.0時代的搜索技術上扛上了，互相指責對方的技術是中看不中用，不過在我眼里，YAHOO至少已經向前邁進了一步，而GOOGLE的相關技術只在英文版中出現雛形。有時候時代成就了先行者，有時也埋沒了先行者，不管Omnisearch如何，至少在搜索技術史上又推動以一大步。
  在此也愿我的 www.omnisearch.cn 和 www.omnisearch.com.cn  在強者的臂彎下茁壯成長。

     首先不能不說IIS非常霸道，明明服務器有兩個IP的，分別是222.208.183.139和222.208.183.252，我把222.208.183.139分配給APACHE2.24使用，主要運行www.brandhongkong.com ，而222.208.183.252分配給IIS使用，主要運行小李書屋www.lilujun.com 。我更改了APACHE的監聽IP，用listen *:80替換成listen 222.208.183.139:80 ，然后IIS也只綁定222.208.183.252一個IP，監聽80端口，結果APACHE和IIS只能一個啟動。
   不過后來我還是設置成功了，APACHE使用222.208.183.139這個IP，監聽80端口，IIS使用222.208.183.252，也是監聽80端口。APACHE運行PHP+mysql，IIS則運行asp+access，兩者互不干擾。
   我的方法：
   首先從WINDOWS2003或WINDOWS XP的安裝光盤里的support/tools/Support.cab解壓出httpcfg.exe，然后COPY到C盤下的windows/system32目錄下，然后進入到命令提示行，運行httpcfg set iplisten -i 222.208.183.252   （222.208.183.252換成你要綁定IIS的IP,命令不用加ip端口），然后運行httpcfg query iplisten查看已經成功綁定，如果你想刪除IIS綁定的IP，那就運行httpcfg delete iplisten -i 222.208.183.252   （222.208.183.252換成你要綁定IIS的IP）。APACHE的HTTPD.CONF配置文件里，要記得把listen *:80替換成listen 222.208.183.139:80 （222.208.183.139換成你要APACHE綁定監聽的IP），如果有虛擬主機，則繼續連虛擬主機里的監聽IP也要由×改成指定的ip。最后重新啟動服務器，一定要重新啟動服務器才生效，當時我在這一步就走了很多彎路。現在IIS和APACHE就能運行在多IP下都使用用80端口了。

     中午仔細查閱了服務器日志，發現老是有人濫發UDP數據包給我，而且流量非常大。我想我又沒招惹誰，網站都是合法運行的，難道是因為服務器的IP問題？
   在周一換機房的時候，當時我就很不喜歡分配給我的IP，因為那IP原先是做私服的，在百度、谷歌都能搜索到，搞不好就容易被人攻擊或則被人誤會是私服的網站。
   這幾天終于嘗到了垃圾IP的后果，就是服務器老是莫名其妙被人攻擊。我決定找ISP換服務器IP，跟負責人磨了半天，他或許也是害怕我老被攻擊又叫他們重新安裝系統或重啟之類的，答應換了IP，之余我又要了一個IP，算是從雙線機房換回電信機房的一點補償吧。

     前天服務器收到DDOS攻擊，頓時機子像癱瘓了一樣，CPU占用率一直居高不下，每個網站的響應速度超過了本分鐘，當時立即打電話給電信機房的值班人員，他們說在我沒打電話之前已經在嚴密關注了。
   昨天白天還是那莫名其妙的死機問題，幾乎是半小時打一次電話催重啟，搞得我自己也不好意思了。
   剛才又再打了一次，打完系統補丁後，就順勢像重新啟動，但沒注意到系統當時被補丁選擇了關機。我等了好長時間都PING不通，心想是不是補丁沖突引起系統崩潰了？幸好打電話要求重啟（當時還真不知道是關機了），再等了一分鐘，系統終于PING通，網站運行了，我的心才平靜下來。

    這段時間服務器經常藍屏死機，輕則服務器自動重啟，重則只有請電信機房的人按重啟才能解決問題。
  我一直百思不得其解，今天中午回到宿舍，心里想有殺毒軟件監控服務器硬盤操作的話，效率一定很低。所以我就把瑞星卸載了。沒想到奇跡發生了，原先是半個小時或一個小時就出現宕機的，現在已經運行了10個小時都沒出現故障，看來瑞星在WIN2003里面和APACHE是有點沖突的，只不過沖突來的很晚，這樣就為排除故障增加了難度。