varnish和squid相比最大的优势就是简单快速，简单是安装和配置都简单，快速是运行速度比squid更快，当然，快的前提是varnish比squid占用更多的内存，估计当年设计squid的时候内存还是很贵的东西，所以更多的侧重硬盘，使用内存多，当然还有一个很显而易见的弱点是机器冷启动时候恢复缓存的时间相比squid要长。
wget http://downloads.sourceforge.net/project/varnish/varnish/2.0.6/varnish-2.0.6.tar.gz?use_mirror=ncu
tar zxvf varnish-2.0.6.tar.gz
cd varnish-2.0.6
./configure –prefix=/srv/varnish
make
make install
启动命令：
/srv/varnish/sbin/varnishd -a :8088 -b localhost:8080
由于我指定了安装目录，所以加上了路径,-a参数表示varnish的监听端口，正常情况下应该监听是80端口，也就是web服务端口，我测试机上被使用掉了，所以用了8088端口， -b 是表示后端（backend）的地址，如果backend在这里指定，那么只能指定一个后端，如果使用的配置文件可以指定多个backend，我的配置文件位置位于/srv/varnish/etc/varnish。
在web服务器的目录中创建一个index.html文件，然后通过varnish进行代理访问.
第一次访问结果如下：
第二次访问结果如下：
根据请求头，我们看到的确是通过vanish来代理访问后端的，第一次访问age 为0 ，第二次访问age为71，说明这个文件已经在varnish中缓存了，此时可以通过/srv/varnish/bin/varnishstat 来查看一些参数，其中Hitrate 一行应该为1，因为命中了一次。
varnish 配置文件还是很有搞头的一个东西，有点类似与Nginx的语法，虽然不是很像，比如对正则的支持，可以绑定和去除head、Cookie等等功能，有时间的话，翻译一下varnish的introduction
好久不玩 Google AppEngine，google 居然用WXPython整出一个带界面的GAE server管理器,有点进步，虽然这个东西在Mac早就有了，至少现在不用在艳羡用Mac的同志了，当初我就觉得，难道google的工程师都用Mac？为啥不顾及大部分开发者呢？google真的太有个性了。down了一个到本地，结果死活加载不了项目，不停的报错，打开log一看，全是如下错误信息：
Traceback (most recent call last):
File “GoogleAppEngineLauncher.py”, line 42, in <module>
File “wx\_core.pyc”, line 7913, in __init__
File “wx\_core.pyc”, line 7487, in _BootstrapApp
File “launcher\app.pyc”, line 53, in OnInit
File “launcher\app.pyc”, line 97, in _CreateModels
File “launcher\maintable.pyc”, line 35, in __init__
File “launcher\maintable.pyc”, line 86, in _LoadProjects
File “launcher\project.pyc”, line 63, in ProjectWithConfigParser
File “launcher\project.pyc”, line 250, in _LoadFromConfigParser
File “ConfigParser.pyc”, [...]
由于godaddy不稳定和龟速，终于把博客搬到自己的VPS上，并且换了一套皮 ，最近日子过得比较快，可能因为事情比较多的缘故，最近两个月写的代码，超过我过去半年的写的代码的总和
废话少说，直接上wordpress Nginx的rewrite规则，我的博客版本是2.8.5，一切正常，其他的不敢保证
if (-d $request_filename){
rewrite ^/(.*)([^/])$ $1$2/ permanent;
}
if (-f $request_filename/index.html){
rewrite (.*) $1/index.html break;
}
if (-f $request_filename/index.php){
rewrite (.*) $1/index.php;
}
if (!-f $request_filename){
rewrite (.*) /index.php;
}
第一条在很多Nginx主机上是默认就可以进行301 move的，意思是：如果请求的是目录，那么将请求rewrite到这个目录里面，不加这一条可能会导致二级或者三级目录无法访问，比如请求地址是http://www.abc.com/abc, abc是一个目录，abc中有一个index.html页面，还有一个名为style的目录，index.html 引用style中的css,js等文件，并且引用方式为相对地址，类似这样的结构：<script type=“text/javascript” src=”style/lib/jquery.js“></script>，那么除index.html能被请求到之外，index.html中引用的所有文件的请求，都将是404
后面三条网上到处都是，如果你不是跟我一样，在Web根目录下放一些jquery，mysql之类的手册，后面三条就足够使用。包括你使用伪静态化
error: C++ compiler cannot create executables….
安装相关开发包：
yum install gcc gcc-c++ gcc-g77 autoconf automake flex bison bzip2-devel zlib-devel ncurses-devel libjpeg-devel libpng-devel libtiff-devel freetype-devel pam-devel
Debian：
apt-get install gcc g++ build-essential
VPS为了保证效率和最小化安装，很多东西都没有所以出现上面的错误，有个偷懒的方法就是：
yum groupinstall ‘Development Tools’
这样和我们本地安装时勾选development tools的效果是一样的，什么编辑器啊，make，automake之类的都有了。
configure: error: *** libmcrypt was not found
安装libmcypt时，用默认的./configure && make && make install后，在下一步安装mcrypt会出现上面的错误，并不是libmcypt 没有安装好，而是没有加到默认的path中，做个软连接即可：
ln -s /usr/local/bin/libmcrypt-config /usr/bin/libmcrypt-config
编译PHP带上–with-xmlpr参数时出现：configure: error: XML configuration could not [...]
Linux进程创建很特别。许多其他的操作系统都提供了产生（spawn）进程的机制，首先在新的地址空间里创建进程，读入可执行文件，最后开始执行。Linux通常采用了与众不同的实现方式，他把上述步骤分解到两个单独的函数（步骤）中去执行：fork()和exec()。
首先fork()通过拷贝当前进程创建一个子进程。子进程与父进程的区别仅仅是多了一个PPID（父进程的进程号，子进程将其设定为被拷贝进程的PID），当然PID也是不同的，不过每个进程的PID都是不同的，要不然操作系统就没法识别和调度了。
exec()函数负责读取可执行文件并将其再如地址空间开始运行。把这两个函数组合起来使用效果和其他系统使用的单一函数效果相似。
fork()是通过简单的资源拷贝来实现创建子进程，尽管子进程有那么点和父进程的区别，这种通过简单拷贝实现的进程创建是非常低效率和耗资源的，因此人们想着去怎么提高这个效率，最后采用了一种类似与程序设计中的延迟绑定的措施，也就是“写时拷贝”。所谓写时拷贝就是内核在创建进程时不复制整个进程的地址空间，而是让父进程和子进程共享同一个拷贝。只有在需要写入的时候数据才会被复制到新的地址空间中，从而是个进程拥有各自的拷贝，也就是说在此之前都是以只读方式实现共享，何种技术使地址空间上的页拷贝被推迟到实际发生写入的时候。在页根本不会被写入的情况下，就无需再复制了。
废话了这么多，实际上也就是说Linux进程的创建是通过拷贝来实现的，然后对这个拷贝方式和时间进行了优化，出现了写时拷贝这么个东西。