Private: 开放而且资源共享的p2p平台

据说微软在Vista中集成了p2p功能，这丝毫不奇怪，更不出人意料。2005年3月10日，微软买下了一家名叫Groove networks的公司，而这家公司的创始人Ray Ozzie则 成为了微软的CTO。Ray Ozzie何许人也，竟有如此能耐？大名鼎鼎的办公套件Lotus Notes的创始人是也。该牛人在1997年创立了Groove Networks，致力于新一代的协作办公套件的开发，而新一代协作办公套件的特点就是建立在P2P基础之上的虚拟办公环境（Virtual Office）。

P2P相对于传统C/S模式有非常多的好处，简单罗列之：

1. 健壮


2. 易于部署


3. 成本低


4. 由智能节点组成的P2P网络更适合建立起协作的应用环境，包括协同办公、在线游戏、流媒体播放等


5. P2P这种分布式的智能网络能更有效的利用带宽（大家对P2P过分占带宽资源的认识，不能说是个误解，但也只能归咎于一些P2P实现的不合理）

微软买下Groove，自然是看中P2P在Office软件中巨大应用前景，而且我相信微软对P2P的应用远不止与此，很快就会推出基于P2P的游戏软件、通讯软件和多媒体软件。近年来，国内有很多公司进入P2P领域，微软涉足这一领域对这些公司将是很大的冲击。

我在03年攒毕业论文的时候，因为“研究”应用层组播的关系，看了些P2P的论文。当时就产生了一个想法，即搭建一个开放的、资源共享的P2P平台。简单 的想法就是，底层的P2P平台完成路由、寻址、会话功能；上层可以开发各种应用，包括协同办公、网络游戏、电话会议、内容共享等等。底层平台如同现在的 TCP／IP网络一样，是开放而且共享的。

在这个框架下，不论是skype、迅雷，还是电驴、BT，还是最近流行的P2P视频软件，都共享同一个P2P的平台，而不需要自己维护邻居信息、路由信 息。而很多聊天室（这个例子是不是有点无聊），联众的在线游戏，都不再需要高性能的服务器，而是通过P2P的方式来实现。

当时花了些时间考察Sun的JXTA，发现其不过本身不过是一个大而空的框架。本人对这种框架很反感，一上来就来个蒸汽锤（还不是实物，是个图纸），其实我只是需要一个改锥来钉个螺丝钉。

后来因为种种缘故，这个想法就一直放在那（一方面也实在是因为其工作量浩大，不是我等熬夜几个月能弄出来的）。但我始终认为这件事情很有意义，而且有其历史的必然性，即使不是我来做，也会有人做，而且会很快。
我想，也许用不了三年，就会有我今天所说的这种平台出现。空口无凭，撰blog为据。

架个wiki服务器，你用哪个软件？

以前用moinmoin架过wiki服务器，它 是用python写的。这次打算找一个php的wiki软件（毕竟php用得更广泛）。和往常一样，这次又面临选择，在debian下随便一找就发现了两 个php的wiki server，一个是mediawiki，另一个是phpwiki。值得一提的是wikipedia用的就是mediawiki，光凭这一点就足以说服我 用它了。在Debian下把这俩都装上试了试，从速度、配置方便性以及外观这几个方面，第一感觉wikipedia都做得好一些。
在网上搜了一下，有一篇文章很细的比较了三种wiki server。感兴趣的可以看一下。

热核聚变还遥遥无期呀，wii便宜卖了

早上起来照例拿手机看看RSS，有篇新闻是说中国、欧盟、美国、俄国等几个大国/组织决定联合起来在法国建一座热核聚变反应堆，预计07年开工，将成为投入第二大的科技合作项目（第一大是啥？国际空间站？）。
文章最后说，如果一切顺利的话，到2040年有希望建成一座热核电站。看来想用上热核能源我还得注意点身体，多撑几年。

还有篇新闻挺鼓舞人心地，任天堂公布了他们的下一代游戏机wii在日本的发售价格，25000日元!算不上白菜价，但比PS3实惠多了。弄一个放卧室或者客厅还是蛮爽的，盛大的盒子得抓紧卖了，不然真拼不过人家啊。

一部动画片的诞生，Elephants Dream

这部10分钟长的动画片最近很热，它并不是来自梦工厂、迪斯尼，而是几位艺术家在荷兰历时7个月制作的开源动画片。
开源动画片？这是头回听说吧。在软件业开源运动如火如荼的时候，艺术家同志们也不甘示弱，用开源的软件制作了这部开源的动画片，这部动画片的音轨、动画人物等所有素材都是开放的、免费使用的（可能也存在像GPL那样对用于商业目的的限制，这个不太清楚）。
粗看了一下这部动画片，欧洲风格十足，画面和音效都挺棒，不过情节没看很明白，挺灵异的反正。我想这部片子论证了这么两种可能：
1.利用开源的工具也能制作出优良的动画片
2.动画片也可以采用集市的方式来制作。

顺带提一下制作这部动画片所用到的开源软件（来自动画片的片尾）：

1. Blender，完成了这部电影的3D建模、动画制作、渲染和合成


2. Gimp，类似photoshop的软件


3. python，优秀的脚本语言


4. twisted，如果没弄错的话，指的是python的twisted库，基于事件的网络程序框架


5. OpenEXR，一种图片格式和相关的工具，


6. KDE，两个最流行的开源桌面环境之一


7. Verse，好像是在每次登录系统的时候显示一段圣经的软件，ft！


8. Gnome，两个最流行的开源桌面环境之一


9. CinePaint，以前叫做Film Gimp，顾名思义一把就是制作电影用的Gimp:)


10. DrQueue，分布式渲染系统


11. InkScape，制作svg的软件


12. Subversion，版本管理软件

Linux需要微内核吗？

这个问题我回答不了。外面几个大佬还在为这事吵呢，其中有两个早几年就吵过一回，他们一个叫Linus，一个叫Andrew S.Tanenbaum。这两位大牛外加一位博士的文章如下，大家有兴趣的可以仔细看看：

• Tanenbaum：Can We Make Operating Systems Reliable and Secure?


• Linus的Email


• Dr. Jonathan Shapiro：Debunking Linus's Latest

泰老（Tanenbaum）在他文章的开头就强调：之所以再次挑起microkernel的事端，是因为时过境迁，系统稳定可靠正在成为超过系统性能的更重要的需求。泰老在文章中列举了4种提高系统稳定性和可靠性的技术，分别是：

• Nooks： 目前是基于Linux的改进，特点是让驱动程序运行于沙箱之中，可以防止因为驱动程序bug导致的系统崩溃，可以恢复崩溃的驱动程序。因为驱动程序的代码 量占Linux内核代码的70％左右，并且代码质量低于其他部分代码，所以如果Nooks能达到其目标，整个系统的稳定性将会有很大的提高。


• Paravirtual Machine：虚拟机（Virtual Machine）是最近比较火的技术（其实已经是非常老的技术了），相信很多人都玩过Vmware或者任天堂的模拟器，这些都算是虚拟机。虚拟机技术不光 是玩玩而已，它在降低企业的IT投入、提高稳定性和可维护性上都有重要的意义，Intel和AMD的新一代CPU中就会在指令级提供对虚拟技术的支持。 Paravirtual与一般虚拟机的不同在于，要对虚拟运行的系统做一定的修改。像UML（User mode linux）和Xen都算此类。泰老举的例子是L4，在L4上运行多个Linux系统，其中一部分专门运行驱动程序，一部分专门运行应用程序，哪个挂了都 不碍事。

按泰老所说，使用L4所带来的性能开销在3％到8％之间。这个数字跟Xen的性能相仿。

• MULTISERVER OPERATING SYSTEMS：代表系统Minix3，也就是泰老自己设计的系统，典型的微内核设计，就不多说了。


• 微 软的Singularity：来自微软的最激进的技术创新。在Singularity里，所有进程在同一个虚拟地址空间里运行，防止一个进程不适当的访问 另外一个进程的数据不是依靠硬件，而是依靠编译时的检查（这样上下文切换的开销就省掉了哦）。除了核心的部分代码由C＃，C＋＋和汇编写成外，其他部分都 是用一种被称为Sing#的类似C＃的语言编写的。另外，在Singularity好像是采用了基于contract的开发。

在泰老发表了他的文章之后，Linus也毫不客气的再次把microkernel更稳定的论调称之为“crap“，不过不等泰老出招，一位从事微内核研究开发的博士就驳斥了Linus。具体如何大家看我在前文给出的链接。
孰是孰非，还是让我来说句公道话吧，Linus是一位技术天才，泰老则是学富五车著作等身的学术泰斗。从Linus的角度来说，他可能不太希望自己的系统 被翻天覆地的修改（每个做技术的人都有这种倾向，天才也不能幸免）；而泰老当然看的更远。Linux的内核能在现有架构上支撑100年吗？显然不可能， 20年都难。总有一天，现在的Linux内核会以某种方式进入历史的回收站，而新的内核，可能已经不叫Linux了，将会建立在新的设计思路之上。
创新，永远都是一件好的事情。

Linux下清晰的中文字体

If 不想看我罗嗦 then goto HERE；

我终于在我的Linux下看到满意（基本）的中文显示了。
说来也是，用Linux这么多年（9年？），只在刚开始的时候倒腾过中文的显示，那时候上网不方便，电脑也很菜，很多技术不成熟，尝试一种方法，要先吭哧 吭哧下载半天，再吭哧吭哧编译半天，最惨的是，弄完后发现效果很差。难怪当年有人用了蓝点的中文Linux，号称流下了眼泪...
后来俺再也没在字体上多花过超过10分钟的时间。
转眼就跨了世纪，眼看第一个十年又过去一大半了，我琢磨着时代总该进步了，也该重新倒腾一下中文了。于是就在网上搜了搜。果然就有好的方法，果然就一试不爽。

HERE：
我找到的方法在这里：http://www.coolcode.cn/?p=55&pp=1。
不过我在操作时后没那么麻烦，就下载了字体解压扔到/usr/share/fonts/truetype下，然后执行fc-cache（注，在哪个目录下执行这个命令都行），然后把local.conf拷贝到/etc/fonts/下。
因为我用的是kde，运行“kcmshell fonts“把字体设成Vera sans Yuanti就OK了。

用手机看rss，免费的哦

当然，你得用联通新时空。联通新时空收email是不要钱的（这年头不要钱的东西不多，不要钱的手机服务更少），拿你的手机信箱在rssfwd.com 这样的网站上注册一下，订阅你要看的RSS。这样一旦有新贴，rssfwd.com就会转发到你的手机上了。
以后上下班路上不会无聊了，小心别累着眼睛。

说道联通，有个有名的笑话是“孙子才用联通新时空”，可气的是作者在刚刚换到新时空的时候，老手机上收到高中同学（在移动工作）的短信，就是这个笑话。 我只好不动声色的发短信告知我的新号码。

大数运算，你用哪个库？

linux下有两个常见的大数运算库，libgmp和openssl所带的BN。它们的性能如何呢？作者写了两个小程序，分别利用这两个库，使用相同的RSA密钥（2048位），对相同的数据进行加/解密操作，用time比较性能，结果如下：

用私钥加密
gmp_imp： real 0m47.169s user 0m47.143s sys 0m0.004s
bn_imp： real 0m28.140s user 0m28.122s sys 0m0.004s
用公钥加密
gmp_imp： real 0m0.182s user 0m0.168s sys 0m0.000s
bn_imp： real 0m0.131s user 0m0.112s sys 0m0.000s

基本上，在使用私钥的时候，gmp的性能是openssl所带大数运算库的性能的60％。使用公钥时，性能差别不大，但gmp仍然慢于bn。
该测试是在debian unstable上完成的。

实战valgrind来优化程序

前一阵子写了一个gzip的解压程序，因为是用在嵌入式环境，而且是用于demo的目的，所以就一味的压缩空间，没有太多考虑优化性能。最终实现的程序目标代码8K左右，解压一个2M的gzip文件，我的程序myzip和系统自带的zcat性能如下：

myzip： real 0m0.439s user 0m0.408s sys 0m0.008s

zcat： real 0m0.195s user 0m0.148s sys 0m0.028s

myzip的性能瓶颈一个是读取bit流的函数，另一个是huffman解码。出于节省空间的考虑，huffman树的设计相当紧凑，解码性能的优化空间不大，于是想对第一个瓶颈做点工作。在优化开始之前，先用valgrind侦察一下敌情。

首先把程序用-g参数重新编译。然后先看看程序有没有什么bug，按如下方式运行：

$valgrind --tool=memcheck ./myzip file.gz

运行结束时，valgrind打印如下信息（stripped）：

==5111== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)

==5111== malloc/free: in use at exit: 0 bytes in 0 blocks.

==5111== malloc/free: 537 allocs, 537 frees, 239,144 bytes allocated.

恩，看来内存操作方面没啥问题，那接着profile一下：

$valgrind --tool=cachegrind ./myzip file.gz

运行完毕后，valgrind打印出程序运行的一些统计信息，并在当前目录生成一个文件cachegrind.out.xxxx。（xxxx是4个“随机"数字）。虽然这个文件是human readable的，但是有更好的工具来看 －kcachegrind。

用kcachegrind打开这个文件，窗口显示如下：



果不其然，读取bit流的函数get_bits占用了66.37%的cycles，huffman解码函数get_code占用了14.75%。那下面就拿get_bits开刀。

$%#^*&^*&，搞定。

再profile一下，kcachegrind的截图如下：



get_bits的比例下降到45.78%，get_code上升到22.64%。

再用-O3编译的程序解压上面的压缩文件结果如下：

real 0m0.361s user 0m0.340s sys 0m0.004s

总结：

本文的情况是作者非常了解程序的瓶颈，在大部分情况下，这种信息并不明显（特别是如果程序不是自己写的）。通过valgrind的cachegrind功 能，可以直观的得到这些信息。这些定量的信息，对于优化程序很有帮助。即使是对于本文所列的情况，作者知道这两个瓶颈，但要分析出这两个瓶颈哪个更堵，以 及优化后可能达到的最佳效果，valgrind提供的信息仍然很有价值。

mono，kaffe和Novell

今早看rss feed，有下面几则新闻值得关注。
Miguel De Icaza访谈＠osnews
此人是gnome的创始人，也是mono的创始人。作为微软.net技术的开源实现，mono很有希望获得更广泛的使用（比如Fedora Core5中加入了mono）。这篇访谈透露了一些mono的开发进展，比如定于4月发布beta1的mono1.2将提供Windows Forms的完整实现。
Kaffe1.1.7的性能评测
kaffe是一个开源的java虚拟机（jvm），开源世界一直试图实现一整套java开发运行环境。
对Novell的分析
Novell放弃Netware，彻底的转向了Linux。最近频频看到有关Novell、SLED10的新闻。SLED10（Suse Linux Enterprise Desktop）是Novell进军企业级桌面系统的武器。当然Novell决不是个一般的Linux公司，作为一个曾经辉煌过的大公司，Novell拥 有很多杀手级的企业应用软件，有大量在Netware时代积累下的用户关系。微软声称Novell转向Linux使得大量Netware用户转向 Windows，而Novell最近声称Vista的延期是SLED的机会。
顺便提一句，Miguel De Icaza受雇于Novell，Novell对mono的支持力度很大，所以微软和Novell的竞争可以说是相当直接。

让自己的驱动支持udev

从linux内核2.6的某个版本之后，devfs不复存在，udev成为devfs的替代。相比devfs，udev有很多优势，在此就不罗嗦了，提醒一点，udev是应用层的东东，不要试图在内核的配置选项里找到它;)
加入对udev的支持很简单，以作者所写的一个字符设备驱动为例，在驱动初始化的代码里调用class_create为该设备创建一个class，再为每个设备调用class_device_create创建对应的设备。大致用法如下：

struct class *myclass = class_create(THIS_MODULE, "my_device_driver");
class_device_create(myclass, NULL, MKDEV(major_num, 0), NULL, "my_device");

这样的module被加载时，udev daemon就会自动在/dev下创建my_device设备文件。

pc上最快的发包工具？

昨天做了个实验，测试了三种发包方式所能达到的最快速度。测试平台是一台双至强、1G内存的服务器，操作系统为Linux，内核版本2.6.15.3，网卡为Intel e1000光口网卡。使用一台smartbit来记录发包速度。
所使用的三种方法分别是：
tcpreplay：常用的发包软件，可以重发tcpdump所捕获的报文。
pktgen：linux内核自带的发包工具。
修改的e1000驱动：在驱动里直接写网卡的发送缓冲区
下面是测试结果：

	tcpreplay ，64字节报文	pkggen，64字节报文	e1000，64字节报文	tcpreplay，512字节报文	pktgen，512字节报文	e1000，512字节报文
pps	298725	600000	610000	232382	234091	234000
Mbps	146	266	270	908	857	850

说明一下，统计数据的值不算精确，因为只花了半个小时时间测了一下，但是拿来参考还是有说服力的。
可以看出，当发送小包时，tcpreplay的性能较差。发送大包时，三者性能接近。
有点出乎意料的是，通过e1000驱动发包，在64字节小包的时候也只达到不到300Mbps的速度。驱动修改的方式是在预先设置好e1000的4096个发送缓冲区，通过在中断处理函数里设置e1000的发送首尾指针来发包，相信这种方式是软件所能做到的最快的方式了。
如果继续深入测试，可以通过调整控制e1000中断产生的几个参数看能不能达到更高的吞吐率。但也可能e1000发包的上限就是这样了。

在ps3上跑linux…

今天看到的好消息，SONY已确认PS3将推迟发布，硬盘将成为PS3的标配，并且预装Linux。
我看不管是盛大的盒子，还是微软的Media Center，都不如这招狠，强劲的主机加上无限生命力的软件，套用一句广告，真是“nothing is impossible"。
不过我现在最想用我的手柄控制我的电脑（Linux系统），完成上网看新闻之类的简单工作。

GTK＋编程FAQ之一

开场白：

GTK＋是非常流行的GUI库，可以运行在Windows， XWindow（各种Unix环境），Framebuffer（各种嵌入式设备）和MacOS之上。很长时间以来，我用GTK＋写一些简单的程序，所用语 言一般是c++或python，但我一直没有系统的看过GTK＋的文档，所以有时候想实现一些功能却不知如何做。相信很多使用GTK＋的朋友也遇到过类似 的情况，当然这些问题大多并不难，如果细细找一下文档，一般都能很快找到答案。
从本文开始，我将记录这些问题，希望能节省各位的时间，对各位有所帮助。

问题1：我想用GTK＋，但是我不喜欢用C来写GUI程序，没有别的选择吗？

GTK＋有很多语言的binding，除了使用各种脚本语言外，你还可以使用它的C++ Binding，gtkmm。实际上本文作者也非常讨厌用c来写gtk+程序，强烈推荐使用gtkmm。

问题2：如何提高编译的速度，特别是在使用gtkmm的时候？

这个问题并不局限于gtk+的开发，很多人抱怨gcc的编译速度，实际上使用预编译头文件可以大大提高编译速度。见作者《使用预编译头文件大大提高g++编译速度》一文。

问题3:没有可视化的界面设计工具吗？

glade是gtk＋的可视化界面设计工具，它生成的glade文件是界面信息的xml描述。程序通过glade库加载xml文件就能声称界面。

问题4：如何产生异形的窗口（非矩形窗口）？

使用gtk_widget_shape_combine_mask函数来指定一个widget要显示的区域。
区域是由一个GdkBitmap定义，可以用gimp绘制你所需的形状，存成xdm图形文件，然后直接在源程序里include该文件，用gdk_bitmap_create_from_data来生成对应的GdkBitmap。

问题5：如何在系统托盘里放置图标？

问题6：如何设置主题？

问题7：如何使窗口没有title bar，不出现在任务栏里？

在XWindow下，窗口的title bar（包括最大化最小化按钮等等）是由窗口管理器（window manger，wm）负责绘制的。如果你不想让wm多管闲事，可以使用gtk_window_set_decorated（false）来通知wm。
同样，使用gtk_window_set_skip_taskbar_hint（false），你的窗口就不会出现在任务栏里了。
你也可以在使用glade创建界面文件的时候指定窗口的这些属性。

问题8:如何使用Gtk on framebuf

即将发布的2.10版gtk+带有对framebuf的支持（此前的版本需要额外的补丁）。
Debian SID的用户可以直接安装libgtk+2.0-directfb-dev这个包。

Linux下如何把IO空间映射到用户进程空间？

其实是个蛮简单的问题。在LDD3的第15章上有写（见“Remapping Specific I/O Regions”这一节）。不过当时作者选择了一个错误的做法：先把这块IO空间用ioremap映射到了内核空间，然后在用户进程访问被映射的地址所产 生的缺页中断里，用vmalloc_to_page得到page，返回给用户进程。
然而，vmalloc_to_page没法用在ioremap所得到的地址上，因为IO空间根本就没有对应的Page结构，返回的page指针自然是不对的。
正确的做法是在mmap函数里，使用remap_pfn_range函数。代码如下。注意要设置一下vma->vm_pgoff为你要map的io空间的物理地址对应的页。

static int filter_mmap(struct file *filp, struct vm_area_struct *vma)
{
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
vma->vm_pgoff = ( (u32)map_start >> PAGE_SHIFT);

if (remap_pfn_range(vma,
vma->vm_start,
vma->vm_pgoff,
vma->vm_end-vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;
return 0;
}

继续讨论van的channel

目前有三处相关的信息，一个是Van自己的presentation，在lwn上一篇比较深入的文章，另外还有一个blog讨论了这个问题。
Van的channel在提高linux TCP/IP协议栈的性能方面做了这样的工作：打破传统分层的TCP/IP设计架构，将IP包直接送达至目的地，好象是一条快速通道，Channel因此 而得名（但据lwn说，channel是指一种设计良好的环形buf，对它的读写不需要锁，而且对Cache非常友好，这么说也有道理，显然这么一种 buf是这个新框架所必须的）。这么做消除了多种开销，包括：

• 当channel在应用层实现时，数据包从内核空间到用户空间的拷贝不再需要，而是通过内存映射将内核收到的数据直接映射到应用程序的地址空间。（这个buf的实现很有点意思）


• 当channel在驱动实现时，不再需要skbuf（文物啊）来保存收到的报文，而是直接把报文丢到一个channel（一个环行buf）里。


• 各种运行环境切换的开销（硬中断、软中断、系统调用）


• Cache不命中的概率大幅降低，对smp更加友好

还有一点是不太明显的。有个“端到端原则”这样说道：要尽量把工作在网络的边界完成，网络本身只做尽可能少的工作。TCP就是这个原则的体现，可靠传输、流量控制、拥塞控制由连接的两个端点完成，网络只负责传输包，仅此而已。
但是诸位可能没注意到，我们目前的tcp协议栈并没有彻底贯彻这一原则，数据包被交给了协议栈，而不是交给了需要该数据包的程序，而这个程序才是真正的边 界。由于协议栈的处理所引入的包括延迟、丢包等情况使得应用程序无法看到真实的网络状况，这将导致无法有效的实施控制。比如TCP协议对RRT的计算会因 为报文在协议栈各层的排队、softirq的延迟而失真，会导致TCP吞吐量的下降。所以当Channel把报文直接送到应用程序时，才有可能实现高性能 的网络协议。

请注意有趣的一点，当channel一直通到应用程序时，需要在应用层实现TCP协议。

Channel对传统TCP协议栈性能的提升是巨大的，但同时对框架的改动也是根本性的，一些依赖于传统架构的应用不得不改写，包括被广泛使用的netfilter。
还有一个问题，就目前Channel的信息被遮遮掩掩的情况来看，这东西的license肯定有问题。而lwn上也有人向Van证实了这一点。 Channelized Driver和Channelized socket都会以GPL形式开放出来，但是channelized Application所需要的应用层TCP协议栈却由于某种原因无法GPL之。

valgrind，好东西，一般人我不告诉他~~

今天dot.kde登了一篇对valgrind的作者 Jonathan Riddell 的访谈。我作为valgrind的老用户，当年调程序时获益很多，在这篇访谈里进一步长了见识，深感有必要把这个优秀的开发工具介绍给诸位。以下内容多翻译自该访谈（意译啦）。

啥是valgrind

Valgrind是帮助程序员寻找程序里的bug和改进程序性能的工具。程序通过valgrind运行时，valgrind收集各种有用的信息，通过这些信息可以找到程序中潜在的bug和性能瓶颈。
Valgrind现在提供多个工具，其中最重要的是Memcheck，Cachegrind，Massif和Callgrind。

Memcheck：

这个工具可以用来寻找c、c++和fortran程序中内存管理的错误。写c或c++程序时，很多隐藏很深的bug是内存操作上出了问题。而这些在 Memcheck面前都无处遁形（偶当年用的就是这个功能）。Memcheck可以检查出下列几种内存操作上的错误（大家自查一下有没有犯过;）：

• 读写已经释放的内存


• 读写内存块越界（从前或者从后）


• 使用还未初始化的变量


• 将无意义的参数传递给系统调用


• 内存泄漏


• （笔者补充一条，同一个malloc的内存块释放多次。当年这么个bug让我找翻天）

Cachegrind：

这个工具可以提供详尽的profiling信息。它不光对指令、内存访问进行计数，更能针对每条指令、每行源代码、每个函数和每个程序统计cache的不 命中次数。大家应该知道，cache对目前系统的性能有决定性的影响。因此这些信息可以指导程序员调整代码，最大限度的提高程序性能。
访谈中提到，valgrind自身利用该工具在过去几个月内使性能提高了25%-30%。据早先报道，kde的开发team也对valgrind在提高kde性能方面的帮助表示感谢。

Massif：

Massif对内存的分配和释放做profile。程序开发者通过它可以深入了解程序的内存使用行为，从而对内存使用进行优化。这个功能对C++尤其有用（因为C++有很多隐藏的内存分配和释放）。

Callgrind：

Callgrind是一个复杂的工具（复杂到笔者没看太明白有关它的介绍）。它基于Cachegrind，除了具有Cachegrind的功能外，还可以统计调用带来的开销。

用法：

Valgrind使用起来非常简单，你甚至不需要重新编译你的程序就可以用它。当然如果要达到最好的效果，获得最准确的信息，还是需要按要求重新编译一下的。比如在使用memcheck的时候，最好关闭优化选项。

linux下的widget - Superkaramba

晚上花了点时间在Debian下尝试了一下superkaramba，安装完后运行出现窗口如下图（第一次运行只有两个选项，每安装一个“宝物”就会增加一个对应选项）。



选择“新建宝物”的选项，出现另一个窗口，在这个窗口里，你可以看到最新、最热门和下载次数最多的宝物排名，选中一项可以获得预览和简要介绍，点击安装即 可下载安装（这种模式是kde3.x之后添加的一个很cool的feature，我以前只知道可以用来下载墙纸），



随便安装了几个，show下截图：

试用感觉：

总体上，宝物数量和质量还不够高。比如那个控制播放器的软件还不能正确显示中文目录（唉，这种问题在开源世界里太常见了），那个记事本做得也忒糙了。不过天气预报软件做得很好，动画特效都很cool，那个系统monitor也做得不错。

另外，种类也不够多，面向web的应用不多，比如blog、rss reader、p2p。感觉人气还不够高，推出这么多年了，不如firefox的插件那么热火，也许随着kde4的推出会有所改观，在kde4里， superkaramba会以plasma的面目重新夺取世人的注意力。

但是。。。

但是局限于kde的plasma并不是一个针对widget的好的解决方案。开源世界应该推出一个标准的widget接口，提供诸如网络、 html/xml渲染、多媒体等功能，利用该接口写的widget可以无缝的运行于gnome、kde、xfce、fvwm等众多的窗口管理器/桌面环境 之中，甚至运行于windows上也不是不可能。

yahoo的widget

今天装了yahoo的widget，嗯，很华丽也比较实用。所谓widget就是一些完成特定功能的小窗口，象下面的抓图里就有Rss Reader，Clock，yahoo信箱监视器，天气预报，相册，yahoo信箱的地址本，搜索窗口等等。还可以从网上下载其他各种各样的 widget。

这一阵子流行web2.0，流行RIA（rich internet application），很多RIA还需要寄生在浏览器的窗口里，并不见得方便。用widget就摆脱了这个限制。当然基于浏览器的RIA也有其优势，比如易于部署之类。
开源世界也有类似的东东。KDE下很早就有一个很cool的软件叫superkaramba，能实现类似的功能，可惜一直没有被广泛的使用。如今 superkaramba改头换面叫做plasma，成为即将发布的kde4.0的重要组成部分。kde4.0计划在今年底或明年初发布beta版，相信 届时必然是很轰动的。

zim, 桌面wiki

zim是一个桌面wiki软件，我现在拿它来做工作记录，因为它秉承了wiki的特点，可以很容易的创建page，并且把page关联起来，所以用起来感觉条理很清晰。虽然现在还做得有点粗糙，但是已经足够用了，推荐之。
zim用的是GTK，不知道有没有被port到Windows上。
另：
有兴趣的朋友可以把zim改进一下，比如可以和web服务器同步，增加模板，增加协作功能。

Van Jacobson的Channel

Van Jacobson何许人也？Cisco的前任首席科学家，因为发明了TCP的慢启动和拥塞控制机制而被称作“拯救Internet的人”。最近Van又有 动作，这次不是对TCP协议本身的改进，而是对TCP/IP协议栈实现的优化，这个从架构上对TCP/IP实现所做的修改被称作Channel。
目前能找到的第一手资料只有Van在Linux.conf.au 2006上对此所做的Presentation。Van在Linux上实现了他的Channel，测试表明性能取得了惊人的提升。下表是从该Presentation中摘出的测试结果。

Van的测试环境是两台采用双至强2.4GCPU的Dell服务器，通过两块e1000网卡直接连接，操作系统是Linux，内核为2.6.15，e1000驱动版本为6.3.9。测试软件用的是netperf。
“1CPU”表示启用了CPU Affinity，“2CPU”表示未启用CPU Affinity，“drvr”表示采用了修改后的网卡驱动，即“Channelized Driver”，“sock”表示采用了“channelized socket”，“App”表示采用了“Channelized app”。“Busy”是CPU占用率，“Intr”和“Softint”是中断和软中断发生次数，
“Socket”、“Locks”、"Sched"和“App”代表相应的CPU占用率。
从此表可以看出，2CPU的性能要远小于2 x 1CPU，由于cache对系统性能的影响越来越大，增加CPU所带来的Cache开销会大大抵消新加CPU所提供的计算能力。通过采用 channelized driver可以很大程度的消除这种影响。随着对Socket和App的进一步优化，性能进一步提升，对比1CPU，2CPU和APP的数据，其结果是惊 人的。
可惜Van的Presentation里没有更多介绍改进的细节，我将在另外一篇blog里与大家讨论这个问题。

TCP协议各种变体的简介