阿里巴巴推出了云计算，为创业者和开发者提供不同的解决方案，用户无需购买硬件，即可在阿里云上运行自己的程序或开创业务。其中社区网站云计算提供了以phpwind为程序支持的网站云服务，为不同规模的网站提供不同的套餐，最低档次现在折扣价1990RMB/Y，原价4990RMB/Y，目前的政策是第二年起8折优惠，近4000RMB，最低档次的配置为：
并免费分配一个外网IP地址。
阿里巴巴刚开始帮客户做实物贸易，现在又开始帮助客户做整个互联网的创业，涉及面更加广泛，最近还要出来一个阿里云手机，又把移动互联网全覆盖了，这就是马云眼里的大阿里？他想的应该更远…
在这里下载1.17.0版本。
转载地址：抚琴煮酒
一、rsync的优点与不足
大家通过我们上面的描述和实验应该了解rsync具有安全性高、备份迅速、支持增量备份等优点，通过rsync可以解决对实时性要求不高的数据备份需求，例如定期的备份文件服务器数据到远端服务器，对本地磁盘定期做数据镜像等。
随着应用系统规模的不断扩大，对数据的安全性和可靠性也提出的更好的要求，rsync在高端业务系统中也逐渐暴露出了很多不足，首先，rsync同步数据时，需要扫描所有文件后进行比对，进行差量传输。如果文件数量达到了百万甚至千万量级，扫描所有文件将是非常耗时的。而且正在发生变化的往往是其中很少的一部分，这是非常低效的方式。其次，rsync不能实时的去监测、同步数据，虽然它可以通过Linux守护进程的方式进行触发同步，但是两次触发动作一定会有时间差，这样就导致了服务端和客户端数据可能出现不一致，无法在应用故障时完全的恢复数据。基于以上原因，rsync+inotify可以解决这个问题。
二、 初识inotify
Inotify 是一种强大的、细粒度的、异步的文件系统事件监控机制，linux内核从2.6.13起，加入了Inotify支持，通过Inotify可以监控文件系统中添加、删除，修改、移动等各种细微事件，利用这个内核接口，第三方软件就可以监控文件系统下文件的各种变化情况，而inotify-tools就是这样的一个第三方软件。
在上面章节中，我们讲到，rsync可以实现触发式的文件同步，但是通过crontab守护进程方式进行触发，同步的数据和实际数据会有差异，而inotify可以监控文件系统的各种变化，当文件有任何变动时，就触发rsync同步，这样刚好解决了同步数据的实时性问题。
三、 安装inotify工具inotify-tools
由于inotify特性需要Linux内核的支持，在安装inotify-tools前要先确认Linux系统内核是否达到了 2.6.13以上，如果Linux内核低于2.6.13版本，就需要重新编译内核加入inotify的支持，也可以用如下方法判断，内核是否支持 inotify（服务器系统为Centos5.5 x86_64）：
uname -r
2.6.18-194.el5
ls -lsart /proc/sys/fs/inotify/
总计 0
0 dr-xr-xr-x 7 root root 0 06-16 00:02 ..
0 -rw-r–r– 1 root root 0 06-21 11:15 max_user_watches
0 -rw-r–r– 1 root root 0 06-21 11:15 max_user_instances
0 -rw-r–r– 1 root root 0 06-21 11:15 max_queued_events
0 dr-xr-xr-x 2 root root 0 06-21 11:15 .
通过以上显示我们明白，Centos5.5 x86_64是支持inotify的。
四、inotify的简单介绍
Inotify 是文件系统事件监控机制，作为 dnotify 的有效替代。dnotify 是较早内核支持的文件监控机制。Inotify 是一种强大的、细粒度的、异步的机制，它满足各种各样的文件监控需要，不仅限于安全和性能。
inotify 可以监视的文件系统事件包括：
IN_ACCESS，即文件被访问
IN_MODIFY，文件被 write
IN_ATTRIB，文件属性被修改，如 chmod、chown、touch 等
IN_CLOSE_WRITE，可写文件被 close
IN_CLOSE_NOWRITE，不可写文件被 close
IN_OPEN，文件被 open
IN_MOVED_FROM，文件被移走,如 mv
IN_MOVED_TO，文件被移来，如 mv、cp
IN_CREATE，创建新文件
IN_DELETE，文件被删除，如 rm
IN_DELETE_SELF，自删除，即一个可执行文件在执行时删除自己
IN_MOVE_SELF，自移动，即一个可执行文件在执行时移动自己
IN_UNMOUNT，宿主文件系统被 umount
IN_CLOSE，文件被关闭，等同于(IN_CLOSE_WRITE | IN_CLOSE_NOWRITE)
IN_MOVE，文件被移动，等同于(IN_MOVED_FROM | IN_MOVED_TO)
注：上面所说的文件也包括目录。
五、rsync+inotify企业应用案例
我们的后端WEB是二台部署了Nginx的WEB服务器，由于没有共享存储，我们现在要实现的是对它们的根目录/data/htdocs/www实现即时同步更新。
WebServer1:192.168.1.5，Centos5.5 x86_64
WebServer2:192.168.1.6，Centos5.5 x86_64
根目录均为/data/htdocs/www，自动同步顺序为WebServer2 WebServer1，我们将WebServer1配置成rsync的服务器端即可
1.我们首先开始安装inotify-tools了，可以到http://inotify-tools.sourceforge.net/下载相应的inotify-tools版本，然后开始编译安装：
cd /usr/local/src
tar zxvf inotify-tools-3.14.tar.gz
cd inotify-tools-3.14
./configure &&make && make install
2.WebServer1端，即192.168.1.5的rsync配置详见此章第一节的内容，我们配置好/etc/rsyncd.conf文件，如下：
[root@server ~0m]# vim /etc/rsyncd.conf
uid = nobody
gid = nobody
user chroot = no
max connections = 200
timeout = 600
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsyncd.lock
log file = /var/log/rsyncd.log
[www]
path=/data/htdocs/
ignore errors
read only = no
list = no
hosts allow = 192.168.1.0/255.255.255.0
auth users = www
secrets file = /etc/rsyncd.password
然后重启xinetd即可，如下所示：
/etc/init.d/xinetd restart
记得二台WEB机器都要配置/etc/rsyncd.passwd文件，rsync的配置过程和原理请大家参考我在51cto.com的rsync配置相关文章，这里就不详细说明了。
3.我们配置好WebServer2的inotify，让其开机即启动，脚本内容如下：
vim /root/rsync.sh
#!/bin/bash
src=/data/htdocs/www/
des=www
ip=192.168.1.5
/usr/local/bin/inotifywait -mrq –timefmt ‘%d/%m/%y %H:%M’ –format ‘%T %w%f’ -e modify,delete,create,attrib $src | while read file
do
rsync -vzrtopg –delete –progress $src www@$ip::$des –password-file=/etc/rsyncd.password &&
echo “$src was rsynced”
done
脚本相关解释如下：
–timefmt：指定时间的输出格式。
–format：指定变化文件的详细信息。
这个脚本的作用就是通过inotify监控文件目录的变化，进而触发rsync进行同步操作，由于这个过程是一种主动触发操作，通过系统内核完成的，所以，比起那些遍历整个目录的扫描方式，效率要高很多。
然后我们将此脚本放在/etc/rc.local，即在最后一行添加，/etc/rc.local文件改动后内容如下：
[root@slave www0m]# cat /etc/rc.local
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don’t
# want to do the full Sys V style init stuff.
touch /var/lock/subsys/local
/root/rsync.sh
4.验证就很容易了，我们可以在192.168.1.6的机器的/data/htdocs/www目录下新建文件，更改文件内容，我们很欣慰的发现，192.168.1.5的机器上马上也会发生相应的改变，就像二台机器是网络Raid-1样，非常方便。
总体说来，rsync+inofity比较适用于没有存储环境的小文件的即时同步更新，如果要更新的文件非常大而且同步的机器数量在10台以上时，我建议还是以共享存储的方法来解决，如果没有资金购置昂贵的存储，大家不妨考虑下Heartbeat+DRBD+NFS方案来作为我们的文件服务器。
参考文档
http://ixdba.blog.51cto.com/2895551/580280
http://www.ibm.com/developerworks/cn/linux/l-ubuntu-inotify/index.html
作者简介：余洪春，网名抚琴煮酒，外企Linux/Unix系统管理员、项目实施工程师，曾担任红帽RHCE讲师，擅长负载均衡高可用和中小型证券类和电子商务网站架构，目前关注网站架构研究及网络安全方向。
1.首先关闭iTunes
2.之后打开我的文档我的音乐文件夹
3.将这里的iTunes文件夹剪切到你想移动到的位置（如D:\）
4.回到桌面，按住Shift键，在iTunes图标上单击鼠标右键，选择打开，注意：按住Shift别放直到出现下面这个对话框
5.点击“选取资料库”，在之前移动到其它盘的iTunes文件夹中找到iTunes Library.itl（如D:\iTunes\iTunes Library.itl），确定
6.iTunes打开之后以前所有的程序都在，但是在程序图标上点击鼠标右键选择“在Windows资源管理器中显示”时没有反应，解决方法是 Ctrl A选中所有程序，删除，在下面这步选择“保留文件”
7.最后把iTunes文件夹中的Mobile Applications文件夹里所有程序全选，用鼠标拖动到iTunes中即可，这时iTunes会显示正在处理xxx程序，等到结束时就已经成功地转移了iTunes默认下载、保存IPA的地方
维基百科对全球5000名编辑做了问卷调查，从发布的数据发现，男人在编辑群体中占有绝对主导地位，变性人也做了自己的贡献。从年龄构成来看，很惊讶的发现，40岁以上的编辑近3成（猜想这些人之中应该很少有中国人），看来年轻人在维基百科编辑群中并不是优势群体:)。教育背景，大学本科以上学历占一半以上，还有很大的发展空间，有这样一个拥有良好教育背景的编辑团队，维基百科的条目的质量会越来越好。
这些编辑多数都有一个共同的特点，他们乐于奉献的自己的时间和智慧，有肯为他人服务的精神，并向往自由和民主。
维基百科英语版、日语版、希伯来语版正在测试手机网页，也就是重新调节网页布局，以适合在不同移动客户端（主要是手机）上浏览，采用的编程语言从以往的Ruby换成PHP，主要是为了判别不同手机的型号等，这里有详细的说明。当然，维基百科也正要发布针对不同智能客户端系统的应用，如已经发布了iSO版本，好像存在许多问题，还需要继续改进。
维基百科有没有想过直接发布一个单机版的应用？把已成熟的条目直接打包，安装到用户的终端，没有的条目，用户仍然可以通过此应用联网查找，并下载到本地。或许用户会因为其所占空间太大，而不会安装？这种想法或许和现在的云计算格格不入，但是我更喜欢本地的应用，而不需要网络。
近年的地震,使民众对地震预报完全失去了信心,也许本来就应该这样,大家以前对地震预报给予太多的厚望.虽然日本的地震科学在世界上很发达,有很好的监测网络,但是似乎也没有意识到3月份地震的到来.为什么?确实,日本的科学家做了很好的工作,可时间不够长,现代高质量数据记录的时间跨度相对一次大地震孕育时间来说,显得非常小.我们每天记录了海量的地震数据,但是一个地方的大地震多长时间才会记录到一次?
地球是一个复杂的结构体,国外的经验不一定适用于中国地区，每个地区都有其特殊性，只有在研究该地区足够多的大震样本情况下，才能总结出其特殊性。
当然，在一个人的有限时间里，样本量不可能完全靠仪器来记录，可以利用其它方法，如历史地震和古地震法，利用史料和探槽特征，总结大震的历史。这还需要面对另一个问题——大震序列的连续性与完整性，如由于地貌演化等因素，探槽中记录的古地震事件通常是不完整的，有遗漏的。古地震学家们只有在理想的地貌位置上开挖许多探槽，才有可能整理出完整的地震序列，在这个基础上才能进一步总结大震的发生规律。比如，美国西海岸的圣安德里斯断裂，科学家们在不同段上先后开挖了大量的探槽，随着古地震资料的不断积累，该断裂上强震或大震复发间隔在不断缩小。
以上所说的都是当今科学家们如何去寻找大震长期的发生规律，而大震的短临异常特征的总结显得更加困难。不同领域的研究人员在大震之后一直扑捉各种蛛丝马迹，但是他们给出的答案只能是这些异常可能和地震有关系，到底是不是有必然联系，没人敢打包票。民众也应该理解这种现状，短临异常完全需要靠现代仪器去观测，他们需要更多的大震前的资料，目前这种局面，显然他们的观测资料还是不够多。
地震科学是一个很年轻的学科，板块构造学说在上个世纪六七十年代才逐渐发展起来，而现在的地震理论都是建立在板块理论之上的。如Kerry Sieh在2005年所说：
Fifty years ago we didn’t know that earthquakes were caused by tectonic plate movement. thirty years ago we didn’t know how often big faults produced destructive earthquakes. Twenty years ago we didn’t know that historically quiet megathrust faults, like the one that ruptured last week, were even capable of giant earthquakes. Fifteen years ago we didn’t know there would be technology and science to enable the creation of a tsunami-warning system.(50年前我们还不知道地震是由板块运动造成的，30年前还不知道大断层多长时间产生一次地震，20年前还不知道沉寂超大逆冲断裂会产生巨震，15年前还不知道去做海啸预警系统)
作为一门基础应用学科，研究人员们还有很长的路要走，特别是在目前科研浮躁的当今社会，国家有责任为有志于潜心研究的人员提供好的科研环境，不是资金，而是体制。
读了Kerry Sieh的两篇科普性的文章《Acts of god, acts of man: how humans turn natural hazards into disasters》和《How Science Can Save Lives》，均讨论了公众如何正确对待现有的地震知识，免受再次地震造成的危害。
Kerry Sieh是著名的古地震学家。古地震是利用探槽技术追索活动断层的活动历史，即几百年、几千年、上万年前发生在某一断裂上地震历史是怎样的。我们常说，史能明鉴或读史可以明智。古地震研究就是研究地震的历史，探明其特征，以此来对现今和未来地震发生的可能性作出合理的预测，并将结果用于工民建或大型工程中。
“我们虽然对地震了解很多，但是常常不会应用这些知识”，Kerry Sieh显的有些无奈。虽然我们认识地震的过程非常缓慢，但是现有的知识对防震减灾或许已经足够。而往往我们看到的是什么呢？地震之后，还是在近断层的地方建房子，该避让的不避让，该提高标准的不提高标准，无论是Sieh提到到台湾、土耳其、印尼还是四川地区，应该是普遍存在这种情况，不是有报道说灾后重建的房子刚建到一半就自己倒了的吗？是天灾还是人祸？我们目前的行为正是为后代埋下了祸根。
最近，Mediawiki的开发者和维基媒体的工程师们