目前分類:電腦和網際網路 (53)

瀏覽方式: 標題列表 簡短摘要

關於微軟的備份與回存機制
常常會有人不太清楚差異備份與增量備份的差別
其實差別在於差異備份不會將檔案標示為已備份
也就是不會將檔案的保存屬性A屬性拿掉
但是增量備份會將檔案標示為已備份
也就是會將檔案的保存屬性A屬性拿掉

到底什麼是保存屬性?

答:當一個檔案建立出來或經過了修改的動作之後,系統預設值便會將 保存屬性(記號)標上,以便記錄這個檔案有經過修改。這個保存屬性(記號) 只會在此檔案執行了標準備份或增量備份後才會清除。保存屬性(記號)在哪裡呢?請你選取該檔案,然後按滑鼠右鍵選[內容],再選[進階],你就可以找到[檔案已經可以開始封存]這個核取方塊,它便是所謂的保存屬性(記號)。

archive     

備份
差異備份:會備份從上一次完整備份到目前所異動的內容(不會將檔案標示為已備份),執行越多次,最後一次備份的時間會越久


增量備份:會備份從上一次完整備份或增量備份到目前所異動的內容(會將檔案標示為已備份),每次執行之後,都只會備份上次備份到目前為止所異動過的資料,因此最後一次備份時間比差異備份短

回存

差異備份:必須先回存完整備份,再回存最後一次差異備份


增量備份:必須先回存完整備份,再依序將所有增量備份回存回去,例如星期一的增量備份要先回存,再回存星期二的增量備份,依照這種順序回存所有的增量備份


優缺點:
差異備份回存速度快也比較簡單!但通常備份的時間比較久
增量備份回存比較複雜,比需依序將所有增量備份回存才能回復資料,但是通常每次的備份時間比較短
因此必須依照個人或各家公司的需求去選擇備份模式

 

範例:

完全備份和差異備份
在星期一進行完全備份,在星期二至星期五進行差異備份。 如果在星期五數據被破壞了,則你只需要還原星期一完全的備份和星期四的差異備份。這種策略備份數據需要較多的時間,但還原數據使用較少的時間。這種策略備份數據需要較多的時間,但還原數據使用較少的時間。

完全備份和增量備份
在星期一進行完全備份,在星期二至星期五進行增量備份。如果在星期五數據被破壞了,則你需要還原星期一正常的備份和從星期二至星期五的所有增量備份。這種策略備份數據需要較少的時間,但還原數據使用較多的時間。這種策略備份數據需要較少的時間,但還原數據使用較多的時間。  


資料來源:http://neo2124.pixnet.net/blog/post/24215688

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

 

 

Router:

中譯:路由器

功能:交換不同網段的封包、決定封包的傳送方向及路徑

作用層:TCP/IP的第三層及第四層(IP和TCP/UDP Port)

補充:市面上所售的IP分享器,也有人稱做ROUTER

不過功能上面就差很多了....



Switch:

中譯:交換器 或是 橋接器(Bridge)

功能:傳送封包,連接PC

作用層:TCP/IP的第二層(MAC)

補充:市面上有所謂的無網管功能及有網管功能的交換器

無網管功能的交換器有的地方會叫做Switch HUB

跟一般的交換器少了網路管理、VLAN、STP及Multicast管理的功能



HUB:

中譯:集線器

功能:連接多台PC

作用層:TCP/IP的第一層



Layer3 Switch(MultiLayer3 Switch)

中譯:第三層交換器 或是 多層交換器

功能:同Switch,不過多了 Routing(路由) 的功能

作用層:TCP/IP的第二層及第三、四層(MAC、IP及TCP/UDP Port)

補充:雖然Layer3 Switch也跟Router一樣有路由的功能

不過,仍然無法當作Router

因為現在的Layer3 Switch仍然無法做NAT(網路位置轉譯)功能

除非你要用像是Cisco 65XX等級的Layer3 Switch


現在需要一個設備來連接ADSL、專線或是FTTx  =====>那所需要的是Router 或是 IP 分享器

如果是要擴充連接的電腦                                   =====>那需要的是Switch and HUB 


 



路由器ROUTER又稱GATEWAY ;它雖然常常帶有HUB的功能,但是他絕對不只是HUB

hub本身是透明的,它沒有IP ; hub本身是不處理資料的,除非是高級的switch hub
否則一般的HUB甚至根本不是數位產品。它只是個訊號交換\緩衝放大器。

但路由器最少會有兩組IP,分別在不同的網域中
router一定要處理數位資料流,它讓內網的封包出去,外網的封包進來。
它是就是這兩個網域之間的橋樑。


為什麼需要router?全部連在一起就好了嘛!
這麼做的話事情就大條了。
全世界的4千萬台電腦的資料全部擠在一起,共享100MB的網路,不用玩了。


Router把內網的資料流與外網的資料流隔開,只有跨網域的資料才穿過router交換。
Internet這個術語就是「網網相連」的意思;
如果沒有router,就沒有Internet的概念了。

比較好的名稱是路徑選擇器

它主要的功能就是在 不同的網路間選擇一條最佳的路徑,都用在比較大型的區域網路架構下,

 

像學校或是企業,而且通常每個單位都會有一台做為自己區域網路對外的連接,

 

像企業裡的A部門會有一台ROUTER,B部門會有一台ROUTER,而各自的ROUTER下再接數10~百台以上的電腦

 

而 今天有A部門的某台電腦要找G部門某台電腦裡的資料,則找到一條路徑是從

 

RA(ROUTER A)->RC->RF->RG,但這條路徑不一定是最佳的,可能只要RA->RD->RG,則路由器就會自己做修正,

 

這樣 就可以減少不必要的路徑了,速度也變快了,要有這些功能其實就不是那麼簡單的事了,

 

要有資料庫要有測試的功能,因此路由器已經可以說是一台特殊的電腦 囉!~價格通常都在20萬上下囉!

 

而路由器的設定也是一門技術喔!



Router既然都已經經手處理資料流了,那就可以把很多功能都包含進來:
(1)Firewall,  :    我可以決定什麼資料可以進來,什麼資料可以出去
(2)QoS        :    我可以決定誰的資料先走,誰可以使用比較大的頻寬等等..
(3)負載平衡  :    我可以使用兩條對外的線路,讓資料平均的在兩個線路上傳輸。一條線路發生故障時,所有的資料流自動移轉到另一條線路上。
(4)NAT 網址轉換:就是人稱的ip分享器,我可以在內網使用虛擬的IP,這樣可以解決ip不夠的問題,也同時把內網與外網徹底的隔開了。
(5)Voip        :       網路電話的應用
(6)... 太多了,想得到的都有人做。

IP分享器是BASE ON router的,也常帶有簡單的firewall功能,
高級的機器會有頻寬管理,做到負載平衡就很少見了。



SWITCH 就是「交換機」,這個詞眼暗示了「不是共享頻寬,而是直接對接的」
就像我們打電話是透過交換機對接一樣,數十萬人同時在打電話,但是彼此不會干擾
這樣可以讓不同的兩組電腦之間擁有完整的頻寬可以使用。
HUB 可以做成 SWITCH HUB 
ROUTER 也可以有SWITCH 的能力

SWITCH的話,是屬於第二層交換器(ROUTER是第一層),他又稱為交換式集線器,
跟普通HUB不同的事,他不僅僅只有集線器的功能,他還有橋接器的功能,
他能記憶哪個位址在哪個PORT,再決定將封包送往何處因為未受影響的PORT就可以繼續對其他PORT傳送資料,
突破了集線器只能有一對PORT在工作的限制,因此對一台高階的N PORT 100Mbps交換器而言,
假如每一個PORT都能以全雙工模式互傳資料的話,那麼理論上最大的傳輸頻寛為100 x N Mbps,
而SWITCH的價格比較便宜也比較不用麻煩的設定




IP 把它當成地址

Switch 你可以把它當成同一條路(也可以用來分割路段)
Router 就可以說是路口,
            就是用來告訴你往南或往北應該是左轉還是右轉或是直走....等資訊
            (會紀錄在Routeing Table上) 




資料來源:http://www.wretch.cc/blog/dagron/9498732

香醇咖啡 發表在 痞客邦 PIXNET 留言(1) 人氣()

交換機和路由器的應用,在網絡中是必不可少的,相對來說容易出現故障的機率也是比較大。尤其是交換機接口的問題也時將出現。大部分交換機都會有自我診斷的功能。當交換機或者交換機端口由於某些原因出現故障的時候,都會通過指示燈來告知管理員存在的錯誤。不過有些時候交換機也會存在誤診斷的情況。如交換機的端口工作指示燈明明表示正常,但是用戶卻反映網絡不通。如果只是普通的用戶,問題還不是很大。但是如果這個端口恰巧是用來進行備份的,那麼情況就會比較糟。為了避免這種情況,在實際工作中很多網絡管理員都喜歡採用交換機的UDLD模式來消除交換機的這種誤診斷。
一、什麼情況下會出現誤診斷?
誤診斷的情形主要是即使當鏈路或者交換機的端口指示燈正常的(即端口的狀態是UP的),但是接口仍然無法正常傳遞數據流量。通常情況才將這種錯誤稱之為單向鏈路。一般情況下,當出現接口故障、軟件故障、硬件失效或者其他異常原因的時候,就會出現這種錯誤。憑現在的技術手段,交換機還不能夠從根本上避免這種錯誤的發生。為此只有採取其他的方式,加強對交換機端口的檢測,以儘早發現這種錯誤。在思科系列的交換機上,就採用了UDLD模式來解決這種情況下的誤診斷。
UDLD從理論上來說,其是在第二層工作的協議。不過從實際情況來看,其往往跟第一層的內容有很深的關係。也就是說,UDLD模式不光光在第二層運作,其還會跟第一層的相關機制協同工作,才能夠完成。其主要的思路就是UDLD協議運行在第一、二層之間,最終確定鏈路的實際工作狀態。當發現有“鏈路UP狀態正常,但是沒有傳遞流量”的時候,UDLD協議會馬上報警。具體的說,在第一層中通過自動協商功能來觀測物理信令等相關的參數運作。而UDLD協議則會完成一些自動協商機制不能夠執行的任務。讓自動協商發現物理信令有異常的時候,不會自動將端口從UP狀態轉換為其他狀態,從而導致了單向鏈路的故障。而UDLD協議能夠接受來自自動協商機制傳遞來的參數,然後再發現故障的時候及時的將交換機端口處於關閉狀態。可見,UDLD模式所採用的不隻隻是一種協議,而是UDLD協議與自動協商機制相互作用的結果。如果網絡管理員要啟動UDLD模式的話,那麼就必須要同時啟用UDLD協議和自動協商機制,在第一層與第二層中通過他們的各司其責、協同工作,來防止物理上或者邏輯上的單向連接,從而從根本上消除交換機的誤診斷。
網絡管理員需要明白的是,UDLD並不是交換機原有診斷體系的補充,而是一種獨立的診斷方法。也就是說,它是從另一個角度對交換機各個端口的運行狀態進行自我診斷。兩者之間基本上沒有衝突或者重疊的地方。在實際工作中,傳統的診斷方法與UDLD模式經常是同時使用。
二、合理配置UDLD模式下的各種參數
如果同時啟用了UDLD協議與自動協商機制,就啟動了UDLD模式,在這種情況下,交換機的某個接口會定期的向鄰近的端口發送UDLD協議數據報。在正常情況下,交換機的這個接口會在預定計時器到期之前接收到回應的數據包。如果在這個計時器到期之前,交換機發送UDLD數據包的接口還沒有收到回應信息,則UDLD協議就會認為出現了故障,即發生了單向鏈路的故障(其實更加精確的說,應該是自動協商發現了這個故障並告知了UDLD協議)。當UDLD知道這種情況後,會馬上關閉有問題的交換機接口。
在UDLD配置的時候,首先需要考慮這個計時器。也就是說,將這個時間設置為多少為好。如果時間設置的比較短,不僅會造成不必要的數據流量,而且也有可能因為數據延遲等原因導致無法在合理的時間內接到回應的數據包。而如果將這個計時器的時間設置的比較長的話,那麼就可能無法在短時間內發現問題。要知道,可能一分鐘對於用戶來說,沒有多少感覺。但是對於數據網絡傳輸來說,這個時間就很長了。默認情況下,這個計時器是15秒。在實際工作中,網絡管理員可能需要根據不同的情況來合理設置這個參數。如需要根據企業網絡的複雜情況、佈線的長短來考慮。如根據以前的情況,企業可能經常會遇到網絡堵塞等情況,而這種堵塞也是暫時的,那麼要適當延長這個計時器等等。筆者的建議是在剛開始的時候可以將這個計時器設置的長一點,然後慢慢的減短。最後得到一個合理的數值。
三、提高端口的適用性
在採用普通接口的情況下,當某個接口因為接收不到UDLD回應消息時,接口就會關閉。這也有一種缺陷。如企業可能會有網絡擁塞,如因為臨時備份等等導致擁塞等等。此時在發送端可能無法在計時器到期之前收到回應的信息。那麼遇到這種情況時,如果將交換機的端口就設置為關閉,顯然就會引起不比要的麻煩。網絡管理員希望能夠給網絡“改錯”的機會。為此在原有UDLD模式的基礎上,思科交換機又提出了積極UDLD模式的概念。兩個模式的差異主要就在於後者給了網絡一個改錯的機會。
在積極UDLD模式下,當交換機接口發現無法正常收到UDLD回應信息的時候,並不會馬上將這個端口設置為關閉狀態,而會繼續發送UDLD數據包。通常情況下,UDLD數據包會發送八次。如故發送八次之後仍然無法收到UDLD數據包的話,那麼UDLD協議就會將這個端口狀態改為Err-disable狀態。如果在這個間斷的時間內,發送端口能夠收到任何一個回應信息,就會認為是正常的。很顯然,如果採用積極UDLD模式,就可能有效的避免因為網絡擁塞而導致的誤判問題。
採用積極UDLD模式的另外一個原因就是路由黑洞。什麼叫做路由黑洞呢?這個定義不怎麼好說,筆者就舉一個例子。如第3層或者路由接口正在經歷單向鏈路時,此時接口匯保持在UP狀態,所以交換機就會繼續將流量轉換到這個接口。但是最終的結果是數據包將永遠達不到遠端設備的對應接口之上。這就是路由黑洞的一個簡單例子。如果採用傳統的UDLD模式,還不能夠很好的避免這種情況下。相反,如果採用積極UDLD模式,就可以有效的避免路由黑洞導致的網絡故障。
積極的UDLD模式除了在發送信息的次數上比較特殊之外,還有以下兩個特殊的地方。一是當鏈路的一側端口發送擁塞時,積極模式的UDLD協議也會將端口設置為Error狀態,並顯示相關的措施信息。而採用傳統UDLD模式對這種情況不會有任何反應。二是當鏈路的一側端口處於UP狀態,而另一側處於Down狀態時,如果採用的是積極UDLD模式,則會顯示錯誤信息,並將端口設置為錯誤狀態。而如果採用傳統UDLD模式的話,則不會有任何反應。這也正是筆者上面所講的通過積極UDLD模式來解決上路有黑洞的原因。
四、故障恢復後重新啟動交換機接口
無論採用的是傳統的UDLD模式,還是採用的是積極的UDLD模式,有一個共同點,即只要將端口設置為Error-disable狀態後,即使故障解決了,交換機也無法自動恢復接口。換句話說,當出現這種情況時,網絡管理員需要手工恢復接口。一般的做法是,先將端口利用命令shutdown關閉掉,然後再利用命令no shutdown進行啟用。
總之,只要交換機支持,就啟用UDLD模式,甚至可以啟用積極UDLD模式,就可以有效的避免單向鏈路的誤診情況。特別是採用積極模式的UDLD,那麼路由黑洞這個網絡難題也可以迎刃而解。

資料來源:http://www.xker.com/page/e2011/0120/99909.html

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

導致交換機接口出現err-disable的幾個常見原因:
1. EtherChannel misconfiguration
2. Duplex mismatch
3. BPDU port guard
4. UDLD
5. Link-flap error
6. Loopback error
7. Port security violation
1.當FEC兩端配置不匹配的時候就會出現err-disable。假設Switch A把FEC模式配置為on,這時Switch A是不會發送PAgP包和相連的Switch B去協商FEC的,它假設Switch B已經配置好FEC了。但實事上Swtich B並沒有配置FEC,當Switch B的這個狀態超過1分鐘後,Switch A的STP就認為有環路出現,因此也就出現了err-disable。解決辦法就是把FEC的模式配置為channel-group 1 mode desirable non-silent這個意思是只有當雙方的FEC協商成功後才建立channel,否則接口還處於正常狀態。
2.第二個原因就是雙工不匹配。一端配置為half-duplex後,他會檢測對端是否在傳輸數據,只有對端停止傳輸數據,他才會發送類似於ack的包來讓鏈路up,但對端卻配置成了full-duplex ,他才不管鏈路是否是空閒的,他只會不停的發送讓鏈路up的請求,這樣下去,鏈路狀態就變成err-disable了。
3.第三個原因BPDU,也就是和portfast和BPDU guard有關。如果一個接口配置了portfast,那也就是說這個接口應該和一個pc連接,pc是不會發送spanning-tree的BPDU幀的,因此這個口也接收BPDU來生成spanning-tree,管理員也是出於好心在同一接口上配置了BPDU guard來防止未知的BPDU幀以增強安全性,但他恰恰不小心把一個交換機接到這個同時配置了portfast和BPDU guard接口上,於是這個接口接到了BPDU幀,因為配置了BPDU guard,這個接口自然要進入到err-disable狀態。解決辦法:no spanning-tree portfast bpduguard default,或者直接把portfast關了。
4.第四個原因是UDLD。UDLD是cisco的私有2層協議,用於檢測鏈路的單向問題。有的時候物理層是up的,但鏈路層就是down,這時候就需要UDLD去檢測鏈路是否是真的up的。當AB兩端都配置好UDLD後,A給B發送一個包含自己port id的UDLD幀,B收到後會返回一個UDLD幀,並在其中包含了收到的A的port id,當A接收到這個幀並發現自己的port id也在其中後,認為這鏈路是好的。反之就變成err-disable狀態了。假設A配置了UDLD,而B沒有配置UDLD:A給B發送一個包含自己port id的幀,B收到後並不知道這個幀是什麼,也就不會返回一個包含A的port id的UDLD幀,那麼這時候A就認為這條鏈路是一個單向鏈路,自然也就變成err-disable狀態了。
5.第五個原因就是鏈路的抖動,當鏈路在10秒內反复up、down五次,那麼就進入err-disable狀態。
6.第六個原因就是keepalive loopback。在12.1EA之前,默認情況下交換機會在所有接口都發送keepalive信息,由於一些不通交換機協商spanning-tree可能會有問題,一個接口又收到了自己發出的keepalive,那麼這個接口就會變成err- disable了。解決辦法就是把keepalive關了。或者把ios升到12.2SE
7.最後一個原因,相對簡單,就是由於配置了port-security violation shutdown。

資料來源:http://bbs.net130.com/archive/index.php/t-246023.html

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

常有客戶會問到ADSL的上、下行速度,例如客戶申請上行64k、下載512k的ADSL服務,他們會問到,是不是同時可以上行64k,下載512k?如果做不到,是不是我們的服務有問題?關於這個問題,需要從ADSL電路服務的物理特性出發,才能得到更正確的認識,ADSL電路的確是將上傳、下載頻寬切開。

例:上行64k,下載512k。但是一般網路所使用的TCP/IP協定,每一個封包,都需要有acknowledge訊息的回傳。也就是說,傳遞的資料,需要有一個收到資料的訊息回覆,才能決定後面資料的傳送速度,並決定是否重新傳遞遺失的資料以資料傳送的速度來看,上行的頻寬一部分是用來傳遞這些acknowledge(確認)的資料,上行頻寬滿載時,是會影響到acknowledge資料的傳送速度,並進而影響到下載速度。這在非對稱性的頻寬如上傳速度遠小於下載速度的ADSL服務的資料傳送,尤其明顯。

詳細的測試報告記錄於下,當上傳頻寬滿載時,下載速度約減為正常速度的40%,但測試仍有112k的下載速度。這並非電路頻寬的問題,而是TCP/IP資料傳送的技術限制,所有的ISP服務都有相同的狀況,非對稱性的資料傳送時,特別明顯!

 
ADSL連線速度測試報告
《一》測試環境
上傳滿載時,從中山大學FTP站下載檔案,測試下載頻寬情形。
 
《二》測試結果
  1. 數據比較:上傳滿載時,下載最大頻寬114k/sec;上傳檔案完畢後,下載最大頻寬恢復到282k/sec。(詳如附圖一、二)
  2. 上傳滿載時,會影響下載頻寬。影響最大頻寬約2.4倍,但仍有114k/sec的頻寬大於撥接的速度。
《三》影響原因分析
  1. TCP/IP協定傳遞資料時,需要傳回acknowledgement資訊,來確認資料已收到,並做流量控制使用。因此,資料下載時,仍有acknowledgement資料需要上傳回覆資料傳輸情形,作為後續下載資料的傳送訊息。因此,上傳頻寬滿載時,會影響acknowledgement的回覆速度,確認速度慢因而下載速度也變慢。
  2. TCP/IP的flow control,當acknowledge的速度快時,會加快下載的反應速度;相反的acknowledge速度慢時,會減緩下載的反應速度。因此,上傳頻寬滿時,flow control機制,也會再減緩下載速度。
  3. ADSL為非對稱頻寬,下載的頻寬較大。也意味著需acknowledge上傳回去的資料量較大,在頻寬較小的上傳頻寬中與滿載的上傳資料同時搶頻寬,因此,上述效應更為明顯。

 

資料來源:http://eservice.seed.net.tw/class/class05.html

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

VI4提供了三種DISK TYPE:

Zeroed thick (default) : pre-allocated , zeroing於run time 

Eager zeroed thick : pre-allocated , zeroing於create-time  (效能較佳)

Thin: No-preallocated , zeroing於run time

針對這幾種格式,許多客戶在效能方面一直有所疑慮,所以VMware原廠也特別對這幾種格式做了IO效能驗證測試.

Test 1 result :

比較thin與thick讀寫效能,以下是測試結果.
使用IOMeter產生的workload aggregate thoughput約180MBps (thin與thick的post-zeroing,也就是先做了eager zeroed.)

而thin與thick的zeroing效能一定比較慢,因為first wirte到空的block前需要被zeroing out.

可見,其實差異只在於是否先zeroing過 , 至於thin format或thick format,在block沒有先zeroing前,其實效能差不多...

對於Thin disk上的fragmentation產生的效能影響:

Internal Fragmentation :
發生在檔案系統為某個檔案配置一個block時,該檔案並沒有用滿整個block.
VMFS-3透過使用sub-block allocation機制來處理這個問題.
小檔案使用sub-block取代file block.
在1MB file block-size 的Volume上,一個sub-block是1/16 file-block的大小.
8 MB volume上的sub-block size是file block的1/128.

External Fragmentation :
某檔案有很多block,但這些block有的是跨實體磁碟存放.
這樣分散的方式由於seek time與rotational latency而影響效能.

下圖,Fragmentation在Thin與Thick並沒有多大差異.

此處VMware提供了指令可以將舊有的Thick format轉換成Thin format :
vmkfstools -i .vmdk  .vmdk -d thin

  

很多的Storage Vendor也提供了thin provision功能,但這種功能是針對LUN/Volume的虛擬化,在比較大的企業環境架構下(Volume不僅僅是提供給VMware使用,還有其他AP Sever也需要使用),儲存虛擬化還是必須要的..

VMware的thin provision其實僅針對vmdk file , 在管理面上可以提供VM Admin比較彈性的空間配置,較不需要擔心立即性所需要的儲存空間issue.

 

資料來源:http://tw.myblog.yahoo.com/my-virtualization/article?mid=548&prev=551&next=543

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

LUN是對存儲設備而言的,volume是對主機而言的。

怎麼去理解呢?

選擇存儲設備上的多個硬盤形成一個RAID組,再在RAID組的基礎上創建一個或多個LUN(一般創建一個LUN)。許多廠商的存儲設備只支持一個RAID組上創一個LUN。此時LUN相對於存儲設備是​​一個邏輯設備。

當網絡中的主機連接到存儲設備時,就可以識別到存儲設備上邏輯設備LUN,此時LUN相對於主機來講就是一個“物理硬盤”,與C盤D盤所在IDC或SCSI硬盤的性屬是相同的。在該“物理硬盤”上創建一個或多個分區,再創建文件系統,才可以得到一個VOLUM。此時VOLUME相對於主機是一個邏輯設備。

從容量大小方面比較VOLUME,分區、LUN、RAID的關係如下:VOLUME =分區≤主機設備管理器中的磁盤= LUN ≤ RAID ≤存儲設備中硬盤的總容量。

上述只是針對一般情況,VOLUME也只是針對主機來講。個別廠商對LUN和VOLUME定義與普通廠商的定義不同,甚至會起一些奇怪的名稱,這些名稱即使是存儲行業的資深人士也不一定全明白。不過只要你能分清楚其實質就行。

因此我們在學習存儲知識的時候,也呼籲一下各廠商都能將產品名稱標準化,概念統一化。不過估計只能等到某一個廠商統一了整個存儲市場之後才有可能做到,就好像當年秦始皇統一了六國之後才能統一計量單位和貨幣一樣。

資料來源:http://www.sansky.net/article/2007-05-12-lun-volume.html

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

1.FaceTime視頻通話中的雙方必須都是iPhone 4用戶。
2.兩個iPhone 4都必須有蜂窩信號,能接打電話。 現在的鎖網機在沒有越獄解鎖的情況下是無法使用Facetime通話功能的。
3.兩台iPhone 4必須都在Wi-Fi環境下,不必在同一局域網中。 使用FaceTime需要保證防火牆的53, 80, 443, 4080, 5223和16393-16472 (UDP)端口沒有被封鎖。 如果對應的端口被封鎖的話,FaceTime也是無法成功的。

資料來源:http://www.zhaoipad.com/thread-2107-1-1.html

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

AJAX

AJAX全稱為「Asynchronous JavaScript and XML」(非同步JavaScript和XML),是一種創建互動式網頁應用的網頁開發科技。

AJAX不是指一種單一的科技,主要包括了 XHTML+CSS+Javascript,利用XMLHttpRequest與 Web Server 進行非同步資料交換。

一般而言,AJAX會包括以下技術:
•以XHTML+CSS來表示資訊;
•利用JavaScript操作DOM(Document Object Model)進行動態顯示及互動;
•以XML和XSLT進行資料交換及相關操作;
•透過XMLHttpRequest物件與Web伺服器進行非同步資料交換;
•使用SOAP-XML的格式,來傳送方法名和方法參數。
Data mining

資料挖掘(Data mining),又譯為資料採礦、資料探勘。它是資料庫知識發現(英語:Knowledge-Discovery in Databases,簡稱:KDD)中的一個步驟。資料挖掘一般是指從大量的資料中自動搜尋隱藏於其中的有著特殊關聯性(屬於Association rule learning)的資訊的過程。資料挖掘通常與電腦科學有關,並通過統計、線上分析處理、情報檢索、機器學習、專家系統(依靠過去的經驗法則)和模式識別等諸多方法來實現上述目標。

LAMP

LAMP 係指利用常用來建置動態網站相關軟體,這些軟體大多是免費或是自由軟體,一般常稱LAMP包括:
L: Linux,作業系統。
A: Apache,網頁伺服器。
M: MySQL,資料庫系統。
P: PHP,腳本語言。

LAMP 因為它們是免費的,加以取得容易(在Linux 的多種發行版本中,大多有捆綁這些軟體),因此,這些軟體被組合成一個相當普遍的動態網站服務解決方案。

MVC

MVC(Model-View-Controller,模型-檢視-控制器模式)是軟體專案中的一種軟體架構模式。它把軟體系統分為三個基本部分:模型(Model),檢視(View)和控制器(Controller)。

•控制器- 程式設計師編寫程式應有的功能(實作演算法等等)
•檢視 - 介面設計人員進行圖形介面設計
•模型 - 資料庫專家進行資料管理和資料庫設計
RIA

豐富型網際網路應用程式(Rich Internet applications,簡稱RIA)是一種具有近似於傳統桌面應用系統功能和特性的網路應用系統。RIA系統最大的特點是將大部分處理任務都從用戶界面端移植到客戶端,僅保留一些必要數據與伺服器端進行信息交互。RIA系統的特性:

•運行於瀏覽器中,不需要額外安裝支持軟體
•在本地運行時,受安全沙箱全程保護。
SEO

搜尋引擎最佳化(又稱搜索引擎優化, 其英文叫 Search Engine Optimization,簡稱SEO)是一種利用搜索引擎的搜索規則來提高目的網站在有關搜索引擎內的提名的方式。由於不少研究發現,搜索引擎的用戶往往只會留意搜索結果最開首的幾項條目,所以不少網站都希望透過各種形式來影響搜索引擊的排序。當中尤以各種依靠廣告維生的網站為甚。

SQL Injection

SQL資料隱碼攻擊(SQL injection,中國大陸稱作SQL注入攻擊),簡稱隱碼攻擊,是發生於應用程式之資料庫層的安全漏洞。簡而言之,是在輸入的資料字串之中夾帶SQL指令,在設計不良的程式當中忽略了檢查,那麼這些夾帶進去的指令就會被資料庫伺服器誤認為是正常的SQL指令而執行,因此招致到破壞。

U化

U化包括了4個A:Any Time、Any Where、Any Service、Any Device。
其目標在於,以人為中心,讓使用者可以在任何時間、地點,透過各其設備,取用、使用任何有需要的資訊或服務。與M化環境不同的是,U化環境加強物件感知網路的建立,以達成主動提供人們所需的內外在資訊之目標。

BI

BI(商業智能,又稱商業智慧或商務智能),指用現代數據倉庫技術、線上分析處理技術、數據挖掘和數據展現技術進行數據分析以實現商業價值。目前,商業智能通常被理解為將企業中現有的數據轉化為知識,幫助企業做出明智的業務經營決策的工具。

DB

一般所謂的資料庫
是一種指將資料跟程式(網頁程式)分離開之後,將所有的資料依一定的方式儲存起來。
這樣的觀念很早就已經型成,而在資料庫軟體(系統)的實作上,可以分成:

● 檔案型資料庫
此類型資料庫比較早實作,因為實作簡單,主要是將資料抽離程式,等有需要的時候,再將其讀入即可。
-表格資料庫
透過execl或是CSV等檔案
-XML資料庫
利用 XML 可自定義的特式,給予不同的資料定義

● 非檔案型資料庫
此類型資料庫比較晚實作,但是較檔案型資料庫有更好的使用彈性,故為目前資料庫的主流。
-網狀式資料庫 Network Database
-關連式資料庫 Relational Database
-物件導向式資料庫 Object-Oriented Database
-階層式資料庫 Hierarchical Database

LDAP

輕型目錄訪問協議,即Lightweight Directory Access Protocol (LDAP)是一個訪問在線目錄服務的協議。
目錄是一組具有類似屬性、以一定邏輯和層次組合的信息。常見的例子是電話簿,由以字母順序排列的名字、地址和電話號碼組成。

PHP

PHP(PHP:Hypertext Preprocessor)是一種在電腦上執行的腳本語言,主要是用途在於處理動態網頁,也包含了命令列執行介面(command line interface),或者產生圖形使用者介面(GUI)程式。

PHP 的應用範圍相當廣泛,尤其是在網頁程式的開發上。一般來說 PHP 大多執行在網頁伺服器上,透過執行PHP程式碼來產生使用者瀏覽的網頁。PHP 可以在多數的伺服器和作業系統上執行,而且使用 PHP 完全是免費的。

RSS

RSS(簡易資訊聚合)是一種消息來源格式規範,一般用來發佈經常更新的網站資料,例如部落格文章或是新聞等。RSS可以是以下三種解釋中任一種的縮寫:

•l Really Simple Syndication(RSS 2.0)

•l RDF(Resource Description Framework)Site Summary(RSS 0.91, RSS 1.0)

•l Rich Site Summary(RSS 0.9 and 1.0)

由於RSS的內容大多只包括部份的文字摘要,所以常被當做是快速、簡短資訊傳遞的媒介,也有部份的部落格利用此一特性,串連其他部落格文章的RSS,做為群體發佈訊息的方式,讓瀏覽網頁者可以一次看到多個部落格最新的資訊,這對使用者而言,是非常方便的。

SOA

服務導向架構(Service-oriented architecture)是構造分散式系統的應用程序的方法。它將應用程序功能作為服務發送給最終用戶或者其他服務。

企業系統的架構師認為SOA能夠幫助業務迅速和高效地響應變化的市場條件[1] . 服務導向的架構在宏觀(服務)上,而不是在微觀上(對象)提高了重複使用性。同時,服務導向的架構可以簡化與傳統系統的互連和使用。

UTF-8

UTF-8(8 位元 Universal Character Set/Unicode Transformation Format)是一種針對 Unicode 的可變長度字元編碼。它可以用來表示 Unicode 標準中的任何字元,且其編碼中的第一個位元組仍與 ASCII 相容,這使得原來處理 ASCII 字元的軟體無須或只須做少部份修改,即可繼續使用。因此,它逐漸成為電子郵件、網頁及其他儲存或傳送文字的應用中,優先採用的編碼。

WEB SERVICES

考慮到並沒某個獨立文檔包含一切相關內容,可採用模塊化的方式給出對WEB SERVICES的描述,但不能給出一個「絕對全面和準確」的定義。受外部環境和實現技術影響,各方給出的核心定義可能稍有出入,但通常包括:

SOAP
一個基於XML的可擴展消息信封格式,需同時綁定一個傳輸用協議。這個協議通常是HTTP或HTTPS,但也
可能是SMTP或XMPP。

WSDL
一個XML格式文檔,用以描述服務埠訪問方式和使用協議的細節。通常用來輔助生成伺服機和客戶端代碼及
配置信息。

UDDI
一個用來發布和搜索WEB SERVICES的協議,應用程式可藉由此協議在設計或運行時找到目標WEB
SERVICES。

資料來源:http://www.prowin.net.tw/main.php?mod=custom_page&site_id=0&page_id=25#

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

OEM: Original Equipment Manufacturing,接受客戶完全指定,按原圖設計代工製造。
ODM: Original Design Manufacturing,為客戶提供設計、製造代工的服務。
EMS: Electronics Manufacturing Service,提供經濟規模及全球各地的電子專業代工製造服務。
CMMS: Component Module Move Service,是郭台銘首創的代工模服務模式。分別為JDVM(Join DeVelopment Manufacture)共同設計開發製造與JDSM(Join DeSign Manufacture)共同設計服務製造。

ODM與OEM的不同,在於增加了設計(Design)概念。EMS與OEM的不同,在於,EMS提供了全球運籌通路與全球組裝工廠。而JDVM跟EMS的不同,在於,JDVM提供了客戶維護與全球維修,最後呢!JDSM又比JDVM多了產品設計的部分。

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

以「智慧地球」、「感知生活」為概念所衍生出來的物聯網(Internet of Things,IOT),其含括的範圍十分寬廣,包括智慧電網、智慧交通、智慧物流、智慧家居、環境安全偵測、工業自動化升級、智慧醫療、智慧農業行動商務等業務。
轉載自:http://money.chinatimes.com/news/news-content.aspx?id=20110225001479

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

綜觀自2008年底AOSP1公佈以來,從2009年當紅炸子雞,所有廠商都要做Android相關產品,各種相關活動場場爆滿,到2010年漸漸回歸常態,該掛的掛,該起的起,做出些成績的都是大廠,而其他廠商雖在政府重點補助下,仍然沒什麼起色。究竟採用Android有什麼好處、進入困難的門檻何在、國內以硬體廠商為主的思維碰到了什麼問題?以下從個人觀點分析。

Open Source帶來的衝擊

許多專案/產品管理者,在面對採用開放源碼為主的軟體專案時,經常碰見以下問題。

  1. 對程式碼的了解/掌握度:大多數情況下,現存的程式碼並不能完全符合專案的需求,仍需要一定程度的修改。然而,開放的程式碼並不一定容易修改,大部分情況下也沒有充分的文件說明,最多說明一下如何使用,對程式碼內部結構的文件可就更稀有了。大型、複雜的專案可以非常難追蹤、理解,不恰當的拙劣修改常常導致事後維護上的困難,但具有恰當修改能力的工程師非常稀少。對整體架構沒有全盤掌握時,修改、除錯、維護所需的資源都難以估計,造成專案更高風險。
  2. 缺乏概觀:根基於開放源碼的產品常由許多專案組成,而這些專案會基於不同的科技,在系統的不同層面有不同的功能。他們之間的互動方式,以及在整個系統中扮演的角色,在沒有適當背景知識的情況下是難以理解的。故,要維持住對產品概觀的了解,以及掌握專案各部份的狀態,會變成一項挑戰。專案管理者必須對核心優勢以及商業價值有正確理解,對其他部份採取開放態度,藉此獲得社群的支援,以減低開發難度。
  3. 不知與upstream合作:開源專案多半有負責維護的個人/團體,就是此處所指的upstream(上游)。要了解程式碼,以及取得支援,最直接的方法就是與上游保持良好關係。實務上最佳解決方案為,與上游直接合作,將自行開發的錯誤修正與新功能等等都回饋到原先專案。由於有貢獻,上游自然也更願意視為一份子。然而,首先公司內部文化必須克服,如何讓保守文化理解到,將非核心的開發成果公開出去與上游直接合作,實際上無損公司,並且有利減低研發成本。克服之後,還要面對與適應開源社群不同的開發模式、工具與文化。
  4. 法律問題:許多商業組織刻意或非刻意的違反開源軟體的著作權要求。這會讓他們有被Harald Welte2這樣的人控告的危險,而且有損商譽。這些商業組織需要有經驗的人來處理開放源碼的著作權益題,尤其是產品本身必須混合自行開發的封閉程式碼以及開放源碼的情況。

Android帶來的額外挑戰

AOSP是由OHA主導的開放源碼專案,其背景與傳統上開放源碼略有異同,一開始差異頗大,但開放至今,其文化已較為趨近傳統開源專案。原因無他,在長時間的適應下,原先的開源專案文化,許多因素已可視為最佳實務(best practice),有利於軟體發展。比如鼓勵貢獻、盡量公開開發流程、增加社群互動等等。此系統亦帶來了一些新的挑戰,嘗試略述如下:

  1. 除錯需跨越各層:Android是由許多不同技術結合起來的複雜集合。系統上大部分提供的服務,其程式碼都由數種不同的程式語言組成,並在系統的不同層級執行。在平台內除錯(而非對應用程式層之內,這部份相對簡單)經常需要在application層、runtime層與library層來回對照,這比傳統上單純的C/C++程式碼除錯複雜許多。
  2. 需跟上快速的上游開發速度:由最早的1.0/1.1到其後1.5 (Cupcake), 1.6 (Donut), 2.0/2.1 (Eclair), 2.2 (Eclair),短短近兩年時間改變甚大,而每版又有明顯更動/改進,使得緊跟上游成為一困難課題。這意味著,當產品還在開發,其版本可能就已經過時,而業者就必須同時進行跟進與產品化,包括細節整修、除錯、新功能開發等等。這對軟體開發團隊而言是很大的挑戰。這在業界引起的效應相當明顯,例如各家廠商旗下Android手機更新版本速度不同,能力不足廠商到2.2時可能還在出1.6版的產品等等。
  3. 不同領域的技術知識:如上所述,Android是一複雜的集合。週邊、電源管理、手機通訊協定、圖形加速、虛擬機器(Dalvik)、toolchain、使用者介面設計、認證等等,每個都是大題目。Android提供了一個可以往上建造的平台,然而與此同時,也需要更多領域的知識,而這些在之前可能都是由需付費的軟體提供者,例如微軟,來負責的。這意味著更高的進入門檻。

麻煩很多,優點何在?

Android很紅,這點大家都知道,市場一片樂觀,廠商紛紛跳入。然而,在跳進之前,若能先理解這倒底是怎樣的系統,特點何在,為何採用,才容易抓到開發重心。基於Android的產品各家都喊了,到現在卻是幾家歡樂幾家愁,不是沒有原因。

若如前例採用微軟視窗系統,則維護由微軟負責,廠商付費使用即可,相對單純。然而,就廠商角度而言,對系統控制低,要怎麼改都是付費看人臉色,很難累積自己的成果。比如從Windows Mobile 6.5到Windows Mobile 7,介面能客製化的程度降低,微軟的識別度增加,對想主打自身品牌辨識度的廠商來說,就不是好事。然而,做軟體就好像堆磚頭,在現代,製作一套完完全全從底層到上層所有功能都自己來的作業系統,一塊塊從底層堆起,是相當大的工作。以PC上運作的GNU/Linux系統為例,底層為Linux kernel,也就是作業系統的核心部份。而運行在這核心之上,有各式各樣的軟體,有的可以讓我們傳 MSN, Yahoo messenger、看網頁、收發 email 等等之類。在 Microsoft Windows 上我們有些熟悉的軟體來做這些事,在開放源碼的世界同樣也有,例如許多人都聽過,而且也可以在 Windows 上使用的Firefox。把許多開放源碼軟體組合起來呈現給使用者,形成一套完整的作業系統,這樣的組合就稱作 Linux distribution(後簡稱distro)。

一distro則可由社群、非營利組織或是公司來維護,其內有成千上百元件,大部份都是開源軟體,其間共同運作是否順暢、各元件維護、處理錯誤回報、修正等等,需要相當大的研發資源。如目前當紅的Ubuntu,就是由Canonical公司主導。但,到了手機領域,若想以現有系統為基礎自行開發,之前就沒有什麼真正主流的選擇。Meego的出現可能會帶來改變,不過這部份有待觀察,應另文討論。Android為何廣泛被考量作為產品之軟體平台,很大原因即在於它是一套由Google主導的開放源碼作業系統,以此為基礎,可以為廠商省下許多的研發成本,而專注於開發產品獨特的優勢。

也就是說,Android的存在,是建立了一個大家可以在其上建造的「標準平台」,而且「可以修改」。

另外一個重要的考量,則是軟體的流通。作業系統不同,程式也會不能互通。在A系統可以跑的程式,在B系統不見得能跑,因為他們對軟體的組合選擇以及採用的版本可能都不同。在開放源碼的世界,程式碼都是公開的,這就容易解決,由distro維護者選取配合的版本,把他們從原始碼一一編譯起來,發行給使用者就行了。然而,對商業應用程式的開發者來說,這就是一大問題,因為同時支援這麼多平台的花費太高。另一問題是,假定採用的硬體CPU不同,那麼就算採用同一系統,在不同硬體上,仍然無法共通,例如Intel與ARM based CPU就是。Android的存在,可從兩方面來解決這些問題:

  1. 系統組合與維護交由Google and OHA主導,所以軟體平台可以固定下來,以AOSP release為參考點即可。
  2. 不同硬體相容性,由Android runtime解決,只需在framework上可以執行,不同硬體影響可由Android負責處理。

Android在同一時間主流版本有限,並有一定程度的向前相容。例如以本文寫作時來說,2.2的平台為主流,並且可以向前相容上一個主要版本,也就是1.6的應用程式。而只要熟悉了Android Framework,就可以持續的開發應用程式。就此角度而言,Android與Windows類似,都減低了發行封閉原始碼程式的困難度。例如下一主流Windows版本應為Windows 7,那麼程式設計師只要以Windows 7為目標平台來製作應用程式即可,大部分之前由XP, Vista累積下來的經驗,都仍然有效。

然而Android帶來的改變,其實還不只於此。前面提到Android runtime可以讓程式在不同CPU架構下執行。在桌上型、筆記型電腦的世界,大家CPU都是 Intel,不同硬體架構的問題不大。然而到了移動裝置的世界,由於要考慮到功耗等等因素,採用的CPU種類就往往不同。這意味著,兩個裝置就算安裝了相同版本的某作業系統,但是CPU架構不同,也照樣不能執行。以往對於此問題的解決方法稱為Java ME,也就是採用Java runtime。對應到Android,則是由Android runtime解決。

走筆至此,讀者應可了解,Android提供了一方便開發、執行應用程式的平台。程式被創作出來,編譯、包裝成Android應用程式之後,便可一併通行各種不同裝置上的Android作業系統。

因應之道

了解Android開發的困難點,以及採用的好處以後,系統廠適應的策略為何呢?由現有例子可以觀察到,只要研發能力足夠,所有的問題都不是問題:拿回來全部in house自己做就行了。有趣的是,國內公司並不見得整體研發能力不足,而是公司體制內各自為政,不同部門互不合作,分則力弱,變成各單位分別挑戰,自然會發生人家手機出了一整排,自家公司蹲好久才出個一兩隻還比人家差的情況。在研發資源有限的情況下,最佳解法就是回到基本,了解Android仍然是一開源專案,採取開源專案已知的合作方式即可。也就是說,除了技術理解,對協同開發方式,也必須熟悉。視專案規模大小與不同需求,以下嘗試提出幾點方案:

  1. 其他廠商合作開發,共同維護一份通用程式碼。
    1. 自家客製化部份,可視專案需求,與提供商業Android服務的公司/獨立開發者合作,或由內部訓練團隊。
    2. 外部需尋找的對象為,不只理解開放源碼如何運作,也懂得商業價值的重要,易於溝通。
    3. 由內部訓練專家。仍需要一些顧問作為種子,需時較長,但可在公司內培養出自有團隊。
  2. 內部一定要有對開放源碼協同開發方式經驗豐富的經理人。不論合作、驗收、內部培養,都非常重要。
  3. 在共通與自有程式碼混合情形下,需有對開放源碼著作權問題有研究的法律顧問。

建立標準、開放合作

如前所述,可以理解通用程式碼的重點應在於共用功能以及硬體支援。以目前業界情勢來講,採用的硬體平台正快速的收斂,例如手機台廠主流多為Qualcomm,既然如此,小廠可依樣畫葫蘆,合作維護一份「基於常見硬體的Android版本」,以AOSP發行為基礎,針對幾個硬體平台合作開發。畢竟將系統在某硬體上動起來,只是產品化的初步而已。以生產製造為強項的廠商,可以以此版本為基礎,專注在自己擅長的生產。而以軟體研發見長的廠商,則可以在此版本上專注於商業應用程式開發。自有品牌者,則可專注於使用者經驗、介面辨識度、工業設計等等。在共同需要的部份合作,而專注精力在自身擅長領域即可。

功能部份,由於Android並不限於手機,目前已經可以看到平板電腦與電視的應用。同一領域中,基本的功能是共通的,例如支援高解析度螢幕,來處理平板與電視的應用,平板需要不同的使用者介面,而電視需要能躺在沙發上輕鬆的操作等等。以上這些基本門檻,都是廠商可以共同努力的範圍。例如發源於日本的OESF3,就是典型的這種組織,其主要幾個功能為:

  1. 廠商生意交流、媒合的場域。
  2. 維護通用程式碼與支援平台。
  3. 針對各領域如set-top box, VoIP, DLNA等等,訂定標準介面,開發參考用程式碼。

概念正確,在日本也蓬勃發展,但在台灣的推廣卻由於硬體廠(連同一公司都不知識分享!)的封閉觀念而感到阻力。國內如0xlab4自09年起就疾呼此一觀念,也不見明顯成效,實在相當可惜。

回饋上游

Android一出,最理解此一系統的當然是Google以及當年共同開發的Wind River。只是Google重心一直在軟體平台,不輕易做支援,Wind River又奇貴無比,致使Android系統內部知識益形珍貴。時至今日,開發應用程式的說明文件已經相當完整,內部結構的文件仍然欠奉,最佳的文件就是程式碼本身。至於未來開發方向,以及Google內部程式碼與外部的差異等等,Android開發團隊非常忙碌,無心也無力主動提供。身在外圍,要取得這些資訊,最佳方式便是由「工程師對工程師」的社群交流來完成。經由實際操作經驗得知,透過mailing list以及source review5往往可以獲得許多有用資訊。

藉由回饋上游,與AOSP達成正向合作關係,對開發團隊大大有利,卻著實違反傳統商業觀念。在硬體微利時代,軟硬體整合以及使用者體驗,都需要更佳的軟體研發能力。現狀既然已經起跑較晚,開源軟體「站在別人肩膀上開發」的特性,其實相當適合台廠快速應變、打帶跑的作戰方式,然而這也需要新的觀念、視野與執行方式。

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

導言

Android應可說是科技界2009年第一大事。Android前身為一公司,被Google買下後繼續開發,以開放源碼的方式發行,還成立了Open Handset Alliance (OHA)作為支持Android的商業組織。其中成員如Qualcomm, TI, Wind River等在各自領域都赫赫有名,尚未上市就已經相當轟動。開放源碼(Open source)的手機作業系統,其實在此之前已經出現數個,例如Qtopia1以及其後雷聲大雨點小的Openmoko,再如當時以行動上網裝置(Mobile Internet Device, MID)為主的Maemo等等。不過,Qtopia與Openmoko的成熟度當時並未達到商業化需求,而日前Nokia雖然已經基於Maemo發表了新一代智慧型手機N900,但當時Maemo仍侷限於行動上網裝置,而非電話。

換言之,Android除了擁有眾多大廠支持,而且在開放之初就發表了T-Mobile G1,有產品可證明商品化能力。這意味著,長久以來受制於Windows Mobile,又無能力開發自有作業系統的手機廠商,看見了站在巨人肩膀上做出自有產品的可能性。從2008年底開放以來,2009年HTC, Samsung, Motorola, Acer等等都發表了Android手機,而看來2010年中還有更多。究竟 Android 有什麼特點,與以往根基於Linux的手機差別何在,以及面對其他手機作業系統的競爭有何優劣等等,本文嘗試做一介紹與探討。

技術面淺探

要談Android,就無法迴避技術面的討論,但在此會忽略細節以及犧牲一些語言精確度,試著做一簡介。

系統架構

Android作為一作業系統,其針對的硬體為智慧型手機,並在設計伊始就考慮到3G網路以及觸控螢幕、相機、GPS等現代應用。作業系統作為裝置與人之間的媒介,以及負責讓手機正常運作。與人接軌的那端,使用者介面、應用程式等,一般稱上層。而與機器接軌的部份,比如對打電話的控制、無線網路晶片、顯示圖形到螢幕上、接受觸控螢幕收到的手指觸摸等等,就是由底層來負責。在此我們先由下層開始介紹,再步步往上。

(http://developer.android.com/images/system-architecture.jpg)

Linux Kernel

必也正名乎:一般所稱Linux,其實是統稱,指根基在Linux kerne以及其他許多跟kernel不見得有關的軟體所組成的作業系統。最早,Linux一詞其實是專指kernel,它提供了系統底層與硬體間的基本核心,讓其他程式可以在上頭執行。其最早作者是Linus Torvalds,他用自己的名字,加上採用了與Unix系統相容的介面,將自己的作品命名為Linux。

如前所述,在Linux kernel上頭執行的程式,跟kernel本身不見得有關係。可以是自由軟體,也可以完全不是。把它加上一些自由軟體,例如基本的函式庫、工具、圖形介面,應用程式等等,所組成的一套完整作業系統,才是一般所稱的Linux。為了避免誤解,而且也為了正確傳達自身的貢獻,自由軟體基金會2 建議大家稱呼這樣的一套作業系統為GNU/Linux。其中的原因是,kernel提供底層機制,但系統中其他重要元件幾乎都是來自於GNU,也就是自由軟體基金會。

希望大家還沒被這些名詞搞混。要弄清這些不同的原因是,Android是在Linux kernel上頭運作的,但他並不是GNU/Linux。因為在一般 GNU/Linux裡面會有的東西,Android幾乎都沒有。

Linux kernel的版權是GNU General Public License version 2 (GPLv2)3,這又是什麼玩意呢?GPLv2是所謂的Copyleft4版權,簡單來說,就是為了確保智慧財產能夠繼續公開流傳,所以任何基於此創作的延伸創作,都自動採用了相同版權。GPL本身還有個特色,就是「共同運作」也算是延伸的一部分,意思是說你的程式沒直接改GPL的程式碼,但是連結了GPL的東西跟你的程式共同運作,那你的程式也必須採用GPL版權。

舉例來講,假定今天某公司覺得某GPL軟體不錯,拿來改了改,放在自己的產品裡頭拿出去賣,那某公司就一定要明確的一起散佈修改後的程式碼。如果沒有,那就是觸犯版權了。有個組織叫GPL Violations5,專門抓這種案例,國內公司如D-Link以及ASUS都上 過榜。這下問題來了:如果你是硬體廠商,希望你的硬體能在Linux kernel下運作,那麼就必須要有驅動程式。驅動程式就是按照硬體的規格寫的程式,用來告訴kernel怎麼操作這個硬體。如果驅動程式的程式碼公開,等於就是揭露了一些內部資訊。許多廠商不願意這麼做,所以就提供編好的驅動程式,但不提供原始碼。而kernel的版權所有者,也就是Linus Torvalds以及其他許許多多的kernel作者們,為了支援盡可能多的硬體,對這種行為是採取睜一隻眼閉一隻眼的態度,也就是目前這種編譯好的驅動程式,算是處在灰色地帶。

既然Android採用了Linux kernel,當然得照遊戲規矩來。但我們從前文可知,Android的重點就是商業應用,他們可不願意系統裡有什麼「灰色地帶」,於是採用了一些手法來繞過這問題。例如可以在 kernel這邊開個小通道,告訴大家說要控制這硬體就透過我吧,我只負責傳進傳出,但真正控制的指令都寫在某個不公開程式碼的Android函式庫裡頭。這樣一來,公佈的就只有那個通道,實際要怎麼控制,別人還是不知道。

走筆至此,可以看出Google的原則之一 “Do no evil” 是很有意思的。他們自己的確承諾,而且也願意公開Android的程式碼,但是他們給了其他人“Do evil”的選擇。這樣還算不算是 Do no evil 呢?當作哲學問題吧。

然而,Linux kernel已經發展了相當長的時間,擁有許多優秀的開發者以及廣大的使用者群,是非常穩定的系統核心。這為Android系統提供了相當穩定快速的基礎建設。

Libraries

這裡說的libraries是跑在系統裡頭的函式庫,採用的語言不是Java,他們提供了許多基礎建設。裡頭有幾個值得一提的元件:

Bionic:這是Android版的 libc。libc是 GNU/Linux以及其他類似Unix系統上最基礎的函式庫,一般最常用的是glibc,就是GNU做的libc。而在較小型的裝置上也可以用uclibc之類的。不論是glibc or uclibc,版權都是LGPL6(GPL的略為弱化版)。看到這大概可以猜到了吧,又是Copyleft問題。官方的說法是,除了版權問題以外,還考慮必須輕量以及快速,所以才做了自己的libc。不過輕量、快速,本來就是小型裝置用的uclibc一開始的目標,因此,最主要的恐怕還是版權問題。

Webkit:鼎鼎大名的Apple Safari瀏覽器背後的引擎就是Webkit,Android也包含進去了。支援可離線使用的html 5新發展,產生了各種有趣的可能,這部分值得另文介紹,這裡就不再贅述。

硬體抽象層(Hardware Abstraction Libraries, HAL):提供了操縱系統硬體的方法,上頭接上標準的Android framework,就可以讓使用者用一致的方式操作硬體。例如程式只要下令「拍照」,那麼雖然不同相機硬體拍照的指令下法不同,透過抽象層都可以包裝成一致的介面。HAL包含了Android對各硬體裝置例如顯示晶片、聲音、數位相機、GPS、3G 等等的需求,但他只是抽象的概念,事實上若要支援新的硬體,需修改的程式碼分散各處,要自行去尋找。這部份與系統廠商息息相關,後面會再談到。

Android Runtime

跨平台:Android最顯著的特徵之一,就是應用程式可以在不同的硬體上執行,而有同樣的行為。這聽起來沒什麼,一般我們用Microsoft Windows不就是如此嗎?其實並不那麼單純。可以想像,假定有一台Windows XP電腦,也有一隻Windows Mobile手機,那麼手機上的程式有沒有辦法拿到XP上面來跑,或者是相反呢?在電腦上,所有人跑的作業系統跟硬體,其實有很高的一致性,但是一旦到了小型裝置五花八門的世界,就不是那麼回事了。

一個程式的執行,牽涉到幾個元素:原始程式碼、編譯器、函式庫、CPU。Android的應用程式是採Java程式語言寫成,跨平台的方式也與Java類似。Java頗為普及,且之前在手機方面已有許多應用如遊戲等,稱為Java ME,由昇陽(Sun Microsystem)主導。一般所謂Java其實包含三個層面,其一是Java這個「電腦語言」,也就是像這樣的東西:

class HelloWorld
{
    public static void main(String [] argv)
    {
        System.out.println("Hello, world!");
    }
}

也就是用人比較容易看懂的語言(也許不那麼容易啦,但至少比一堆0跟1來得好)來叫電腦做事,比如上個例子是在螢幕上印一行字Hello, world。所謂程式的原始碼,就是一整篇這樣的文章,結合起來,可以叫電腦執行某些功能。這樣的語言比自然語言容易「翻譯」成電腦看得懂的「指令」,而負責翻譯的,就是「編譯器」。

電腦的核心CPU有很多不同種類。一般我們用的是Intel的產品,有些是32位元、有些是64位元。有些人用的可能是Power,例如以往蘋果電腦的使用者。還有一些小一點的電腦,可能就是用ARM架構。總之,不同的CPU具有不同的指令集合,是不能直接互通的。在此我們可以想像,同樣的程式碼,可以經由編譯器,翻譯成適合不同CPU架構的程式,而他們之間是不能互換的。例如編給ARM使用的程式,在Intel的CPU上頭就不能跑。要如何解決這個問題呢?

這裡引入第二層面:「Java 虛擬機器」(Java virtual machine)。虛擬機器可以想像成一虛擬的CPU,先設定一些共通的指令,然後針對各種不同的架構做個別轉換,如此只要是採用此「共同指令集」的程式,就可以在這虛擬機器上面執行,由虛擬機器負責轉換成目標CPU的指令集。如此一來,我們只需要把用電腦語言寫好的程式編譯成「虛擬機器」看得懂的就行了。Java使用的共通指令就稱做 “Java bytecode”。

最後則是Java runtime library,也就是一個「函式庫」,裡頭存了很多編譯好的現成程式,來讓開發者使用,這樣就可省下很多重覆的工作。比如上頭這例子裡頭的System.out.println就是函式庫提供的。那我們可以想像,如果在程式中我們用了很多某個函式庫裡頭的東西,但是用的人只拿到編譯好的程式,但沒有同樣的函式庫,那這程式還是不能用。比如說,Windows, Linux提供的基本函式庫就很不一樣,所以做同樣事情的程式,寫法可能完全不同。Java函式庫裡頭提供的工具,是有標準可循的,所以以上的程式,不管是要在Windows上頭跑,或是Linux上頭跑,都是一樣的寫法。

於是乎,我們可以把Java runtime library跟Java虛擬機器搭配起來,這樣我們只要用Java這個語言寫程式,裡頭呼叫Java runtime library裡頭的工具,用編譯器編成Java bytecode,交給虛擬機器去執行,就可以在各種平台上面跑一樣的程式了。這兩者的組合稱為「Java Runtime Environment, JRE」,只要針對某環境提供JRE,就可以執行Java應用程式了。雖然這聽起來很棒,但我們可以想像,由於隔了一層虛擬機器,程式跑起來容易比直接下命令來得慢,而且必須額外安裝JRE,用掉較多資源。

Java Runtime讓人們可以在不公開原始碼的情況下,發行編譯好的應用程式,在各種不同的平台上執行,相當適合商業應用。Android循著相同架構,也提供了Android Runtime,但有幾點不同。

Android使用的虛擬機器叫作Dalvik,原本並不是針對Java設計的。它認識的指令集並不是Java bytecode,而叫Dalvik executable,簡稱dex。Android裡頭提供了一個工具程式叫dx,可以把 Java bytecode再翻譯成dex,這樣Dalvik就可以執行它了。這虛擬機器為了適合在電話這種比較小型的平台上使用,而做了許多最佳化的處理,例如適用較慢的CPU、低記憶體使用量、減小應用程式的大小等等。

Android虛擬機器與函式庫合稱Android Runtime,在函式庫方面,提供了大部分的標準Java函式庫,讓Java工程師可以無痛的轉換,而關於手機的部份則提供許多諸如使用者介面、藍芽、GPS相關、網路、3D加速、影音、以及電話本身等等許多現成的函式可用。這些函式使得開發者可以直接取用基礎功能,進而專注於應用程式的開發。

Application Framework

提供應用程式執行環境,針對手機設計,許多觀念與一般個人電腦應用程式有相當不同。在此將開發者網站上的說明大略翻譯如下:

應用程式元件

Android的重要功能之一為,應用程式可在對方允許的情形下,使用其他應用程式的元素。例如,如果你的應用程式想要顯示一排可以捲動的影像,而另一應用程式已經開發出了適合的捲軸元件,並開放給他人使用,你可以直接呼叫這元件來使用,而不需自行開發。你的應用程式不需要包含他人的程式碼,也不需固定連結到某程式。反之,Android框架會在有需要時,自動啟動其他應用程式的相關功能。

要順利運行,系統必須能夠在需要其任一元件時,啟動一應用程式程序,並做出需要的Java物件。所以,與大部分系統上的應用程式不同,Android應用程式並沒有一個單一的「進入點」來使用所有功能。反而是,他們提供元件讓系統可以視需要使用。元件類別有四種:

Activities

Activity表示一使用者介面,用以完成某特定事務。例如,activity可呈現一選單列表,或是顯示相片跟標題。簡訊軟體可能包括一個列出所有傳簡訊對象的activity,一個讓使用者對選擇對象寫簡訊的,以及其他的activity來看舊訊息以及設定功能。他們雖然組成一個使用者介面,但各元件互相之間仍是獨立的,例如,其他軟體需要傳訊時給某人時,可能只需叫出「寫簡訊」的activity,而不需其他。

一應用程式可以只包含一個activity,也可以像剛才描述的簡訊軟體一樣,包含好幾個。當然,需要哪些,以及要多少,都是取決於應用程式的設計。一般來說,其中一個activity會被標為程式執行時第一個看到的畫面。由一個activity移動到另一個,是利用目前的來呼叫下一個。每個activity都分配到一個預設的視窗,可以在裡頭畫東西。一般說來,這視窗跟螢幕一樣大,但它也可以比螢幕小,並浮在其他視窗上。而activity也可以開多個視窗,例如跳出一個視窗來取得使用者回應,或者是針對使用者選擇顯示重要資訊。

視窗內部的視覺組成是由樹狀結構的”view”組成,每個view可以包含其他view,控制視窗中一塊長方形的區域,並可跟使用者互動。換句話說,view可組成activity與使用者互動的「實相」。Android系統中有許多現成的view可供取用,例如按鈕、文字欄位、捲軸、選單、勾選格等等。

Services

Service並沒有可見的使用者介面,而是在背景永久執行。例如,當使用者做其他事情時,service可能在播放音樂,或正從網路上抓取資料等等。

Broadcast receivers

唯一功能為收取以及回應「廣播訊息」。廣播經常來自Android系統本身,例如,手機所處的時區改變,電池快沒電了,或是剛照了一張照片,或是使用者剛改變了顯示介面的語言等等。應用程式也可以發出這類廣播,例如,讓其他應用程式知道某些資料已經下載完成,可以使用了。

一應用程式可以有任意數量的broadcast receiver來收取任何它認為重要的訊息。它沒有使用者介面,然而,他們為了回應廣播訊息,可以呼叫某個對應的activity,或者是發出一訊息通知來告訴使用者發生了什麼事情,以及震動、播放音效、閃爍軌跡球等等。

Content providers

負責對其他應用程式提供或收取資料。資料可存放在檔案系統中,或資料庫、或任何合理的方式。例如:通訊錄。

任何時候,當系統需要某一特別元件時,Android系統會先肯定擁有這個元件的應用程式正在執行,如果沒有,就啟動他。另外還會確認此元件是否已經存在於系統中,若視沒有,就製作一個。

啟動元件:intents

Content provider在有人需要存取時便會由系統啟動,而其他三類元件:activity, service, broadcast receiver都是由一種叫intent的訊息啟動的。一個intent表示的是一種「企圖」。例如,它可能是要求「顯示這張圖片」,或者是「編輯這段文字」,或「編一段訊息傳給這個人」。比如說,某應用程式想傳訊給通訊錄中的某一人,可先發出企圖「瀏覽通訊錄」,則系統中負責此事的元件便被啟動。選取對象後,便呼叫「編輯簡訊」的元件來編輯並接著發送出去。
關於應用程式運作,詳細情形可參考開發者網站上的說明7,在此就不詳述了。

Applications

要開發Android應用程式,並不需要下載整個平台的程式碼,只需要採用Google發行的軟體開發工具(Software Development Kit, SDK)即可。使用的電腦語言是Java,並內建模擬器,可直接驗證寫出的應用程式,而不需擁有實體手機。建議的開發環境為Eclipse,此軟體亦為開放源碼專案,不需付費即可使用,許多公司如IBM等亦根基於Eclipse推出了自有的工具,可說應用相當普遍。Google在這部份提供了Eclipse的一個延伸套件,與模擬器、除錯等等都有整合,並提供完整文件,進入門檻降得相當低。

延伸閱讀:

  1. http://www.betaversion.org/~stefano/linotype/news/110/ (Dalvik: how Google routed around Sun’s IP-based licensing restrictions on Java ME):關於 Android 如何繞過 Java ME
  2. http://blogs.sun.com/jrose/entry/with_android_and_dalvik_at (with Android and Dalvik at Google I/O):對 Dalvik 有興趣的話一定要看
  3. http://sites.google.com/site/io/anatomy–physiology-of-an-android (Anatomy & Physiology of an Android):Google 對 Android 平台內部架構的概觀介紹

notes

1 現已經多次改名,先改為 Qt Embedded,現通稱 Qt,讀音同cute。現已由 Nokia 收購。

2 http://www.fsf.org/

3 http://en.wikipedia.org/wiki/GNU_General_Public_License

4 http://en.wikipedia.org/wiki/Copyleft

5 http://gpl-violations.org/

6 http://www.gnu.org/copyleft/lesser.html

7 http://developer.android.com/guide/topics/fundamentals.html

 

資料來源:http://mmdays.com/2010/08/27/android-1/

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

本篇目的在儘量不觸及技術細節的情況下簡介 Android 架構,並探討其設計的特殊處,以及在版權上的意義。主要資料來源為 Anatomy & Physiology of an Android,有興趣深入研究的讀者可參考。

首先來一張現在大概已經很有名的圖片:

由下到上,可以看到紅色的 kernel 層,綠色的系統函式庫,黃色的虛擬機器,以及藍色的 Java 程式碼。以下將一一介紹。

Linux kernel

必也正名乎:一般所稱 Linux,其實是統稱,指根基在 Linux kernel 以及其他許多跟 kernel 不見得有關的軟體所組成的作業系統。最早,Linux 一詞其實是專指 kernel,它提供了系統底層與硬體間的基本平台,讓其他程式可以在上頭執行。其最早作者是 Linus Torvalds,他用自己的名字,加上採用了與 Unix 系統相容的介面,將自己的作品命名為 Linux。

如前所述,在 Linux kernel 上頭執行的程式,跟 kernel 本身不見得有關係。可以是自由軟體,也可以完全不是。把它加上一些自由軟體,例如基本的函式庫、工具、圖形介面,應用程式等等,所組成的一套完整作業系統,才是一般所稱的 Linux。為了避免誤解,而且也為了正確傳達自身的貢獻,自由軟體基金會建議大家稱呼這樣的一套作業系統為 GNU/Linux。其中的原因是,kernel 提供底層機制,但系統中重要的元件幾乎都是來自於 GNU,也就是自由軟體基金會。

希望大家還沒被這些名詞搞混。要弄清這些不同的原因是,Android 是在 Linux kernel 上頭運作的,但他並不是 GNU/Linux。因為在一般 GNU/Linux 裡面會有的東西,Android 很多都沒有。

Linux kernel 的版權是 GNU General Public License version 2 (GPLv2),這又是什麼玩意呢?GPLv2 是所謂的 Copyleft 版權,簡單來說,就是為了確保智慧財產能夠繼續公開流傳,所以任何基於此創作的延伸創作,都自動採用了相同版權。GPL本身還有個特色,就是「共同運作」也算是延伸的一部分,意思是說你的程式沒直接改GPL的程式碼,但是連結了GPL的東西跟你的程式共同運作,那你的程式也必須採用GPL版權。

舉例來講,假定今天某公司覺得某GPL軟體不錯,拿來改了改,放在自己的產品裡頭拿出去賣,那某公司就一定要明確的一起散佈修改後的程式碼。如果沒有,那就是觸犯版權了。有個組織叫 GPL Violations,專門抓這種案例,國內公司如 D-Link 以及 ASUS 都上過榜。這下問題來了:如果你是硬體廠商,希望你的硬體能在 Linux kernel 下運作,那麼就必須要有驅動程式。驅動程式就是按照硬體的規格寫的程式,用來告訴 kernel 怎麼操作這個硬體。如果驅動程式的程式碼公開,等於硬體規格也公開的差不多了。許多廠商不願意這麼做,所以就提供編好的驅動程式,但不提供原始碼。版權所有者,也就是 Linus Torvalds 以及其他許許多多的 kernel 作者們,為了支援盡可能多的硬體,對這種行為是採取睜一隻眼閉一隻眼的態度,也就是目前這種編譯好的驅動程式,算是處在灰色地帶。

既然 Android 採用了 Linux kernel,當然得照遊戲規矩來。但我們從前文可知,Android 的重點就是商業應用,他們可不願意系統裡有什麼「灰色地帶」,於是採用了一些手法來繞過這問題。他們把驅動程式移到 “userspace”,也就是說,把驅動程式變成在 Linux kernel 上頭跑,而不是一起跑的東西,這樣就可以避過GPL。然後,在 kernel 這邊開個小門,讓本來不能直接控制到硬體的 “userspace” 程式也可以碰得到,這樣只要把「開個小門」的程式碼公佈就行啦。事實上,目前因為 Android 已經發行,所以依法他們已經公開了對 kernel 的修改,其原始碼在 http://git.android.com/

走筆至此,可以看出 Google 的原則之一 “Do no evil” 是很有意思的。他們自己的確承諾,而且也願意公開 Android 的程式碼,但是他們給了其他人 “Do evil” 的選擇。這樣還算不算是 Do no evil 呢?當作哲學問題吧。

關於 Android 對 kernel 的修改,Google 的簡報還提供了兩個重點:

  1. Binder (IPC):提供有效率的程式間溝通管道(Inter-Process Communication)。Android 系統中有很多服務,而上層的應用程式經常要取用這些服務,一般的 Linux 系統已經提供了不少 IPC 的方式,不過 Android 還是搞了套自己的。雖說文件中解釋原因為「一般 IPC 會造成額外資源花費,以及安全問題」,但其實這些都是可以基於原有架構在 kernel 外頭解決的,為何要改在 kernel 裡頭,筆者對此存疑,也只能等找時間去研究程式碼才知了。
  2. Power Management:與桌上型電腦或筆記型電腦不同,手持裝置的電源一向相當有限,必須無所不用其極的去想辦法省電,但又不損及順暢的使用經驗。Android 在此採取了頗為積極的作法:「沒有人說要用,就關掉」。例如某程式在放 MP3 音樂,於是此程式會需要 CPU 的計算能力,那就得開口要。如果與此同時沒其他程式在執行,那麼 LCD 顯示器就可能被關掉,藉以省電。另一特別處,是在於 Linux kernel 一般考慮的都是在電腦上的作法,所以多半只有進入暫停、休眠等等的選擇,而不會如此細緻的去控制到各個小裝置的電源供應。

系統函式庫

這裡說的系統函式庫是指 “native libraries”,是跑在系統裡頭的函式庫,採用的語言不是 Java,提供一些基礎建設。裡頭有幾個值得一提的元件:

  1. Bionic:這是 Android 版的 libc。libc 是 GNU/Linux 以及其他類似 Unix 系統上最基礎的函式庫,一般最常用的是 glibc,就是 GNU 做的 libc。不然在比較小型的裝置上也可以用 uclibc。不論是 glibc or uclibc,版權都是LGPL (GPL 的略為弱化版)。看到這大概可以猜到了吧,又是 Copyleft 問題。官方的說法是,除了版權問題以外,還考慮必須輕量以及快速,所以才做了自己的 libc。不過輕量、快速,本來就是小型裝置用的 uclibc 一開始的目標,因此,最主要的恐怕還是版權問題。
  2. Webkit:鼎鼎大名的 Apple Safari 瀏覽器背後的引擎就是 Webkit,Android 也包含進去了。離線使用的 html 配上 html 5 的一些新發展,產生了各種有趣的可能,這部分值得另文介紹,這裡就不再贅述。
  3. Surface Flinger:提供把各種”surface”組合在一起的能力。在這裡 surface 解釋為程式想要顯示在螢幕的東西,可能同一螢幕上有來自不同程式的內容,而這些內容有可能是 2D 顯示或是 3D 顯示等等之類。Surface flinger 就是把這些東西結合起來,一起送到螢幕上。目前程式碼還沒公布,不過 2D 跟 3D 的混合顯示一直都是問題,根本原因是我們通常告訴 3D 顯示卡的東西都是一些「我要在哪裡哪裡畫上什麼形狀,貼上某某材質然後旋轉多少度」之類的事情,也就是說,我們並不知道最後顯示出來會長什麼樣子,那是顯示卡上頭的 GPU 去算出來的。一般這些東西是顯示在一個有裝飾的視窗裡頭,這裝飾通常是 2D 效果。接下來假定我們想要旋轉這整個視窗,而且裡頭的東西還要繼續動,那等於要隨時把握 3D 視窗裡的東西長什麼樣子,然後把它跟 2D 的視窗框框結合,然後再開始轉動。目前在一般 GNU/Linux 上這件事情還沒有處理的非常好,Android 怎麼做,值得在程式碼公布之後注意。
  4. 硬體抽象層 (Hardware Abstraction Libraries):這就是前文所述的 userspace 驅動程式,如果想要將 Android 在某硬體平台上執行,基本上完成這些驅動程式就行了。其內定義了 Android 對各硬體裝置例如顯示晶片、聲音、數位相機、GPS、GSM 等等的需求。

Android Runtime 前文已有涉及,這裡不再重複。另外藍色部分的 “Application Framework” 主要是跟如何在 Android 上寫程式有關係,之後將另文介紹。

資料來源:http://mmdays.com/2008/10/11/android-%e6%b7%ba%e6%8e%a2%e4%ba%8c%ef%bc%9a%e7%b3%bb%e7%b5%b1%e6%9e%b6%e6%a7%8b/

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

Java

Android 所採用的語言是 Java,先從這開始談起。一般所謂 Java 其實包含三個元素,其一是 Java 這個「電腦語言」,也就是像這樣的東西:

class HelloWorld
{
    public static void main(String [] argv)
    {
        System.out.println("Hello, world!");
    }
}

也就是用人比較容易看懂的語言(也許不那麼容易啦,但至少比一堆 0 跟 1 來得好)來叫電腦做事,比如上個例子是在螢幕上印一行字 Hello, world。我們還會需要一個「編譯器」,來把這語言從人看得懂的,翻譯成電腦看得懂的。容後再論。

第二個元素是「Java 虛擬機器」(後稱JVM, Java virtual machine)。電腦的核心 CPU 是有很多不同種類的。一般我們用的是 Intel 的產品,有些是 32 位元、有些是 64 位元。有些人用的可能是 Power,例如部分蘋果電腦的使用者。還有一些小一點的電腦,可能就是用 ARM 架構。總之,不同的 CPU 使用方法也不同,指令是不能直接互通的。虛擬機器就是設定一些共通的指令,然後針對各種不同的架構各寫一個程式去配合這套指令。如此一來,我們只需要把程式編譯成「虛擬機器」看得懂的就行了。Java 使用的共通指令就稱做 “Java bytecode”。

其三是 Java runtime library,也就是一個「函式庫」,裡頭存了很多編譯好的現成程式,來讓開發者使用,這樣就可省下很多重覆的工作。比如上頭這例子裡頭的 System.out.println 就是函式庫提供的。那我們可以想像,如果在程式中我們用了很多某個函式庫裡頭的東西,但是用的人只拿到編譯好的程式,但沒有同樣的函式庫,那這程式還是不能用。比如說,Windows, Linux提供的基本函式庫就很不一樣,所以做同樣事情的程式,寫法可能完全不同。Java 函式庫裡頭提供的工具,是有標準可循的,所以以上的程式,不管是要在 Windows 上頭跑,或是 Linux 上頭跑,都是一樣的寫法。

二跟三兩者加起來,合稱 “Java Runtime Environment”, JRE. 它可以讓編譯好的 Java 程式「跨平台」。怎麼說呢?我們用 Java 這個語言寫程式,呼叫 Java 函式庫裡頭的工具,最後用編譯器編成共通的指令集,交給虛擬機器去執行。如此一來,同樣的程式在各個地方都能跑了。這雖然聽起來很棒,但我們可以想像,由於隔了一層虛擬機器跟函式庫,一定會比直接下命令來得慢,而且也要有人針對某作業系統跟某 CPU 架構去寫了這套東西,大家才能用。另外一個想法就是,那為何不直接把程式碼公開,讓大家針對不同的情況去處理,這樣就不需要虛擬機器,速度也一樣快,不就兩全其美了嗎?自由軟體走的就是這樣的路子。

問題是,許多公司不想公布自己的程式碼,因為必須要靠它賺錢。Java 讓他們可以不公布程式碼,只發行編譯好的程式,就在各平台上執行。使用者只需要安裝虛擬機器跟函式庫就行了。我們可以說,Java 是適合商業應用的。這點是很重要的一個特性。

以上的觀念大概瞭解了以後,我們看看 Android 在這部分做了什麼。

一、語言部分

Android 使用的 Java 語言並沒有不同,原本熟悉的工程師仍可以繼續使用。

二、虛擬機器

Android 使用的虛擬機器叫作 Dalvik,原本並不是針對 Java 設計的。它認識的指令集並不是 Java bytecode,而叫 Dalvik executable,簡稱 dex。Android 裡頭提供了一個工具程式叫 dx,可以把 Java bytecode 再翻譯成 dex,這樣 Dalvik 就知道怎麼執行它了。這虛擬機器為了適合在電話這種比較小型的平台上使用,而做了許多最佳化的處理,例如減低記憶體的使用,而且可以有效率的同時執行好幾個程式。它仰賴底層的 Linux 作業系統來幫他處理一些事情,意味著目前 Dalvik 是綁在 Linux 上的

三、函式庫

Android 提供了大部分的標準 Java 函式庫(來自於Apache Harmony),並把他們轉換成 dex 的格式,如此 Dalvik 才認得。除此之外,還提供了很多獨有的函式,讓使用者可以直接呼叫來使用電話、GPS等元件,或者是一些視覺的元件來取得跟其他 Android 程式相同的外觀。

Android 虛擬機器與函式庫合稱 Android Runtime。它有幾個特性:

  • 不能直接執行編譯好的 Java 程式。要轉換成 dex 檔案後才能執行。
  • 若此程式使用了 Android 未提供的函式,仍不能執行。
  • 若我們拿到了 Android 應用程式,無法在 Java Runtime 上跑起來。原因為 1. 必須把 dex 轉回 Java bytecode,這難度目前不明。2. 沒有 Android 提供的獨有函式。

仔細思考的話,會發現所謂 Android Runtime 跟 Java Runtime (尤其是 Sun所提供的套件)的不同處很多,只是「剛好」Android 提供了很多 Java 函式庫裡的功能,讓 Java 工程師可以無痛的轉換罷了。另外就是他仍然保持了對商業應用的親和性,只要發行編譯好的 dex 檔案,而不需公布程式碼。

資料來源:http://mmdays.com/2008/09/29/android-%e6%b7%ba%e6%8e%a2%e4%b8%80/

香醇咖啡 發表在 痞客邦 PIXNET 留言(1) 人氣()

由於先前整理eSATA的傳輸速度,所以也一併閱讀了SATA相關技術資料,故整理成篇以便查閱。

SATASerial ATA(Serial Advanced Technology Attachment)的縮寫,亦稱串行ATA。它是一種電腦總線,主要功能是用作主機板和大量儲存裝置(如硬碟光盤驅動器)之間的數據傳輸之用。

SATA是一種可足以完全取代舊式PATA(Parallel ATA)的新型硬盤接口,因採用串行方式傳輸數據而得名。在數據傳輸上這一方面,SATA的速度比以往更加快捷,並支持熱插拔,使電腦運作時可以插上或拔除硬件。另一方面,SATA總線使用了嵌入式時脈訊號,具備了比以往更強的糾錯能力,能對傳輸指令(不僅是數據)進行檢查,如果發現錯誤會自動矯正,提高了數據傳輸的可靠性。不過,SATA和以往最明顯的分別,是用上了較幼的排線,有利機箱內部的空氣流通,某程度上增加了整個平台的穩定性。

現時,SATA分別有SATA 1.5Gbit/sSATA 3Gbit/s即將推出的SATA 6Gbit/s三種規格。

排線和電源線

SATA排線

傳統的 Parallel ATA 使用 單模信號放大系統「single-end-signal-amplified-system」。在這種系統中,雜訊會隨著正常信號一起傳輸、放大,不易被抑制;在高速時尤其嚴重,為了有效的減少雜訊的干擾,我們只好使用高達5V的電壓來傳送正-常訊號,使大電壓的正常訊號蓋過小電壓的雜訊信號。雖然大的電壓可以有效的抑制雜訊,但是大的電壓同時也表示驅動電路的生產成本將因此上升,大電壓更不利於高速傳輸系統的設計和製造,高達5V的傳輸電壓限制了追求高速和低成本的可能性。

和 Parallel ATA 相比,新的SATA 使用了差動信號系統「differential-signal-amplified-system」。這種系統能有效的將雜訊從正常訊號中濾除,良好的雜訊濾除能力使得SATA只要使用低電壓操作即可,和 Parallel ATA 高達5V的傳輸電壓相比,SATA 只要0.5V(500mv) 的峰對峰值電壓即可操作於更高的速度之上。「比較正確的說法是:峰對峰值『差模電壓』」。

和 Parallel ATA 的 5V 驅動電壓相比,0.5V的SATA系統節省電力,其驅動IC的生產成本也較為便宜。

SATA支援進階主機控制器介面(AHCI)功能,可讓SATA儲存裝置啟用進階SATA功能,例如NCQ熱插拔

SATA 1.5Gb/s為第一代SATA介面,坊間的非官方名稱為SATA-1[1],傳輸速度為1.5Gbit/s。

SATA 3Gb/s2004年正式推出,坊間的非官方名稱為SATA-2[1],符合ATA-7規範,傳輸速度可達3.0Gbit/s。這顯示SATA的速度提升是以幾何級數增長,這點和PATA的一級級算術級數增長是不同的。

SATA 3Gb/s比SATA 1.5Gb/s進步的地方在於:

  1. 3.0Gb/s的高傳輸速度;
  2. 支持真正的SATA指令排序(NCQ);
  3. SATA 3Gb/s資料線長度最多2m。SATA 1.5Gb/s只是1m,PATA更短到50cm;
  4. 全新的圍擋式接口更穩固。

SATA 6Gb/s2009年9月推出,傳輸速度達到6.0Gb/s。

eSATA是External Serial ATA的略稱,是為面向外接驅動器而制定的Serial ATA 1.0a的擴展規格。雖然規模比較小,但已經有相對應的產品在市面流通。

  • 為了防止誤接,eSATA的接口形狀與SATA的接口形狀是不一樣的。
  • 連接線的最大長度為2m。
  • 支持熱插拔。
  • 傳輸速度可以達到現在主流的USB2.0的傳輸速度的2倍以上。
  • 提高接頭的插拔耐用度

eSATA與其他規格的比較

名稱  ↓ 理論頻寬 (Mbit/s)  ↓ 實際速度 (MB/s)  ↓ 接線最大長度 (m)  ↓ 電源供應  ↓ 每頻道最多可接設備  ↓
eSATA 3000 300 2 with eSATA HBA (1 with passive adapter) [2] 1(15 with port multiplier
串列SCSI 3000 375 8 4
SATA 3.0Gb/s 3000 300 2 1(15 with port multiplier
SATA 1.5Gb/s 1500 150 1 1 per line
PATA 133 1064 133 0.46(18 英寸 2
FireWire 3200 3144 393 100; alternate cables available for 100 m+ 15 W, 12–25 V 63 (with hub)
FireWire 800 786 98.25 100[3] 15 W, 12–25 V 63 (with hub)
FireWire 400 393 49.13 4.5[3][4] 15 W, 12–25 V 63 (with hub)
USB 2.0 480 60 5[5] 2.5 W, 5 V 127 (with hub)
Ultra-320 SCSI 2560 320 12 15 (plus the HBA)
Fibre Channel
透過銅線
4000 400 12 126
(16777216 with switches
Fibre Channel
透過光纖
10520 2000 2–50000 126
(16777216 with switches
Infiniband
12X Quad-rate
120000 12000 5 (銅線)[6][7]

<10000 (光纖)

1 with Point to point
Many with switched fabric

 

 

 

AHCI(Advanced Host Controller Interface 進階主機控制器介面),是一種允許軟體與SATA儲存裝置溝通的硬體機制,可讓SATA儲存裝置啟用進階SATA功能,例如原生指令佇列(NCQ, Native Command Queuing)及熱插拔。AHCI詳細定義了一個記憶體架構規範給予硬體製造商,規範如何在系統記憶體與SATA儲存裝置間傳輸資料,目前(2008年6月)最新AHCI規範為1.3版。

許多SATA裝置控制器可個別啟用AHCI功能或與RAID功能合併使用,英特爾就建議如果在其支援AHCI晶片組上使用RAID功能,採取AHCI模式組建RAID可以獲得最大彈性,因為AHCI可在完成安裝的作業系統中切換RAID組建模式。

在一般硬碟上Fujitsu、HITACHI、Seagate、WD...等均在3.5英吋及2.5英吋提供相關支援技術

在固態硬碟方面目前僅英特爾控制晶片支援AHCI功能(並無單一販售)。


Windows Vista核心已完全支援AHCI,Linux系統核心2.6.19版起支援,其他較舊作業系統則需要相關硬體製造商提供驅動程式才可以支援。

原生指令排序(Native Command Queuing,簡稱NCQ),原先是改善伺服器硬碟存取控制技術,應用在[[SCSI介面][SATA1.0/2.0/3.0介面]][SAS介面] 硬碟讀寫的加速技術,其介面開啟磁碟陣列RAID亦有所提升。透過硬碟韌體、硬碟控制器以及作業系統三者的互相配合,改善硬碟內部磁區的讀取順序,可以提高硬碟效能約30%,亦能夠輕微減輕硬碟損耗的速率。NCQ對用於伺服器上的硬碟的效率提昇尤為明顯。

本圖闡述一顆硬碟在沒有NCQ及有了NCQ的存取順序分別。兩顆硬碟所要求的內容順序均為1、2、3、4,但NCQ硬碟可以透過改變讀寫次序而增加效率。
 

原理

一般硬碟使用的硬碟格式通常為Windows 98核心所使用的FAT32系列,或是Windows NT所使用的NTFS,此種硬碟格式在存取資料時,時常會出現散亂的情況,導致一個檔案被不規則的分散成許多的區塊存放於磁盤上面,時間一久,檔案散亂的程度會日趨嚴重,由於傳統的硬碟讀取方式,會從檔案的開頭依序讀取到結尾,若檔案散亂的程度愈嚴重,則讀取頭需要來回移動的距離就越長,導致硬碟讀寫效能逐漸下降。一旦發生這樣的問題,解決方案便是使用磁碟重組軟體來進行硬碟重組,將散亂的檔案重新排列為連續的區塊,但由於執行磁碟重組可能會需要搬動大量的磁碟區塊,如果太常執行磁碟重組,除了會提高系統負載,亦將會縮短磁碟機的使用壽命,NCQ即為了解決此種情況而誕生。 NCQ的概念原本是應用在伺服器上常見的SCSI介面上,在SCSI的規格中即包含此項技術,只是不叫做NCQ,將此項技術經過些許修改後稱為NCQ,並將其應用在SATA介面上,後來的SAS介面也支援此項技術。 啟用NCQ技術的硬碟,在讀取檔案時,會依照檔案在硬碟上的分佈,將存取的順序作最有效率的排序,以減少機械臂移動的距離,進而達到省時以及延長硬碟壽命的效果。

優勢

於 SATA II NCQ 協定中,新增3個功能,分別是:

  • Race-free status return mechanism:
    硬碟在完成任一指令後,可以無須再進行Handshake即可繼續另一個指令,以便讓多個指令快速接序或同時執行。
  • Interrupt aggregation:
    硬碟由於以NCQ模式執行多個指令,所以原本每一個指令完成後必須中斷(interrupt) 以便讓系統接續處理的模式,轉成可以在多個指令完成後再一次提出(interrupt) ,故介面控制器(host controller) 對於多個指令只須處理一次中斷即可。
  • First party DMA(FPDMA):
    硬碟完成資料讀取後,無須靠 host controller 的DMA動作取得特定記憶體位置,而是由硬碟本身建立 DMA setup FIS(Frame Information Block)直接對 host controller 送出記憶體存取通知,如此無須驅動程式的運作,可以有效提升存取效率。

條件

開啟NCQ,除硬碟本身必須支援NCQ外,作業系統(OS) 與介面控制器(controller) 的支援也是不可或缺的條件。舉例說,在Microsoft Windows平台上,從Windows Vista開始才支援NCQ,而Windows XP若要使用NCQ,則要額外安裝支援軟件。

支援NCQ技術的晶片組

支援NCQ的硬碟控制器(部分):

  • JMicron
    • JMB360
    • JMB361
    • JMB362
    • JMB363
    • JMB365
    • JMB366
  • nVIDIA
    • nForce 4 Ultra, nForce 4 SLI
    • nForce 410
    • nForce 430
    • nForce 550
    • nForce 570 Ultra, nForce 570 SLI
    • nForce 590 SLI
    • nForce 650i Ultra, nForce 650i SLI
    • nForce 680i SLI
    • nForce 780i SLI
  • Intel [1]
    • ICH6M, ICH6R
    • ICH7DH, ICH7M, ICH7MDH, ICH7R
    • ICH8DH, ICH8DO, ICH8M, ICH8M-E, ICH8R
    • ICH9DO, ICH9M, ICH9M-E, ICH9R
    • ICH10D, ICH10DO, ICH10R
  • VIA
    • VT 8237S
    • VT 8251
  • ATI
    • SB 600
    • SB 700
    • SB 750
  • ALiULi
    • M1573
    • M1575
    • M1567
    • M1697
  • SiS
    • SiS966/SiS966L
    • SiS968

資料來源:http://zh.wikipedia.org/wiki/SATA

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

滾輪老古董 LED光學不夠看 雷射光學最新穎
     電腦在日常生活中扮演的角色,從過去單純的文書處理、程式運算,到今天的影音視訊、電玩娛樂,功能越來越多樣化,而擔負起控制介面重任的滑鼠鍵盤,也隨著電腦任務的不同而逐漸進化,感應技術從傳統的滾輪、LED光學,進步到今日最新的雷射光學,操控性也從單純的游標控制,逐漸延伸到畫面縮放、指紋辨識等附加效果,讓電腦使用者一根指頭就能掌控一切。


感應技術邁向雷射新標竿
     感應技術一直是無線滑鼠進化的指標規格,目的是讓使用者能有更精確的游標定位,而且能夠在各種表面上工作,過去無線滑鼠採用的大多是LED光學照明技術,感應原理是利用物體表面粗糙度產生的陰影來辨識,因此在瓷磚、金屬等光滑表面操作時會相當不順暢,目前最新的滑鼠感應技術為雷射光學,讓游標定位更靈敏也更精確。雷射光學的感應原理,是透過雷射光速直接反射出表面的細節,無需利用陰影來辨識,據說可提供比傳統LED光學滑鼠強20倍的表面追蹤能力,因此傳統光學滑鼠無法正常感應的大理石、瓷磚、金屬、漆面木桌、相片紙、毛玻璃等光滑的表面,雷射滑鼠也能夠精確的將位移資訊傳給電腦。如何得知雷射光學滑鼠的感應能力有多強?從技術層面來看,計算滑鼠跟電腦間的訊號傳送速率(report rate)單位為rps(report per second),也就是每秒滑鼠傳送給電腦的位移訊號數,rps越高,代表電腦游標與手中滑鼠動作的一致性越高,一般USB有線滑鼠通常是125rps,傳統無線滑鼠為50rps。雷射感應技術還有省電的好處,原因是LED光束會發散,光源會隨距離減弱,比起光束集中的雷射更耗電。

一根指頭 就能掌控一切
 除了感應技術精進外,新款滑鼠鍵盤產品也朝向更完整的操控介面發展,希望使用者能有更便利的操控性,最流行的是一種俗稱「鏡頭縮放滑動器」的滾輪,只要一根指頭就能讓畫面放大縮小,就像是相機變焦的zoom-in及zoom-out效果。這種小工具經常被用在看大型的文件、網頁或圖片,只要把按鍵往下一按,再向前或向後捲動滾輪即可放大縮小,最適合在Windows XP的影片模式下瀏覽圖片,完全不必開啟看圖軟體。另一個讓操控性更強的設計就是多樣化的快速鍵,方便快速瀏覽經常使用的網站、檔案及資料夾,也可設定為迅速切換程式的快速鍵或捲頁便捷鍵,適合瀏覽大範圍網頁或長文件使用。如果嫌這些設計的操控性還不夠強,只有靠指紋才能登錄電腦的滑鼠,真的是「一根指頭就能掌控一切」!讓一台電腦的不同使用者都必須靠自己獨一無二的指紋才能登錄,方便之處在於可以快速在同一部電腦上切換不同的使用者。

傳輸範圍更廣 攜帶性更強
 除了雷射滑鼠外,藍芽滑鼠也有新品問世,還可以「撈過界」的扮演起「藍芽無線集線器」,原因是滑鼠專用的充電器也有集線器功能,可以讓電腦成為藍芽設備的控制中心,和10公尺內支援藍芽傳輸的設備互相連線,包括掌上型電腦、行動電話、耳機麥克風、印表機等。另一個深受上班族歡迎的新款滑鼠設計,是無線滑鼠的接收器可以收納在滑鼠底部,方便攜帶及省電,是一款專為筆記型電腦使用者所設計的滑鼠,可同時適用於左手與右手的使用者,當滑鼠在未使用狀態時,接收器可以收入滑鼠底部並自動切斷電源,可快速收入公事包內不佔空間,也能節省耗電量因而延長電池壽命。

資料來源:http://www.libertytimes.com.tw/2004/new/oct/25/life/information-1.htm

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

名稱  ↓ 理論頻寬 (Mbit/s)  ↓ 實際速度 (MB/s)  ↓ 接線最大長度 (m)  ↓ 電源供應  ↓ 每頻道最多可接設備  ↓
eSATA 3000 300 2 with eSATA HBA (1 with passive adapter) [2] 1(15 with port multiplier
串列SCSI 3000 375 8 4
SATA 3.0Gb/s 3000 300 2 1(15 with port multiplier
SATA 1.5Gb/s 1500 150 1 1 per line
PATA 133 1064 133 0.46(18 英寸 2
FireWire 3200 3144 393 100; alternate cables available for 100 m+ 15 W, 12–25 V 63 (with hub)
FireWire 800 786 98.25 100[3] 15 W, 12–25 V 63 (with hub)
FireWire 400 393 49.13 4.5[3][4] 15 W, 12–25 V 63 (with hub)
USB 2.0 480 60 5[5] 2.5 W, 5 V 127 (with hub)
Ultra-320 SCSI 2560 320 12 15 (plus the HBA)
Fibre Channel
透過銅線
4000 400 12 126
(16777216 with switches
Fibre Channel
透過光纖
10520 2000 2–50000 126
(16777216 with switches
Infiniband
12X Quad-rate
120000 12000 5 (銅線)[6][7]

<10000 (光纖)

1 with Point to point
Many with switched fabric
 

香醇咖啡 發表在 痞客邦 PIXNET 留言(2) 人氣()

在人的一生當中,很多事物永遠不會過時,例如待人有禮的態度。相反地,不同的服裝風格則隨著潮流起伏,原本被視為過氣的款式,也可能在一夕間重新風靡全球。至於各種IT技術,則是有可能隨著市場需求而過時,而且一旦從舞台上離開,往往就很難東山再起。
不久前國際IT教育訓練機構Global Knowledge發佈了一個研究報告,從專業人力需求變遷的角度,指出目前正在走向過時的十大IT技術。其實要把某種曾經顯赫一時的技術評斷為「過時」,是非常困難的,畢竟所謂過時與否,應該是相對而非絕對,愈是認真比較,愈會發現它們都有繼續存在的價值與必要性。  

不過從個人競爭力與人力資源市場的角度來看,如果身為專業IT人士所引以為傲的核心技術,正好就榜上有名,那麼倒是可以考慮進修升級技能,以便為未來預作準備。接著就來逐步揭曉這個排行榜吧!  

COBOL  

這個高齡40歲的古董級程式語言,始終很難論斷。一方面到處都可以聽到專家宣稱「COBOL已死」,但是也同樣經常聽到,企業組織願意花高薪卻仍聘不到COBOL工程師來維護既有的應用程式。根據IBM的統計,目前地球上仍有70%的商業交易資料是經過COBOL應用程式的處理。  

雖然不少老字號的大型機構與商業銀行仍在使用COBOL應用程式,但是眼前的問題是,這些應用程式還能繼續堅守在COBOL平台上面多久?目前已經幾乎找不到開設COBOL課程的大學院校了。IBM也建議客戶進行「過渡」措施,並採行SOA以便將傳統應用程式移轉導入到更快更有彈性的新式IT架構。  

HTML  

有沒有搞錯,HTML也被列為過時?這當然絕非意味著網際網路即將走入歷史,而是隨著各種簡單易用的「所見即所得」網頁編輯器,建構網頁已經不再是當年那種神秘的藝術了。當然,專業的網站開發人員還是非常受歡迎,但是如果僅靠著掌握HTML碼,顯然已經完全不足。  

專業的網頁開發工程師,通常還必須通曉Java、AJAX、C++或 .Net等,過去只精研HTML為主的網頁架構師,即使將HTML運用得再怎麼出神入化,也很難繼續保有競爭力。事實上,從人力網站職缺就可以看出,「熟悉HTML」在徵才條件中已經成為不太重要的項目了。  

SNA  

自1960年代起企業廣泛引進TCP/IP及其他網際網路技術,差不多就象徵著IBM的Systems Network Architecture(系統網路架構)開始走向落幕,儘管目前SNA網路仍然被使用於許多銀行、金融業者及政府機構中,業界還是需要熟悉SAN的技術人員。  

IBM最主力的SNA設備3745/3746 Communications Controller已經停產,不過據估計業界仍有約2萬台正在持續運作中,這些支持著關鍵性應用的設備還是有維護的必要。然而在徵才市場上,需要SNA技術的職缺已經銳減,並且企業傾向找大型系統整合業者的SNA專家顧問提供短期服務。  

Siebel  

從90年代晚期到本世紀初,Siebel幾乎等於CRM(客戶關係管理)的代名詞,2002年Siebel在CRM市場的佔有率高達45%,堪稱主宰了整個市場。Siebel的創辦人Thomas Siebel原本任職於Oracle,但是始終與Oracle激烈競爭,直到2006年被這家資料庫巨人併購為止。  

雖然功能優越,但是Siebel的CRM系統複雜昂貴,而且需要技術高深的專業人員進行設定與管理,以致後來大量被如Salesforce.com等透過網路提供服務的SaaS套件取代。這也導致了擁有Siebel技術認證的專業人員,雖然目前在就業市場的薪資水準仍高,但比起以往的待遇和職缺數量都有明顯的下滑。  

RAD與Extreme Programming  

回顧1990到2000年代初期,Rapid Application Development(快速應用開發)與Extreme Programming(極限編程,簡稱XP)的開發方法論新思潮席捲軟體業界,藉由在設計過程中擁抱隨時改變的用戶需求,創造了更快更有彈性的應用系統開發方式。  

在XP方法中,開發者在專案過程中隨時接受用戶不斷改變的需求,而非企圖在最初就把所有規格都定義好。至於RAD方法則在開發過程中,互動性地運用圖形元件及其他介面的建構工具來協助定義用戶需求。這兩種技術都有效加快了應用系統開發的速度,然而自2003年以來,由於委外開發應用系統的比率持續提高,企業對這類型的人力需求也隨之明顯衰退。

ColdFusion

ColdFusion是一種曾經廣受採用的動態網頁程式設計語言,雖然支持者堅稱它具有易學易用的優點,不過就像許多獨立軟體工具曾經遭遇的命運,它很難與砸下重金行銷的大公司產品競爭。ColdFusion在1995年由Allaire公司創造,後來被Macromedia公司併購,接著Adobe又收購了Macromedia。  

目前ColdFusion已經被其他的開發平台所取代,包括Java、Ruby on Rails、Python、PHP和微軟的.Net等程式語言。關於ColdFusion是否真的無法和這些程式語言競爭的討論仍未平息,不過事實是ColdFusion開發工程師的求才起薪正在降低,相關職缺也明顯少於其他開發平台。  

Wireless Application Protocol  

沒錯,在蘋果電腦推出iPhone以前,其實人們在90年代晚期就能用手機瀏覽網頁了哦。當時內容供應商必須把網頁改寫成WAP語言格式,以便讓行動電話用戶可以透過手機瀏覽最新股價、新聞標題或電子郵件。市場對WAP的接受度一開始就很低,因為WAP網站不僅速度慢而且內容豐富度遠不及Web,此外由於全球各地的電信法規及無線技術標準的差異,也造成用戶經驗很大的落差。 目前WAP實質上已經變成MMS(多媒體簡訊服務)的功能之一,不過由於可以適應標準Web網頁的瀏覽器如Opera Mobile與iPhone的Safari等相繼問世,WAP技術會繼續走向沒落是可以肯定的。  

Visual J++  

據Foote Partners的調查,主攻這個微軟版Java語言的技術人員,去年的平均薪資相較下滑了37.5%。隨著Microsoft Visual Studio 6.0提供的Visual J++語言,堪稱命運多舛。雖然Sun Microsystems(現已被Oracle併購)把Java技術授權給微軟開發J++,但是微軟在實作自有組件時並未引入某些標準的Java官方功能。 這不僅導致了嚴重的相容性問題,更引發昇陽狀告微軟擅自更改Java版本,破壞跨平台特性違反授權合約,雙方纏訟三年多。最後結果是微軟放棄了Visual J++,改以全新的.Net平台取代。  

Novell NetWare  

在1990年代,超過七成的企業網路都使用Novell的網路作業系統NetWare,實際上也等於LAN的產業標準。後來在微軟Windows NT的行銷威力下,Novell作業系統節節敗退,雖然併購了WordPerfect打算與微軟Office決一死戰,最後還是沒有成功並在1996年把WordPerfect又賣給了Corel公司。  

原本在業界最熱門的Novell證照例如CNE(Certified Novell Engineer)、MCNE(Master Certified Novell Engineer)甚至Certified Novell Certified Directory Engineer與Novell Administrator等,如今明顯乏人問津。Foote Partners在2008年的統計指出,這些認證工程師的身價大不如前,取而代之的是Linux及Windows Server技術。  

Asynchronous Transfer Mode  

名列第一的夕陽技能,則是網管人都知道的ATM(非同步傳輸模式)。ATM技術在90年代後期非常普及,特別是在電信業者之間,用來取代已經不堪負荷的Frame Relay做為廣域網路之用。相較於Frame Relay技術,ATM更具擴張彈性且有先天的QoS能力。當年ATM還曾經被當成新一代的LAN平台架構來推廣,然而這其實正好是ATM的弱項,更適於統合語音和數據訊務的IP協定很快就佔領了區域網路領域。  

為了配合既有的ATM網路投資,電信營運商還是會繼續部署ATM網路,但是面對語音數據匯流的整合通訊趨勢,ATM勢必無法滿足對效能及流量管理持續升高的需求。  

愈來愈多的電信業者採用MPLS技術,它兼具了ATM的標籤交換以及IP的封包導向能力。可想而知,ATM技術受限於用戶數量及未來前景,在專業人力需求方面也就難以增加了。

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

路由器是用來將網路的資訊, 使用在電腦之間傳送的基本設備, 路由器的工作在於 OSI 模式第三層(網路層), 用來決定資料傳遞路徑的設備. 我們使用的IP協定就是藉由路由器將不同的IP位址連接在一起. 網路上的資料分成一段一段的封包packet, 而這些封包要指向何處便是由路由器來決定的, 路由器會根據資料的目的地, 指示正確的方向, 計算評估最便捷有效率的路徑來傳輸資料, 也就是說路由器要為封包做最佳化的工作, 找出最適當的路徑. 路由器通常最少會有兩個介面, 而這兩個介面分別區隔不同的IP網段. 例如IP分享器有WAN和LAN兩種介面, 區隔WAN的實際IP與LAN的虛擬IP網段.

何謂"OSI"模式

OSI是 "開放式系統連接" 的縮寫, 是由 "國際標準組織" (ISO)於1983年所制定, 稱為OSI/ISO. 該標準共有七層, 每一層均分別負責資料在網路中傳輸的一定步驟.OSI通訊分成七層的原因是讓用戶更方便的使用網路, 當用戶在上層作業時, 可以不必理會低層的運作.

  • 七層架構

    第七層 應用層(Application Layer)

    第六層 表達層(Presentation Layer)

    第五層 交談層(Session Layer) 第四層 運輸層(Transport Layer)

    第三層 網路層(Network Layer)

    第二層 資料連接層(Data Link Layer)

    第一層 實體層(Physical Layer)

    OSI七層架構排列

  • 實體層

    是OSI的最下層, 主要負責處理由硬體設施(如網路卡、傳輸媒介)送來的訊號, 例如依傳輸媒介電器特性轉換電壓、脈波數... 等, 此訊號單位是"Bit"(0 or 1).
  • 資料連接層

    是OSI的第二層, 它將實體層傳來的0 、 1訊號組成"資料框"的格式. 該層主要係負責資料在網路中傳遞的交通管制, 例如何時送出資料、傳送過程中如何偵錯、如何復原... 等; 該層也定義了Ethernet、ARCnet、Token Ring… 等網路.
  • 網路層

    是OSI的第三層, 主要係規劃資料在網路中最佳的傳輸路徑, IP、IPX...等網際通訊協定及在此層定義的. 在一單一網路中, 只要有"節點位址"即可將封包送達目的地; 但在一網際網路中, 除了節點位址外, 還要有"網路位址"才行, 此位址是由網路層所賦予, 因封包在網際間傳輸的路徑不只一條, 該層的另一項功能即是在各封包送達目的後再將其重新組合回原來的順序.
  • 運輸層

    是OSI的第四層, 主要係監督兩節點在建立聯繫的狀態下, 將資料安全無誤的送達目的地, 若資料在傳送過程中發生遺失、錯誤、重複等問題, 本層能立即偵測並更正.
  • 交談層

    是OSI的第五層, 主要係負責兩節點在正式通訊前的會談, 例如兩節點欲正式通訊前, 需先講好所用的通訊協定為何? 通訊模式為何(全雙供或半雙工)? 如何偵錯及復原? 兩點如何結束通訊… 等.
  • 表達層

    是OSI的第六層, 主要係負責將資料轉換成電腦或系統程式所看得懂的格式, 功能包括有字碼的轉換, 資料的壓縮與擴張(extract).
  • 應用層 是OSI的最頂層, 主要係擔任用數之應用程式與網路間的溝通介面, 使應用程式能很方便地與網路交談. 電腦廠商常將一些服務性質的應用軟體置於本層內, 例如 FTP(檔案傳輸)、TELNET(虛擬終端機)及SMTP(電子郵遞)等均是建立在本層上的.

資料來源:http://pesotaiwan.spaces.live.com/?_c11_BlogPart_BlogPart=blogentry&_c=BlogPart

香醇咖啡 發表在 痞客邦 PIXNET 留言(0) 人氣()

1 23