BenQ Joybook U101W 試用報告

最近入手了 BenQ Joybook U101W 這台小東西，10吋的螢幕，普遍的1024x576的解像度，無線，藍芽，可選配3G網卡，6 Cell的電池

基本上看到的東西與其他Netbook無異。

本篇只是描術一下用了幾天後對這台Netbook的感覺。

重量與Size: 普通輕，對用習慣12吋NB和14吋NB的我，他讓我明顯學會了NB真的很細小。

螢幕：很靚，很水。1024x576會讓人很難習慣，太窄了，對常上網頁的我來說576會讓人很不方便，anyway，要用netbook可能得習慣這一點。

續航力：因為我是用3G無線手指上網，所以慣性地將藍牙和無線網卡都關掉，可能會省電一點。 N270的CPU還真的蠻省電的，由上班9點開機開到中午1點，電池剛好用完....:)

TouchPad：無奈地，TouchPad會讓我用到發瘋但又不能不用，那個該死的鍵實在有夠硬，用到姆指痛。

升級能力：對我來說是滿意的，因為我本身鍾意的Dell Mini 10 有致命缺點....RAM 1G Fixed 不能改，而其他Netbook 如 Lenovo S10 都有一條記憶體插槽可以讓用戶很簡單地換RAM。

而這台U101W還有另一個優點，但我沒做調查所以不清楚有多優。 就是他底部有一塊生口，可以讓你加裝一塊SSD硬盤進去....聽說可以此做雙系統....

總括來說，我對玩家的要求本身並不會太高，換了2G的記憶體後，整體來說我對這台U101W都很滿意，主要是因為價錢還算廉宜的關係吧。

SNMP簡介

SNMP簡介
一個網路管理系統一般要包含以下幾個元素：若干個(可能很多個)需要被管理的網路設備節點，如路由器、伺服器等設備，每個節點上都執行著一個稱為設備代理(agent)的應用進程，其實現對被管理設備的各種被管理物件的資訊如流量等的搜集和對這些被管物件的訪問的支援；?至少一個管理工作站，該管理站執行著管理平臺應用系統，實現為管理員提供對被管設備的視覺化的圖形介面，從而使管理員可以方便的進行管理；一個管理協定，用來定義設備代理和管理工作站之間管理資訊傳送的規程。其中管理協議的操作是在管理框架下進行的，管理框架定義了和安全相關的認證,授權,訪問控制和加密策略等各種安全防護框架。
在執行TCP/IP協定的互聯網環境中，管理協定標準是簡單網路管理協定(Simple Network Management Protocol,SNMP)，其定義了傳送管理資訊的協定消息格式及管理站和設備代理相互之間進行消息傳送的規程。

出於業界對網路管理協定標準化的迫切要求的驅動，IETF於1990發佈了SNMPv1的正式RFC文檔；其設計思想重點放在保證協議的簡單性、靈活性和可擴展性上，並希望把SNMP作為一個過渡性的網管協議來作為實現對互連的網路設備進行管理時遵循的標準，待OSI的網路管理協定-CMIP的開發、實現和標準化成熟和完善到可以在業界推廣之後，再用CMIP來替換SNMP。但是由於各種的原因，CMIP並沒有替代SNMP，而SNMP發展為業界的標準。

SNMP一共發展有3個主版本，分別為SNMPv1 ，SNMPv2和SNMPv3。其中SNMPv2又分為若干個子版本，其中SNMPv2c應用最為廣泛:
SNMPv1: 是第一個正式協議版本，在RFC1155-RFC1158中定義，該版本採用了基於共同體名的安全機制；
SNMPv2c: 這個版本被稱為基於共同體名的SNMPv2，使用基於共同體名的安全機制和SNMPv2p做出的協議操作方面的擴充，由RFC1901-RFC1906定義；
SNMPv3: 該協定版本採用基於用戶的安全機制，其安全機制是在SNMPv2u和SNMPv2*基礎上進行大量的評議以後進行了更新，並且對協定機的邏輯功能模組的進行了劃分而保證了良好的可擴充性，由RFC2271-RFC2275所定義。
執行SNMP管理系統的原理及SNMP協定
使用SNMP協定的網路管理系統管理結構工作一般包括：管理進程通過定時向各個設備的設備代理進程發送查詢請求消息(以輪詢方式)，來跟蹤各個設備的狀態；而當設備出現異常事件如設備冷啟動等時，設備代理進程主動向管理進程發送陷阱消息，彙報出現的異常事件。這些輪詢消息和陷阱消息的發送和接受規程及其格式定義都是由SNMP協議定義的；而被管理設備將其各種管理物件的資訊都存放在一個稱為管理資訊庫（Management Information Base）庫結構中。
其中SNMP協定是執行在UDP協定之上，它利用的是UDP協議的161/162埠。其中161埠被設備代理監聽，等待接受管理者進程發送的管理資訊查詢請求消息；162埠由管理者進程監聽等待設備代理進程發送的異常事件報告陷阱消息，如Trap。

設備的所有的需要被管理的資訊被看作一個各種被管理物件的集合，這些被管理物件由OSI定義在一個被稱作管理資訊庫(Management Information Base,MIB)的虛擬的資訊庫中。

管理物件庫MIB
MIB是一個按照層次結構組織的樹狀結構（定義方式類似於功能變數名稱系統），管理物件為定義為樹中的相應葉子節點。管理物件是按照模組的形式組織，每個物件的父節點表示該種物件屬於上層的哪一個模組。而且OSI為樹中每一層的每個節點定義唯一的一個數位標識，每層中的該數位標識從1開始遞增，這樣樹中的每個節點都可以用從根開始到目的節點的相應的標識對應的一連串的數位來表示，如1.3.6.1.2.1.1表示了MIBII中系統組子樹,而1.3.6.1.2.1.1.1.0表示系統組中的系統描述(sytem Descrption)物件。每個物件的一連串數位表示被稱為物件識別字（Object Indentifier,OID）。
相關的一組物件的集合被定義為一個MIB模組。這些模組使用OSI的抽象語法標記(Abstract Syntax Notation One，ASN.1)的一個子集寫成。該子集被定義為管理資訊結構(Management Information，SMI)。
SNMP的消息在發送和傳輸時消息是採用基本編碼規則（BER）對消息進行編碼。
SNMP基本的標準MIB庫是MIBII，具體請參考RFC 1213。
SNMP協議操作
SNMP提供有三類操作，分別為Get，Set和Trap。
Get操作實現對被管理物件所表示的管理資訊的讀操作。在SNMPv1中，GET操作具體一共有兩種形式
Get和GetNext操作： Get操作指示直接讀取操作參數指定的OID所表示的被管理物件的管理資訊值。GetNext操作指示讀取操作參數指定的OID所表示的被管理物件在MIB樹中按照字典順序的下一個被管理物件的管理資訊的值。在SNMPv2中，增加了一種GetBulk操作，其是Get和GetNext的綜合，是為了提高對被管理資訊的訪問的效率而增加的。
Set操作實現對被管理物件的管理資訊進行寫操作，其實現直接對操作參數指定的OID所表示的被管理物件對應的管理資訊的值的設置。
前面幾種消息是由管理工作站主動實現對被管理設備進行輪詢訪問時發出以得到被管理設備的各種資訊；而在被管理設備出現異常事件需要及時向管理工作站報告時，就需要Trap操作，該操作實現被管理設備向管理工作站報告設備上出現的異常事件，如網路介面出現故障或恢復工作，設備重新啟動等資訊。另外在SNMPv2中新增加了一種Inform操作來實現管理站與管理站之間的通信。
其中上述操作的消息都可以在操作參數中一次指定一個或多個管理物件OID資訊，也就是說一個消息一次可以實現對多個被管理物件的操作。
SNMPv1和SNMPv2c採用了一種簡單的基於共同體名的安全機制：
管理站和被管設備上都存儲有該充當密碼作用的共同體名；消息發送者(一般是管理者)在要發送的消息中的共同體名欄位中填入對應於接收者的共同體名，然後以明文方式在網路上發送消息，接收方(被管理設備)接收到消息以後，如果消息格式是正確的，則讀取該欄位，與自身保存的共同體名相比較，來實現對發送消息者的認證。在一些實現中，對應於每個共同體名還有一個機器位址列表，來表示只有位址在這個列表中的機器使用該共同體名發送的消息才認為是可信的。這裏的共同體名就擔任密碼的作用。同時對應於每個共同體名都有一個訪問控制許可權，可能值為讀或讀寫。只有請求的操作和使用的共同體名的許可權一致才允許進行。
詳細情況請參考RFC 1157、RFC 1902、RFC 2273、RFC 2274。

Mysql備份還原

原文摘自網路.....出處不可考

本文來自  http://forum.slime.com.tw/thread208592.html 

SQL - MySQL 資料庫的備份與還原

MySQL Server 的日常維護中最重要的一項大概就是資料庫的定時備份，而 MySQL 資料庫的備份方式有很多但一般來說大致上可概分為二種：

Binary Copy (直接複製資料庫檔案)

Dump Database (將資料庫輸出成為文字檔)

一、Binary Copy (直接複製資料庫檔案)

開門見山的說，非常不建議你這樣子做。MySQL 支援許多種不同的 Storage Engine，但並不是每一種 Storage Engine 都是 Binary Portable，意思就是說不是每一種 Storage Engine 都可以讓你把資料庫檔案直接複製到另外一台 MySQL Server，然後還可以正常運作的。MySQL 預設的 MyISAM Storage Engine 是 Binary Portable 的，因此若你的資料庫只有使用 MyISAM Storage Engine 的話，那麼你大可以直接複製資料庫檔案來進行備份（當然還必須考慮到資料的一致性，比方說複製之前先關閉 MySQL Server）。但若您有使用到 InnoDB Storage Engine，那麼你就不能這麼做，因為 InnoDB Storage Engine "不是" Binary Portable，只要 CPU 的浮點運算架構不同，複製過去的資料將無法正常運作。除此之外，你複製起來的 InnoDB 資料庫檔案(share table space)若是還原到不同版本的 MySQL Server 上，也會有很大的機率無法正常運作。除非你很肯定備份(複製)起來的資料只會使用在 "同一台 Server" 並使用 "同一個版本" 的 MySQL Server，不然請勿使用此方法進行備份。

註：

對於 MyISAM Storage Engine，每個資料庫(Database)都是一個獨立的目錄，而資料庫中的資料表則會分別以三個檔案儲存在該目錄中，這三個檔案分別是：

FRM： 儲存這個資料表的結構

MYD： Row Data，也就是你存在資料表(table)裡的資料

MYI： 此資料表的索引

但對於 InnoDB Storage Engine 來說，所有的資料庫(Database)與資料表(Table)都是儲存在同一個(或同一系列)的檔案之中，例如 /var/lib/mysql/ibdata1。

二、Dump Database (將資料庫輸出成為文字檔)

MySQL 在安裝時即有提供一系列的客戶端程式(Client Program)，這些程式其實就是各種功能不同的 Perl Scripts 的集合，其中包括有協助您操控 Server 的 mysqladmin、用來執行 SQL 指令的 mysql、轉換 binary log 用的 mysqlbinlog 等等。其中有一樣工具是專門讓您用來備份資料庫的，那就是 mysqldump。

mysqldump 的使用方式十分的簡易，其語法為：

引用:

mysqldump --lock-all-tables -u root -p 資料庫名稱 > example.sql

--lock-all-tables：進行備份時將正在備份的資料庫裡的資料表，全部鎖定以確保資料的一致性

-u root：使用 root 帳號進行備份

-p：需要輸入密碼，如果你的 root 帳號有密碼保護，而你又不加這個選項，就會直接 ACCESS DENIED

資料庫名稱：你要備份的資料庫名稱

example.sql：這個部份你想取什麼名字都行，總之這裡就是備份出來的檔案名稱

開啟備份出來的檔案看看，你會發現裡面其實是由許多 SQL 指令所組成，而這些 SQL 指令就是用來重建整個資料庫用的，因此當您還原資料庫的時候其實對 MySQL 來說，只是單純的重新執行備份檔裡面所有的 SQL 指令。由於備份出來的檔案是單純的文字檔案，因此它是 Binary Portable，你可以將它複製到任何一台 MySQL Server 上然後進行還原。

還原的方式也很簡單，只要使用以下的指令即可：

引用:

mysql -u root -p 資料庫名稱 <>

大部份論壇程式都會提供資料庫備份機制來協助您備份論壇的資料庫，但除非您無法直接掌控伺服器(例如租用虛擬主機)或是你不具有使用 SHELL 執行指令的權限，否則不建議您使用那些第三方程式所提供的功能來備份資料庫，不然您有可能會遇到備份出來的東西還原不回去的情況。