2008年3月25日星期二

向太空移植生命


人类从来没有停止过探索太空的步伐,无论是科学幻想或者是把什么东东真的送到天上去,可我们不得不面对一个现实,在没有有效的运输工具被发明出来之前,我们基本上只能等着外星人来串门了。

换一个思路,太空中到底有没有生命?虽然现在理论上已经"证明"了这一点,可谁也拿不出有效的证据来。UFO的传言也时常出现但众说不一,美国51区依然神秘。与其这么麻烦,我们为什么不把地球上的生命"传播"出去呢?现在知道的就是原来抛出去过一个留声机什么的,那玩意儿搁现在的地球上都落后了,天知道能被外星人当什么看。再说了,茫茫宇宙,找个星星都困难,发现一台小机器的几率又有多大呢?

所以啊,想增加发现或者被发现的几率,弄不了太大的东西,只能靠数量补,搞"人海战术"了。最小的生命体大概就是细菌、病毒什么的了,这些东西体积又小,又不值钱,最重要的,适应能力强,高温黑暗无氧都难不倒他们,把这些东西传播到太空中,让他们随宇宙里的各种"风"四处传播好了。

不用担心这些东西再被重新传播到地球上,给人类带来什么危害,因为他们本来就产生于地球,既然以前我们能够对付他们,将来也能。

这样一来,也许在将来的某一天,某处的外星人会收到来自地球的礼物,凭借他们强大的科技,追本溯源找到我们,岂不皆大欢喜?另也许在将来的某一天,当我们的后代的后代的后代与外星人相聚的时候,他们会说:"我们在800x年爆发了非典疫情,在900x年流行禽流感,合着都是你们地球人搞的鬼啊?",呵呵。还也许在将来的某一天,我们会登陆到一个陌生的星球上,发现与我们同一起源,但随着完全不同的进化过程形成的"新人类",和我们的远方亲戚亲密接触不知感觉如何。

涉及到地球上最早的生命体的问题,有一说是"古菌、细菌和真核生物",并不影响我的想法的施行,不管科学的答案怎样,扔太空里就是了。一公斤就能装很多哦,超值的"大礼包"。

你能一眼找到下载链接在哪儿么?

Free Image Hosting at www.ImageShack.us

Source: http://www.fwolf.com/blog/post/387


蒼き狼〜地果て海尽きるまで〜/苍狼:直至天涯海角


我想说这部电影不好看的人,要么是没看进去,要么是太年轻。铁木真的故事已经妇孺皆知了,能以外国人的身份在蒙古国拍中国人的电影,拍到这种程度,知足吧。

蒙古的草原不算完美,大概是季节不对,有些镜头中花花草草蓝天白云是挺漂亮,另外一些镜头马儿跑起来照样是尘土飞扬,不愧为沙尘暴的发源地之一。打打杀杀的场面咱们也见多了,虽然比不上欧美的大片场面壮观,相对于东方电影来说也算不错了,呼啦啦的人也是一大片一大片的,rmvb版就更加分不清那些是真人那些是特技了。但这些不影响真正的剧情,铁木真和札木合的安达之交,铁木真为父的心酸才是精髓啊。

本来想着这部电影还是挺适合孩子们看的,可想到那几个砍人喷血的优美镜头,以及从小就弑兄的事情,还是罢了。

反町隆史虽然个子是不太像蒙古大块头,可消瘦的脸庞却更能衬托铁木真的沧桑,这可是重要的剧情需要,像大块头有大智慧里刘德华那样用模具"强身"日本人又不是作不出来。但是,我一直有一个深深的问号,每次呐喊怎么都那么嘶哑,看过的其它日本片也几乎都是这样,这大概也是日本语言的特点吧,所以有人说日剧味儿太浓了。其实看过一些韩剧,韩语说起来也是大呼小叫的,都差不多,还是中文好,绵甜静柔啊。还有,那么大一片人,没有扩音器,谁能听见啊,风有那么大,真的内功练到家了,太阳穴高高鼓起、中气十足、会千里传音么?光顾场面大,把这头给忽略了吧。

还有,蒙古人怎么都不带盾牌啊,蒙古包里不都挂着了么,弓箭那么狠,盔甲跟没穿一个样,不重视防御,真以为自己是barbarian了。

蒙古马真是又经济又实惠,个头不高,适合东方人,操纵性强,草料肯定吃得也少,也不用豪华马厩,还能征善战,让铁木真横扫欧亚大陆,哇噻哇塞,和大众甲壳虫有得一拼。

再翻回来说两句剧情,说铁木真和札木合的安达之交,其实结拜的时候都还小不懂事,可都成了气候之后展开了一场半个蒙古与半个蒙古的战争,不仅让我猜想如果Intel和AMD的老大也是结拜兄弟会怎样。。。?与这种天翻地覆的气魄相比,什么"决战紫禁之颠"就太小家碧玉喽。

史诗片算不上,年代不够远,虚构成分太少。

花瓶式的人物,Ara柯兰,体现铁木真的凝聚力和号召力也不用如此手段吧,口口声声说要作soilder,到头来又主动献身,参政的时候在旁边补衣服,打仗时又穿着盔甲却不动手,一搭没一搭啊。哦对了,札木合的弟弟暗杀那一场戏的需要,远程武器还是厉害啊,札木合的弟弟要是也会飞刀就好了,野蛮人玩暗杀的确不行哪。总是觉得野蛮人柯南里面的阿诺和女剑士更般配一些,啧啧。。。

光瞎说了,盼望着哪一天,我们也到韩国去拍拍什么太阁立志传、信长之野望、德川家康什么的,别老让日本人玩咱们的三国志、西游记。

官方网站用Firefox进不去,残念。。。对于电影的官网来说好像这种情况很少见哦。

======== 分隔符,第二场电影 =========

之所以在这里随便写几句,是因为感觉这片子得太烂了,本以为揭密大兵们在伊战中的感受,谁知道一直在拿虐囚事件说事,说得还不明不白,藏着掖着,很有耐心的我都忍不住按快进了。

看完以后,没啥感觉,所以也就写不出什么来了。


 

Source: http://www.fwolf.com/blog/post/386

2008年3月7日星期五

ssh的连接重用

原理很简单,开一个ssh连接在后台放着,以后再有需要用到ssh到同样主机的时候,直接使用这个连接的socket文件,不用再创建连接了,同理,也不需要再进行用户身份验证。

默认是关闭的,可以在~/.ssh/config中打开:

Host *     ControlMaster auto     ControlPath ~/.ssh/master-%r@%h:%p 

创建"Master"连接就可以用:

ssh -M -N -f fwolf.com 

认证成功后会创建socket文件master-fwolf@fwolf.com:22

其它的介绍资料也很多,我是在邮件列表中看到的,惭愧,使用ssh很久了,现在才知道,网上用ssh master ControlMaster搜索资料很多。

实际使用中,我倒有一个反面的感觉,创建了"Master"之后,一般的scp什么的操作的确是快了,可如果单独开一个ssh terminal上去的话,输入的响应速度很变慢。开始以为是这个ssh连接也重用了"Master"的原因,后来加上-o ControlMaster=no参数强制不使用Master,单独创建新连接也是一样,不知道是什么原因导致的。

仔细测试一下效果,首先在已经创建Master的情况下连接主机,执行命令并马上退出:

$ time ssh fwolf.com -C pwd 

执行多次,得到的执行时间一般在0.33秒左右,然后关闭Master,再次执行这个命令,平均执行时间为6.7秒,的确是快了许多。

后来才发现,刚才对响应速度"慢"的感觉应该是错误的,可能是由于另外开着一个scp的缘故,scp完成之后,速度就快很多了。之所以会感觉"慢",其实也是相对而言的,因为单独ssh连接上去之后,也是不中断的持续连接、持续响应,同样没有重新建立连接的时间,速度也是非常快的。开启Master主要对那些一会儿连接、一会儿断开,请求断断续续的情况最有效果。

另外,还有两个比较有用的相关控制命令:

# 检查当前是否已经创建Master连接 $ ssh fwolf.com -O check Master running (pid=6350)  # 发送断开当前Master连接的请求,比我用的笨kill方式好多了 $ ssh fwolf.com -O exit Exit request sent. $ ssh fwolf.com -O check Control socket connect(/home/fwolf/.ssh/master-fwolf@fwolf.com:22): No such file or directory 

参考

Accelerating OpenSSH connections with ControlMaster

Source: http://www.fwolf.com/blog/post/385

PDO和sqlite的一点体会

用php写了一个小工具,顺便体验了下PDO和sqlite,一个是php5自带的数据库层,一个是简易的文件型数据库,没什么章法,简单记录在这里。

  • 配合pdo使用,只用安装php5-sqlite即可,php5-sqlite3这个extension可能是单独的sqlite支持,就是类似mysql,有专门的sqlite_connect函数。
  • 系统中也可以安装单独的sqlite3(不带3的是sqlite2),采用类似mysql的shell方式管理库文件。
  • 通过PDO好像无法查询数据库的结构等信息,只能操作DML。
  • 不知道pdo使用sybase(dblib)的时候是否能在sql中使用limit,以及使用了是否有效,要到hardy 8.04 php5-sybase才支持pdo,到时候再试验。
  • Bug: rowCount()无法工作于pdo_sqlite数据库,其他一些函数也有小问题,官方文档的user comment中有说到。
  • PDO的exec方法可以一次执行多条sql,但不返回结果,而query则只能执行一条,返回结果信息。
  • 使用PDO的prepare和PDOStatement的execute不仅有助于加速同一sql不同参数的调用速度,还有助于防止sql注入攻击。
  • prepare的:name不能是表名,大概只能是where中的变值,prepare中的字符型:name不需要带上引号,这一点很方便。

总体感觉,PDO还没有AdoDb方便,大概是用熟了的感觉,但功能上的确要少一些。sqlite数据库表现不错,但由于数据类型、结构、功能相对简单,还是主要用在小型、简单一点的应用里更合适。

Source: http://www.fwolf.com/blog/post/384

[MediaTemple]虚拟主机内存优化的一点心得

今天下午好像有人对服务器ddos,或者大量灌spam(我不敢说每个人都安装了anti spam插件,即使安装了,"应对"spammer也要消耗服务器资源),http服务器耗尽服务器资源后挂掉,一会儿被watchdog重启,过不了多一会儿再次挂掉。。。以前也尝试过优化apache,不过今天似乎终于摸到了一点儿窍门。

我们合租的MediaTemple服务器cpu负载不高,内存相对紧张:

top - 23:39:45 up 16 days,  7:24,  2 users,  load average: 0.58, 0.50, 0.47 Tasks:  46 total,   1 running,  45 sleeping,   0 stopped,   0 zombie Cpu(s):  9.9% us,  2.5% sy,  0.0% ni, 87.6% id,  0.0% wa,  0.0% hi,  0.0% si Mem:    689496k total,   550892k used,   138604k free,        0k buffers 

所以优化主要针对如何节约内存。主机内存实际是256M,可能是多核的缘故,总显示接近700M内存,不过对应的各个进程占用的内存也相应增加了。MediaTemple的KB中有一篇(dv) HOWTO: Performance tuning (Optimization),先按照这个来优化一下,主要分为三个部分。

优化Apache(httpd)

缩短超时时限:

#Timeout 120 Timeout 30 

调整prefork参数,我调整的结果是:

 #1/1/3 StartServers       1 MinSpareServers    1 MaxSpareServers    3 # 50 ? ServerLimit       20 MaxClients        20 MaxRequestsPerChild  2000  

StartServers是开始的httpd进程数,Min和Max SpareServers是最少和最多空闲进程数,ServerLimit和MaxClients是总进程数限制,这两个参数一般来说是相同的,httpd所消耗的总内存数就和这个相关(实际进程数还会多两个,应该是负责管理子进程的"父进程"),内存不够可以把这两个数值进一步缩小,但这也同时对应着httpd同时处理的并发数。MaxRequestsPerChild是每个进程在处理多少个任务后自杀,根据需要和相关设置还会再启动新的子进程,这种机制有利于释放一些内存碎片。

MaxClients不够会在log产生错误信息,可以用下面的命令查询:

grep -i maxclient /var/log/httpd/error_log 

可以根据情况再调整MaxClients的值,但如果内存就是短缺,又能有什么办法呢?

优化Mysql

设置缓存,在my.cnf的[mysqld]段中增加:

# Cache query-cache-type = 1 query-cache-size = 16M 

虽然会多占用一些内存,但能加快处理的速度,尽快把等待队列"消化"掉,还是有利于加速的。在mysql中可以查询cache使用情况:

mysql> show status like 'Qcache%'; +-------------------------+----------+ | Variable_name           | Value    | +-------------------------+----------+ | Qcache_free_blocks      | 12       | | Qcache_free_memory      | 13028408 | | Qcache_hits             | 35117    | | Qcache_inserts          | 751      | | Qcache_lowmem_prunes    | 0        | | Qcache_not_cached       | 56       | | Qcache_queries_in_cache | 377      | | Qcache_total_blocks     | 872      | +-------------------------+----------+ 8 rows in set (0.00 sec) ...... some times late ...... mysql> show status like 'Qcache%'; +-------------------------+---------+ | Variable_name           | Value   | +-------------------------+---------+ | Qcache_free_blocks      | 88      | | Qcache_free_memory      | 8837920 | | Qcache_hits             | 164437  | | Qcache_inserts          | 3572    | | Qcache_lowmem_prunes    | 0       | | Qcache_not_cached       | 432     | | Qcache_queries_in_cache | 1177    | | Qcache_total_blocks     | 2579    | +-------------------------+---------+ 8 rows in set (0.00 sec) 

调整query-cache-size的值让Qcache_lowmem_prunes保持在0最好,设置太大了也是浪费内存。

关闭不需要的服务

比如named,域名解析使用域名注册商提供的就足够了,关闭spamassassin,邮件服务仅限于对外发送邮件,不接收:

chmod 644 /etc/init.d/psa-spamassassin 

watchdog暂时不建议关闭,人不在的时候它会自动重启服务,还是有一点用处的。

其它优化设置

从其它地方还看到可以开启KeepAlive:

KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 

这样每个连接可以发送100次请求,超时时间为15秒。如果KeepAliveTimeout减少一些,MaxKeepAliveRequests还可以设置得更大一点。

还可以启用apache的压缩输出功能:

 #   DeflateCompressionLevel 2     AddOutputFilterByType DEFLATE text/html text/plain text/xml application/x-httpd-php application/x-javascript text/css  

简单观察一下,开启deflate之后,服务器cpu idle值大概会减少15~20%,国外主机数据传输本身就慢,希望这些花销值得。

top - 01:39:03 up 16 days,  9:23,  3 users,  load average: 2.16, 2.09, 1.97 Tasks:  48 total,   1 running,  47 sleeping,   0 stopped,   0 zombie Cpu(s): 24.1% us,  8.4% sy,  0.0% ni, 67.6% id,  0.0% wa,  0.0% hi,  0.0% si Mem:    689496k total,   431452k used,   258044k free,        0k buffers Swap:        0k total,        0k used,        0k free,        0k cached 

结果

现在看一下结果,ps -U apache u能看到一共有20个apache进程在运行,占用内存总量为:

root@fwolf:~# ps -U apache u|awk '{S+=$6} END {print S}' 385396 

随着服务运行,内存使用量还会增加(所以MaxRequestsPerChild别设太大,定期重启一些进程)。再看看那个疑似对我ddos的家伙:

root@fwolf:~# netstat -nap|grep :80|wc -l 513 root@fwolf:~# netstat -nap|grep TIME_WAIT|wc -l 9 root@fwolf:~# netstat -nap|grep 124.115|wc -l 464 root@fwolf:~# netstat -nap|grep 124.115.0|wc -l 376 root@fwolf:~# netstat -nap|grep 124.115.4|wc -l 93 

此时服务器访问稍慢,有时会超时,但起以前动不动内存不足,httpd挂掉要好一些了。查了一下,这个IP地址属于"陕西省西安市 电信",地址总换,但基本都在上面两个网段之内。

再后来,访问量降下来之后,系统就恢复正常了,优化应该还是对服务器速度有一些作用的。

root@fwolf:~# netstat -nap|grep :80|wc -l; netstat -nap|grep TIME_WAIT|wc -l 69 47 

最后贴两张后台流量图表,异常大概开始于18号下午16点,导致18号流量剧增。服务器时间是西8区,所以小时图表中的0点就是16点。按天的那个图表不知为什么出不来,不过注意18号的流量只是前9个小时的就是了。

Free Image Hosting at www.ImageShack.us

Free Image Hosting at www.ImageShack.us

另外,合租的兄弟们,现在新的dv主机默认是PHP 5.2了,咱们啥时候升级呢?

参考

Source: http://www.fwolf.com/blog/post/383

为了Linux,BT可别没喽

看标题,Linux怎么能和BT扯上关系呢?并非因为这两个都是开源东东,而是,对日常拿linux作为桌面系统的使用者来说,BT真是越来越重要了。。。为什么捏?

现在用Linux免不了上网,上网就免不了下载东西,传统的下载无外呼http或者ftp方式,这两种方式基本上用wget都能搞定,除非文件比较大,而比较大的文件提供的更多下载方式是BT,包括我们喜爱的各种电影,应该说现在下载电影的主要方式就是BT了。所幸,Linux下的BT软件还是非常丰富的,那我们还担心什么呢?

说实话,我担心的是迅雷、脱兔之类的软件,今天在神话论坛下载电影的时候就发现,下载的链接是这样的:

下载 || 迅雷下载:【www.btmyth.com】先婚后友◎BT神话论坛◎神话.torrent (42.62 KB) 

只有前面两个字"下载"点击是BT的种子,后面包括名称的一长串链接都是迅雷的下载链接,作为BT用户有一种"失落"感。还有很多软件下载站,提供的http或ftp下载链接根本不能用,然后再给一个迅雷的下载链接,简直就是逼良为娼,好在我很少上这种下载站。

迅雷、脱兔在国内占有很大市场,很多人也都喜欢用,在这里我不评论他们的好歹,但我知道他们都没有linux版,所以作为linux桌面用户,下载我还是只能用BT。至于emule/amule,一般下载站很少提供这样的链接,不讨论了,和BT性质类似,反正用mldonkey也都支持。

对了,现在还有个新出的什么scm烂格式,别说不兼容linux了,在windows下也不稳定,还没法转码,比avchd还难搞定。

假如没有了BT,大家都只提供迅雷或脱兔的下载链接,电影都是scm格式,Linux用户怎么办?像qq一样放弃么?

Source: http://www.fwolf.com/blog/post/382

Ô-oku/大奥

不得不承认,这部影片对于不太熟悉那段日本历史的我来说,有些拖沓,虽然在神话的介绍里说明了是"日本06古装真实历史丑闻大片",看完之后对丑闻还真没什么感觉,但还是有很多看点的,故事性上评C的话,制作工艺上就要给A-的成绩了。

画风很好,优美得像日式的漫画,片中角色也都像在作慢动作,随时都可以停下来成为一幅照片,加上女美男俊,甚是养眼。

伎不是妓,很讲究"技"的,和中国以前一样,女人地位低下,是不能参与戏曲表演这种"高尚"行为的,戏中的女人仍然要让男人来扮演。不过片中那么多疯狂的女观众实在出乎我的意料,不知道是史实还是改编,中国古代定然是不会有的啦。

从古至今,宫廷都是人心最险恶之处,尤以后宫为甚(这一点现代社会好多了),万恶的封建社会哦。

天英院老大自己也不干净,还有很多人也是有贼心无贼胆,往好了想也许是日本战国时代男人比较稀缺的自然产物,往坏了想也许是编剧加入了更多的现代社会的意识形态。

绘岛工作的时候要比谈对象的时候漂亮,真的。(涂老鸦甚至还会联想到"不纯洁了。。。" XD)

和服很漂亮,男士的服装(也叫和服么?)也不错,并且,从后面看显得男人上身很宽大、魁梧,真是比唐朝的大宽袖子好看多了。

将军的每个家臣衣服上的"标识"好像都不一样啊,太阁立志传什么的我是外行,这个。。。正常么?

所有的人都是白袜子,看来日本空气真的很好,地板擦得也干净,也没有人汗脚、臭脚,搁现在的中国北方还没出门估计就得换袜子了。

最搞笑的是轿子啊,那么矮,难道他们都不会把抬杠放在轿箱腰部么?

最让人着急的就是女士们上台阶,还是想不通,和服在脖子后面舍得空那么大一块,怎么在脚下就不会开个分叉呢,像旗袍那样。

日本人真的很勤劳,戏院里倒茶的都是一路小跑。

有机会真想看一场原味的日本戏曲,那个戏台也很讲究哦,后面布景的更换,前面还是个歪T字布局。

Source: http://www.fwolf.com/blog/post/381