ubuntu 9.10下编译安装pidgin 2.5.8

刚装了ubuntu 9.04, 就推出了 ubuntu 9.10 Alpha4,
我对自己常用的软件有一种尝鲜的习惯，每次一有更新，便迫不及待的安装试用。
ubuntu下面版本升级比较容易，输入：
update-manager -d
即可看到最新发布的版本，点击即可升级，版本升级需要下载较多东西，升级时间视你的网速而定，从及时分钟到几个小时不等。
ubuntu
9.10使用最新的内核2.6.31-4，购新吧？我昨天才升级到30内核，今天升级就又更新了。
还没来得及细细体验ubuntu9.10的新特性，发现pidgin2.5.8出来了，下载源码编译安装，希望能解决我QQ的问题（我的QQ总提示QQ异常，每次都需要登陆腾讯网站更改密码，太烦了，大惊小怪，也不知道腾讯侦测QQ异常基于什么机制，反正是好处没发现，误报一大堆）
Ubuntu 9.10 Alpha 3用Empathy取代Pidgin，所以使用sudo apt-get build-dep
pidgin命令构建编译pidgin依赖环境也不行了，没办法，直接./configure吧，
提示:
configure: error:
XScreenSaver extension development headers not found.
Use --disable-screensaver if you do not need XScreenSaver extension
support,
this is required for detecting idle time by mouse and keyboard usage.
原来是缺少libxss-dev库：
可以使用sudo apt-get install libxss-dev直接安装之。
libxss-dev
的相关链接http://archive.ubuntu.com/ubuntu/pool/main/libx/libxss/libxss_1.1.2.orig.tar.gz
X11 Screen Saver extension library (development headers)
http://packages.ubuntu.com/zh-cn/hardy/libxss-dev

安装完libxss-dev后，接着./configure,又提示：
configure: error:
Startup notification development headers not found.
Use --disable-startup-notification if you do not need it.

相关错误提示所需要安装包：
gettext header:
XScreenSaver extension development headers not found.: libxss-dev
You must have libxml2 >= 2.6.0 development headers installed to build.
libxml2-dev
Startup notification development headers not found.:
libstartup-notification0-dev
GStreamer development headers not found.: libgstreamer0.10-dev
Meanwhile development headers not found.: libmeanwhile-dev
D-Bus development headers not found.: libdbus-1-dev libdbus-glib-1-dev
NetworkManager development headers not found.: network-manager-dev
Perl development headers not found.: libperl-dev
Tcl development headers not found.: tcl8.5-dev
Tk development headers not found.: tk8.4-dev
GtkSpell development headers not found.：libgtkspell-dev
avahi development headers not found.:libavahi-client-dev libavahi-glib-dev
Neither GnuTLS or NSS SSL development headers found.: libgnutls-dev
nss-updatedb

理解Jumbo Frame巨帧

常常见到交换机和网卡说明中提到支持Jumbo Frame，但我一直对以太网的Jumbo Frame（巨帧）如何使用不太理解，今日在网上找到2则现摘录下来，相信看了以后大家会有收获。
---- 这是一种厂商标准的超长帧格式，专门为千兆以太网而设计，目前还没有获得IEEE标准委员会的认可。以太网标准的最大帧长度为1518字节，而Jumbo Frame的长度各厂商有所不同，从9000字节～64000字节不等。采用Jumbo Frame能够令千兆以太网性能充分发挥，使数据传输效率提高50%～100%。在网络存储的应用环境中，Jumbo Frame更具有非同寻常的意义。
----Jumbo Frame需要在相互通讯的2个通讯端口(交换机端口或网卡端口)上同时支持，而且与以前的以太网产品不兼容，因此主要会应用于千兆主干的端口之间以及服务器端口接入到网络主干的链路。交换机把Jumbo Frame格式的数据转发向不兼容Jumbo Frame的端口时应进行帧格式的转换，即把Jumbo Frame帧格式的数据转换成标准以太网的帧格式，从而保证其正常工作。相反，从不兼容Jumbo Frame的端口向支持Jumbo Frame的端口转发数据时，交换机可以把多个标准以太网帧合并成超长Jumbo Frame帧，从而提高传输效率。 ---- 由于Jumbo Frame没有成为国际标准，目前只有部分厂商支持这种帧格式。不过随着以太网向千兆、万兆的发展，必然要诞生1种超长帧格式，因而Jumbo Frame从厂商标准转变为国际标准的可能性非常大。
---- 巨型帧 ( Jumbo Frame )面临的问题 （转载自安恒）
通常人们都认为Jumbo Frame（巨型帧）是一个相对简单的技术，应该被广泛的应用在局域网中，但是情况并非如此。
应该说Jumbo 帧在一些领域里是非常有用的，它是有意设计为加速大文件传输服务的。以太网标准定义的最大帧长度为1518字节，这样一个大的文件就需要被切碎成为若干块，放到多个以太网帧中。而每个数据块传输的时候都会引入帧头和尾的开销。倘若能够用一个大的帧完成文件的传输，则会减少很多帧的开销，提高网络的利用率和传输速率。通常人们认为，这一技术最大的应用瓶颈是在于至今没有标准化。
但是，有些人不这么看，许多人提出了超长帧的以下缺点：它们可能会成为融合网络的障碍。如果人们在网络上传送语音或其他对延迟敏感的内容，不需要有妨碍这些对延迟敏感数据的超长帧传输。有人举例说，超长帧会造成延迟，一旦一个'大家伙'在线路上传送，它会较长时间占用线路，阻止其他人使用线路，从而造成延迟。
另一位读者提到超长帧可以在一条与其他网络隔离的网络中使用，因此它们不会妨碍其他传输流。存储区域网也许就是这样的一个例子。
但是首先，使用超长帧可能不再是一种优势。来自大学的两位用户说，为了了解超长帧是否能实际提高性能，他们测试了超长帧。一位用户谈道："经过全面的测试后，我们得到的结论是：在使用现代的PC和千兆网卡时，性能提高得很少。超长帧在过去年代里的主要优势是减小高中断率对计算机的影响。但是，3-GHz CPU具有处理千兆流量的充足能力，网卡和驱动程序不再需要每一个数据包都中断一次。我们认为超长帧理论上看是一个不错的想法，但是在实际中它在千兆位时用处不大。10G以太网可能是另一个问题。
另一位用户谈道："我们发现降低性能的原因不是协议处理开销，而是CPU与网卡缓冲区之间数据移动所产生的延迟和影响。由于DMA（直接存储器存取）尺寸越大，CPU花在设置DMA和其他东西的时间就越少，时延也减少了。随着CPU速度的增加，协议处理开销就变得越来越无足轻重。我们的结论是，如果标准的商品化网卡允许超长DMA传输，你就可以获得更大的性能增益。同时，你不必修改MTU（最大传输单元）大小，打破标准。"
最后，一位来自厂商的人提到了使用巨型帧的几个缺点。首先，帧越长意味着如果丢失一帧数据，则是一次更为严重的网络事件，而重新传送丢失的数据包成为更为耗费时间的工作。其次，网络中的每种东西都必须支持超长帧，超长帧才能使用。第三，Internet连接不支持超长帧：一个长度超过Internet连接所支持长度的帧将在发送前被分段，从而大大降低了Internet连接的性能和可靠性。这导致需要每一个工作站都必须知道哪个数据包传送到本地网络，哪个数据包传送到Internet。为了检测线路上的最大数据包长度，IP执行MTU路由发现算法，但是，这不是标准化的作法，并且，由于拒绝服务攻击，许多防火墙不允许与这种算法有关的ICMP数据包通过。因此，超长帧不能在与Internet连接的网络中使用。
=====================================================
国内关于Jumbo帧的讨论并不多，国内一些有识之士，对其应用持肯定态度，但对使用方法提出建议。
Fluke公司蔡昌信先生的看法非常有意思。他对Jumbo帧的看法有两点。首先是，他认为帧大小的选择，实际上体现的是数据通信过程中对链路可靠性的一种控制。如果说链路是非常干净的并且很少出现差错，那么这条链路上可以传输非常大的帧，而不必为此付出任何系统开销。但是问题是，人们是否认为他们的链路状况足够好，信任他们的链路状况。
另一方面是，在一条链路上究竟有什么样的数据在传输。如果在一个链路上同时有实时应用的数据和对延迟并不敏感的数据在传输，那么Jumbo帧的使用，会极大地影响到实时应用（蔡先生在此用到了"kill"这个词）。他认为Jumbo帧对于一些比较纯粹的大文件传输是非常有用的，比如说SAN这样的应用。但是如果在一个多种应用混合传输的环境中，并且没有端到端的QoS策略、带宽分配设置，广泛的使用Jumbo帧是非常不理智的事情。
另一位来自厂商的朋友也表达了自己的意见，他认为如果想享用Jumbo帧所带来的好处，就需要一个能够端到端支持Jumbo帧的环境，否则的话在一些地方需要重新切帧，同样会引入更多的开销。
另一方面，支持Jumbo帧需要新的硬件，但是这同样是一个令人非常头痛的事情。这也导致了今天Jumbo帧现在仅仅在一些特殊环境使用，比如在服务器场用于数据的传输。
他个人认为，从长远的角度看Jumbo帧是有好处的，而且不仅IP存储，很多应用都会从中获益。而且，新设备中支持Jumbo帧的越来越多，端到端支持是有希望的。他特别强调要端到端使用才有意义。
另外，他还表示，在1000米的距离上，我们计算传输9K字节长的帧的时间，在高速网络上，并不像一些人担心的那样，会引入巨大的延迟。