什么是pinax？欢迎光临pinax中文网站！
什么是pinax？简而言之，pinax是一个基于django的，由众多高度模块化app组成的一个快速开发平台。
基于pinax project，你可以非常方便，非常快速的搭建起自己的网站应用。由于pinax已经集成了大量的、可复用的、网站基本的、常用的app，因此，pinax为您节省了大量人力，物力，时间，使网站开发者可以集中精力关注于自己网站的特色部分。
pinax的官方网站：http://pinaxproject.com
pinax中文网站：http://www.pinaxcn.com
内核2.6.28下获取sys_call_table的问题
在2.6.24和2.6.28内核下，使用下面函数获取到的sys_call_table与System.map中的不一致，而与/proc/kallsyms一致。
grep sys_call_table /proc/kallsysms
c04ed700 R sys_call_table
grep sys_call_table /usr/src/linux-2.6.28.7/System.map
c12ed700 R sys_call_table
获取sys_call_table的函数如下：
unsigned int get_sys_call_table(void)
{
unsigned int sys_call_off;
unsigned int sys_call_table;
char* p;
int i;
asm(”sidt %0″:”=m”(idtr));
printk(”addr of idtr: 0x%x\n”, (unsigned int)&idtr);
memcpy(&idt, (void *)(idtr.base+8*0×80), sizeof(idt));
sys_call_off=((idt.off2<<16)|idt.off1);
printk(”addr of idt 0×80: 0x%x\n”, sys_call_off);
p=(char *)sys_call_off;
for (i=0; i<100; i++)
{
if (p==’\xff’ && p[i+1]==’\x14′ && p[i+2]==’\x85′)
{
sys_call_table=*(unsigned int*)(p+i+3);
printk(”addr of sys_call_table: 0x%x\n”, sys_call_table);
return sys_call_table;
}
}
return 0;
}
使用该函数获取的sys_call_table地址为c04ed700
问题2：在linux 2.6.28内核下，使用上面get_sys_call_table获取的sys_call_table地址时，在下面的语句出现oops：
sys_call_table[__NR_test_syscall] = (long)test_syscall;
在2.6.24下，工作正常
请问有人遇到该情况吗？如何解决的？
谢谢！
subversion编译安装
subversion(svn)是很好的版本管理工具，但如果手动编译安装，真的是非常麻烦的事情。
subversion有三个最常用的模块：
* ra_svn : 使用svn网络协议访问档案库的模块。
- handles ’svn’ scheme
* ra_local : 访问本地磁盘的档案库模块。
* ra_dav : 访问http://档案库模块。
前面两个，是subversion编译的默认模块，ra_dav是大多数人遇到的问题。如果ra_dav没有编译到系统中，当你从http://这样的路径checkout时，会出现这样的错误提示：
svn: Unrecognized URL scheme
pinaxcn上了pinaxproject官方网站的首页！
今日pinaxcn访问量暴涨，去查了查访问来源，一看，排在第一位的是http://pinaxproject.com
去pinaxproject网站一看，居然把pinaxcn.com放在上面了！呵呵，真是令人兴奋！
感谢pinaxproject如此优秀的项目！
=========================================================================
再仔细一看，pinaxproject上的网站推荐原来是随机的，哈哈！
我自娱自乐了一把！
温格罕见的庆祝动作
阿森纳主帅温格通常都是以温文尔雅的方式出现在场边，像下面的情形很少出现：
温格, 阿森纳
gdb（1）
在Linux下开发程序，缺少IDE环境，因此，调试程序时，大多数程序员都选择使用printf这样简单直接的方式，而避免使用gdb这么复杂的调试工作。
通常，对付简单的逻辑错误，printf是一个很好的方式，但对于复杂的问题，就必须使用gdb了，尤其是涉及到多线程，信号等情况。
1、调试core文件
在有些Linux系统中，core文件默认是不会dump出来的，使用ulimit -a来查询是否允许core dump，使用ulimit -c unlimited来允许系统dump core文件。
ok，系统能够dump core文件后，即可使用
gdb a.out core来让gdb解析core文件，进入gdb后，使用where来查看core dump的位置，函数名。
2、signal
默认情况下，一些信号会被gdb截获，不会传递给被调试的程序。例如，在console下按Ctrl－C后确实发送了SIGINT信号，但是gdb里的缺省设置将会导致由GDB截获的该信息，调试的应用程序无法接受到该信号。
不过，你可以修改gdb的默认动作，让gdb把信号传送给应用程序。
1）改变gdb信号处理的设置
比如,以下设置会告诉gdb在接收到SIGINT时不要停止、打印出来、传递给调试目标程序
=====================================
(gdb) handle SIGINT nostop print pass
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) y
Signal Stop Print Pass to program Description
SIGINT No Yes Yes Interrupt
(gdb)
=====================================
（2）使用gdb命令直接向调试的应用程序发送信号
首先在你希望发送信号的语句处设置断点，然后运行程序，当停止到断点所在位置后，用gdb的signal命令发送信号给调试目标程序
====================================
(gdb) signal SIGINT
Continuing with signal SIGINT.
Breakpoint 1, handler (signal=2) at main.cpp:15
15 printf(”Signal handler…\n”;
====================================
3、断点 break
设置断点是一个常用的调试方式。
pktgen及tcpreplay、tcpreply-edit
pktgen和tcpreplay都是Linux下的发包软件，但两者之间有着明显的不同。
pktgen是内核的一个模块，tcpreplay是应用软件。因此，从发包速度的角度上说，pktgen有很大的优势。
1、安装
pktgen是内核的模块，因此，安装pktgen需要重新编译内核，在network option的选项下，把pktgen作为模块选中，重新编译内核即可。
tcpreplay的官方网址为：http://tcpreplay.synfin.net/trac/，下载tcpreplay的最新版本，解压缩，安装编译即可。典型安装命令如下：
./configure –prefix=/usr;make;make install
2、使用
由于pktgen是一个内核模块，因此，使用pktgen不像通常的应用程序一样，有相应的命令。
pktgen通过/proc文件系统作为用户接口，通过写proc文件来控制pktgen的动作。
相应的pktgen的配置文件可以在pktgen的官方网站上获取。
tcpreplay (tcpreplay) – Replay network traffic stored in pcap files
USAGE: tcpreplay [ -<flag> [<val>] | –<name>[{=| }<val>] ]… <pcap_file(s)>
我在中超的废墟中，发现了一颗明珠…..
蒿俊闵。
友情提示：不关心中国足球，鄙视中超者，欲痛骂中国足球者，请绕道。
中超第一轮，蒿俊闵打入的进球，颇为惊艳，能够排在中超第一轮最佳进球的前三位。
也正是因为这个进球，上轮比赛，特地看了天津对浙江绿城的比赛。两只球队都是技术流打法，配合娴熟，在中超各支球队中，算是不错的。不过，在机会的把握上，在球队整体的控制上，泰达对更胜一筹，蒿俊敏的表现也非常出色，能突，能控，能带，能传，大局观相当好。
天津队目前非常强势，已经表现出争冠的实力。希望天津队能够在亚冠赛场上取得好成绩，蒿俊闵能够早日凭自己的实力去欧洲更高水平的球队中锻炼。
google蒿俊闵资料如下：
姓名：蒿俊闵（haojunmin）
国籍：中国
性别：男
生日：1987.3.24
身高：1.78米
体重：70公斤
项目：足球
效力球队：天津康师傅队
tcpdump/ethereal文件格式
libpcap format has a file header, followed by the packets, with each packet consisting of a packet header followed immediately by the data in the packet, with no padding between the file header and the first packet header, the packet header and the packet data, or the packet data and the header of the next packet, if any. The file header consists of, in order: a 32-bit "magic number"; a 16-bit major version number; a 16-bit minor version number; a 32-bit "time zone offset" field that's actually not used, so you can (and probably should) just make it 0; a 32-bit "time stamp accuracy" field that's not actually used, so you can (and probably should) just make it 0; a 32-bit "snapshot length" field; a 32-bit "link layer type" field. The magic number has the value hex a1b2c3d4. All the fields can be written in either big-endian or little-endian format; the magic number is one of those fields, so the program reading the file (tcpdump, Ethereal, whatever) can infer from that fields value, when it reads it, whether the file was written in the same byte order as the native byte order of the machine reading the file or in the opposite byte order, and can byte-swap the values if they're written in the opposite byte order (both libpcap, the library tcpdump and many other programs use to read those files, and the library Ethereal and the programs that come with it use to read the file, do so). All numbers in the headers are usually written in the byte order of the processor on whatever device is saving the frames. The major version number should have the value 2. The minor version number should have the value 4. The "time zone offset" and "time stamp accuracy" fields should both be zero. The "snapshot length" field should be the maximum number of bytes per packet that will be captured. If the entire packet is captured, make it 65535; if you only capture, for example, the first 64 bytes of the packet, make it 64. The link-layer type depends on the type of link-layer header that the packets in the capture file have: 0 BSD loopback devices, except for later OpenBSD 1 Ethernet, and Linux loopback devices 6 802.5 Token Ring 7 ARCnet 8 SLIP 9 PPP 10 FDDI 100 LLC/SNAP-encapsulated ATM 101 "raw IP", with no link 102 BSD/OS SLIP 103 BSD/OS PPP 104 Cisco HDLC 105 802.11 108 later OpenBSD loopback devices (with the AF_ value in network byte order) 113 special Linux "cooked" capture 114 LocalTalk If you need a new type for a new link-layer header, send mail to tcpdump-workers at tcpdump.org asking for one; do *not* pick one yourself, as you may pick one that's already in use, or reserved for future use. Immediately following that header are the actual frames. Each frame consists of a frame header followed by the raw bytes of the frame. The frame header consists of: a time stamp, consisting of: a UNIX-format time-in-seconds when the packet was captured, i.e. the number of seconds since January 1, 1970, 00:00:00 GMT (that's GMT, *NOT* local time!); the number of microseconds since that second when the packet was captured; a 32-bit value giving the number of bytes of packet data that were captured; a 32-bit value giving the actual length of the packet, in bytes (which may be greater than the previous number, if you're not saving the entire packet). All those numbers must be in the same byte order as the numbers in the file header.
