双核的威力

athlon64x2 3800+ dfi nf4-d geil 512M*2
看看编译速度的对比
# genlop -t xorg-server
* x11-base/xorg-server

Sun Jul 23 18:48:30 2006 >>> x11-base/xorg-server-1.1.1
merge time: 21 minutes and 35 seconds.

Tue Jul 25 00:57:54 2006 >>> x11-base/xorg-server-1.0.2-r7
merge time: 28 minutes and 31 seconds.

Wed Aug 30 15:10:47 2006 >>> x11-base/xorg-server-1.1.1
merge time: 9 minutes and 28 seconds.

前两次是athlon64 3000+ kst512M的时间，最后一次是现在的时间
排除掉内存双通道和超频的因素，速度的增长依然十分可观

整个系统发热也不算很高，开了cool'n'quiet后cpu空载时只有30度，满载45度，散热器是tt金星9,当然现在气温低，夏天的时候肯定还要高

之前在cool'n'quiet开启的情况下超频不稳定，一编译就死机，后来发现是因为跑的是270*9，而默认倍频是10,在空载的时候自动降频，倍频 变成5,负载一高就自动变成10了，270*10就挂了，其实bios里有个选项是什么什么max fid，默认就是10,设置成9就不会出现这个情况了

新的blogger，玩一下，觉得不错

到目前为止的进展

在写一个google talk的客户端，目前为止核心还没有完成，打算先实现xmpp规定的功能特性的一个基本子集
我发现google的talk服务器也并不是严格地实现了所有xmpp的服务器端功能特性，比如说客户端发送的流里存在某些错误的时候 talk.google.com并不会返回错误的类型，而是直接发送</stream>然后关闭所有已建立的连接，比较暴 力，呵呵
现在存在的问题的：因为xml解析器用的是expat，基于回调函数，限制非常大，因为我不可能把什么东西都通过expat传递给回调函数，那样就破坏了 各个模块的独立性。所以打算第一个版本就expat了，但是完成之后第一件事就是自己实现一个针对xmpp的解析器，不会很复杂，差不多应该相当于一个词 法分析器的复杂度？
这两天停下来了，因为要实习，累得开不了工，还有一个原因是我还没想好要怎么处理<message></message>，因为这里会涉及到后面的gui和cli要用到的接口，不考虑全面一点以后免不了要重写
收获还是很大的

atoi?itoa?

atoi ()是库函数，用于把字符串转换成整数，实现起来相当容易，于是我傻乎乎地开始去找itoa，找了一圈，终于发现了，没有itoa啊
然后转念一想，要itoa做什么！真要的话自己写一个，几分钟的事情，但是现成的sprintf放这儿不用就真的傻了
而且sprintf显然更方便，因为它有转义字符可以控制输出的格式，于是结论：C语言哪里需要什么itoa嘛！