XRP Ninja

http://lwn.net/Articles/204542/ It's a pity that I don't have a nvida card to try the exploit. :) I am so admire those who could create an exploit all on his own. It requires a lot of skill. A famous Chinese Poet Lu You (陆游) from Song Dynasty has once said, if you do want to learn poem, you should learn beyond poem (汝果欲学诗，功夫在诗外). Take this exploit as an example, I myself know little on Xlib programming, so although I have some basic idea on shellcode/exploitation, it's still impossilbe for me to write an exploit of nvidia driver at this moment.

这篇文章写了有段时间了，不过没有在这里贴过。现在拿出来和大家分享一下。如果有理解错误的地方，还望指正。 Linux（包括其上运行的应用程序）的启动速度相比Windows要慢，这是个不争的事实。不过未来这种状况必将会发生变化。 lwn.net 上有两篇文章与此话题有关。 首先，要明确的一点是，导致这种状况的根本原因与内核关系不大。两个主要原因，一个是用户层程序启动时往往会做很多无谓的动作，可以从strace的结果里体会到；一个是ELF(现代*nix系统所采用的可执行文件和共享库文件格式)格式的二进制程序在符号解析时要耗费不少时间。lwn.net上的这两篇文章就分别针对这两个问题。 第一篇是 http://lwn.net/Articles/192214/ 第二篇是 http://lwn.net/Articles/192624/ 第一篇是Dave Jones在渥太华Linux研讨会(Ottawa Linux Symposium)的一个演讲，这个pdf的第441页 http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf 就有这篇文章，题目是"Why user space sucks"。Dave观察了他的Fedora系统的启动过程，结果发现整个过程调用了stat() 79000次，打开过27000个文件和运行了1382个程序。但实际上不一定需要这么多动作。他还具体分析了很多程序的表现，比如gamin(fam ——file alteration monitor——的后继者)，Xorg，CUPS，HAL等等。虽然Dave没有提出具体的解决方案，但是自此以后这个问题必定会引起人们的重视。 第二篇题目是Optimizing linker load times。文章开头提到目前很多发行版都在想尽办法提高系统启动速度，目前已有一些途径，比如预读取(readahead)，启动重排序(boot reordering)，还有并行执行init脚本。还有一个途径就是文章的主题，提高连接器动态连接的速度，主要是符号解析的速度。符号解析的目的，是把在程序里未定义的函数名解析为运行时该函数的内存地址。解析的过程就是查hash表，按惯常做法表里hash值相同的符号(就是未定义的函数名)组成链表。文章提到目前已经有的一个

I didn't mask it in /etc/portage/package.mask when I emerge =scim-1.4.4. So it was upgraded to 1.4.5 in the lastest update. And now it works. Don't know why. Anyway, it works. This is the most important thing.

我找你找了好久 别人都说我们会分开 我找你找了好久 别人都说我们会分开 这两对，看似一模一样，实则不同 第一对不同的字是“了” 第二对不同的字是“都” 第一行是我在转用utf8字符集的时候用convmv改的 看来还有点问题

I have created a feed on feedburner. You may subscribe to that as well. http://feeds.feedburner.com/zhllg

使用GDB/Emacs debug C++程序 Date: 2006-09-26 Version: 1.0 Authors: 张乐 内容 gdb使用技巧 注意事项 准备工作 运行 设置断点 检查状态 继续运行 信号 与Emacs配合使用 gdb使用技巧 注意事项 gdb使用 Readline 库 可以使用bash快捷键，tab补齐 清除inputrc里有冲突的设置 准备工作 重新编译安装程序。系统里现有的程序一般不适合直接拿来跟踪。需要使用合理的CFLAGS重新编译安装后再跟踪。 ./configure find -name "Makefile" | xargs sed -i -e 's/^CFLAGS = /CFLAGS = -g3 -ggdb3 -gdwarf-2 /' make && make install 运行 启动gdb a. gdb bayonne b. gdb --args bayonne -vvv script.scr 利用帮助 a. help 命令类别名 b. help 命令名 运行程序 a. r[un] b. r[un] -vvv script.scr 设置断点 按照函数名设置断点 b[reak] main b[reak] 'namespace::Class::func()' 按照文件名和行数设置断点 b[reak] methods.cpp:523 检查状态 检查堆栈 b[ack]t[race] up down 检查当前函数的源代码 list 检查/改变变量值 p[rint] var p[rint] ptr->mem p[rint] *ptr p[rint] ('namespace::Class') *this p[rint] (('namespace::Class') *this)->a.b.c p[rint] var=value 检查类 ptype ptr set print object on whatis ptr 检查并启用/禁用断点 set breakpoint pending on info b[rea

According to my own experience, scim 1.4.4 works fine with glibc 2.5! Scim 1.4.5 must have used something which is changed from glibc 2.4 to 2.5.

I am not sure about the cause at this moment. Thanks to fcitx, I still can input Chinese. However I can't get used to it, there is some difference between the two input methods. For example in fcitx you need to press 2 keys when switching between English/Chinese, while in scim you just need to press "shift", which is the same as in MS Pinyin. Updates: Anyway, I have come back to scim (1.4.4). So good bye to fcitx! http://zhllg.blogspot.com/2006/10/latest-news-on-scim-and-glibc.html

Background: http://www.linuxsir.org/bbs/showthread.php?t=266936&highlight=mkinstalldirs http://bugs.gentoo.org/show_bug.cgi?id=144930#c3 Solution: layman -a gentoo-china layman -S emerge -1 scim-pinyin PS: some info about gentoo-china-overlay http://www.linuxsir.org/bbs/showthread.php?t=272832

I have been translating GWN to Simplified Chinese with my teammates since May 2006. Originally, I sent translated GWN to gwn-feedback. Several weeks ago I started to send to neysx, because neysx will be my mentor. At the beginning, I sent translated GWN via email. However, the attachment was lost several times. Then I began to use bugs.gentoo.org. Neysx gave me a link. http://bugs.gentoo.org/show_bug.cgi?id=147686#c4 I was supposed to use this link to assign bugs directly to neysx. I have tried it 3 times. Each time the assignee will be changed from neysx to docs-team. Like this one: http://bugs.gentoo.org/show_bug.cgi?id=150726 However, dev's seem never know this. This explains why words like "Whatever you do, you do it wrong" would come out. Later, neysx verified this fact himself: http://bugs.gentoo.org/show_bug.cgi?id=150743 Then neysx said sorry to me. Problem solved.

I did some housekeeping work today, unmerged glitz. I have disabled glitz USE flag for a long time. Don't know why it still exists today. Of course, I do --depclean regularly. Then disaster happened as you may guess. All the apps previously linked with glitz ceased to work. So I have to resort to revdep-rebuild. However, many program still failed to emerge, as "/usr/lib/libglitz.la" exists in many la files under /usr/lib. Honestly, I still don't know exactly la files' functionality. But I guess it plays an important role in the linking process. I used the following command to wipe out all the "/usr/lib/libglitz.la" string from la files under /usr/lib. sudo find /usr/lib -name "*.la" | xargs sudo sed -i -e 's# /usr/lib/libglitz.la##' Not sure whether this is the right way to go, but it works here.

http://www.youtube.com/watch?v=KoRozMganNQ

比XGL还要顺畅 哦yeah!