• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 12, comments - 4, trackbacks - 0, articles - 36

            2006年4月9日

            分手,是由短信開始!

            06.04.01???14:52
            ???寶貝,我親愛的寶貝,請你去愛別人,好嗎?你是我一生最好的朋友,是我的親人,可是不再有戀人的感覺了。

            06.04.02???16:05
            修不好算了,也不要緊,錢不重要,下次攢錢買個好些的

            06.04.02???18:16
            不開通網絡,電腦對我沒有用的,你先拿去用吧,哪天來拿說一聲就好。

            06.04.02???19:26
            你知道,這兩年來我們之間一直有些人,我不是好女人,但是為了你我都結束了。只是我現在忽然有了年齡壓力

            06.04.02???19:42
            不是的,單純的年齡小些的女孩子更適合你,而我需要各方面都制得住我的,請相信我是理智的

            06.04.02???19:55
            對我來說,沒什么是長久的

            06.04.02???20:14
            這件事你不要告訴別人,我不希望公司里有干擾。公司里你還是我名義上的男友。

            06.04.02???20:41
            我們把最美好的歲月都給了彼此,沒有什么可遺憾的了。

            06.04.02???21:07
            你永遠是我最好最可信賴的朋友,我會在北京待幾年,因為還喜歡這份工作。但將來應該會去上海的。

            06.04.03???21:33
            我會的。謝謝你!我牽掛你如同你牽掛我,家里都是白酒味,呵呵。

            06.04.03???21:45
            不一定離婚,但是很可能出軌/不要去追究了,從功利或者世俗的角度看,我們不適合過一聲,我作的很,而你適合好女孩子。

            06.04.03???22:10
            這次你比我想象的堅強,也許我們習慣了彼此看作孩子吧。我還夢想著有天能用學生的方式去蝥源,不知道是否永遠變成一個夢想。我們都是完美主義者,而世界永遠是不完美的,不說了,干活,你也好好看書,我們都好好生活:)

            06.04.09???11:51
            我們之間近兩年有一些小插曲,你也知道我因為害怕傷害你,最終都放棄了,可是戀愛太久,確實沒有激情了,也不想平淡過下去。

            06.04.09???11:54
            你對我太好,我卻不知足,反而覺得有壓力,對我而言保留一個人的空間很重要,即使一個人住,一個人打掃,不用遷就別人的感覺很自由。

            06.04.09???16:02
            我遇到一個和自己很象的人,彼此都看得透,但是都不說,類似的人可能不是個好選擇,也不會長久,但是這次我不想再背著你,腳踏兩條船會有負疚感

            06.04.09???16:29
            你不明白,我卻了解自己,我實在是太愛玩了,根本不能用理智控制自己,不論什么結果,將來出什么亂子都是自找的。但是,不該一再對不起你。這樣我再沒有心理負擔了。

            06.04.09???22:05
            我知道,你是少有的好男人,但是我更看重情商,你明白嗎?你的成熟度已經比我落后,以后也不可能趕上,因為你我環境不同,而且我也在成長。

            06.04.09???22:12
            謝謝你一直以來的寬容和愛護,你是我一輩子的親人和朋友,我依舊牽掛你的點點滴滴,只有這次,我必須負你,其他能為你做的,我絕不猶豫

            06.04.09???22:26
            別計較這些了,好嗎?我很可能是錯的,是幼稚的,但是我既然已經做了決定,請尊重我,后果我也會自己承擔

            06.04.06???22:36
            恩,我知道,這次經歷會讓我們都更成熟,我很喜歡你這樣,結束吧,這段戀愛的結束,也許是新的開始,我對你的感情,早就是親情了。

            06.04.09???22:51
            謝謝你,親愛的,謝謝你的努力!但這是我最后一次說愛你了,對了,我給你帶了兩袋奶酪,不知道你會不會喜歡,我睡了,再見

            posted @ 2006-04-09 17:43 inwind 閱讀(324) | 評論 (0)編輯 收藏

            2006年4月3日

            比干問菜農,空心菜無心是菜,人如果無心了呢?
            ?
            終于明白中國古人為什么用心痛,傷心,揪心這些詞了。
            ?
            思考的是大腦,可是,痛得是心,揮之不去的,痛徹心菲的

            posted @ 2006-04-03 08:13 inwind 閱讀(239) | 評論 (0)編輯 收藏

            2006年3月21日

            1. 數據結構不必強求功能復雜,夠用就行,太復雜的數據結構難于控制,并且消耗資源。
            2. 注意內存的分配&回收,設計實現時一定要清楚所使用內存的生存周期,出生點&死亡點
            3. 初始化,所有使用的變量一定要初始化,一點點的開銷,可以節省大量的時間
            4. 算法的修煉有欠火候

            posted @ 2006-03-21 12:02 inwind 閱讀(264) | 評論 (0)編輯 收藏

            2006年2月10日

            項目主頁: http://www.uclinux.org/

            簡介
            Linux是一種很受歡迎的操作系統,它與UNIX系統兼容,開放源代碼。它原本被設計為桌面系統,現在廣泛應用于服務器領域。而更大的影響在于它正逐漸的應用于嵌入式設備。uClinux正是在這種氛圍下產生的。在uClinux這個英文單詞中u表示Micro,小的意思,C表示Control,控制的意思,所以uClinux就是Micro-Control-Linux,字面上的理解就是"針對微控制領域而設計的Linux系統"。

            uClinux小型化的做法

            標準Linux可能采用的小型化方法
            1. 重新編譯內核
            Linux內核采用模塊化的設計,即很多功能塊可以獨立的加上或卸下,開發人員在設計內核時把這些內核模塊作為可選的選項,可以在編譯系統內核時指定。因此一種較通用的做法是對Linux內核重新編譯,在編譯時仔細的選擇嵌入式設備所需要的功能支持模塊,同時刪除不需要的功能。通過對內核的重新配置,可以使系統運行所需要的內核顯著減小,從而縮減資源使用量。
            2. 制作root文件系統映象
            Linux系統在啟動時必須加載根(root)文件系統,因此剪裁系統同時包括root file system的剪裁。在x86系統下,Linux可以在Dos下,使用Loadlin文件加載啟動,
            uClinux采用的小型化方法
            1.uClinux的內核加載方式
            uClinux的內核有兩種可選的運行方式:可以在flash上直接運行,也可以加載到內存中運行。這種做法可以減少內存需要。
            Flash運行方式:把內核的可執行映象燒寫到flash上,系統啟動時從flash的某個地址開始逐句執行。這種方法實際上是很多嵌入式系統采用的方法。
            內核加載方式:把內核的壓縮文件存放在flash上,系統啟動時讀取壓縮文件在內存里解壓,然后開始執行,這種方式相對復雜一些,但是運行速度可能更快(ram的存取速率要比flash高)。同時這也是標準Linux系統采用的啟動方式。
            2.uClinux的根(root)文件系統
            uClinux系統采用romfs文件系統,這種文件系統相對于一般的ext2文件系統要求更少的空間。空間的節約來自于兩個方面,首先內核支持 romfs文件系統比支持ext2文件系統需要更少的代碼,其次romfs文件系統相對簡單,在建立文件系統超級塊(superblock)需要更少的存儲空間。Romfs文件系統不支持動態擦寫保存,對于系統需要動態保存的數據采用虛擬ram盤的方法進行處理(ram盤將采用ext2文件系統)。
            3.uClinux的應用程序庫
            uClinux小型化的另一個做法是重寫了應用程序庫,相對于越來越大且越來越全的glibc庫,uClibc對libc做了精簡。
            uClinux對用戶程序采用靜態連接的形式,這種做法會使應用程序變大,但是基于內存管理的問題,不得不這樣做(這將在下文對uClinux內存管理展開分析時進行說明),同時這種做法也更接近于通常嵌入式系統的做法。

            uClinux的開發環境

            GNU開發套件
            Gnu開發套件作為通用的Linux開放套件,包括一系列的開發調試工具。主要組件:
            Gcc: 編譯器,可以做成交叉編譯的形式,即在宿主機上開發編譯目標上可運行的二進制文件。
            Binutils:一些輔助工具,包括objdump(可以反編譯二進制文件),as(匯編編譯器),ld(連接器)等等。
            Gdb:調試器,可使用多種交叉調試方式,gdb-bdm(背景調試工具),gdbserver(使用以太網絡調試)。
            uClinux的打印終端
            通常情況下,uClinux的默認終端是串口,內核在啟動時所有的信息都打印到串口終端(使用printk函數打印),同時也可以通過串口終端與系統交互。
            uClinux在啟動時啟動了telnetd(遠程登錄服務),操作者可以遠程登錄上系統,從而控制系統的運行。至于是否允許遠程登錄可以通過燒寫romfs文件系統時有用戶決定是否啟動遠程登錄服務。
            交叉編譯調試工具
            支持一種新的處理器,必須具備一些編譯,匯編工具,使用這些工具可以形成可運行于這種處理器的二進制文件。對于內核使用的編譯工具同應用程序使用的有所不同。在解釋不同點之前,需要對gcc連接做一些說明:
            .ld(link description)文件:ld文件是指出連接時內存映象格式的文件。
            crt0.S:應用程序編譯連接時需要的啟動文件,主要是初始化應用程序棧。
            pic:position independence code ,與位置無關的二進制格式文件,在程序段中必須包括reloc段,從而使的代碼加載時可以進行重新定位。
            內核編譯連接時,使用ucsimm.ld文件,形成可執行文件映象,所形成的代碼段既可以使用間接尋址方式(即使用reloc段進行尋址),也可以使用絕對尋址方式。這樣可以給編譯器更多的優化空間。因為內核可能使用絕對尋址,所以內核加載到的內存地址空間必須與ld文件中給定的內存空間完全相同。
            應用程序的連接與內核連接方式不同。應用程序由內核加載(可執行文件加載器將在后面討論),由于應用程序的ld文件給出的內存空間與應用程序實際被加載的內存位置可能不同,這樣在應用程序加載的過程中需要一個重新地位的過程,即對reloc段進行修正,使得程序進行間接尋址時不至于出錯。(這個問題在 i386等高級處理器上方法有所不同,本文將在后面進一步分析)。
            由上述討論,至少需要兩套編譯連接工具。在討論過uClinux的內存管理后本文將給出整個系統的工作流程以及系統在flash和ram中的空間分布。
            可執行文件格式
            先對一些名詞作一些說明:
            coff(common object file format):一種通用的對象文件格式
            elf(excutive linked file):一種為Linux系統所采用的通用文件格式,支持動態連接
            flat:elf格式有很大的文件頭,flat文件對文件頭和一些段信息做了簡化
            uClinux系統使用flat可執行文件格式,gcc的編譯器不能直接形成這種文件格式,但是可以形成coff或elf格式的可執行文件,這兩種文件需要coff2flt或elf2flt工具進行格式轉化,形成flat文件。
            當用戶執行一個應用時,內核的執行文件加載器將對flat文件進行進一步處理,主要是對reloc段進行修正(可執行文件加載器的詳見fs/binfmt_flat.c)。以下對reloc段進一步討論。
            需要reloc段的根本原因是,程序在連接時連接器所假定的程序運行空間與實際程序加載到的內存空間不同。假如有這樣一條指令:
            jsr app_start;
            這一條指令采用直接尋址,跳轉到app_start地址處執行,連接程序將在編譯完成是計算出app_start的實際地址(設若實際地址為 0x10000),這個實際地址是根據ld文件計算出來(因為連接器假定該程序將被加載到由ld文件指明的內存空間)。但實際上由于內存分配的關系,操作系統在加載時無法保證程序將按ld文件加載。這時如果程序仍然跳轉到絕對地址0x10000處執行,通常情況這是不正確的。一個解決辦法是增加一個存儲空間,用于存儲app_start的實際地址,設若使用變量addr表示這個存儲空間。則以上這句程序將改為:
            movl addr, a0;
            jsr (a0);
            增加的變量addr將在數據段中占用一個4字節的空間,連接器將app_start的絕對地址存儲到該變量。在可執行文件加載時,可執行文件加載器根據程序將要加載的內存空間計算出app_start在內存中的實際位置,寫入addr變量。系統在實際處理是不需要知道這個變量的確切存儲位置(也不可能知道),系統只要對整個reloc段進行處理就可以了(reloc段有標識,系統可以讀出來)。處理很簡單只需要對reloc段中存儲的值統一加上一個偏置(如果加載的空間比預想的要靠前,實際上是減去一個偏移量)。偏置由實際的物理地址起始值同ld文件指定的地址起始值相減計算出。
            這種reloc的方式部分是由uClinux的內存分配問題引起的,這一點將在uClinux內存管理分析時說明。
            針對實時性的解決方案
            uClinux本身并沒有關注實時問題,它并不是為了Linux的實時性而提出的。另外有一種Linux--Rt-linux關注實時問題。Rt- linux執行管理器把普通Linux的內核當成一個任務運行,同時還管理了實時進程。而非實時進程則交給普通Linux內核處理。這種方法已經應用于很多的操作系統用于增強操作系統的實時性,包括一些商用版UNIX系統,Windows NT等等。這種方法優點之一是實現簡單,且實時性能容易檢驗。優點之二是由于非實時進程運行于標準Linux系統,同其它Linux商用版本之間保持了很大的兼容性。優點之三是可以支持硬實時時鐘的應用。uClinux可以使用Rt-linux的patch,從而增強uClinux的實時性,使得 uClinux可以應用于工業控制、進程控制等一些實時要求較高的應用。

            uClinux的內存管理
            應該說uClinux同標準Linux的最大區別就在于內存管理,同時也由于uClinux的內存管理引發了一些標準Linux所不會出現的問題。本文將把uClinux內存管理同標準Linux的那內存管理部分進行比較分析。
            標準Linux使用的虛擬存儲器技術
            標準Linux使用虛擬存儲器技術,這種技術用于提供比計算機系統中實際使用的物理內存大得多的內存空間。使用者將感覺到好像程序可以使用非常大的內存空間,從而使得編程人員在寫程序時不用考慮計算機中的物理內存的實際容量。

            為了支持虛擬存儲管理器的管理,Linux系統采用分頁(paging)的方式來載入進程。所謂分頁既是把實際的存儲器分割為相同大小的段,例如每個段1024個字節,這樣1024個字節大小的段便稱為一個頁面(page)。
            虛擬存儲器由存儲器管理機制及一個大容量的快速硬盤存儲器支持。它的實現基于局部性原理,當一個程序在運行之前,沒有必要全部裝入內存,而是僅將那些當前要運行的那些部分頁面或段裝入內存運行(copy-on-write),其余暫時留在硬盤上程序運行時如果它所要訪問的頁(段)已存在,則程序繼續運行,如果發現不存在的頁(段),操作系統將產生一個頁錯誤(page fault),這個錯誤導致操作系統把需要運行的部分加載到內存中。必要時操作系統還可以把不需要的內存頁(段)交換到磁盤上。利用這樣的方式管理存儲器,便可把一個進程所需要用到的存儲器以化整為零的方式,視需求分批載入,而核心程序則憑借屬于每個頁面的頁碼來完成尋址各個存儲器區段的工作。
            標準Linux是針對有內存管理單元的處理器設計的。在這種處理器上,虛擬地址被送到內存管理單元(MMU),把虛擬地址映射為物理地址。
            通過賦予每個任務不同的虛擬--物理地址轉換映射,支持不同任務之間的保護。地址轉換函數在每一個任務中定義,在一個任務中的虛擬地址空間映射到物理內存的一個部分,而另一個任務的虛擬地址空間映射到物理存儲器中的另外區域。計算機的存儲管理單元(MMU)一般有一組寄存器來標識當前運行的進程的轉換表。在當前進程將CPU放棄給另一個進程時(一次上下文切換),內核通過指向新進程地址轉換表的指針加載這些寄存器。MMU寄存器是有特權的,只能在內核態才能訪問。這就保證了一個進程只能訪問自己用戶空間內的地址,而不會訪問和修改其它進程的空間。當可執行文件被加載時,加載器根據缺省的ld文件,把程序加載到虛擬內存的一個空間,因為這個原因實際上很多程序的虛擬地址空間是相同的,但是由于轉換函數不同,所以實際所處的內存區域也不同。而對于多進程管理當處理器進行進程切換并執行一個新任務時,一個重要部分就是為新任務切換任務轉換表。我們可以看到Linux系統的內存管理至少實現了以下功能:
            運行比內存還要大的程序。理想情況下應該可以運行任意大小的程序
            ◇可以運行只加載了部分的程序,縮短了程序啟動的時間
            ◇可以使多個程序同時駐留在內存中提高CPU的利用率
            ◇可以運行重定位程序。即程序可以方于內存中的任何一處,而且可以在執行過程中移動。
            ◇寫機器無關的代碼。程序不必事先約定機器的配置情況。
            ◇減輕程序員分配和管理內存資源的負擔。
            ◇可以進行共享--例如,如果兩個進程運行同一個程序,它們應該可以共享程序代碼的同一個副本。
            ◇提供內存保護,進程不能以非授權方式訪問或修改頁面,內核保護單個進程的數據和代碼以防止其它進程修改它們。否則,用戶程序可能會偶然(或惡意)的破壞內核或其它用戶程序。
            虛存系統并不是沒有代價的。內存管理需要地址轉換表和其他一些數據結構,留給程序的內存減少了。地址轉換增加了每一條指令的執行時間,而對于有額外內存操作的指令會更嚴重。當進程訪問不在內存的頁面時,系統發生失效。系統處理該失效,并將頁面加載到內存中,這需要極耗時間的磁盤I/O操作。總之內存管理活動占用了相當一部分cpu時間(在較忙的系統中大約占10%)。
            uClinux針對NOMMU的特殊處理
            對于uClinux來說,其設計針對沒有MMU的處理器,即uClinux不能使用處理器的虛擬內存管理技術(應該說這種不帶有MMU的處理器在嵌入式設備中相當普偏)。uClinux仍然采用存儲器的分頁管理,系統在啟動時把實際存儲器進行分頁。在加載應用程序時程序分頁加載。但是由于沒有MMU管理,所以實際上uClinux采用實存儲器管理策略(real memeory management)。這一點影響了系統工作的很多方面。
            uClinux系統對于內存的訪問是直接的,(它對地址的訪問不需要經過MMU,而是直接送到地址線上輸出),所有程序中訪問的地址都是實際的物理地址。操作系統對內存空間沒有保護(這實際上是很多嵌入式系統的特點),各個進程實際上共享一個運行空間(沒有獨立的地址轉換表)。
            一個進程在執行前,系統必須為進程分配足夠的連續地址空間,然后全部載入主存儲器的連續空間中。與之相對應的是標準Linux系統在分配內存時沒有必要保證實際物理存儲空間是連續的,而只要保證虛存地址空間連續就可以了。另外一個方面程序加載地址與預期(ld文件中指出的)通常都不相同,這樣 relocation過程就是必須的。此外磁盤交換空間也是無法使用的,系統執行時如果缺少內存將無法通過磁盤交換來得到改善。
            uClinux對內存的管理減少同時就給開發人員提出了更高的要求。如果從易用性這一點來說,uClinux的內存管理是一種倒退,退回了到了UNIX早期或是Dos系統時代。開發人員不得不參與系統的內存管理。從編譯內核開始,開發人員必須告訴系統這塊開發板到底擁有多少的內存(假如你欺騙了系統,那將在后面運行程序時受到懲罰),從而系統將在啟動的初始化階段對內存進行分頁,并且標記已使用的和未使用的內存。系統將在運行應用時使用這些分頁內存。
            由于應用程序加載時必須分配連續的地址空間,而針對不同硬件平臺的可一次成塊(連續地址)分配內存大小限制是不同(目前針對ez328處理器的 uClinux是128k,而針對coldfire處理器的系統內存則無此限制),所以開發人員在開發應用程序時必須考慮內存的分配情況并關注應用程序需要運行空間的大小。另外由于采用實存儲器管理策略,用戶程序同內核以及其它用戶程序在一個地址空間,程序開發時要保證不侵犯其它程序的地址空間,以使得程序不至于破壞系統的正常工作,或導致其它程序的運行異常。
            從內存的訪問角度來看,開發人員的權利增大了(開發人員在編程時可以訪問任意的地址空間),但與此同時系統的安全性也大為下降。此外,系統對多進程的管理將有很大的變化,這一點將在uClinux的多進程管理中說明。
            雖然uClinux的內存管理與標準Linux系統相比功能相差很多,但應該說這是嵌入式設備的選擇。在嵌入式設備中,由于成本等敏感因素的影響,普偏的采用不帶有MMU的處理器,這決定了系統沒有足夠的硬件支持實現虛擬存儲管理技術。從嵌入式設備實現的功能來看,嵌入式設備通常在某一特定的環境下運行,只要實現特定的功能,其功能相對簡單,內存管理的要求完全可以由開發人員考慮。
            標準Linux系統的進程、線程
            進程:進程是一個運行程序并為其提供執行環境的實體,它包括一個地址空間和至少一個控制點,進程在這個地址空間上執行單一指令序列。進程地址空間包括可以訪問或引用的內存單元的集合,進程控制點通過一個一般稱為程序計數器(program counter,PC)的硬件寄存器控制和跟蹤進程指令序列。
            fork:由于進程為執行程序的環境,因此在執行程序前必須先建立這個能"跑"程序的環境。Linux系統提供系統調用拷貝現行進程的內容,以產生新的進程,調用fork的進程稱為父進程;而所產生的新進程則稱為子進程。子進程會承襲父進程的一切特性,但是它有自己的數據段,也就是說,盡管子進程改變了所屬的變量,卻不會影響到父進程的變量值。
            父進程和子進程共享一個程序段,但是各自擁有自己的堆棧、數據段、用戶空間以及進程控制塊。換言之,兩個進程執行的程序代碼是一樣的,但是各有各的程序計數器與自己的私人數據。
            當內核收到fork請求時,它會先查核三件事:首先檢查存儲器是不是足夠;其次是進程表是否仍有空缺;最后則是看看用戶是否建立了太多的子進程。如果上述說三個條件滿足,那么操作系統會給子進程一個進程識別碼,并且設定cpu時間,接著設定與父進程共享的段,同時將父進程的inode拷貝一份給子進程運用,最終子進程會返回數值0以表示它是子進程,至于父進程,它可能等待子進程的執行結束,或與子進程各做個的。
            exec系統調用:該系統調用提供一個進程去執行另一個進程的能力,exec系統調用是采用覆蓋舊有進程存儲器內容的方式,所以原來程序的堆棧、數據段與程序段都會被修改,只有用戶區維持不變。
            vfork系統調用:由于在使用fork時,內核會將父進程拷貝一份給子進程,但是這樣的做法相當浪費時間,因為大多數的情形都是程序在調用fork后就立即調用exec,這樣剛拷貝來的進程區域又立即被新的數據覆蓋掉。因此Linux系統提供一個系統調用vfork,vfork假定系統在調用完成 vfork后會馬上執行exec,因此vfork不拷貝父進程的頁面,只是初始化私有的數據結構與準備足夠的分頁表。這樣實際在vfork調用完成后父子進程事實上共享同一塊存儲器(在子進程調用exec或是exit之前),因此子進程可以更改父進程的數據及堆棧信息,因此vfork系統調用完成后,父進程進入睡眠,直到子進程執行exec。當子進程執行exec時,由于exec要使用被執行程序的數據,代碼覆蓋子進程的存儲區域,這樣將產生寫保護錯誤(do_wp_page)(這個時候子進程寫的實際上是父進程的存儲區域),
            這個錯誤導致內核為子進程重新分配存儲空間。當子進程正確開始執行后,將喚醒父進程,使得父進程繼續往后執行。
            uClinux的多進程處理
            uClinux沒有mmu管理存儲器,在實現多個進程時(fork調用生成子進程)需要實現數據保護。
            uClinux的fork和vfork:uClinux的fork等于vfork。實際上uClinux的多進程管理通過vfork來實現。這意味著 uClinux系統fork調用完程后,要么子進程代替父進程執行(此時父進程已經sleep)直到子進程調用exit退出,要么調用exec執行一個新的進程,這個時候將產生可執行文件的加載,即使這個進程只是父進程的拷貝,這個過程也不能避免。當子進程執行exit或exec后,子進程使用 wakeup把父進程喚醒,父進程繼續往下執行。
            uClinux的這種多進程實現機制同它的內存管理緊密相關。uClinux針對nommu處理器開發,所以被迫使用一種flat方式的內存管理模式,啟動新的應用程序時系統必須為應用程序分配存儲空間,并立即把應用程序加載到內存。缺少了MMU的內存重映射機制,uClinux必須在可執行文件加載階段對可執行文件reloc處理,使得程序執行時能夠直接使用物理內存。

            posted @ 2006-02-10 09:52 inwind 閱讀(388) | 評論 (0)編輯 收藏

            2006年2月9日

            傳統的入侵檢測系統(IDS)只能被動地給管理員提供檢測報告,最終還必須通過人工來解決問題。雖然大部分IDS產品能夠在攻擊發生后與防火墻進行互動,但是這種互動只能夠對持續的低層次攻擊產生很好的阻止作用,在容易受到深層次攻擊的場合,用戶還是希望采用能夠對攻擊行為進行實時阻斷的產品,來提高信息系統的安全級別,因此入侵防護系統McAfee IntruShield應運而生。

            體驗部署和配置

            IntruShield 2600有別于基于通用平臺的產品,它采用NP(network processor)和ASIC(專用集成電路)混合的架構設計。因為需要實現實時阻斷,所以IntruShield 2600在進行協議重組的過程中需要比傳統IDS更強的處理能力。通用的硬件平臺在多端口的配置的情況下很難滿足實時阻斷的需求。NP加ASIC這種結構在高端的3層交換機和防火墻中被大量采用,能夠實現非常高的轉發率,可以幫助入侵防護設備進行實時阻斷。

            靈活多樣的配置方式

            這款產品配置了8個端口,在SPAN (Switched Port Analysis)模式工作時,全部可以用作檢測端口,即如果用戶只需要傳統的IDS功能,這款產品完全可以充當一個8口的IDS,不過在部署時需要考慮到吞吐量。IntruShield 2600的拿手好戲在于對入侵和非法的數據包進行阻斷,這是在In-line的模式下實現的,這個模式是把IPS作為一個以太網的橋接器,透明地連接到已有的網絡中,而不需要改動原有網絡的配置,對于一個復雜的網絡來說,這種設計可以減輕調試安裝設備對原有網絡的影響。在這種模式下,必須成對地配置端口。因此在只使用全部100M銅纜口時,這款產品幾乎可以達到100%的利用率,而在使用千兆光口時,這款產品就只能處理60%左右的網絡流量,對于一個正常設計的網絡來說,60%已經是很高的突發流量了。

            即插即用的快速部署

            這款產品的軟件和硬件的配合程度是非常高的。雖然各個管理服務器上都需要安裝多個服務程序,但是McAfee通過把這些服務打包,整合成安裝向導提供給了用戶。我們只需要點擊幾次“下一步”,并且設置好管理端口的IP地址,就能夠完成安裝。通過RS-232配置好控制網絡接口的IP地址后,我們就可以采用瀏覽器對設備進行管理了。

            整個管理配置界面完全是由動態網頁和Java Applet組成,既能在管理服務器本機上進行管理,還可以在任意能夠訪問管理服務器的計算機上通過瀏覽器進行管理和配置。這樣可以把警告信息匯總到單個管理服務器上,然后在其他節點上進行分析或者報告。

            高性能的安全屏障、檢測率測試

            我們選擇了Blade測試工具進行模擬攻擊測試,選取50種典型攻擊樣例。通過模擬攻擊和被攻擊的環境,把IntruShield 2600設置為阻斷模式,通過比較發出的攻擊和從控制臺上觀察到的報警信息來確定設備檢測的正確性。Blade是目前可以模擬攻擊類型最多的安全測試工具。我們選擇的攻擊樣例也是按照最近比較盛行、危害比較大以及容易發生的原則來進行的。

            測試結果非常令人振奮。在測試中,所有的攻擊都沒有被漏報。但是,在這樣的測試中,我們并不能確定攻擊是否真的被阻斷了,于是我們進行了下面的測試。

            阻斷能力測試

            我們找來了一個針對Windows NetBIOS缺陷的攻擊工具,這個缺陷存在于Windows 2000 SP3(包括SP3)以下的版本中。在沒有打開IntruShield 2600阻斷功能的情況下,僅打了SP2補丁的目標主機直接藍屏,在進行內存轉存以后自動啟動,而在開啟IntruShield 2600阻斷功能后再次發起攻擊,目標主機就會安然無恙,并且兩次攻擊在管理服務器上都有詳細的報告,這說明IntruShield 2600的阻斷能力非常出色。

            大家可能已經發現了,我們所采用的攻擊類型并不是簡單的畸形IP包攻擊,而是在防火墻看來正確連接的情況下進行的高層次的操作,這些操作大多是利用系統或者應用本身的缺陷,制造異常操作來導致其無法正常工作,尤其是一些七層攻擊,如果只采用IDS和防火墻互動的方法來阻止攻擊,很可能讓攻擊得逞,因此需要在攻擊進行中立即阻斷。在阻斷模式下,IntruShield 2600除了要重組協議進行判斷外,還需要放行正確的數據,因此面臨著嚴峻的性能考驗。

            吞吐能力測試

            為了考驗NP/ASIC架構的性能,我們創建了一個穩定的背景流,然后模擬攻擊。通過觀察在處于標稱吞吐量邊緣的IntruShield 2600對攻擊的報告情況來確定這款產品的實際吞吐性能。

            我們采用思博倫通信的Avalanche和Reflector,制造了一個約等于600Mbps的HTTP流量,然后依然沿用功能驗證中的攻擊檢測方法對 IntruShield 2600進行了測試。在標稱的600Mbps吞吐量下,IntruShield 2600居然能一個不漏地檢測到攻擊,這一測試結果一方面肯定了這種基于NP和ASIC混合平臺的優勢,另一方面,也說明了這款產品在標稱的吞吐量下,還保留了一部分處理能力,用于應付突發的流量對系統正常運作帶來的影響。

            測試總結

            由于采用了NP/ASIC架構,在進行大數據量的協議分析時,這款產品表現出了非常強的吞吐性能,使得阻斷攻擊這一獨特的功能沒有受到任何影響。因為這款產品主要聚焦在4到7層的攻擊類型,在測試中,我們并沒有看到太多基于一些3層以下的入侵檢測和阻斷手段。不過,在后來我們采用Nessus端口掃描工具進行變形逃逸測試時,發現這款產品對于SynScan等掃描入侵手段能夠進行檢測,但是需要配合防火墻來更徹底地杜絕這類攻擊。由此證實了我們的推斷,單一的 SynScan或者Flood攻擊對于系統是沒有攻擊性的,并且由于這類攻擊非常簡單,不需要IPS進行復雜的協議分析,只需要在偵測出攻擊后,通過和防火墻聯動,由防火墻就能進行處理。

            通過對IntruShield 2600進行測試,我們發現:IPS是對IDS的增強和延伸,能夠彌補和防火墻之間的空白,而不是簡單地對防火墻和IDS進行融合的結果。

            IntruShield 2600

            產品亮點
            ● 在1U厚度實現2個千兆光口,6個銅纜百兆端口的入侵阻斷系統,所有端口可以靈活配置,完全邏輯隔離。
            ● 能夠快速進行安裝部署,支持分布式部署管理。
            ● 完善的檢測引擎,沒有漏報一個測試樣例中的攻擊。
            ● 高性能的吞吐能力,能夠在高達600Mbps的HTTP背景流下正常工作。
            (e129)

            posted @ 2006-02-09 16:50 inwind 閱讀(412) | 評論 (0)編輯 收藏

            CNET科技資訊網2月8日國際報道 Jason Fried,37Signals 公司的總裁是一位很棒的軟件企業家。但他不想用傳統模式去開辦一間軟件公司。沒有試圖擠進復雜的,價格昂貴的產品業務市場,Fried 和他的同志選擇了相對比較偏門的軟件:主機式個人組織器及項目管理應用。 對于Fried 而言,那種老式的依靠客戶拿出大把美金維持運營的模式已經作古。

            Fried 說:"我認為企業軟件的理念已經死亡。企業軟件是一個骯臟的世界-大而無用的東西從來就不奏效,永遠沒法按時為客戶就位,并且,它們太昂貴了。" 雖然發展速度比以往幾年有所放緩,企業軟件市場仍然是一個價值數十億美金的行業,它還在增長。一些投資者和企業家們說,不斷變化的這個行業使得它很難突入進去。

            Onset Ventures公司的Mark Hildenbrand說:"投資者們對企業軟件的興奮度正在降低。毫無疑問,它是一個具有挑戰性的區域。"

            與此相反,過去兩年,小型公司正在大量的出現,它們開發基于網絡的應用,或者開發開源軟件,人們有時稱它們為Web2.0公司。 它們中的許多能夠依靠相對小規模的前沿投資獲得騰飛,而不是過去那種上億美元的大手筆。 例如,37Signals 的商業計劃就是構建簡單的主機式應用,按月向小企業或者個人收取注冊費用。 自從推出它的第一個服務的兩年多以來,這家自籌資金起步的公司已經獲得了成百上千名客戶,它沒有債務。這家公司還成功的資助了開源Web 開發項目Ruby on Rails.


            Fried 說:"你可以利用互聯網建立很棒的小巧產品,你可以獲得1 百萬或者50萬用戶。"
            企業家和投資者們說,一系列技術的變化令非常專門的產品生存下來變為一種可能。大多數的變革是那些正在不斷發展普及的主機式應用,或者服務式的軟件。
             
            網絡字處理器公司Upstartle 的創始人們,最開始考慮開發針對企業內部網的協同與文件管理軟件,但他們最終放棄了這個主意,而決定將注意力集中在互聯網上的字處理器上。


            Writely 公司的創始人之一的Claudia Carpenter 說:"過去,你不得不做一種巨大的事情-象套件一類的東西。現在,似乎你能夠做一些輕量級的東西。" 由于互聯網已經成為一種應用平臺,Writely 能夠將他的字處理器服務與其它網絡服務連接起來,比如網絡日志或者照片分享網站。現在,很多網站不斷的公布它們的應用程序接口(API ),這讓用戶及開發者們能夠在不同的主機式服務之間分享信息。


            另外一個重要的技術進步就是AJAX(異步JavaScript+XML)的興起。這是一種創建交互式圖形用戶界面(GUI )及網頁的開發技術,它能夠自動的刷新網絡服務器上的數據。利用AJAX,程序員門能夠開發出桌面應用程序的主機式版本,比如文件和照片發布,AJAX可以給用戶提供和在PC上類似的用戶體驗。


            除了將注意力集中在專門的產品上,和以往相比,這些新創公司能夠用很少的資金實現騰飛。
            自由提供的開源軟件正在增長,功能強大的硬件服務器價格變得越來越低。而在5 年之前,新創業的公司可能需要花費成千上萬美元去購買這些硬件設備。


            運營成本也變得相當的低。以37Signals 為例,這家公司沒有花錢在市場營銷上,他們采用了網上的營銷手段,比如網絡日志的口碑宣傳。這家7 人公司沒有銷售人員。


            紐約天使投資公司的董事David Rose說:"我們看到的Web2.0是一場軟件公司發生深刻變革的運動。" Rose表示,現在的網絡企業家可以在短短的一年時間內,僅僅用50萬美元的資金即可實現從概念到功能性產品的轉變。他說:"要是放在過去,得花數年時間,上百萬美元,以及多次的計劃修改才會等到第一個產品出籠。"


            RDF 風險基金的主任Richard Forman認為,基于網絡的軟件模式可以同時輻射個人與企業兩個市場。 他說:"Web 2.0 的迷人之處在于它是一種雙管齊下的模式。一方面,你擁有用戶提交的內容,這對網絡來講是一種巨大的機會,另外一方面,你擁有針對協同性工作以及應用服務提供商的網絡服務,它將給企業世界產生真實的影響。"


            現在,Salesforce.com,NetSuite和SAP 都在鼓吹,企業客戶正希望放棄那些大型的軟件項目,而選用主機式服務。即使微軟這個軟件世界的君王也已經發出過類似的感言。


            進入Web 2.0 世界的低門檻使得那些新奇主意可以輕易的轉化為新創企業。一些分析師說,也許這個門檻太低了。 許多的Web 2.0 網絡應用可以由幾個人,相對較少的創業投資和時間來完成。但是,與此同時,投資者們認為,這些服務很容易被復制。另外,一些Web 2.0 公司的業務模式沒有經過完全測試,比如Writely 就仍處于測試當中,公司仍然在評估幾種不同的收入模式,比如客戶注冊和廣告模式。(編輯:孫瑩)


            Small is beautiful for Web 2.0 start-ups

             

             

             

             

             

             

             

             

             

            posted @ 2006-02-09 16:46 inwind 閱讀(427) | 評論 (0)編輯 收藏

            2005年12月23日

            本文列出了當今計算機軟件開發和應用領域最重要十種關鍵技術排名,如果你想保證你現在以及未來的幾年不失業,那么你最好跟上這些技術的發展。雖然你不必對這十種技術樣樣精通,但至少應該對它們非常熟悉。

            一、XML
                在十種技術中,最重要的一種技術我想應該非XML莫屬。這里不僅僅指XML規范本身,還包括一系列有關的基于XML的語言:主要有XHTML,XSLT,XSL,DTDs,XML Schema(XSD),XPath,XQuery和SOAP。如果你現在還對XML一無所知,那么趕快狂補吧。XML是包含類似于HTML標簽的一個文本文件,在這個文件中定義了一個樹型結構來描述它所保存的數據。
                XML最大的優點是你既可以在這個文本文件中存儲結構化數據,也可以在其中存儲非結構化數據——也就是說,它能包含和描述"粗糙的"文檔數據,就象它描述"規則的"表格數據一樣。
            • XHTML是目前編寫HTML的首選方法;因為XHTML本身就是格式良好的XML,與通常畸形的HTML文檔相比, XHTML格式文檔更容易處理。
            • XSLT和XSL是對XML文檔進行轉換的語言。它們可以將XML文檔轉換成各種格式,比如另一個文本文件、PDF文件、HTML文件、逗號分割的文件,或者轉換成其它的XML文檔。
            • DTDs 和XML Schema用來描述XML文件所包含的數據內容的類型,使你不用編寫定制的代碼就能對XML文檔的內容進行"有效性"檢查,使內容強行遵守給出的規則。
            • XPath 和 XQuery是查詢語言,用它們可以從XML文檔中吸取單個的數據項或者數據項列表。XQuery的功能特別強大,因為它對XPath查詢進行了擴展。實際上,XQuery和XML的關系就像SQL之于關系數據庫一樣。
            • SOAP是Web services間進行通訊的標準協議。你不必知道SOAP協議的所有細節,但是你應該熟悉其常用規則及其工作原理,這樣你才能使用它。
            二、Web Services
                Web服務是XML流行后的直接產物。因為XML可以描述數據和對象,XML大綱可以保證XML文檔數據的有效性,因為XML的基于文本的規范,因而XML文檔極其適合于作為一種跨平臺通訊標準的基本格式。如果你還沒有接觸過Web服務,那么過不了多久你肯定會碰到它,所以必須熟練掌握Web服務,最好是精通它,因為它是迄今為止應用程序間跨不同種類機器、語言、平臺和位置通訊的最簡單的一種方式。不管你需不需要它,Web服務都會是將來互用性的主要趨勢。
                XML工作組的John Bosak曾說過:"XML使得Java有事可做",那么,我們也可以說,Web服務使得所有語言都有事可做。Web服務讓運行在大型機上的COBOL應用程序與運行在手持設備上的應用程序相互溝通;讓Java小應用與.NET服務器相互通訊,讓桌面應用與Web服務器進行無縫交互,不但為商業數據處理,同時也為商業功能提供了方便的實現——并且這種實現與語言、平臺、和位置無關。

            三、面向對象編程
                許多程序員仍然認為OOP乃技術的象牙之塔,但是細細想一下過去十年里在面向對象領域里占據過統治地位的開發語言之后,你就不會這么認為了,OOP理念從Smalltalk開始,然后蔓延到C++和Pascal(Delphi),到Java成為真正的主流,幾年之后,VB.NET 和 C#的出現可以說是OOP發展到了登峰造極的地步。雖然使用這些語言不必了解OOP的概念,但如果你缺乏一些OOP的基本知識和方法,我想你很難在逐漸疲軟的就業市場中找到工作。

            四、Java, C++, C#, VB.NET
                如果你熱衷于技術,并且熱愛編程,那么我想你應該輕松玩轉這些高級語言,我說的玩轉并不一定要你成為超級編程高手。而是能看懂用這些語言編寫的代碼即可。如果你還有精力用它們編碼那就更好了。其實這種機會甚少。但是看代碼的機會很多,學習編程的最有效的一種方式就是看源代碼——浩如煙海的源代碼中很多都不是用你所鐘愛的開發語言編寫的。
                在過去的幾年里,各個語言功能的發展基本上都差不多。現在你完全可以用VB.NET來寫Windows服務、Web應用或者命令行程序。即使你只用其中的一種語言寫程序。我認為也完全有必要學習另外一種語言,使自己能閱讀和理解它們現有的例子代碼,并且能將一種語言編寫的代碼轉換成你首選的編程語言代碼。這里列出的四種語言可謂是一個強大的開發語言工具箱,如果你掌握了它們,毫無疑問你一定是一個眾人仰慕的高手。這里我要聲明一下:那就是我并沒有要忽略和排除其它的高級語言,如:FORTRAN、COBOL、APL、ADA、Perl和Lisp等等,根據你所從事的領域不同,應該選擇適合的語言和工具。

            五、JavaScript
                Java 和JavaScript兩者的名字盡管很類似,但它們之間并沒有什么關系。為什么一種腳本語言會如此重要,以至于將它列入十種關鍵技術之一呢?仔細想一下就知道了,目前所有主流的瀏覽器都使用JavaScript。如果你要編寫Web應用程序,那么JavaScript不可或缺。此外,JavaScript還能作為一種服務器端的腳本語言,如將它嵌入在ASP、ASP.NET中,或者嵌入XSLT來擴展功能。目前JavaScript在Mozilla/Netscape中是激活基于XUL界面的首選語言,它派生出了ActionScript,成為Flash MX應用的編程語言。還有就是JavaScript極有可能成為未來新設備的腳本語言以及主流應用的宏語言。
                相比之下,VBScript雖然在微軟的產品中得到很好的支持,但從長遠來看,沒有跡象表明它會有美好前途。微軟自己都趨向于用JavaScript(或者用由JavaScript派生的JScript)來編寫其客戶端腳本代碼。因此,如果你要選擇腳本語言,非JavaScript莫屬。

            六、Regular Expressions
                從所周知,關系數據庫的查詢使用SQL,搜索XML文檔用XPath 和XQuery,而正則表達式則用來搜索純文本。例如,你可以用一個命令來查找或刪除HTML格式文件中的注釋內容。大家都用過"IndexOf"、"InStr"以及"Like"這些內建在JavaScript或VB中的文本搜索函數,這些函數雖然很容易使用,但是它們的功能卻無法與正則表達式同日而語——現在每一種主流的開發語言都提供對正則表達式的存取。盡管有人認為正則表達式本身的讀寫艱澀難懂,但畢竟它的功能強大,使用它的領域也越來越多。

            七、Design Patterns
                就像OOP通過創建和分類對象來簡化編程一樣,設計模式將普通的對象交互分類成指定的模型,這是一個從一般到具體的過程。OOP的成分使用得越多,設計模式就顯得越有用武之地。所以你必須理解它們,跟上其總體理論的發展。

            八、Flash MX
                當你需要比HTML和CSS所能提供的更多的客戶端圖形和編程能力時,Flash是最佳選擇。在Flash中編程比用Java小應用或者.NET代碼來得快得多,也容易得多。
                在最新版本中(MX),Flash不僅可以畫圖和進行動畫打包,它還是個高度的可編程應用環境。具備強大的與SOAP Web服務溝通的能力,可以調用運行在遠端服務器上的ColdFusion、Java或.NET代碼。可以說Flash幾乎無處不在,包括手持設備、置頂盒、甚至是新的平板電腦,你到處都可以見到它的身影,所以使用它實際上可以擴展和延伸你的應用程序使用領域。

            九、Linux/Windows
                這是當今PCs機操作系統的兩大陣容,如果你想在計算機行業里混,就一定要熟悉它們。對于Linux,最好能自己安裝,配置,下載它的圖形用戶界面以及一些應用程序。自己安裝Apache并會編寫Web應用程序。要清醒地認識到這個世界除了Windows之外,還有Linux的存在。并且這種局面將會長期存在。反過來,如果你是一個死忠的Linux開發者,不要再繼續對Windows的憎惡,要相互學習,取長補短,看看Windows有什么好的東東可以采納。記住Windows仍然是桌面之王。
                誰也說不準你們公司什么時候會決定從Linux轉向Windows,或者從Windows轉向Linux。誰也說不準什么時候你會跳槽跑到另外一個使用不同平臺的公司上班——或者即便不跳槽,也有可能在不同平臺上開始另外一個殺手級項目——所以最好在每個平臺上都積累一些經驗,而不要在一棵樹上吊死。

            十、SQL
                盡管SQL在當今眾多的技術中已不是什么新東西,而且在未來的十年里它的作用很有可能被削弱,甚至整個被淘汰,但它仍然是一種基本技能——別看它是一種基本技能,至今仍有許多開發人員不懂什么是SQL或對它了解不多。不要指望基于圖形用戶界面的SQL構造器會幫你的忙,還是自己親手寫SQL查詢吧,確定你掌握了SQL的基本語法。現在理解了SQL,不僅對以后學習XQuery有所裨益,而且可以使你很快找到簡化或改進當前開發項目的途徑。

            尾聲:培養對技術的好奇心
                其實,不管技術的發展趨勢如何,每個人最重要的一個技能是好奇心。敢于面對挑戰,在你目前或未來的工作中,新語言或新技術可能很重要,也可能不怎么重要,你所學習的東西并不一定非要針對你的工作。不要怕失敗,任何新的技術對初學者來說都是困難的。大多數的失敗都可以歸咎于本身急功近利,希望速成。俗話說——千里之行,始于足下,應該腳踏實地,一步一個腳印地往前走。不要讓時間來左右你行動,而是要利用時間來關注、研究、測試新的開發技術和工具。
                本文的用意不在于要讓你成為任何一種技術的專家——只是想借VCKBAE這塊寶地拋磚引玉,和大家暢談現在和未來哪些技術是我們要密切關注的,討論今后IT行業就業的知識結構,思考自己今后應該在哪些方面需要多花些功夫。因為每一個人的情況各有不同,應該根據具體情況來構筑自己的知識層面。但有一點無庸置疑——那就是保持良好的好奇心始終會使你充實和睿智。

            posted @ 2005-12-23 17:13 inwind 閱讀(342) | 評論 (0)編輯 收藏

            2005年12月22日

            這一天,大夫伍舉進見楚王。楚莊王手中端著酒杯,口中嚼著鹿肉,醉醺醺地在觀賞歌舞。他瞇著眼睛問道:"大夫來此,是想喝酒呢,還是要看歌舞?"伍舉話中有話地說:"有人讓我猜一個謎語,我怎么也猜不出,特此來向您請教。"楚莊王一面喝酒,一邊問:"什么謎語,這么難猜?你說說。"伍舉說:"謎語是‘楚京有大鳥,棲上在朝堂,歷時三年整,不鳴亦不翔。令人好難解,到底為哪樁?'您請猜猜,不鳴也不翔。這究竟是只什么鳥?”楚莊王聽了,心中明白伍舉的意思,笑著說: "我猜著了。它可不是只普通的烏。這只鳥啊,三年不飛,一飛沖天;三年不鳴,一鳴驚人。你等著瞧吧。"伍舉明白了楚莊王的意思,便高興地出退了來。

            posted @ 2005-12-22 13:43 inwind 閱讀(348) | 評論 (0)編輯 收藏

            2005年12月8日

            讀書讀到這個份上了,如果只是做一個coder,太虧了,也不一定有小本做得好。

            但是問題在于,只作科研,paper,對于以后找工作呢?

            實驗室幾位畢業的碩士今年找工作,就凸現了這個問題,而相識的幾位科大的碩博,找到的工作都非常棒。他們除了有比較出色的科研成績之外,另外一個相同之處,就是都對一項或者幾項技術非常非常的熟練。說到底,資本家雇用你,是因為你能實際的為他做事,能為他創造實際的價值,而不是需要只能做文章的理論者——雖然也需要,但是非常非常的少,而且做為理論,我們又怎么做得過數學系出身的人呢?

            考慮一下需要研究的技術
            c/c++,java ,vc, c#,
            linux系統和網絡編程,驅動程序編程
            windows的系統和驅動程序編程

            還有,看到某位大蝦說得,感覺挺有道理,應該找個時間,研究一下腳本語言的說

            在近一年以內,要做什么呢?
            linux內核,在放假前應該可以看完了,然后可以參與社區的開發研究——限于條件,暫時可以不用linux的機器,不要緊,關鍵在于理解其內核運行的機制,算法等
            然后是c++,一月份之前需要徹底復習一下,然后,就需要開始vc內幕四版的學習,加上算法的學習——算法i-iv,然后是art of programming。對于c++的深入研修也是必要的,primer加上那兩本特價書。

            除了art of programing,其他應該在三月份以內搞定。

            oh yeah~~~~~

            posted @ 2005-12-08 22:09 inwind 閱讀(401) | 評論 (0)編輯 收藏

            2005年12月7日

            剛剛注冊了這個blog,熱情足啊,一口氣轉載了那么多文章,沒有幾篇仔細看的,呵呵:)
            不過,先放著,下班之后就可以看了。
            還是先把本職工作做一下吧

            posted @ 2005-12-07 13:42 inwind 閱讀(237) | 評論 (0)編輯 收藏

            国产精品伦理久久久久久| 欧美大香线蕉线伊人久久| 97精品国产97久久久久久免费| 日韩精品国产自在久久现线拍| 久久久久国产日韩精品网站| 2020久久精品亚洲热综合一本| 久久久久人妻一区精品色 | 久久精品国产精品亚洲| 亚洲午夜精品久久久久久浪潮 | 天天久久狠狠色综合| 91久久精品国产免费直播| 亚洲а∨天堂久久精品| 久久亚洲美女精品国产精品| 久久久久亚洲AV无码专区桃色 | 久久精品国产黑森林| 久久人妻少妇嫩草AV无码专区| 久久国产成人| 久久综合综合久久狠狠狠97色88| 中文字幕精品久久| 国内精品久久久久久久涩爱 | 草草久久久无码国产专区| 亚洲中文字幕无码一久久区| 日韩中文久久| 久久99精品久久久久久秒播| 狠狠色丁香久久婷婷综| 亚洲国产精品无码久久久不卡 | 久久午夜伦鲁片免费无码| 香蕉久久影院| 青青青青久久精品国产h久久精品五福影院1421 | 久久天天躁狠狠躁夜夜avapp | 久久久网中文字幕| 国产精品美女久久久久av爽| 国产午夜精品理论片久久影视| 久久精品人人做人人妻人人玩 | 久久精品夜夜夜夜夜久久| 久久99久久99精品免视看动漫| 久久久久亚洲国产| A级毛片无码久久精品免费| 久久99这里只有精品国产| 久久夜色精品国产亚洲| 中文无码久久精品|