看了活字印刷那部分后我还到 Twitter 上说，没有麻将的文化展示真是太可惜了。
后来忽然想到，那个“和”不就是说的麻将嘛！不是和平的”和”，而是和(hú)牌的”和”啊！ 这个字音还暗示了胡哥的”胡”，这是何等马屁也～
好多外国记者看活字样子误测麻将的文化内涵，谬矣。
不许娱乐，允许联想。
–EOF–
补充一: 以前流行的段子（从前同事 Tony HU 那里看来的)：
2008 年北京奥运会开幕式猜想：主场摆 1 万张(为暗合2008, 需要修改成 2008 张) 麻将桌，4 万人在民乐演奏中狂搓，乐声至高潮处戛然而止，全体起立高呼：”和！(hú,胡)”。此刻胡总书记闪亮登场。
补充二: 我个人觉得从电视上看到的开幕式还算不错的，只是孙正平的太监声音解说太差(实在不行，找个能让人”肝胆俱裂”的解说人嘛)，而且解说词写的也烂，中学生估计也写的出来。不知道解说词事先有没有给秋雨老师看看。
补充三: 秋雨老师事后赋”梨花体”一首
毫无疑问
不是我写的
解说词
是全世界最差的
利用电脑启动、收邮件的一些零散时间，看完了这本 Inside Facebook 翻译版，感觉有所得。有些朋友说没看到”实质性”的东西，什么是”实质性”的东西? 难道你要看到”成功宝典”么? Facebook 只有一个，东施效颦的模仿者学其形或许还成，学其神就难了。
Note: 一个公司能有几个技术上能包打通关的人(比如 @Livid 同学)是幸事。但在国内，往往走从泛到专的路线。
Note: 这么说是不是会伤害很多人? 但这的确是一句真话。对于公司来说，如何在创业初期找到的人都是这一小部分工程师? 对于个人来说，在创业团队如何成为这样的一小部分工程师?
Note: 工具无所谓轻量级重量级之分。Trac ，可能上一点规模的开发团队都不屑一顾了，看看Facebook，用的挺好。
Note: 虽然没看到 Facebook 如何开会的，如果 CEO 在会议上的 PPT 都不超过 5 页，其他人也不会好意思来进行冗长的会议。
Note: 嗯，如果你也有同样的特点，没准也能做CEO呢…
这本书尽管翻译行文上有一些不一致和粗糙的地方，但还是指的一看的。毕竟应该看传递出来有价值的那一部分，盯着一本书的缺点就没意思了。这本书定价不贵，建议买一本也算支持译言翻译小组辛苦的劳动了。
–EOF–
BTW: 最近工作、私事都很多，奥运也来了，可能更新频率会不那么高了，朋友们见谅!
为什么有些人创业成功，而更多人失败? 成功的人当初承担过哪些压力，做过那些重要的抉择? 有没有初创公司的创业者们必须要看的一本书? Founders at Work 或许能担当此重任。
前一段时间在财帮子网站创建人孟岩的推荐后读完了这本书，最近这几天分析 Paypal 的一些东西，又把电子版翻了出来。重新读了一遍对 Paypal 创始人 Max Levchin 的采访。10 年前创建的 Paypal 现在是美国互联网最赚钱的互联网企业，而走出 Paypal 的创建者们，也已形成了 Paypal 黑帮，手握着世界 Web 2.0 公司的权柄。
Paypal 最早并不是做在线支付的。因为 Levchin 对软件安全兴趣由来已久，最初做过软件加密、手持设备转帐软件等，在为手持设备用户开发软件的过程中发现了在线支付的庞大需求量和无限商机，这里面比较关键的一点是Paypal 的及时转身。
如果用一句话概括 Paypal 该怎样描述? 表面是财务服务公司，实际是一家安全公司。 Paypal 最开始的一段时间，最大的挑战倒不是来自竞争对手那里，而是恶意用户的欺诈行为。最高的时侯 Paypal 每个月因为欺诈造成的损失超过 1000 万美元（前面有篇文章我提到 Paypal 现在有 达 0.25% 的资损，我还觉得挺高的，没想到以前更高)，而开始大家对于可能存在的欺诈损失还有些一头雾水，可见摸着石头过河的事情，大家都干过。
与 X.com 合并后，Max Levchin 作为 CTO，而来自 X.com 的”那个家伙”做 CEO 。Paypal 技术架构差点转向 Windows 平台，因为 X.com 是运行在 Windows 上的。工程师的文化对立也比较明显，貌似一场冲突不可避免。问题如何化解呢? Levchin 精心构造了一次测试，对 Unix 、Windows 针对某应用作压力测试，”证实” Windows 扩展性只有 Unix 上的 1%。”那个家伙”闭上了嘴。随之不久，那个家伙离开了 Paypal。如果当初转向 Windows，或许现在的 Paypal 也不是这个样子了…
仅仅因为这篇对 Max Levchin 的采访，就让我要推荐一下这本书。其实，看看其它 Founder 的访谈记录，有趣的东西还有很多，各取所需吧。
–EOF–
又读了一遍这个 PPT： Federation at Flickr: Doing Billions of Queries Per Day ，发现还是值得咀嚼一下，尽管这”甘蔗”已经被吃过了。
Flickr 数据库的硬件配置一般用 16G 内存，6块 15K 硬盘，RAID 10，在 EM64T 下跑 RHEL 4，运行在 Deadline I/O 调度器 模式 。回写 Cache 用控制器电池而不用磁盘的 Cache。Swappiness 设置为 0 . 。
上面提到了 Flickr 是把 Swappiness 设置为 0 ，简单的通过:
echo 0 > /proc/sys/vm/swappiness
个别情况下这样也可能没起作用，因为实际上对 Swap 的调用是由如下的公式计算得到的：
swap_tendency = mapped_ratio/2 + distress + vm_swappiness;
其中 vm_swappiness 默认值是 60.
这是个防御性的措施。Linux Kernel 2.6 （个别版本）有些诡异行为，当有大量物理内存空闲的时候，Linux 仍(或许)会傻乎乎的调用 Swap 空间，这导致有的时候系统性能很差。有人建议如果是 INNODB 的引擎的话，可以用 O_DIRECT 的方式强制直接调用物理内存。但似乎副作用很大（存疑)。
如果关闭 Swap (swapoff -a)的话，又会遇到 OOM 的问题。这是绝对不推荐的。
还有人用的方式是把 Swap 建立到 RAM 盘上。
Swap 的自动校正其实是个老问题，几年前可能超过 4g 的 Linux 服务器都不多，而现在动辄几十 G 的内存配置，应用场景发生了很大变化，Kernel 的算法思路肯定也要调整一些了吧(尽管几年来不断看到有小的 Patch 出来，可好像 RHEL 的 Kernel 还是老样子)。
我在这里抛砖引玉，大家实际应用中应该也遇到类似问题吧? 有什么建议? 还是干脆就不管? 默认情况下其实也能跑…
–EOF–