作者文章: Fenng

德川家康之二:崛起三河

最近做项目稍有点累,每到睡前睡不着,只得看一会儿小说转移一下注意力,缓冲一下压力。用这些空隙时间把《德川家康》的第二部《崛起三河》也看完了。看第一部的时候还是比较费力的,毕竟历史背景一点不熟悉,第二本总算熟悉了一些(毕竟咱也查了好几回维基百科嘛)。

竹千代 –> 松平元信 –> 松平元康 –> 松平家康,这套 13 部又厚又长的大作到了第二本总算出现了”家康“这个名字,战国时代的日本人名字可真挺多的,贵圈够乱,这明显不利于 SEO 嘛。哪像咱们三国时候的人名,如曹操曹孟德,一个用到底,个人品牌。当然,这或多或少说明了日本就那么个弹丸之地,而一个大名的领地基本上也就是相当于一个村或者乡那么大,改了名街头巷尾吼几嗓子大家也就知道了。

说每个大名的地盘小,用数字或许能说明,号称当时最有实力进京、领有俊河、远江、三河的今川义元伐织田信长,出动了多少兵力? 两万五千! 自己的主力仅有五千, 而信长连五千都没,最后用急就章似的集合的千把人偷袭居然得手。这一仗今川一方死了武将 500 多,兵士 2500,这个比例着实让我费解,难道日本人在那个时代就已经掌握了管理学的方法:一个管理者最多只带几个兵,否则沟通上有问题…

相比家康的隐忍, 织田信长狂放更令人神往,的确是那个时代的一个怪才。不过胜今川义元的整个过程在这本书里会让人产生”误打误撞”之感,历史就是充满了巧合,短短几个时辰胜负已分。下一部信长”天下布武”,相信会有更多笔墨给描述信长。

织田信长最喜欢唱的这段《敦盛》词我找到了好几个版本:

人生五十年,
如梦亦如幻。
有生斯有死,
壮士何所憾?

–《织田信长》书中翻译的版本

人间五十年,跟下天比起来,如梦似幻,人生一度得生,焉有长生不灭者?

–百度百科上看到的版本

人生五十年(载),
如梦亦如幻。
有生斯有死,
壮士复何憾

–网上最多的版本。”复何憾”的确更有味道一些。
EOF

Linux 下的 df 命令以及其他

手边有 AIX 以及 Linux 环境,df 算是我用的频率较高的系统命令了。这个小小的命令在不同的环境中差别还是很大的。比如 “-v” 这个参数,在 AIX 上可以配合 -k -m -g 等参数显示可读性更强的信息, Linux 上只是为了兼容 System V 的 df 命令而保留 “-v”。在 Linux 上类似的命令 是 “-B” ,可以接 k 、m、g 等. 如 df -Bg 按照 GB 显示。如果同时维护这样的混合环境,在命令的使用上也要考虑“兼容性”。

以前介绍过 GNU 核心工具,不过没介绍那份有趣的 GNU Core Utilities FAQ,前两天又重新读了一遍。多少有点新内容。比如那个比较经典的问题,“Linux 下 df 与 du 显示的为什么不一样” (我自己就遇到过一次),在 FAQ 上更新了很有权威性的线索: df and du report different information

我这里补充一下的是,在比较大的文件系统上,保留给超级用户的数据块也可能会产生混淆。默认是 5%,如果文件系统比较大,这里的浪费还是比较惊人的,需要就实际情况作权衡。这个也会对 df 的显示有影响。如果创建文件系统的时候需要修改,用”-m”参数指定特定的百分数。

虽说差不多每天都在用 Unix ,但是总有无数知识盲点.

EOF

大脚(Footbig) 准备开放 API

Livid 总能搞些让人惊喜的 Web 应用。之前的备受好评的 V2EX 被阻尼后,新开发的大脚社区 也赢得了不少朋友关注。今天早晨 Livid 给我演示了几张截图:大脚准备开放 API了。

查看截图:
1、界面展示
2、样例代码截图

目前 API 主要是针对先前大脚的便签本功能(?)。如果客户能够比较轻松的把便签内容集成到自己的站点或者 Blog 上,那么和 Livid 早前的 个人数据中心 的想法还是有些一致的。

本周应该就能看到这个服务了,Livid 还在继续提高程序的健壮性。至于性能,现在“普通的 1U PC-server,性能大概在 100RPS”。

更多的小道消息:现在每条便签可存储最多 50000 个 UTF8 字符,每个帐号可以存储最多 10000 条 note,”还计划让每条 Note 都支持带中文分词的 $nc->match() 及 Tagging“

.

有想法,能实现,这两条加在一起就非常难了,Livid 正在做…..非常有意思。算起来,大脚也是国内 Web 2.0 站点三个提供 API 服务的了(除了 Yupoo 和豆瓣,还有谁? Updated: Faint ,还有N多)。

EOF

Google 的计算能力仍是独步武林

从 Greg Linden 的文章看到的数据:Google 的 MapReduce 平均每天处理 20 Petabytes 的数据。每天能跑完 10 万个工作任务。光是 07 年 9 月,就用掉了 11081 个”机器年” ,跑了 220 万个 Mapreduce 任务。这个计算能力是惊人的。

Yahoo! 也用 Hadoop 实现了 Mapreduce , 我个人感觉和 Google 可能还有一段距离。光有计算环境还不行,还要有应用程序来实现功能,Google 已经实现了超过 1 万个应用程序,Yahoo! 有多少呢?

这方面估计微软更没戏了,要是弄个不包括 “Window” 的 Windows 服务器集群估计还能差不多,否则,光是一个视窗要耗费多少计算资源? 如果服务器规模是几万、几十万台,计算能力的浪费是惊人的。微软的对抗计划是 Dryad.

所以说啊,Google 的计算能力仍是独步武林,虽然有不服气的,但有什么办法? 这方面 Google 就是强啊

EOF
补充:
更多的数据(来源):
MapReduce.png