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是兼容的，相对来说局限性教少。很多人都喜欢使用。