青春作赋，皓首穷经

盛大研究院在其网站http://www.sndacode.com/projects开源了不少应用。很多都是上层应用相关，我感兴趣的有如下几个：

在手机上看code的人估计是个傻帽，但是在PAD上面还可能是一件爽快的事情。

作为google reader的中毒使用者，这个功能还是很有价值的，是盛大电子书的亮点。

作为在线需求，可以做出来很酷的手机应用。引擎开源当然很有价值，更有价值的是后台的歌曲数据库。

看起来不错，虽然我还没做过Javascript开发。

微博的备份

那些魂牵梦绕的游戏 0.艺术就是给我们带来另一个世界的东东。以此解释Game就是艺术。再以此解释，悲催的计算机coding也是艺术,在玩物丧志的大学时代，整天泡在电脑旁，有时自己玩，因为机时不够，大部分时间是指导别人玩，人送绰号“赵指导”，大规模怀念一些经典游戏于此，老了有个念想:-(

那些魂牵梦绕的游戏 1.三国英杰传-大众软件有攻略，认真打了两遍这个有趣的战棋游戏，长坂坡为了赚曹操经验，废了好几天时间。还有心比金钿坚的玩友，每一步都要求完美无缺，一个游戏玩打了n年，每个人都要培养到最高级。这款游戏以16色的配色做出了256色都达不到的效果，我到现在还想玩之，KOEI。

那些魂牵梦绕的游戏 2.魔法门六，满足了文艺宅男探索未知世界、带队砍人、练级施法、配药等多方面需求。第一视角的界面更是惊叹。在还不会用光明之火的时候，没头苍蝇一样乱闯。冷不丁窜出来的响尾蛇搞得我心惊胆战，后来有了光明之火的小地图，如鱼得水。刚学会飞行的时候，世界都在我脚下。3DO。

那些魂牵梦绕的游戏 3.永远的仙剑，那个年代都是286，少有几台386，还见过更破的，估计是传说中的8086，恰逢通宵上机，别人的都是4M内存，我那台只有2M。仙剑要占1.7M，搞了半宿内存，用QEMS386替代微软的EMS386，终于仙山飞鹤的水墨CG出来了，那仿佛来自远古世界的音乐让我的心都停止了跳动，大宇。

那些魂牵梦绕的游戏 4.C&C，已是486时代了，C&C最炫之处在于联网对战。几个宿舍自费在窗户外面拉上铜轴电缆，顺便可以晾衣服，现在都进博物馆了。很快证明我这个战棋玩家不适合激烈对抗，高手们击键如弹琴。一次我捡到一隐形运兵车，遂放若干工程师去偷东西，东西没偷到，心脏差点跳出来，西屋。

那些魂牵梦绕的游戏 5.魔法门英雄无敌，年复一年，夜复一夜，每晚自己玩或指导别人玩，武器/魔法攻击，兵种的能力，幸运概率诸多公式烂熟于胸。可以负责任的说，如果用玩魔法门的时间和劲头去做学问，应该已经是院士了，至少是博士了。游戏取材西方神话，狮王盾等道具更于魔幻电影中屡次出现3DO。

那些魂牵梦绕的游戏 6.轩辕剑4-黑龙舞兮云飞扬，多魔映画小组的经典之作，大气而不失精致的情节策划、知其不可为而为之的墨家情怀感人至深，看着大寨几经而战伐而破损不堪，我的心也在失血，台湾幸运存留着正统中国文化之一脉。游戏中的天书世界、炼妖系统给人极大的乐趣，适合避世之用。大宇。

那些魂牵梦绕的游戏 7.金庸群侠传。垃圾游商智冠当年最好玩作品。有熟悉的小说情节，漂亮的绝技动画，我至今难忘独孤九剑那落英缤纷的画面，虽无音效，但剑势一出心中‘刷’的一声。500次攻击才可用的‘野球拳’，是练级控永远的爱。当辰辰月嫂的老旧手机传出群侠之传背景音乐，我faint了。

那些魂牵梦绕的游戏 8.大菠萝 last but not least. 一代应该运行在586-166上，那个神秘小男孩处总是有特殊的宝物。二代更是玩了多遍，同样满足男人了带队砍人的天性需求。嫌恶心，不喜近战，喜用大闪电摧枯拉朽式砍人或者放若干骷髅。三代十年没release，影响PC工业，因为我们没有理由升级机器，暴雪。

Droplet写过一些Network应用实现的模式，鉴于网络设备的复杂性，还有不少D还没有囊括进去，我这里补充一种累积下发模式：

其实很简单，如果发送方有很多小的消息需要发送，延迟一会儿累积一些消息一并发送。这里一般有两个条件会触发发送：

1.在消息积累到一定数量的时候，超过Threshold的时候发送累积消息。

2.在消息没有达到threshold，但是经过一定超时时间的时候，也发送。

这个模式很常用，其实熟悉TCP协议的人会想到Nagle算法就是完全使用这种模式，当时解决的问题是Telnet协议中的大量小报文造成的协议损耗以及低速链路的拥塞。Nagle算法是84年采纳的，当时网络还很不发达，行家更少，以至于这样简单的设计也会成为著名算法，恨不早生20年，也发明一下":-)

半夜看了钱穆的《湖上闲思录》，加之微博上一些智者的话，突然有所领悟。作为一个普通人，人生的道路应该是践行有情的哲学并以他人的幸福为幸福。看到读到的很多的人和事，用这个道理都解释的通。这个也是儒家思想实际上倡导的，或者能接近其仁义忠恕的思想本质。为此希望今后不在半夜看书了。

什么是幸福？

每天沉迷游戏享乐是幸福吗？用“以他人的幸福为幸福”来衡量，不是幸福，因为没有任何他人收益。

为了解决客户问题，心急火燎，日复一日，是幸福吗？我们是为家人的生活努力打拼，是幸福，我们是为了客户系统可以正常运行，以便更多的人可以有工作生活便利，是幸福。但是如果工作压力使得身体无法承受，最终给家人带来痛苦则这个不是幸福。所谓“他人”有亲疏远近之别，以亲人为先，这个不是自私，人性使然也是理所当然。

希特勒这样的人，一生以灭绝犹太种族为目的，是幸福吗？不好说，对于他本人来说，或许是幸福，因为他践行的不是有情的哲学。在他的哲学之中，或许他是幸福的。但是他的哲学不是常人的哲学，多数人不会因为有他这样的行为和思想而觉得幸福。老庄的哲学，虽然飘逸，但是究其根本是无情的哲学，希望保全自身，希望出世，历代推崇之的帝王也只是希望个人的长生以及羽化登仙，这也非常人的幸福。

看过乔布斯的传记，此人抛弃了怀孕的女友，因此后半辈子为此后悔，这个不是幸福。另外，此人如此拼命以至于折寿的创造了多个伟大的产品，给世人带来了极大的工作便利和生活愉悦，是幸福。为了他人幸福其实是实现人生价值和意义的根本。一个人，即使通晓若干种语言，知天下事，但是与人无益，何谈生命价值的实现。作为工程师，于家庭，照顾妻儿父母就是幸福。于社会，搭建产品，解决问题，共享知识就是幸福。

努力赚取金钱或争取更好的薪酬是否是幸福呢？当然是，穷则独善其身，金钱可以养家糊口，使得家人有安全安心的居所。如果你有项羽的板肋虬筋，达则兼善天下，像盖茨和陈光标那样造福更多的人。

以这两点约束我日常的行为，过滤我过多的兴趣点或于人生有益处。不要在晚上读书过度了，自己虽然能有些许收益，但影响身体。不要兴趣过多，扰乱视听。不要没事上网看微博之类的东西，保护眼睛，其实很多眼花缭乱的天下事与何人有益呢？不要一放假就见天儿躺在沙发上看无聊的电视。主动锻炼身体，以有更好的精力照顾家庭。不要对过度关注别人过失，横眉冷对，要考虑言行影响他人的幸福。

对于我这个亲儒家的普通人，要践行儒家的哲学，以他人的幸福为幸福，其实就是活的像一个普通的中国人，老婆和多数亲人就是这样做的，只是我今天才想清楚。

又过了一年，what a year！

基本上可以负责任的说，在工作和专业上又学到了不少东西，大脑里面的深沟又增加了不少，同时知道了有更多的东西自己不懂，更加敬畏生命，也不想去搞懂所有的疑惑了。

看着女儿长到一岁，每天都有开心的笑料，心理负担也日渐沉重。我这个当老爸的各方面还做不了她的楷模，如何教育好她以便从容适应这个社会同时又能够尽量不减少她人生的乐趣，以当前中国的社会环境和价值评估体系来说，是个难以两全的问题，只好做实验了。

今年生活上的改变在于用了微博和豆瓣，这两大工具尤其是后者消耗了我不少的时间。一方面在不断记录自己以往读过的书籍，也新读了100+电子书，另一方面从别人的共享中看到了不少前所未见的好书，to read list里面有个1000+的图书。我有时甚至想放弃工作，像某个晋朝前辈那样找个山沟子，拿一本Kindle，读几年书，想清楚更多的东西，这样或许后半生精神上更洒脱，更少纠缠。

不好的地方很多，最主要的仍然是身体锻炼不足。另外，缺乏主动去认识朋友的主观能动性。后者我可能不愿意去改，一辈子做个技术人员没什么不好的。为了利益关联而非信任、欣赏去结交朋友有些浪费生命。

新的一年没有什么太多愿望：好好看看英语；做人更加诚实谦逊；锻炼身体以便有更多的时间学习，也为了多活几年照顾家庭并还清房贷。

祝自己和大家新年愉快，也祝droplet万寿无疆，这样这个小网站有人按月付费不至于被关闭。

【Appleleaf：在很多领域，无论对于中间设备还是服务器，high performance都是最大的Kill App，我们这些C工程，练好本领还有的饭碗端】

http://www.dbanotes.net/web/web_performance_optimization.html

在 O'Reilly Velocity China 2010 大会上，业界最有影响里的 Web 性能技术专家 Steve Souders 宣告 Web Performance Optimization (WPO) 时代已经到来。这是个颇为重要的主题演讲，要知道，Google 已经开网站载入时间纳入到搜索排名因素之中(refer)，或许 Web 性能优化，商业网站要考虑作为一项战略来对待了。

我们看一组数据（信息来源）:

• Amazon: 增加 100ms 延迟将导致收入下降 1%；
• Google: 400 ms 延迟将导致每用户搜索请求下降 0.59%；
• Yahoo!: 400ms 延迟会导致流量下降 5-9%；
• Bing: 2 秒的延迟将导致收入降低 4.3%/用户(请问，首页用个那么大的背景图干啥?);
• Mozilla 将下载页时间缩短 2.2 秒之后下载量增加 15.4%;
• Google Maps 将文件大小减少 30% 后请求增加了 30%；
• Netflix 在服务器端启用 gzip ，页面快了 13-25%，节省了 50% 的网络流量；
• Shopzilla 将页面载入时间从 7秒缩减到 2秒，转化率提升了 7-12%，页面请求增加 25%，只用一半服务器就够了

要注意，这些只是数据，实际上，我们没有办法验证这些数据的真实性。但是可以肯定的是，网站访问速度过慢，一定对用户有负面影响。严重一些的，国外有 Friendster 因为网站访问过慢而导致的用户流失可以作为前车之鉴；网站访问速度快也可以增加竞争优势，比如Tumblr 一骑绝尘而将竞争对手 Posterous 甩在后面。国内这方面的例子比如优酷，斥重金改进用户访问速度，很大程度上保持了竞争优势。

相比投资在硬件上，我个人认为技术团队在 WPO 上的投入是可以用来评估团队技术能力的。有一次在和一位投资人聊起国内的分类网站哪个技术团队更具优势，我毫不犹豫的说看好百姓网，为何？访问一下同类网站，比较一下最终页面访问速度就知道了。这是体现一个技术团队意识和能力的地方。

【Appleleaf：这是个过劳死的行业，努力活过下面这些兄弟们，注意下面很多人相当长寿：-）

原文 http://blog.jobbole.com/10254/】

艾伦·萨克斯（A. Sachs）有句话是这么说的：“死比生更普遍，人皆有一死，但并非谁都活过”。

的确，得过且过的人无数，但是真正活过的人不多。

2011年终将近，此刻，我们应该纪念一下一些今年逝去的人，虽然他们逝去了，但是凭借着在技术界、甚至在全世界做出的卓越影响，他们完全可以无愧地说：“我们活过了”。

乔布斯（1955年2月24日-2011年10月5日）

杰出的创新者，纯粹的开拓者，有谁能够像他那样终其一生照耀整个业界，变革整个行业？虽然他并不能将每一样东西都点石成金，但是，作为我们这个时代最杰出的发明者之一，他一定会被我们久久铭记。

乔布斯对细节的关注、他的商业天才，还有专注以及无情的内驱力，这些应当也必将成为许多新生代创业者的灵感源泉。

其他对乔布斯的评价参见对乔布斯逝世的47个评价。

丹尼斯·里奇（Dennis Ritchie） （1941年9月9日-2011年10月12日）

要是没了这位受人尊敬的计算机科学家，没有了他创建的C语言以及参与开发的UNIX操作系统，我们现在都能干些什么？

他死后，计算机历史学家Paul Ceruzzi做出了最好的评价：“里奇为人低调。他的名字并非家喻户晓，但是……如果你有显微镜并且能够在计算机上找找，你就会发现，他的作品随处可见。”

对里奇的其他评价参见我们能够从C语言的创造者身上学到什么东西？

鲍勃·高尔文（Bob Galvin） (（1922年10月9日-2011年10月11日）

摩托罗拉创始人Paul Galvin之子，摩托罗拉1959-1986年间富有远见的CEO。在高尔文的领导下，摩托罗拉引领了全球手机产业的诞生。

摩托罗拉在他的带领下还成为了全球半导体、寻呼、对讲机、太空与军事通讯以及汽车嵌入控制技术产业的领袖。

以前写过一篇SSL Proxy的小的分析，在最近一次讨论中发现我还是了解的不够细致，这里描述的细致一些。

首先是定义一下应用场景：

SSL Client<--------------------------->SSL Server

首先是标准的SSL Client和Server进行通信。

SSL Client<-------------->MITM<------------->SSL Server

需求是：在其间加入中间人，劫持会话，生成两个SSL会话，从而可以获取明文数据，同时符合SSL标准，同时不用Client明确关注到中间人。

业界有两种实现：

1.SSL Forward Prxoy -- 正向代理

即代理Client。中间人生成自签名证书，Client要明确相信中间人的证书，这样中间人就不必将Server的证书发送给Client。

2.SSL Reverse Proxy -- 反向代理

即代理Server，要求Server的证书必须明确的配置在中间人上，这样中间人可以完全承担Server的加解密的功能。

从技术角度讲，潜在的还可以将Client的证书配置到中间人上，但是这是无法操作的。

即使是业界的实现也有一些局限：

1.两种实现所共有的局限是：Server不能对于Client进行身份验证，因为Client的私钥无法获取。

2.正向代理的另一个局限是，由于中间人是自签名证书，如果Client实现一定要验证Server证书合法性，则无法实现会话的劫持。

原文：http://blog.sina.com.cn/s/blog_5fe6d7750100dlwj.html

网络处理器方面目前比较主流的是cavium和RMI，目前讨论最多的也就是这两个，RMI进入国内比较早，国内RMI有HW, H3C等大厂商，cavium以hillstone为代表，不过据说华为等也开始转向cavium了。网络处理器的出现降低了国内安全设备厂商的门槛，因为国内所有网络设备公司目前都还没有能力自己研发芯片的。

要完全比较两款处理器，有太多方面需要说了，硬件方面包括指令集，core结构，总线， 各种加速的unit等，软件方面包括特定的os，sdk，还有开发门槛，开发难度等，商务产品定位方面那也不少。

其实cavium和RMI都是network multicore processor，这是不同于通用处理器的一个细分的市场，因为通用处理器市场已经被intel和AMD垄断，想到这个市场分一杯羹的梦想最好想也别想，想在处理器市场上有点作为，最好避开这个领域，专攻其他一些细分的市场，比如说嵌入式，音视频处理等，扯远了。Cavium和RMI的定位比较类似，但也不能说市场覆盖范围100%重合，毕竟两个不同的产品各有特点。

别的方面偶就不说了，说说处理器和软件开发的一些体会

Processor方面：

cavium 和RMI都是MIPS64 R2的core，cavium低端的50xx，高端的58xx以及68xx等，最高32core，1.5G，RMI最高8core，但每个core有4个硬件线程，每个vcore有独立的寄存器组，切换效率非常高，所以可以宣传说是32 vcore，最高1.5G。另外至于这个硬件线程的差别不知道有没有人评估过，Ｒaza自己说能提高100% ~ 150%, 理论上cavium刚开始的时候要支持硬件线程也不是什么难事，是疏忽还是认为没必要，不得而知，不过我偏向后者。

指令集方面，ｃａｖｉｕｍ除了支持MIPS instruction set之外，还扩展一部分访问内存优化，CRC/DES/AES等加解密指令以及背后运算单元，ＲＭＩ据说是没有这类似的扩展。另外，Icache/Dcache/L2cache等两者应该都差不多吧，没有去仔细比较。

Core之间interconnect方面，Cavium采用的是传统共享总线＋L2 cache的方式，这个总线速度特别快，９００Ｍｈｚ下峰值可达５００多Ｇbps；ＲＭＩ的各硬件线程之间采用的是ＦＭＮ ring传递，可以使得各个unit之间并行传输数据 避免冲突仲裁，ＦＭＮ的宽度是６４bit，所以１.5Ghz可以到90Gbps.

Packet的ＩＯ bus方面，值得提出的是cavium在在这个方面专门针对网络数据包做了大量的加速和优化工作，小的方面比如DWB, FAU等，包进来的时候有预处理，覆盖了包２到４层的检测，提取，校验等等，生成包信息，然后按策略调度到各个core，并且能支持同一个流上的包之间的order，包被处理完了之后出去的时候有自动port queue, 自动添加CRC等等；当然ＲＭＩ做的也不少，基本上这些功能ＲＭＩ也有，除了数据包order的支持。

其他coprocessor上面，cavium有IO bus上挂的有ZIP compress/decompress，另外有in-core的AES/DES/CRC等coprocessor，ＸＬＲ也有内建的安全引擎，号称可以提供１０Ｇ的加解密运算能力，不过据说实用也就２.5G，据说而已。另外这块我知道有一个cavium有的东西ＲＭＩ肯定没有，就是DFA unit，上回ＲＭＩ的ＦＥ过来推介的时候还特意调查了这个东西到底有没有需求的，有没有需求呢，我不知道。

对于IEEE（Institute of Electrical and Electronics Engineers，电气电子工程师协会， "Eye-triple-E"），我以前就知道一些以太网相关的协议以及Wireless协议是IEEE发布的，今天又多了解了一些。1963年由IRE和AIEE合并而成，后两家机构的创始人是贝尔、爱迪生以及马可尼。因为，两个机构的研究内容日渐趋同，因此进行合并。

IEEE的标准一般都以标准号而闻名，例如IEEE802.1Q就是VLAN的代名词，这一点同另一大著名组织IETF的标准有所不同，大家都知道TCP/IP，但是从没有人会记住RFC的号码。因此每次改版会出现新的RFC。这一点我觉得IETF不如IEEE，目前RFC的号码数量应该超过6000直奔10000去了，很多协议的历史文档其实没有单独保留一份的必要,。唯一一点可以想到的好处是，RFC多了，RFC的作者就多了，很多人因此有了炫耀的资本。其实很多RFC就是一个option的扩展，甚至还没有这么有价值。

IEEE的内容已经远远超越了电气电子，而是包括了能源、生物、计算机、通信等等领域，日渐庞大。IEEE声称非盈利，但是其理念积累的文档、会议资料、期刊等等是要收费才可看到的。对于普通的研发人员，无论是软件硬件，个人觉得其内容可能帮助不大，我们有google学术就足够了。但是其标准的进展相关领域人员还是应该跟踪的。

IETF的会员审核似乎不严格，对于高级会员仅仅需要5年行业工作经验，每年缴纳会费就可以了。Fellow比较厉害，据称，中国区仅有50多人。