dbus主要產品有什麼

❶ 雷達液位監測系統的如何應用

近年來,為增強石油行業在激烈的市場競爭中調節市場和抵榔風險的能力，儲油罐的容量和數量不斷增加，已相繼出現5×10000m�0�6、10×10000m�0�6的大罐。這些大罐的出現對於液位監測提出了更高的要求。本文以庫部(庫爾勒一部善)輸油管道部善外運油庫中四座5×10000m�0�6油罐為倒，介紹其雷達液位計的應用。
目前，常用的油罐液位監測系統有：浮子式液位計、差壓式液位計、電容式液位計、超聲波液位計和雷達液位計等。都善外運油庫採用的是873型智能雷達液位監測系統，它分別安裝在四座大罐上。該儀表測量系統天線和天線單元(AU)設在罐頂．而且遠離液面不與液面接觸。控制單元(cu)設在罐外地面。通訊介面單元(CIU)和協議轉換介面(MODBUS CIU)設在控制室內。該儀表除可以測量液位外．還可通過Ptl00熱電阻測量油溫。液位、油溫就地顯示並遠傳至控制室。系統具有網路介面，可聯入管道自動化系統SCADA(Supervisory Control And Data Acquisition)，大大提高了罐區自動化和整個管道自動化水平。
2 系統基本結構
Enraf系列雷達液位計主要對液位和介質溫度監測。它採用模塊化設計，具有多種功能模塊供用戶根據自己需有選擇，如：液位數字輸出(APU)、液位模擬輸出(MPU 4～20mA)、點溫測量(TPU)、平均溫度測量(MPU)、壓力測量(OPU)等。由於雷達採用的是微波，對介質的要求比較寬泛，因此它可應用於瀝青、燃料油、原油、黑色產品、白色產品、LPG／LNG的測量。它適用於多種罐體，如固定罐、浮頂罐、壓力罐。其液位測量精度小於±1mm，解析度為0.1mm，模擬輸出±0.1％FS(可選)，溫度測量精度為±0.2℃。
外運油庫四座大罐安裝的是四台873Smart Radar智能雷達監測系統。其天線和天線單元(AU)通過法蘭連接到罐內的帶孔鋼管上。控制單元(cu)安裝在罐外地面上．它通過四線制為Au提供電源並接收AU傳回的液位信號。同時它還接收來自Ptl00的溫度信號。這兩個參數經CU轉化後．通過Enraf自己的現場匯流排傳送至CIU，又通過MODBUS的協議轉化並入SCADA系統。整個系統採用分布式設計．系統性能穩定可靠，傳輸快捷准確，實現了罐區自動化和整個管道的自動化。
873型雷達液位計的系統組件
873型雷達液位計按功能可分為三部分：測量部分(Au)，控制部分(CU)和通訊部分(CIU和MODBUS)。這三部分構成了雷達液位監測系統。雷達液位計的測量部分和控制部分均採用IP65工業現場防護等級，防爆等級為：EEx dIIB T6，工作溫度最高達+65℃ ，最低溫度達一40℃ ，工作壓力一0．048～+0.689MPa。
3．1 測量部分
天線和天線單元構成了雷達液位計的測量部分件。雷達液位計液位測量的精度完全依賴於它，它完成了雷達渡的發射和接收，通過內部固化的SEEPROM程序計算出罐位信號，並傳送到控制單元。Enraf公司採用平面天線技術PAT(Planar Antenna Technology)．它具有多個發射源，使其反射波信號純度高．提高了測量精度。
天線單元採用四線制接線，兩根為電源線(15～18Vdc)，另兩根為信號線(0～5V)。其內有兩
塊功能模板HFB(High Frequency Board)和DAB(Data Acquisition Board)。
用於液位測量的雷達披一般採用高頻(9．15—10．85GHz)電磁波。由於油罐相對來說高度不大，測量其發射波和反射波的時間差幾乎不可能。雷達液位計一改傳統的脈沖雷達(PR)，採用合成脈沖雷達波(SPR)，通過測量發射波和反射波的頻率差來計算雷達波傳輸的距離。
通過頻差校正提高了測量的穩定度和精度。
3．2 控制部分
控制單元(CU)採用了模塊化設計。它提供了一個框架，其內的模板包含基本模板和可選模板。基本模板包含電源模板(GPU)和傳輸模板(XPUII)；可選模板包含天線處理模板(APU)和測溫模板(TPU)。GPU、APU和TPU均可與其他罐的相應模板互換。XPU與罐的自身特性有關，必須在拔掉模板上的EPROM才可用其他模板替換。
控制單元對接收的液位、溫度信號調理，就地液晶顯示並遠傳至控制室。另外它提供了一個光通訊口，可用手操器(PET)就地現場調試。
3．3 通訊部分
通訊部分包括CIU和M0DBUS。這兩塊模板集成在控制室的壁櫃內，完成現場設備通訊和系統通訊任務。
CIU有3對現場匯流排，每對現場匯流排可下掛10台雷達液位計，而且CIU 也可通過MODEM 擴展。整個系統具有豐富的擴展能力，可滿足用戶的需要，也提高了集中管理的水平。
MODBUS具有集中顯示(可顯示30台)和協議轉化(內置轉化程序BEAD CT1)的功能。安裝了相應軟體的上位機可以以RTU 的模式向現場設備請求數據。通過工業標準的MODBUS協議，整個系統具有了網路功能。在郡善外運油庫中，把雷達液位計系統通過數字橋等網路設備並入SCADA系統的Ethernet。本文轉自 http://www.yb1518.com轉載時請留此鏈接！

❷ 我想參加嵌入式實訓，北京華清遠見和上海上海尚觀哪個好些我想實訓完就地就業，或者還有哪些更好的謝

北京、上海、深圳這些大城市嵌入式就業都挺好，至於你問的這兩個機構，我覺得華清遠見各方面要更好些，華清遠見總部在北京，上海也有分中心，看LZ想在哪個城市發展了，做決定前可以自己上門咨詢一下，看看教學環境，了解一下師資方面，相信你會很快做出決定的。

❸ 如何高效的利用dbus做client-server架構

高效的利用dbus做client-server架構的方法
在嵌入式系統中使用dbus主要有兩個方面的用途：
1：進程間通信
2：實現client/server模式；
2也是1的具體表現形式；
包括dbus自帶的例子，都是採用dbus對數據的封裝，實現client/server模式的，
缺點有二：
1 一個API要定義一個xml介面描述
2 數據封裝非常復雜，非常不利於以後介面的擴展；
為了客服上面的缺點，提高可擴展性和效率，可以這樣做：
如果一個應用分為client,server兩端的話，要高效率的實現client/server之間
的通信，可以採用如下方式：
第一步：定義一個通用的API xml 介面描述，暫命令為dbus_general.xml
<?xml version="1.0" encoding="UTF-8" ?>
<node name="/org/freedesktop/DBus/General_api">
<interface name="org.freedesktop.DBus.general_api">
<method name="client_request">
<annotation name="org.freedesktop.DBus.GLib.CSymbol" value="__client_request_cb"/>
<arg type="i" name="action_id" direction="in" /> //這個地方就是不同API的ID
<arg type="i" name="input_int" direction="in" /> //這個參數可以用，也可以不用
<arg type="ay" name="input_garray" direction="in" /> //這個Garray用來從client傳遞數據，包括復雜的數據結構到server
<arg type="i" name="outut_int" direction="out" /> //這個可以用，也可以不用
<arg type="ay" name="output_garray" direction="out" /> //這個Garray用來從server側傳回數據到client側
<arg type="i" name="result" direction="out" />
</method>
</interface>
</node>
大家知道：在dbus文檔中有這么的描述，
ay | Array of bytes | DBUS_TYPE_G_BYTE_ARRAY | GArray * |g_array_free
大家都不常用位元組數組(GArray),大家常用的是integar,string等；
這個通用的模板關鍵之處就是這個Garray, Garray本身是個容器，這個
容器裡面可以裝任何東西。
我們就是利用這個GArray來實現client與server之間數據的傳遞，無論想傳遞
什麼要的數據；
第二步：用dbus的工具函數生成stub/proxy頭文件，這一步寫到Makefile腳本中，以後不用修改了；
dbus-binding-tool --mode=glib-server --prefix=your_mole_name dbus_general.xml > general_stub.h
dbus-binding-tool --mode=glib-client --prefix=your_mole_name dbus_general.xml > general_proxy.h
生成的頭文件，大家一般不要動它們，直接使用就可以了；
general_proxy.h:
.....
client_request (DBusGProxy *proxy, const gint IN_action_id, const gint IN_input_int, const GArray* IN_input_garray, gint* OUT_output_int, GArray** OUT_output_garray, gint* OUT_result, GError **error)
{
return dbus_g_proxy_call (proxy, "request", error, G_TYPE_INT, IN_action_id, G_TYPE_INT, IN_input_int, dbus_g_type_get_collection ("GArray", G_TYPE_UCHAR), IN_input_garray, G_TYPE_INVALID, G_TYPE_INT, OUT_output_int, dbus_g_type_get_collection ("GArray", G_TYPE_UCHAR), OUT_output_garray, G_TYPE_INT, OUT_result, G_TYPE_INVALID);
}
.....
general_stub.h:
.....
#include <dbus/dbus-glib.h>
static const DBusGMethodInfo dbus_glib_your_mole_name_methods[] = {
{ (GCallback) __client_request_cb, dbus_glib_marshal_your_mole_name_BOOLEAN__INT_INT_BOXED_POINTER_POINTER_POINTER_POINTER, 0 },
};
const DBusGObjectInfo dbus_glib_your_mole_name_object_info = {
0,
dbus_glib_your_mole_name_methods,
1,
"org.freedesktop.DBus.general_api/0client_request/0S/0action_id/0I/0i/0input_int/0I/0i/0input_garray/0I/0ay/0output_int/0O/0F/0N/0i/0output_garray/0O/0F/0N/0ay/0result/0O/0F/0N/0i/0/0/0",
"/0",
"/0"
};
......
第三步：實現client側，主要是直接調用general_proxy.h的介面函數client_request()，用GArray傳入你的數組（可以攜帶任何你自己定義的數據結構）
gboolean proxy_func1 (void)
{
int api_id = 0; //這個在不同的proxy_func裡面可以有不同的值，主要是區分函數作用
GArray* in_array = NULL;
GArray* out_array = NULL; //在這里不用分配內存，放在server側做內存分配

in_array = g_array_new(FALSE, FALSE, sizeof(guint8));
if (!in_array)
return FALSE;

//把你自己的數據封裝到in_array中，假設你的數據結構是your_strcut_t

your_struct_t my_own_data;

//fill my_own_data
...

//放到in_array中，這很關鍵
g_array_append_vals(in_array, my_own_data, sizeof(your_strcut_t));

//調用general_proxy.h中的dbus介面
client_request(dbus_proxy, api_id, in_array, &out_array, .....); //通過dbus把數據從到server側,server側如何處理，看第四步；

//當sever返回數據後，從out_array中取出來就可以了
your_strcut_t* g_array_data = (your_strcut_t*)out_array->data;
.....

//free
if (in_array)
g_free (in_array);

if (out_array)
g_free (out_array);

....
}
第四步：實現Server側，主要是實現general_stub.h中的函數__client_request_cb();
//這個函數的參數很長，除了第一個參數是server對象外，其餘的參數可以直接從
general_proxy.h對應的介面參數拷貝過來；應該這個函數和proxy的介面是一對！
gboolean
__client_request_cb (ServerObject *server_object, const gint IN_action_id, const gint IN_input_int, const GArray* IN_input_garray, gint* OUT_output_int, GArray** OUT_output_garray, gint* OUT_result, GError **error)
{
*OUT_output_garray = g_array_new(FALSE, FALSE, sizeof(guint8));//在client側沒有分配內存，server這里一定要分配

//卸下client側傳遞過來的數據
your_strcut_t ×p_data= (your_strcut_t *)&g_array_index(input_garray,your_strcut_t, 0);

//對卸下的數據進行處理，看你的程序做什麼功能了:)
.....
.....

//如果要傳回數據到client側，假設處理過的數據為：your_strcut_t dealed_with_data
g_array_append_vals(*output_garray, &dealed_with_data, sizeof(your_strcut_t));

return TRUE;//一定要返回TRUE,否則client側收不到數據的；

}
上述通用步驟中，1，2在今後的擴展中，是不要要改的，尤其是第一步，dbus的xml介面描述非常
麻煩；如果為每個API自己去定義xml介面描述，搞不好，client和server之間不通；而且，一段時間
後，不看dbus的文檔，就會忘記如何寫其xml介面；所以做個通用的xml介面描述很省事；
3,4是client/server側的各自實現，結構是釘死的，不用改多少；一個函數如此，N個函數也是這樣；
如果你有30個函數，要分別實現它們嗎？不必要，只要給各自的函數定義其ID就行；
在client/server側的函數裡面搞個switch-case結構就分開了；
架構定好了，傳遞數據也非常方便，比dbus自己的dbus_g_type_struct_set效率高的多，目前開源軟體
多用dbus_g_type_struct_set，效率很低，對於傳遞批量數據，效率很低；
如果大家對於如何提高dbus傳遞消息/數據的效率，有什麼更好的看法，歡迎交流。

❹ 開發人員為何應該使用 Mac OS X 兼 OS X 小史

Tinyfool 筆頭很快，當即就寫了一篇長文章， 我則筆頭很慢，今天才全部碼好。 他的文章的主要切入點在於 Mac 平台作為目標開發平台的優勢，而我這篇的切入點主要是 Mac OS 作為一種開發工具的優勢。開發人員的趁手工具 對於開發人員來說，所有的開發工具的最大的用途，就是最大限度的提高開發人員的生產率 (proctivity) 和創造力(creativity)。在我們這個時代，使用 GUI (圖形界面) 是一個提高生產率的好手段。雖然上一代的那些 UNIX 開發人員的確不需要 GUI。一個屏幕，一個鍵盤，一個編輯器，在陋巷，人不堪其憂，也不改其樂的黑客比比皆是， 但二十多年過去了， 現如今開發環境發生了巨大的變化。 比如說，相比較於當年程序員使用的基於文本的環境，在 GUI 下格式豐富的文檔顯得更直觀，閱讀體驗更加好；就算工作中不需要開發任何 GUI 程序，現代開發人員也會使用 GUI 來完成網頁圖片和文檔閱覽等等。 因此，即使是最傳統的用命令行的開發人員，其實也能沾 GUI 的光。 比如說現在最好的終端程序，都是 X 下模擬的，因為這些模擬的終端的出現，一些復雜的可視化功能可以在這些終端中實現了，比如 Unicode 的顯示(rxvt-unicode)等等。對於開發人員，擁有一組非常好用的，能夠最大程度的提高生產率的開發工具乃是一大人生夢想。那麼，這套開發工具從何而來呢？ 大體來說，這些工具來自於三個方面： 1. 通過系統和單一的應用軟體提供的；2. 通過搭配使用各種應用軟體 3. 通過定製和改變現有的應用軟體。 這三點，對於 UNIX 開發人員是再熟悉不過的了， 無非就是寫腳本，走管道而已。 所以，在前 GUI 時代，這一套哲學非常盛行， 開發人員都知道，需要通過安裝腳本解析器，寫一些的腳本，配置一些環境等等，才能把剛出廠的 UNIX 系統，改造成自己使用起來得心應手的系統。 基本上任何一個使用 UNIX/Linux 系統多年的人，機器裡面都有各種各樣的「私藏」的腳本。離開了這些腳本，他的效率會大打折扣。 GUI 時代傳統的喪失上世紀 80年代的時候，GUI 時代和個人計算機普及的時代降臨了。從此，計算機變成了個人電腦，歷史上第一次，計算機不是專為開發人員設計，而是為了普通用戶設計。普通用戶的需求就是完成一個一個的現實問題，軟體產業提供的解決辦法就是為用戶提供一個一個的應用軟體，而不是讓用戶自己一行一行的編程和寫腳本，巨大的軟體需求瞬間成就了一個巨大的軟體產業。 這樣的一個間接後果就是，對於普通用戶來說，讓一台計算機變成能夠幫助自己完成任務的「個人計算機」的唯一手段，就是疊床架屋的不斷的裝各種應用軟體。我們可以用一個簡單的例子說明這種使用模式。 我們都知道，安裝 Windows 系統的一個經驗原則是把操作系統和應用程序分成兩個邏輯盤，一個在 C 盤，一個在 D 盤。這個磁碟分區的經驗原則不光網吧老闆知道，連我大學裡面只會點滑鼠的那些女同學都知道。為什麼有這個奇妙現象呢？其實，這是由 Windows 系統的用戶的典型使用模式決定的。 在 Windows 系統上， 應用程序和文檔是關鍵，操作系統只是一個隨時可以重裝的東西而已，所以乾脆兩者分開，互不影響。在這樣的使用模式引導下，Windows 系統上格盤重裝是非常低成本的，只要文檔不丟，應用程序不丟就行。這種使用習慣，浪費了多少 geek 男美好的時光為人重裝系統，又促成了多少美妙的姻緣 :)。 總之，在 GUI 時代，要解決一個問題，就裝一個應用程序。至於應用程序之間的通信，和用非鍵盤滑鼠的方法控制應用程序等等，都不再是要考慮的問題，有這樣的需求的人成了非主流，非主流到以致於主流的操作系統和應用軟體都不讓你這么幹了。 操作系統把所有其他的路都封死，就是明擺著告訴你，要想某樣功能，請出門買軟體。Smalltalk 的啟示 其實GUI 時代原本不應該是這樣的。 我們都知道，GUI 原本是施樂的 Alan Kay 那一幫人做科研做出來的，Bill Gates 和 Steve Jobs 各自到施樂」抄襲」 了一部分過來，於是窗口啊按鈕啊就到處都是了。 他們都看到了圖形界面和面向對象的形， 看到了圖形界面就是把按鈕圖標等等對象放好，然後滑鼠點擊拖動等等這些表面的東西。 因為所有的 GUI 界面都是從文字界面起步的，所以所有的 GUI 程序，其實就是原來的可執行程序的包裝。 C++ 這個語言的出現也很討巧，把 C 包裝成了一個面向對象的語言，包裝對包裝， C++ 很討巧的適應了把可執行程序 GUI 化的趨勢， 成了 GUI 時代的主流開發語言。從表面上看，只要運行這些可執行的程序，就能夠看到圖形界面，就能夠用滑鼠點擊操作他們，可是這些東西的底層，都是一個編譯過了的可執行程序，原先 Smalltalk 中的那些運行時環境啊，對象容器啊，都統統不見了，所有的圖形界面程序，還是直接運行在計算機的 CPU 上，而不是一個虛擬的面向對象的容器上。而這個面向對象的容器（也叫做「運行時」或者「運行環境」），才是 Smalltalk 的神。 簡單的說，Smalltalk 本身具有一個面向對象的運行時，所以即使到了執行的時候，裡面所有的對象還是可以互聯互通的。 而 C++ 寫出來的程序，除了編譯之前是面向對象外，只要一編譯，就全部變成機器碼，和對象就再也沒有任何關系了，也就不存在運行時去動態的查看(inspect) 和改變(modify) 這些程序對象的說法。 總之，因為歷史的局限，這些 GUI 的平台，都是漸進的照貓畫虎的演變的，所以沒有一個平台像 Smalltalk 那樣細致地考量過對象的互相通信的問題，再加上我們上面說了，反正擴展系統的方法就是引入新的應用軟體而已，本身也沒有互聯互通的需求，所以這種拋棄運行時的，不讓對象被外部程序控制的實現方法也無所謂不好。可是開發人員不是普通用戶啊，他們依然要改造計算機成為自己的工具的。在現有的現有工具不能解決問題的時候，要不然自己重新發明輪子，要不然就復用現有的一些工具，或者重新按自己的需求重新配置這些工具。 所以，和一般用戶不一樣，開發人員需要這些 GUI 的可配置性，也需要這些 GUI 程序之間的互聯互通。 用黑話來說，第一個問題關繫到 GUI 應用程序的腳本化， 第二個問題關繫到 GUI 程序之間的進程間通信。 這兩個問題，說起來簡單，但都牽扯到 GUI 系統的根本設計問題。 歷史在這里開了一個不大不小的玩笑，把這個唯一的機會給了 Mac OS X。其他操作系統，都因為這樣那樣的原因，在這兩個問題上沒有很好的解決方案。進程間通信，蘋果的方案花開兩朵，各表一隻。我們先說 GUI 程序的進程間通訊的問題。 所謂的進程間通信 （IPC），就是兩個程序之間的信息共享。 我們都知道，*nix 的一個強大之處就在於管道，管道是最簡單，最廉價也是最常用的 *nix 進程間通信的方法。在 GUI 時代，最常用的 IPC 機製成了剪切板和滑鼠拖放操作。這兩個操作雖然都很直觀，但都要人操作，離開了人，程序根本無法自動完成進程間通信。 而要工作效率的提高，就是要讓計算機離開了人的干涉，也能完成這些任務。為了自動化這些任務，操作系統就不能簡單的繪制窗口然後萬事大吉了，它必須要知道哪些程序在運行，哪個運行的程序可以給哪個程序發消息通信等等，比如說，如果我們想自動的在閱讀器裡面選擇一個詞送給字典程序查釋義，計算機就需要知道字典程序在運行的時候可以接受一個字元串，但是不可以接受圖片。如果我們把字典程序抽象成一個可以提供「查字典」服務的對象的話，毫無疑問，如果想要向字典程序發送字元，必須首先知道字典程序能夠接受什麼，用什麼方式把這個單詞發送給字典等等。 所有的這些信息，都必須由操作系統託管才行（不可能每個應用程序裡面都要記著字典這個程序能接受字元串不能接受圖片，這樣每個應用程序都要記下所有其他可能的應用程序的信息，這是一個平方級別的關系，需要開發人員開發一個程序的時候還要兼顧其他所有程序，這顯然是不現實的）。用行話來說，必須要有一個統一管理的運行環境，來管理這些程序之間的互相通信問題。 我們上面說了，Smalltalk 的神在於一個統一的面向對象的運行時，使得所有的應用程序能互聯互通。 可是所有平台上的 GUI 程序的演化進程都沒有走這條路，而是只把外表給模仿走了；有的平台即使想做互聯互通，也做得不徹底（比如微軟的 OLE，COM 等等）。是好東西，總會發光的。 但是要想讓這個好東西被新的操作系統全盤採納，要想讓一個系統能夠從底層到上層全部採用統一的運行環境，就要扔掉很多的歷史包袱。甩掉這種歷史包袱，對於任何操作系統都是不容易的。如果我們回到當年，一定會幻想，要是有個神人，能夠不管市場也不管現有平台，從頭打造一個沒有任何歷史包袱的干凈整潔的 GUI 系統該多好。 歷史就是這么戲劇，還真就安排了一個人，做成了這件事情，這個人，就是那個斯蒂夫喬布斯。1985 年，喬布斯被蘋果掃地出門，成立了 Next 公司， 一心想要做出質量上乘的 GUI 計算機系統。 歷史給了喬布斯一個全部從頭做的機會。這一次，喬老師和 Next 的開發人員意識到，光照搬 Smalltalk 的形是不行的，要連它的神也拿過來，重頭設計進程間通信和 GUI 系統。 在內核層面，他們用了 Mach 這個為 BSD 設計的微內核。 這個操作系統內核就是為了替換已經過時的 UNIX 內核而設計的，其中的一個核心設計哲學就是重新設計進程間通信； 雖然現在基於微內核的操作系統已經不是什麼潮流（為此 Linus 和 Tanenbaum 吵了一場著名的架)，但在相比較於當時 UNIX 系統的內核（此時 Linux 還沒出現的，UNIX 內核只有 BSD， Bell, SUN 等幾套），Mach 算是一個高的起點。在這個內核上，Next 公司的工程師開始構建面向對象的基礎系統。 這套系統在 Smalltalk 中已經有了藍圖，因此這些工程師以 Smalltalk 為藍圖，先設計了一套基於 C 的語言，也就是 Objective C，照搬了 Smalltalk 的經典的 [對象 消息: 參數] 語法。 (我個人不喜歡 Objective C 這個語言，Smalltalk 是一種純面向對象的動態類型的語言，Next 公司當年完全有機會用 Smalltalk 語言的，如果用了 Smalltalk，現在的 Cocoa 框架還會更加漂亮，代碼更加干凈；用 Objective C 這個自創的語言，不知道是不是因為專利的考慮，反正 Objective C 這20年的所有創新，就是在慢慢的更像 Smalltalk 而已，Java 和 Ruby 這幾年也是不斷的從 Smalltalk 拿東西）。有了內核，有了語言，Next 構建了一個純的面向對象的運行環境和類庫（和 Java 和 .Net 的統一類庫想法類似，只不過超前了十幾年)， 這套類庫，在當時叫做 NextStep, 所以所有的類名前面都帶有 NS 前綴，無比醜陋。可惜的是，當年這個超越時代的類庫太陽春白雪了，話說 Smalltalk 超越了時代 20年，所以90 年代中期的時候， 程序員才想起來當年 Smalltalk 的好，出現了 Java Ruby 等等受�0�2 Smalltalk 啟發的語言。 喬老師雖然落後了 Smalltalk 5 年，卻領先也業界 5-10 年，所以在 1995 年的時候， Windows 95 賣瘋了， 喬老師的 NextStep 卻沒動靜，只能把這個類庫重新打包當成 Web 類庫賣賣，即 WebObjects。這倒是無心插柳，生意不錯，因為當時的 Web 開發已經吃盡了沒有一個統一的運行環境的苦頭（這也是日後 Java 風行的原因）。 我們說，是金子總要發光的，但是前提是要 (1) Next 再等幾年，等業界回過神來認識到它的好處，(2) 獲得一個主流的操作系統支持，把底層全換成喬老師的東西。 喬老師也知道這兩個條件，所以加快了和 SUN 合作的步伐，想要把這套系統放到 SUN 的工作站上。 但是 SUN 本身有很強的底層技術，那段時間又狂推 Java, 所以其實喬老師在 SUN 這條路上勝算不大，況且 SUN 自己內核技術很強，所以肯定要肢解 NextStep 把內核重寫，如果不和 SUN 玩，一來Next 這家公司能夠多撐 5 年都是問題，二來幾乎每家做個人計算機的公司都倒戈微軟了，其他做工作站的公司又都有自己很強的底層技術，不可能用喬老師的玩意兒的，所以看起來喬老師和他的陽春白雪好像前景不妙。 可是天無絕人之路，放眼看當年的市場，只有一家公司沒有倒戈微軟，又沒有很強的底層技術，又和喬老師有一些淵源，歷史就是這么戲劇，這家公司就是把喬老師掃地出門的蘋果。90年代中期蘋果的日子很不好過，個人電腦市場敗給了 Wintel 聯盟，新興的市場上成績也一塌糊塗，投資人也不糊塗，把當年讓喬老師掃地出門的 Sculley 也掃地出門了，隨後就把喬老師的公司給買了回來，讓喬老師復職負責復興蘋果。 所以，上面我們說的兩個條件就這樣突然的滿足了： 第一，他現在是老大了，所以可以徹底的把原來蘋果的系統推倒重來，用自己的新傢伙；第二，原來 Next 公司的那幫工程師不要擔心失業了，現在由蘋果負責發工資了，所以，正好可以讓這些人著手改造蘋果系統，主要的工作就是用自己帶過來的新系統取代蘋果的舊系統，並且讓新系統的圖形界面和舊系統保持風格的一致。 這個工作，從1995年 Next 被收購，到 2001 左右的時候才做好，這6年的時間里， 喬老師也順帶讓蘋果重新盈利了。2001 年發布的 Mac OS X, 是蘋果操作系統的第十代，完全基於了喬老師在 Next 開發出來的那套類庫，所以自然的，具有了一個統一的面向對象的運行時。 這個運行時和類庫系統，Mac OS X 把它叫做 Cocoa。其實 Mac OS X 剛出來的時候也不怎麼好，不過依賴於這套設計精良的底層系統，Mac OS X 的迭代開發周期要比其他操作系統短多了 （僅慢於Linux, 不過 Linux 只有內核部分). 在短短的 8 年裡，Mac OS X 就搞出了 7 次大的版本發布。 雖然我們看 Mac OS 好像從 10.0 到 10.6 只是次版本號在進步， 其實每次都是一個 major release, 大致相當於從 Window 95 到 Windows 98 或者 Windows 2000 到 Windows XP 這樣級別的升級。 這樣的發布卻不改主版本號，一方面是從市場上考慮，另一方面也的確說明 OS X 的底層已經處於一個相對穩定的狀態。 有很多 Windows 程序員非常推崇 .Net。 是的，.Net 的確是一個非常好的框架，可是想像一下，蘋果在1995年的時候就有了一個統一的運行時，加上這么多年所有的程序都在這個統一的框架上開發，如果論在 Mac OS X 這個平台上的經驗積累，應該說 Cocoa 社區是比 .Net 社區更加成熟的。應用程序腳本化光有進程間通信的系統還不能算是一個完全成熟的 GUI 系統，因為進程間通信依然是相對底層，而 GUI 上的應用軟體是層出不窮的，不可能任何問題都跑到底層用進程間通信解決；所以，要想讓 GUI 系統進化到易用和易於定製的水平，就需要開放對 GUI 程序的腳本控制。只有 GUI 程序能被外部控制了，才能真正的達到搭配使用 GUI 系統的效果。 其實，一旦有了一個統一的運行時，只要開發應用軟體的時候統一設計一下腳本介面，用腳本控制 GUI 程序應該不難。 比如說，微軟的 Office 系列套件， 就完全可以用 VBScript 去控制。 可惜的是，沒有一個系統能夠實現全系統的控制。 要實現全系統的控制，不僅僅要這個系統能夠提供底層的支持，更重要的是要能說服所有的開發人員，或者說讓所有的開發人員養成開放腳本介面的好習慣。 從技術上來說，這不是太大的問題，只要開發人員按照統一的腳本通信協議，實現特定的介面就行了，可是，如果一個平台上開發 GUI 的方法太多，開發人員只選自己喜歡的來，這種標准就不可能統一。 比如說 Linux 上 KDE 和 Gnome 都有自己的腳本化系統，可是開發人員有的用 KDE, 有的用 Gnome, 有的乾脆兩者都不用，這就談不成有一致的介面。 一個平台要想有一致的腳本控制介面，除非 (1). 這個平台上就一種 GUI 開發方法，自古華山路一條，要不不做，做出來的東西就只能是標準的介面； (2). 這個平台上大部分的，主流的應用軟體，都實現了這個腳本介面，這樣因為這些程序的拉動，其他 GUI 程序想要融入這個平台上現有的應用軟體的圈子相互通信，那也就必須要實現這個介面。 在 2000 年的時候，又只有一家公司能夠同時滿足這兩個要求，就是蘋果。 微軟部分做到地了這兩條，基本上用 VBA 統一了 Office 的控制，但是跳出 Office，微軟的 OLE 對象模型幾乎沒有任何用武之地，與之捆綁密切的 VBA 自然無人問津。 不過據一些在金融行業工作的朋友說， VBA 能夠大大提高 M$ Office 的生產率。GUI 腳本化不是一夜之功，特別是我們說要做出統一的腳本介面，能兼顧各種程序的需求，這就完全不是一兩年的時間能夠搞定的，總需要很多年的技術積累和設計取捨後才能收斂到一個相對穩定成熟的系統， 而蘋果，居然很神奇在十幾年前就有這方面的經驗，蘋果再次怎麼這么幸運呢？在80 年代後期的時候，蘋果機上有一個非常超越時代的軟體，叫做 Hypercard。 這個軟體我曾經在上一代蘋果上玩過，具體的思想就是你可以存儲一張一張的「卡片」，這些卡片上面可以放置多媒體的聲音，圖像文字和其他對象，基本上就和現在網頁一回事，唯一的區別就是這些卡片都存在本機。 在沒有 Powerpoint 這類軟體之前，這個 Hypercard 的軟體可以用來做課件，做幻燈片演示等等，是個極其強大的工具。 為了讓用戶可以定製這個卡片，這個程序提供了一套非常強大的編程系統，叫做 Hypertalk。 因為這種編程語言是給普通人而不是程序員用的，所以你會感覺根本不是編程，而是寫英語。這套東西，雖然本質上也是從 Smalltalk 學來的，但是用英語語法的方法編程的確是一個全新的思路，蘋果把這個給普通人編程的語言發揚光大了，用更加貼近自然語言的方法重寫了語言和文檔，模仿 Hypertalk 系統，發布了一個跨系統的腳本控制語言，叫做 Applescript。這個語言就和自然語言沒什麼區別，比方說, 獲取窗口的大小不再是 window.getSize() 而是 get size of window顯示第 22 段的 第一個單詞不再是 print(paragraph[22].getWordByIndex[0]) 而是 print the first word of paragraph 22更狠的是，你還能用法語和日語寫。 80年代後期的時候和整個 90年代初期，蘋果基本上已經被 PC 機逼到牆角了，只剩下出版行業，設計行業等等專業的行業因為應用軟體和圖形處理能力的關系，依舊在守著蘋果機。 兩個行業的用戶都需要自動化的 GUI 控制，但是編程都不怎麼樣，於是，這些應用軟體的開發商也主動摻合加入 Applescript 旗下。 在90年代喬老師沒有加入前，蘋果自己把 Finder 全部腳本化，出版業的 QuarkXPress 和 Filemaker 也都完全腳本化，等喬老師入主蘋果後，基於 Cocoa 的新技術，蘋果一口氣在 Mac OS X 上推出了 Safari, iTunes, iPhotos 等等軟體，一股腦兒的全部腳本化了。 在別的公司都可望而不可求的歷史機遇，又是被蘋果給抓住了，一股腦兒全部塞進了 Mac OS X。這下，所有的第三方開發的工具，如 Firefox, Adium 這些，其實本來都不是蘋果開發的，也沒有太強的蘋果淵源，但是 Firefox 要讀 Safari 書簽吧，哈，那就用 Applescript 吧，所以， Firefox 也逼著腳本化了（這個在其他平台上都不存在的事情）。 Adium 也是，這個聊天軟體想要把 iTunes 正在播放的歌曲當成狀態信息，好呀, Applescript，所以，也被帶著腳本化了，而在 Linux 上的對應產品 pidgin 就沒有這么腳本化。 所以，蘋果平台已經成了一個慣性，你不想腳本化，就不帶你玩，看你還腳本化不？結語我們都知道， UNIX 時代的主要哲學是提供給開發人員一組小巧精美且可以任意搭配使用的小工具，也就是所謂的 Software Tools, 然後任由開發人員由此出發，自己搭建自己的工具，打造自己的瑞士軍刀。而開發人員所用的操作系統的目的，要不就是提供這樣的一組開發工具，要不就是為這樣的開發工具提供一個便利的平台，使得這樣的工具變為可能。如果說 UNIX 是命令行時代的一個易於改造成 「自己的操作系統」 的操作系統的話， Mac OS X 就是 GUI 時代的這樣的一個操作系統。 即使是從應用軟體的層面看， Mac OS X 的底子好，更加容易出精品軟體，所以即使僅使用應用軟體，開發人員也應當優先考慮 Mac OS X。附A: 相對正確的 Mac OS X 使用習慣0. 一定要裝 Quicksilver 或者用「服務」，否則就是把蘋果當 Windows 用。 1. 在蘋果計算機上，因為有服務和 Quicksilver 這樣的工具，90% 的程序間的拷貝粘帖都是可以避免的。 等等。 這幾年，這些系統終於開始統一管理一個面向對象的運行環境了。可是這兩個系統都是用C++ 所寫，所以免不了費很大的力氣才有了運行時信息，繞了一個大彎路，如果一開始這兩個系統就用 Smalltalk 之類的有運行時的語言編寫，至少現在應該有能和 Cocoa 抗衡的框架。第二， 這幾年 X 也認識到了在腳本化控制上面的不足，所以幾年前做桌面的 Redhat 提出了 DBus 標准。 可惜的是不是每個程序都開放了 Dbus 介面，所以和蘋果比起來，還有比較長的路要走。

❺ Ubuntu里python dbus是什麼軟體包

D-Bus是一種高級的進程間通信機制，它由freedesktop.org項目提供，使用GPL許可證發行。D-Bus最主要的用途是在Linux桌面
環境為進程提供通信，同時能將Linux桌面環境和Linux內核事件作為消息傳遞到進程。D-Bus的主要概率為匯流排，注冊後的進程可通過匯流排接收或傳
遞消息，進程也可注冊後等待內核事件響應，例如等待網路狀態的轉變或者計算機發出關機指令。目前，D-Bus已被大多數Linux發行版所採用，開發者可
使用D-Bus實現各種復雜的進程間通信任務。

而Python-dbus毫無疑問就是D-Bus的Python開發介面。
建議如果沒有相關Linux下折騰的經驗的話，不了解刪除這個包會產生的後果的話，不要嘗試卸載這個包。
當然非要作死也沒關系，注意看卸載時的依賴關系，有沒有把其他重要的包一起卸載了。

❻ 智能客房網路管理系統的網路系統

網路管理系統由兩級組成，上級網是基於乙太網的酒店內部區域網，子網是由智能客房管理伺服器和現場匯流排智能網路交換機、客房路由器以及分布於各個客房的智能控制中心主機組成的現場匯流排控制網路系統。
對於上級網使用的就是酒店的區域網，一般使用一台伺服器接入酒店的區域網，這台伺服器也稱為智能客房管理伺服器。智能客房管理伺服器與一台現場匯流排控制器相連,酒店客房的即時數據均由現場匯流排控制器搜集並傳到伺服器。在區域網內的任何一台安裝有智能客房管理系統軟體的電腦電腦均可訪問伺服器，進行相應授權的操作。一般區域網交換機等網路設備均為通用產品，智能客房所特有的網路設備有： a、WK604現場匯流排交換機
種類：普通現場匯流排交換機
匯流排類型：增強型485匯流排
扇出力：64*4=256客房
數據隔離：光電式
電源隔離：磁隔離
數據刷新率：30ms / 單元
WK604現場匯流排交換機完全按照工業現場要求設計，採用最高抗干擾等級的全隔離結果，即匯流排分支與分支全隔離、匯流排與底板全隔離，具有抵禦嚴酷的工業現場強電磁干擾的能力。匯流排協議採用增強型485，系統在完全與標准485兼容的同時卻完全克服傳統485的缺陷：匯流排不會因為某個單元的故障而鎖死、任何單元內部的干擾不會竄入匯流排從而保證系統的穩定工作。
WK604現場匯流排交換機組成的現場匯流排系統技術成熟工作穩定可靠，完全滿足酒店智能客房控制的技術要求。一般客房數量在200間以內的酒店可以選用本品。當控制單元為100時系統的數據更新周期為 3秒。
b、ZWK808智能現場匯流排交換機
種類：智能現場匯流排交換機
匯流排協議：oh-hdbus
最大扇出能力：256*8
數據隔離：光電式
電源隔離：磁隔離
數據刷新率：2.5 ms /單元
ZWK808現場匯流排交換機完全按照工業現場要求設計，採用最高抗干擾等級的全隔離結果，即匯流排分支與分支全隔離、匯流排與底板全隔離，具有抵禦嚴酷的工業現場強電磁干擾的能力。匯流排不會因為某個單元的故障而鎖死、任何單元內部的干擾不會竄入匯流排從而保證系統的穩定工作。匯流排協議採用高速oh-hdbus協議，數據刷新率達2.5 ms /單元。
ZWK808現場匯流排交換機組成的現場匯流排系統技術成熟工作穩定可靠，完全滿足酒店智能客房控制的技術要求。一般客房數量在100間以上的酒店可以選用本品。對於客房數量為500間的酒店數據更新周期為1.25秒。 現場匯流排路由器的主要用於匯流排到客房的地址分配，協議轉換、電平變換、干擾阻斷、故障隔離等作用。與亨東的一切現場匯流排產品一樣，本品採用全隔離設計匯流排與客房設備完全隔離並具有智能故障阻斷功能,保證客房設備的任何故障和干擾均不能傳遞到匯流排，不能幹擾到其他客房。同時匯流排上的任何干擾也不能傳遞到客房設備，保證系統的穩定工作。
RT 3061智能現場匯流排路由器
支持匯流排：RS422/RS485
客房端協議：RS232
數據隔離：光電式
電源隔離：磁電式
最大波特率：9600
電源電壓：DV12V
電源電流：DC100mA
RT 3062智能現場匯流排路由器
支持匯流排：CANBUS / OHHDBUS
客房端協議：RS232
數據隔離：光電式
電源隔離：磁電式
最大波特率：100K
電源電壓：DV12V
電源電流：DC100mA

❼ linux那個版本最好用

目前主流和常用的Linux版本主要有：
1、Redhat 版本5.5和6.0最新；培訓、學習、應用、知名度最高的Linux發行版本，對硬體兼容性來說也比較不錯，版本更新很快，對新硬體和新技術支持較好。
2、Debian 版本5.0和6.0最新；社區版的Linux來說是較好的，文檔和資料較多，尤其是英文的。但在國內的佔有率有一定的局限性。關鍵是上手難，但在所有的Linux發行版本中，這個版本應該說是最自由的。
3、SuSe 版本11和11.4最新；最華麗的Linux發行版，很多人都這樣說，X windows和程序應用方面做得確實不錯。尤其與Microsoft的合作關系，應該是在所有的Linux發行版本中最親密的。
4、Ubuntu 版本9和10最新；最近幾年出來的，主要指Server版本，強項就是其desktop版，應用實在太廣泛了。
5、Centos 版本5.4和6.0最新；這個發行版主要是Redhat企業版的社區版，基本上跟redhat是兼容的，相對來說局限性教少。很多人都喜歡使用。