之所以说二者是竞争关系，关键字还是在于"平台"。Adobe Flash 是当前业界占有率最广泛的一个技术平台，甚至超过大家想当然的 Java 。根据 Adobe 的统计，Flash Player 占领了 99% 可上网电脑设备，有超过 200 万专业用户在使用，这里的专业用户应该指具备一定开发能力的用户，依托于 Flash 的应用程序数量已经相当的惊人。所以，是否在 iPhone 、iPad 上引入 Flash 的支持，从苹果的角度看，这是平台之战，谁也不想引狼入室。我们设想一下假定 Flash 已经得到了苹果公司的支持，那么 Adobe 可以一转身也建立一个 "Flash App Store" 或者类似的东西，开发者可以用上传的小应用，任何平台的用户都可以下载使用。想想对苹果的冲击会有多大? Adobe 或许还没想好如何也建立一个 App Store ，但不排除将来会染指这一块业务。

苹果公司长久以来不太有"开放"的态度，或者说是"封闭的开放"，最希望通过自己封闭的环境，让用户通过圈下来的地建立一个生态圈子，不想和其它公司一起合作。乔布斯回归后，通过激发用户对 iPod 喜爱与信赖，进而购买使用 iPhone ；通过 iPhone ，进而使用 iPad ；通过 iPad ，再回去使用 Mac 。这是个非常好的封闭循环过程。开放，会丢掉利润，而封闭，才会让苹果公司有更大收益。当然，我也想说的是，对 Flash 的支持友好也的确有可能让 iPad 在某些方面导致平庸，比如性能。与之类比的是 Firefox ，现在速度问题广为用户诟病，而这问题基本由插件导致的，现在 Chrome 尽管足够快，但随着扩展日益增多，必然重蹈覆辙。

现在乔布斯游说内容提供商加入他的 iPad 阵营，而他之所以敢批评 Flash 的不足，也是因为还有另外的技术路线可选，那就是 HTML5 。但是有多少内容提供商会舍弃 Flash 而加入 HTML 5 的阵营，这个还需假以时日才能看清楚。换做另外一家公司，来自用户的呼声可能都会受不了，对于苹果来说，我行我素是一贯的风格，乔布斯一直是个精明的商人。

是否会在 iPad 上看到 Flash ? 将来或许会，但是这要在乔布斯开给 Adobe 的条件都得到满足的情况下才会出现(没错，这两家现在或许已经在谈判桌上了)，这些条件当中，除了解决当前的性能和稳定性问题(这个问题并非原则上的问题)，最重要的是 Adobe 不要与苹果有商业利益上的冲突，苹果一定要得到某种承诺，而这，对于 Adobe 来说，也会是艰难的选择。

--EOF--

注：春节期间构思此文，一直没发出来，后来发现有不少人也持类似观点，澄清一下，并非拾人牙慧。

说起平台，国内 360 安全卫士尽管已经取得了惊人的装机量，进而推的浏览器和网址导航也都立竿见影，但是还难脱"工具" 的影子，还是不能形成技术生态环境，我相信不会有类似 "360 平台" 的产品出来的，不是不想，而是做不到。

Sun(Oracle)公布的 Java 在桌面机有 8 亿。

彼时的乔布斯，恰似刚受封齐天大圣，自信无所不能，被排挤到 Lisa 项目之外意味着他将来没有权利说这是他设计的产品，所以最想做的事情就是找个项目来证明自己。他对于 "自己参与设计" 的项目无疑是寄予厚望的，也给予了足够的支持，否则这个从概念项目起步的团队也不可能发展起来。对于这个团队的多数人，他们要研发的这个产品，不为名不为利(实际上也只有少数几个人得到了名利)，更多的是创造性工作给自己带来的成就感，什么是激情，或许这就是。

对于 1984 年苹果推出的 Macintosh ，现在来看，或许是那个寓意深刻的广告更为令人津津乐道。当时的 Macintosh 只能算是杰出的电子艺术品，是否是成功的产品很难定论。毕竟从市场表现来看，没有给苹果带来像 Apple II 那样的辉煌。这个产品的推出从某种程度上也间接促成了乔布斯被赶出苹果。 是苹果公司发展历史上的一道分水岭。如果没有当初，或许也不会成就现在的乔布斯。现在的 Mac，其实无法让人等同于 1984 年的 Macintosh...我相信只是有些精神会延续下来...或许这样就已经足够了。

在这本书的最后， 作者 Andy Hertzfeld 感伤 "我所渴望的理想麦金托什团队模式已经消失了，融入了那种我们以前常常取笑的大型组织当中，内部充满官僚障碍及人际摩擦"。曲终人散，这个团队的大多数人都将不再服务于苹果公司。这也是那些非凡团队成员的普遍命运。

阅读这样一本书，对我们更有价值的事情从中学习那些经验和教训，关于人，关于事。让人欣喜，让人心酸。

--EOF--

虽说年底是 IT 事故多发的期间，不过这次民生银行系统瘫痪事故还是让人觉得有点严重。事发 2 月 3 号，从上午11:00到下午15:30，故障持续四个多小时，全行系统瘫痪。对外称是"核心系统维护"。

个人之所以比较关注这个事故，是因为新闻标题中的"数据库维护失误"。据说是"由于数据系统进行维护时出现了失误，造成宕机"。开始的时候，大家把关注的焦点放到灾备切换与否的问题上，据说是"没敢切换"。初看上去倒是有点像 DBA 误操作。有人说是和时间服务器有关，我错过了讨论现场。

也有朋友在 Twitter 上说：民生银行上周的系统宕机事故，源于IT部门某应用系统数据库（应该是 DB2 Informix，数据库版本老旧，且无正常维护服务），一个应该在夜间处理的长任务，运行到银行开门也未结束，该系统正常时的CPU使用率就已经到达70-80%，长任务从夜里一直跑到上午无法停止，把本来就不堪重负的业务系统拖慢到不能忍受，由于数据库版本 EOS (End of Service) ，无厂商实验室的工具支持无奈之下，要求重启相关系统，结果造成业务停止。事件的(后续)处理还在进行中。(via)

上述说法看起来比较可信，也足以解释为什么不切换到灾备上。如果因为计算能力的不足 (或是系统性能问题) 的话即使是切换也无济于事的。民生的旧系统是 SAP 核心，实施方是埃森哲(refer)。不过，"民生银行打造的新核心系统已经开发完毕，目前处于内部运用的阶段，今年上半年将会在全公司上线"，估计到时候能稳定点?

另外看到有网友说，2008 年初，民生银行的的小额支付系统也出过严重问题，由于操作失误或是程序内部控制原因，造成了几百万的重帐。

涉及到钱的问题总是让人如履薄冰。根据我个人亲身经历过的一些事情来看，事故发生后，更多的时间都会花在决策上，而一旦选择错误或者不是做出最优的决定，灾难才刚刚开始。

--EOF--

有朋友后续补充到：2010 年 2 月 12 日上午 10:25，民生银行的信用卡网银不可用，返回 HTTP 500 服务器内部错误，网站上并没有相关的维护计划，咨询客服，说是系统维护升级。整个民生的 eBank.cmbc.com.cn 都是无法登陆的状态，看来"维护升级"的不只是信用卡网银，自2月3日以来，不到10天又发生状况。

我们知道 eBay 在 2002 年的时候也在 Sun 技术团队的帮助下，将整个应用架构从 C++ 迁移到 J2EE 。也就是 eBay 内部所说的 V3 版本(refer)。

最近一件有趣的事情是，据说腾讯的财付通在招聘 Java 方面的高手，"参与系统架构选型"，要把底层架构从 C/C++ 迁移到 Java 架构上来。另外，百付宝的后台技术据说也是基于 C++ 的(最开始的时候只是一两个人写核心代码）。我相信，现在百付宝或许规模还比较小，总有一天，也要面临向 Java 的迁移。这和阿姆达尔定律有点类似，要得到更大的计算能力，就要尽量减少整个系统中的非并行的环节。只是一两个人能搞定的地方，再加入更多的开发人员也是无济于事的，除非，改变协作的模式。

去年接触到的一些国内的电子商务公司，有些已经在进行技术架构上的变迁，当然，多数是从 Windows 平台迁移到 LAMP 平台，究其原因，也无非是成本与效率，而后者，更为大家所看重。当然，也有一些顽固派，比如京东，仍然固守原来的手工作坊技术模式。

如果单兵作战的话，很多程序高手会说，"用什么语言都是无所谓的"。但是如果是团队协作开发的话，用什么语言，影响则是不一样的。对于电子商务网站来说，语言的选择意味着不同的架构路线、不同的开发框架、不同的测试框架、不同的部署流程，最后更为主要的是不同的开发效率，意味着可以把更多的开发资源并入到当前的环节中。

事实上，对于一个高速发展中的网站，每隔18 或 36 个月，几乎总要有一次架构上变革的阵痛。没有这种变革的勇气，意味着以后也不会有人敢做这个尝试。没有这种阵痛，就不会有成长。

变化的节奏最后影响一切。编程语言的选择并非无关紧要，短期看来似乎影响不大，从长期来看，决定最终的竞争结果。这就是我要说的。

--EOF--

所处的位置不同，不同的人阅读这本书会有不一样的体会。给我印象最深的是郭士纳初入 IBM 所采取的策略，"我们只有很少的时间用来找出问题，大部分时间、精力和关注点都将用于解决问题和采取行动上。"

问题本质

新的 CEO 上任之前从众多人的建议中就已经抓住了问题的本质(收到众多建议的时候如何过滤重点?)：IBM 不缺乏能人和天才，公司也不缺致胜战略，新领导人要从"战略"和"文化"等方面推行改革入手。这个改革，体现在具体行动上，是后面的"热烈拥抱"计划，说白了，也就是"拥抱用户"，倾听用户的声音，解决用户的问题，赢取客户信任。然后才是财务方面的止血，最后才涉及到远景规划。能从千万重关系中抓住这些关键点，这是核心能力的提现。

对待人才的策略，也就是如何对待现有管理层，郭士纳也是自有一套。在第一次会晤管理人员的时候就主动传递了这样的信号： "IBM 历来是个人才济济的地方...只有如果有必要的时候，才会从外部引入人才"。但是我相信，这样的策略恐怕只有针对 IBM 等少数公司才会有效。多数公司不能照搬--如果问题的本质抓不住的话。(实际上，郭士纳后来还是招聘了不少曾经和他合作过的管理人员进来。)

对于这只管理团队，也不是真的没有问题 ，当时的 IBM 比较严重的官僚气是存在更多关心公司内部部门之间利益争夺而不是关注竞争对手的情况。任何一家大公司都会有既得利益者，这一点大家都会有共鸣吧。

"大象跳舞"

这本书的书名有多重隐喻。其命名或许和 TIME 杂志的这篇 Can This Elephant Dance? 有关。"大象跳舞"是什么意思? 对于 IBM 这样的庞然大物来说，跳舞意味着优雅、协调，意味着摆脱笨拙。而一旦大象能够做到以这一点，那么竞争对手自然不足为惧，因为问题来自自身而不是外界。

"Elephant Dance" 应该是个证券行业常用语，大致是"大盘股活跃，反复上涨"之意，从这个角度上来说，郭士纳也做到了，IBM 股价在他的任内也是一路上涨。

--EOF--

乱翻书，不求速进，但求有所得。

(via)

人们谈论起 Sun，总要说起这家伟大公司曾经的辉煌。Solaris、Java、SPARC、NFS......

很多人知道 Sun 是 Stanford University Network 的缩写，不过 Sun 的创始人并不全来自斯坦福大学，虽说 Vinod Khosla 、Andy Bechtolsheim 与 Scott McNealy 三个斯坦福的毕业生是 Sun 的发起人，稍后加入的 Bill Joy 大神则来自伯克利，他尽管不是发起人，但也是公司创始人。对于创始人中的 Andy Bechtolsheim ，必须要多说一嘴，多年之后，是他给了 Google 两位年轻的创始人第一笔 10 万美元的天使投资。

二月创建的公司，当年七月份就已经盈利，这是因为 Andy Bechtolsheim 在成立公司之前就已经设计处了 Sun 的第一代工作站。Sun 工作站在当时可以说无敌于业界，十余年间就卖掉了 1 百万套。而到了 1995 年 Java 推出的时候，简直让业界疯狂，我还记得当初的报纸写到"几乎一夜之间互联网动了起来"，这是 Sun 对业界最大的贡献。尽管 Sun 的品牌在将来或许消失，但是 Java 仍将继续改变这个世界。

公司创建四年之后成功 IPO，股票代码 SUNW ，最早代表 Sun Workstations ，这是 SUN 早期现金牛产品，后来解释为 Sun Worldwide，而到了 2007 年，则更改为 JAVA。这个更迭多少意味着 Sun 的无奈。Solaris 工作站已是明日黄花。在第一波互联网泡沫破灭前，Sun 市值一度超过 2000 亿美金，这是个惊人的数字。互联网上运行的服务器有 35% 跑在 Sun 的服务器上。彼时，Sun 自诩 "We are the dot in the .com"，可惜 Sun 后来的志向 "We're the Dot in Web 2.0" 未能实现，壮志未酬。

除却 Java 之外，Sun 在其它方面的产品创新几乎都有 Bill Joy 的功劳(其实 Java 项目也有他的推动)，这位号称在一个周末重写 BSD 内核的大神，在 Unix 操作系统领域带来惊人的成就，对业界产生无与伦比的影响，甚至他一个周末写就的编辑器 vi 都是很多 Unix 用户离不开的工具 (更正)。Bill Joy 在 2003 年从 Sun 出走(据说与麦克尼利不和)，他的离去给 Sun 蒙上了一层阴影，从此后，Sun 在 Unix 方面鲜有有创新(这几年数来数去也只有 ZFS 算有点影响力了)。Bill Joy 在离开 Sun 之后转投纳米技术、机器人学等领域，在软件技术方面未有大的动作，但说不定这天才什么时候杀个回马枪呢。

Sun 创造了 Java ，却无法从这个金矿上赚钱。以往的分析往往认为 Sun 卖硬件卖得太舒服了，没能够及时转型。这倒的确是很重要的一方面。而另一方面是开源社区(甚至 IBM )都比 Sun 更能赢得用户的心。而 IBM ，更是抛出了 Eclipse(日蚀)项目以及后来联合其它公司成立了 Eclipse 基金，这实际上是用免费策略断了任何公司想在 Java IDE 上盈利的念头(当然主要针对 Sun)。Sun 在硬件服务器领域和 IBM 争夺市场，而 IBM 则在 Java 上断了 Sun 的后路，除此之外，IBM 亦大力扶植 Linux，甚至鼓励用户将大型机迁移到 Linux 环境下，一方面节约遗留系统维护成本，一方面硬件照卖，这是很高明的一招。

反观 Sun ，在 Linux 渐成燎原之势的时候，应对战略相当的失误，与 IBM 拥抱开源截然不同的是，Sun 采取冷眼旁观。等到 Jonathan Schwartz 主政时期，力主推出 OpenSolaris 策略虽说是一步好棋，但是时过境迁，为时晚矣。试想如果在 Linux 崭露头脚的时候，Solaris 就能够开源或者是 Sun 能援助一臂之力，那说不定就是另一番天地了。

Sun 在收购策略上一直是走弥补硬件产品线的策略，大多数收购并不成功，收购 StorageTek 花费的 41亿美元似乎是绝对的赔本买卖。收购 MySQL 虽说被业界看好，甚至 Jonathan Schwartz 称收购 Sun 是"现代软件史上最重要的并购案"，可没想到仅仅一年的时间，Sun 自己也被卖掉。到现在，MySQL 仍前途未卜。

说起 Sun ，当然绕不开执掌 Sun 帅印长达 22 年之久的斯科特·麦克尼利(Scott Mcnealy)。Sun 成也麦克尼利，败也麦克尼利，说到底，他毕竟是一个商人，一个刚愎自用的商人，对于 IT 大势的判断仍然比盖茨差几个段位。Sun 的四位创始人当中，他其实是没有任何技术背景的。"网络就是计算机" 据说并不是他提出的想法，而是 Sun 的第五位员工的灵光乍现。麦克尼利给中国用户的更多印象是对微软的抵制和对盖茨的敌意，这一点倒是和拉里埃利森是一路人。一个人成功的时候，大家看到的都是他的光环；一旦失败，大家都会去指责他的缺点。

现在有一个公司颇像辉煌时期的 Sun ，那就是 Google。

"一代人来，一代人走，大地永存，太阳升起，太阳落下，太阳照常升起。"

--EOF--

说起 Bill Joy ，在 2000 年曾经发表过 2 篇影响深远的文章：

• Why the future doesn't need us
• Design For The Digital Revolution As computers change the world, we need to make sure the new world works for humans.

第一篇广为流传，而第二篇似乎少为人知。这两篇文章现在看来，仍然像一位先知对未来作出的预言。这一年，Bill Joy 46 岁。

后记：McNealy "I love the market economy and capitalism more than I love my company"

又及：当年有传言说 Sun 准备收购 Apple，如果成功的话会怎么样呢？历史不容假设啊。

揣测 Google 这样做的动机与商业目的对我们大多数人来说没有什么实际意义，不如让我们把讨论的焦点放在这次事件背后的问题上：这次实际上是客观承认了"内容审查"（refer: Censorship）变本加厉的既定事实，也让更多人知道了这一现状对社会带来的负面作用。对互联网的不当隔离与审查是不符合普世价值的，尤其不符合人民群众对于"先进生产力的发展要求"，是民众无法认同与接受的做法。Google 对于互联网来说是先进生产力的绝对代表者，如果将其拒之门外，那么可以肯定这无助于社会的进步。

如果说出于政治目的的审查有其可解释性，但是为了"倒洗澡水而把孩子也倒掉"则是极其错误的做法(当然，表面上都是以一些类似"保护未来的花朵"为借口，这和过去那些重大对立冲突的导火索何其相似也)。这种错误的做法还包括前一段时间的 IDC 整顿、域名整顿等一系列事件乃至要推行网站白名单的传说，这些都是操作层面上的极度不当。"疏"与"堵"，历史给我们带来无数次的经验教训，后者无疑是饮鸩止渴。我不知道在皇帝的新装的那个故事中，喊出来那家伙其实什么也没穿的小孩受到了什么对待，也不知道皇帝是否再次上演新装的闹剧。是在我们这里，似乎这样的闹剧无时无刻都在上演。

上网十年，从一个乐观者变成了悲观者。历史有的时候是进一退二，有的时候是以退为进，还是让我再乐观一次吧，期待 Google 这次准备撤离会唤醒我们更多的思考，给我们带来哪怕是一点点的进步。

--EOF--

更新：

在审查过程中造成的直接和间接的经济损失似乎少有人关注，不知道是否有经济学人关注这一领域。如果有人算一笔经济账，恐怕会是个惊人的数字。而有关部门相信也是投入了大量人力物力的，这也是不小的资金开销。

因为在兄弟公司中第一家推出官方 Blog，可参考的同行案例并不多，借鉴了一些 Google 运作产品 Blog 的大致思路和策略(尽管没有明确的策略)。所以，更多只能是摸石头过河，一点点的进行尝试。这里总结一点运作的经验，以供后来人参考。

避免陷入争论

对于用户的疑惑或者质疑，做解释说明(To make plain or comprehensible)，不要辩解，也不要争辩。其实总有一些话题一些客观因素导致的现状是很难迅速解决的，比如"网银对非 IE 浏览器的支持"，一旦就某些观点讨论起来，很容易陷入论战。身处漩涡是一件危险的事情，更好的办法是说明，中立性的的说明。在这里我也建议如果遇到恶意攻击，最好的办法当然是保持沉默。

传递必要信息

说是"官方"，但不意味着事无巨细报道公司的一切，也没有必要专写一些小道消息，有关公司文化或者公益活动等事宜是有必要进行宣传的。而有关产品更新，有关用户问题的跟进解决是有必要进行说明的。而我个人比较关注的是一些被忽视但是对用户会有价值的地方。

关心有用指标

我知道有很多公司的官方网志是有专人维护的，而且，主管会定下来很多莫名其妙的指标给维护人，比如访问人次、PV 等等。其实这些指标可能会背离做这件事情的初衷。产生价值有多种渠道和方法，通过 RSS 、转载等多种渠道更能够有效的传递信息，未必一定要用户总在本地阅读，而用户阅读的多寡也不意味着信息传递价值的大小。所以，对于支付志来说，重要的是对用户传递产品信息与公司理念，前面一两个月我还是关心访问人次，到了后期，我更关心的是内容引用率的跟踪，以及引用本站内容的网站所产生的影响。

制定内容策略

在准备运行的时候，针对内容制定了如下几条原则，现在看起来依然适用：

• 我们可能会犯错误，但一旦发现会尽快纠正；
• 所有评论在通过管理人员审核后发布，并且将在适当时候尽可能快地回复评论；
• 我们将尽可能对引用的文章和内容给出初始连接；
• 对所有不同的意见我们都将给予尊重。

这里面要说明的是对待留言的态度，我对留言的处理先行定下策略，实际操作中有章可循。

积极对待反馈

官方 Blog 的维护过程中，会看到非常多的用户反馈，而有些典型但是没有引起重视的问题要第一时间转发给内部团队，积少成多，长期下来看，这个收益是非常可观的。也有用户会提供针对某些长期问题的自行解决办法，也是非常值得参考的。有的时候，可能从有些角度看，只是小问题，但是对单个用户来说，都是大问题。不要忘了蝴蝶效应，小问题，可能也会带来大影响。这也是我在开始游说开辟 Blog 的一个出发点。

善用媒体工具

适当利用 Twitter (@Alipay)或是新浪微博( @支付宝 ，已经有超过 5000 人关注了) 等工具，面向不同的关注群体做一下信息广播也会有不错的效果。

结束语

必须要说的是，尽管获得了一点经验，但实际上现状距离目标还相去甚远，还有太多不尽人意的地方，只能尽力为之。

--EOF--

VMKid - 手机虚拟机与无线互联网技术平台

年底的时候，猛犸科技( VMkid.com ) 在杭州 BetaCafe 举办了产品发布会，演示了他们令人心动的手机虚拟机技术以及无线互联网平台解决方案。这是一家颇为神秘的初创公司，甚至官方站点到现在还没有正式对外开放，不过已经得到了阿里集团旗下子公司淘宝的大力支持。创建人在硅谷爬摸滚打了多年，对技术趋势的把握非同一般。相信在 2010 年，这家公司会在业界有不小的动作。

Yupoo -- 图片托管解决方案提供商

又拍(Yupoo.com) 虽说是在几年前创建的，不过在 2009 年开始了二次创业。创始团队在 2008 年底被迫离开，到了 2009 年末颇有戏剧性的取回了控制权，宣布再度归来。随后的 Yupoo 进行了一系列的调整，无论是个人摄影爱好者还是电子商务网店用户，都有对应的图片解决方案。年底的时候 51.com 悄然对封锁了图片外链，给不少网店用户带来了恐慌，相信会给第三方图片托管一个很好的发展契机。国内需要有个第三方图片托管服务，期待 Yupoo 接下来会大展拳脚。

DNSPod - 智能DNS解析服务提供商

因为 2009 年 6 月份暴风影音域名解析引起的大规模断网事件让 DNSPod 引起了很多人的关注，也让更多人知道了站长吴洪声，不到半年的筹备后，DNSPod 已经进行了正规的商业运作。依托 DNS 的服务国外有大家颇为熟知的 OpenDNS，而 Google Public DNS 的发布无疑也给了 DNSPod 足够的信心。考虑到国内独特的互联网环境，DNSPod 自然不愁客户。

射手影音播放器 -- 一站式多媒体播放工具

射手影音播放器是射手网站长发起的项目，到现在或许还没有进行商业运作，不过谁说一定要商业运作呢? 说起播放器，在国内客户端工具竞争到白热化的今天能做到创新是不容易的，但是射手播放器仍有独到之秘。且不说绿色无广告，依托射手网的字幕资源的"智能下载匹配字幕"功能让用户再也不用担心找不到精确的字幕。这也是 2009 年我唯一新安装的一个桌面客户端工具。

监控宝-- 网站性能监控的在线服务

监控宝提供第三方网站运维服务，主要针对网站性能、服务器状态的监控。对于大网站来说，绝大多数都会自荐监控系统。监控宝则有点像服务于初创公司的初创公司，很多还在起步中的网站要么没任何监控服务，要么自己费力做的监控成本太高，这个服务的出现倒是弥补了市场上在这方面的空缺。

在新的一年，在新的互联网形势下，相信创业会更加艰难，不过，寒冬过去才是春天。想到这些，才有希望。

--EOF--

Weta Digital 的计算集群在 2008 重新进行了设计，采用了 HP Cluster Platform 3000BL 集群平台作为其解决方案， 操作系统是 Linux ，在 TOP 500 超级计算机中排名也从最初的 400 多上升到了 190 多名(refer)。这套环境在 2008 年的时候是 4096 个 Core，到 2009 年增加到 5936 个(refer)，而不是所说的 40000 个 (refer，我猜测是笔误)，在 TOP 500 超级计算机中一度排名第一的 IBM 的走鹃（Roadrunner），也不过才 12 万个核而已。

总内存有 104 TB，内联采用的是万兆以太网，没有使用 Infiniband 。BL2x220c 是惠普面向高性能计算推出的刀片服务器，其独到之处是一个刀片内放两台服务器，每服务器有两个 4 核 CPU，用的是 Intel Xeon 处理器(支持 EM64T 技术)。

整部电影大约 3 PB 的数据存放在 BlueArc 和 NetApp 的存储上，数据传输走光纤通道。电影完成时一帧的数据是 12 MB，一秒钟 24 帧，每分钟的数据就有 17.28 GB，而整部 AVATAR 长达 160 多分钟。我想不会有哪个人在自己的 PC 上有这么样的一部电影吧，恐怕也是没办法播放的。

Weta Digital 大有来头，这是彼得·杰克逊（Peter Jackson）创建的公司，因为给《指环王》制作特效而受到业界瞩目，其实还有不少电影，比如《金刚》《机械公敌》以及前不久的 《2012》，也都是由 Weta Digital 制作的特效。不知道我们国内的导演有没有创建过类似的公司，当然，我相信他们对动画特效的运用与理解恐怕还差得很远。

计算机集群能力的提升从一定程度上推动电影艺术的发展，对电影来说，电影越来越好看，票价也是越来越贵。而因为摩尔定律依然有效，计算机集群的运算能力是逐年提升的，成本反而下降，只要能取得更震撼的视觉效果，剧情不太白痴，投入产出似乎倒也是一笔明白账。

--EOF--

读这本书是从 Brad Fitzpatrick（Memcached的作者） 的采访开始的，因为整本书里面他最年轻，Brad 在 1980 年出生，能够跻身一群业界技术前辈中间是非常惹眼的，他什么时候开始接触计算机？5 岁。整本书里面采访的一些程序员，也多半都是在高中之前就接触计算机并且被 0 和 1 的世界所吸引。国内现在仍活跃的一些顶尖程序员，比如云风、章文嵩，也都是很小的时候就开始接触计算机（而实际上很多资深的程序员在一起，几乎都会谈到 Apple II，这是一代 IT 人的技术启蒙之门）。

从很小的时候开始接触计算机，并且对计算机产生兴趣的话，那么到了上大学的时候，可能已经积累了 10000 小时的实践经验，意味着他已经跑在很多同行的前面。而如果对计算机接触较晚的话，那么发现了自己的兴趣之后自然要投入大量时间去进行实践，也就是我们经常读到的那些国内第一代程序员的典型故事：整天泡在机房蹭机器，通宵达旦。最近这个 10000 小时的说法因为《异类》这本书的火爆而再次流行起来。就我个人的理解，类似写程序、下围棋之类的事情要实践的量达到一定程度才会产生质变。

"二十岁不成国手，终生无望"，用在计算机这个领域或许有点绝对，毕竟大卫·卡特勒 这样的牛人在 20 多岁才开始折腾计算机的，国内也有王江民 39 岁学计算机的励志故事。不过不要忘了，那是什么时代? 此一时，彼一时。看这本Coders at Work 至少能够警示我们，其实没那么多天才，大家眼中的天才也都是经过数年的苦功夫才熬出来的。

另外一个有趣的现象是会发现这本书里面受采访者的父母有很多也都是理工科出身的，孩子在很小的时候就耳濡目染接触到很多技术方面的信息，对于以后的投身 IT 行业有一定影响。从这一点来说，国内很多家长望子成龙心切，硬逼着孩子去整天上什么音乐舞蹈之类的学习班其实对孩子的成长没啥太大的帮助，除非有兴趣才会达到足够的练习实践时间，否则孩子自己也会疯掉的。

--EOF--

又及：有伟人说，"计算机要从娃娃抓起"。要我看更好一点的做法应该是，把计算机早点扔给娃娃。

传统的格式如下图，绿色部分为 ECC (Error Correcting Code)区域。一般来说，每存储1000位(bit)的数据就会有产生一个物理错误，所以必须要有一个可靠的校验机制。这也是 ECC 必不可少的原因。

每 512 字节用一个 ECC 区，占用 40 字节做错误矫正代码，这在需要存储大数据量的时候，显而易见是比较大的物理空间开销。而将扇区扩大，使用一个相对比较大的 ECC 区也是同样可以达到安全存储的目的。

如果使用 4K 的扇区，则大约需要 100 个字节的 ECC 区域就行了。空间收益大约是 7-11% 。对于存储工业来说，这是惊人的。当初设计硬盘规格的时候，估计研发者是无法预见到信息如此迅速膨胀的今天的，512 字节已经不太适应现在一个平均 I/O 的大小。

值得注意的是，这个变更更多是在空间上的收益，在性能上的收益还不确定，当然不会变得更差，至于是否有提高，能提高多少，要看具体的场景。另外，也不会提高硬盘的可靠性，每 12.5TB 的数据依然会有一个不可恢复的读错误。(refer) 。4K 扇区其实在数年前就被提出来，只是最近 Western Digital 才真正的推动，估计是因为磁盘容量要保证每年的增长率带来的压力。

使用该技术对或许企业级服务器用户并不会有什么太大的风险，Western Digital 同时也在固件层提供对传统的 512 byte 扇区的模拟方式。另外，也可以下载这个官方校正工具。对于个人用户来说，多少还是有点影响的，尤其是使用克隆软件安装 Windows XP (Windows 5.x )以及更低版本的操作系统的用户可能要注意一下。

4K 是个有趣的数字，还记得 4K偏移量的问题么？

未完，待补充 ...

延伸阅读：

• How to 4k Align Flash on Solaris x86

准则一：不要发布不为公众所知的和公司相关的业务数据。如果要引用公司的公开数据，不要加主观的断言。对于关注你的人来说，小道消息并非那么有价值。

准则二：不要匿名攻击公司(包括自己的雇主和竞争对手)。尽管"在互联网上没有人知道你是一条狗"，但是，雇主还是很容易知道你是公司里面的哪一位。

准则三：Twitter 上的信息具有不可修改性，被转发后会引来不同的解读。所以发布消息前要衡量是否会对同事或团队造成负面影响。如果回答为"是"，不要发布。

准则四：倾听用户的声音，收集用户反馈而不要和用户争辩，如果能够解释，进行必要的解释，但是记住不要推脱责任，尤其不要攻击或是嘲讽用户。

准则五：如果你的主管或同事不能理解或者认可Twitter会对公司带来的价值，向他们解释，同时最好能证明使用 Twitter 并非是在浪费工作时间--用 Twitter 或许比用 IM 更节省时间。

准则六：必要的时候尽可能转发对用户的警示信息，比如"系统维护公告"或"费用调整"等信息应更快更及时的传递给用户。

准则七：团队的内部规划，正在进行的项目及相关实施细节，未经相关负责人允许也尽量不要披露，以免带来各种不可预期的不利影响。

很多人在 Twitter 上发消息，不可避免的会提及自己的雇主。新用户或许意识不到 Twitter 对消息传播的便捷性会带来的破坏力，如果没有一个类似指导原则的话，可能不经意间就会对雇主造成负面干扰，也会给自己带来一定的麻烦。这里的准则或许不能覆盖所有的情况，所以更多的时候要依赖于常识来判断。

如果你在鼓励同事或者朋友来用 Twitter 或者其它微博，要向他(她)说明这些。( 感谢 @hutuworm 同学贡献了准则七)。

--EOF--

对此，图灵出版社刘江先生回应到，"技术出版的危机。此书首印 3000 册，定价75 元（不低），利润空间仅两三万，如果部分滞销或退书，很容易就赔了。" 而且，"这本书如果按5%给版税，还不如千字稿酬。" 这实际上道出了当前英文 IT 图书引入国内的一个困境。国外出版社版权费用本已经不低(所以博文视点更倾向于做原创图书，别搞错，我说的是武汉的那个博文)，加上纸张以及印刷成本的上涨，以及图书销量连年受到网络媒体的冲击，做一本纸版书不亏本已经不容易了，现在据说在国内一本技术图书能做到 5000 册的销量就是不错的成绩了，出版社不得不通过一些不得以的手段控制成本。有一次和蔡学镛聊天，他说台湾现在的 IT 图书出版已经萎缩得不成样子，而大陆因为市场太庞大，所以一时半刻还能撑下去。

李笑来老师曾经质疑过"为什么引进书籍的翻译普遍都很差？"，他认为直接原因就是"稿费太低"。对于译者来说，如果只是为了稿费而做技术翻译的的话，绝对是一件收益不大的事情，何况，这事情本身就是一件"瓷器活儿"。翻译得好的话，必然需要投入更大的精力，而译文质量不过关，读者不会饶过你。我相信像余晟这样把翻译当作一种乐趣的人已经凤毛麟角了，而像阮一峰那样偶尔的"头脑发热"一回也是值得我们欣赏的。

国内出版社有的时候自己也扮演杀鸡取卵的事情，据我所知，多数出版社对于翻译时间的限制都比较紧，一本书，一般只给译者 3-6 个月的翻译时间，为了能在既定时间之内完工，要么找更多的的合作者--这会带来翻译风格不统一的问题，译稿质量也难免下降，要么拖延，而拖延，在合同里是写着明确条款的，会根据不同的时间扣除稿费。也就说，如果遇到了不良出版社，而你的合同时间又签得比较不利，那么可能一分钱拿不到。当然，我们这本书总体来说编辑还是比较宽松的，这是非常值得庆幸的一件事。其实话说回来，我认识的几个出版人如果他们转身去做畅销书，至少不会比做 IT 差，或许他们为了理想也在咬牙坚持。

危机，危机，危险之中机遇何在?

--EOF--

这本书的内容覆盖了一个 IT 人将要面临的方方面面，不管是否认可书中的观点，不可否认的是 Joel 的见解的确是颇为独到的，有些话语堪称一针见血，这家伙的写作风格也是从不隔靴搔痒。我觉得在这本书中传递给我们的是一种理念--如何把技术效能发挥出来，如何把技术的价值最大化。而 Joel 本人也用自己的亲身经历来证明他所说的并非是做不到的事情，实际上，他创建的 Fog Creek Software 就是一家很酷而且颇为成功的公司。

《软件随想录》不是一本讲技术的图书，但是我相信如果认真读过之后会发现对自己的技术提升会最大。另外，有必要强调的是Joel 对人才的论述，如果要招聘真正牛的技术人员，那么自认为理解技术人员的管理者都应该读一下这本书，某些章节场景或许会让你觉得脸红，哦，原来以前自己所谓的一些招聘手段是多么的低级而低效，我们有太多的理念需要转变。

今天晚上还给 Yupoo 的刘平阳推荐了这本书。个人觉得，无论是一线技术人员还是 IT 公司的的管理者，或是创业团队的成员，都应该读一下这本书，相信能给你很多启迪。

八卦一下：Joel Spolsky 给自己起了一个中文名字：周思博，不知道他知道在中国有这么多粉丝不?

好久没有读到这么有趣的书了，也要感谢译者 阮一峰 的辛苦工作，他也是个有趣的家伙。（周思博）

--EOF--