国庆期间，我专程去了趟上海，住在岳母家里。当时北京已经有点凉了，但上海还很热，需要开空调。不过由于线路老、容易跳闸，一个屋子开了空调另外一个屋子就不能开，这样两个屋子只能一个凉一个热。当时我就想，要是空调的功耗降低一半，这个问题也许能迎刃而解。节能是多么现实的一个问题。

由此我回想起国庆前，中国电子学会节能工作推进委员会成立，当时英特尔和其它12家机构联合起来，向全国信息产业界发出“中国电子节能倡议书”，号召研发、采用和推广电子节能新技术、新产品，并且利用先进电子信息技术帮助传统产业节能减排。

中国拥有数以亿计的电子信息产品，降低电子产品能耗、提高电子产品能效迫在眉睫！英特尔作为芯片创新领域的领先厂商，已率先行动起来了。我们去年推出的英特尔®酷睿™2双核处理器产品，超越上一代奔腾，节能40%，高效节能跨出了一大步。今年最新的基于酷睿架构的奔腾双核和赛扬单核处理器，根据中国软件评测中心（CSTC）的评测结果，平均功耗只有19瓦，这是非常激动人心的。英特尔正在网吧和其它市场积极地推这个东西，将这个好处带给更广大的消费者。

11月，英特尔即将发布45纳米新一代芯片，在提升性能的同时进一步降低功耗。明年，英特尔将继续推出全新的微体系架构Nehalem，后年英特尔芯片技术将过渡到32纳米，那时候，功耗还会进一步降低。

在芯片技术和产品的微观层面，我们已经形成了高性能、低功耗的清晰路线图。另外一方面，英特尔正与产业界密切合作，以降低计算机产品的整体功耗，进一步将高效节能的特点推广到几乎所有电子产品中去。

电子产品节能迫在眉睫，在节能环保方面英特尔有强大的信心，也有坚定的承诺。现在，节能减排不仅仅是政府的议程，也正在成为整个产业界和广大电子产品用户的共识与行动。相信不久的将来，随着电子信息产品能效标准的诞生，电子产品节能必将为国家和社会带来更大的福利。

又到深秋，喇叭沟门儿之旅开始报名啦，大家跟帖报名。（去年的贴）

集合地点：西直门火车站售票处门口；

集合时间：10月13日（周六）上午6：15分（火车6：30开）；

活动费用：每人预交100元（包车、门票、住宿、用餐、进山拖拉机）多退少补。火车票早上集合后到窗口自行购买。

注意事项：请大家带好一顿早餐、盥洗用品、保暖衣物、相机。

活动行程：

1、13日早上6：15分西直门火车站集合后自行买票进站，上车杀人；

2、火车到怀柔北站下，老吴（去年住的那个农家的男主人）派中巴车接我们到喇叭沟门儿孙栅子老吴家；

3、老吴家午餐，分炕（睡炕自由组合），随后进山（五龙潭）；

4、下山、晚餐、杀人、睡觉；

5、14日早上包当地豪华敞篷拖拉机（绝对敞篷）上山（凤凰台/枫叶林）

6、下山、午餐，走人，到怀柔县城坐公车回城。

应急措施：

1、如果担心睡过头，妮妮友情提供叫醒（感动中！！！）。

2、如果赶不上火车，请立即坐地铁到东直门，乘坐936路公共汽车到怀柔，下车即有到喇叭沟门的中巴车。

这是车东提供的相关帖子，供大家参考：http://forum.enorth.com.cn/thread_564304_1.html

　 　“我们不能再依靠上一代技术来提高互联网的性能了，这些技术四十年来都没改变过，”现年69岁的罗伯茨指出。上个月，他组建的初创公司Anagran Inc.研制了一款被称为流量路由器的新设备，据他说能促进互联网的现代化发展。该设备能对网络流量进行分析，进而判断网络信息是电子邮件、电影还是电 话，然后决定传播该类信息所需要的频宽。

　　认为网络技术不仅仅应停留于早期成功的网络先锋可并非罗伯茨一人。现年55岁的蓝•博萨克 (Len Bosack)是网络巨擘思科公司(Cisco System Inc.)的创始人之一，并曾担任该公司的首席技术长，推动过路由器的商业化发展。路由器是能让电脑相互进行交流的网络连接设备中的核心部分。但如今，博 萨克认为路由器“越来越难以满足”现代的网络需求。上个月，他的公司XKL LLC推出了一个新系统，能将企业电脑与地下电缆相连接，地下电缆的容量是当今电信设备容量的一百倍左右。

　　广告互联网现有的基础设施能 否处理那些频宽需求很大的网络服务，例如网络电话和视频节目等？目前，人们的这场争执不断升温，而博萨克和罗伯茨的行动无疑是火上浇油。在近期的一份报告 中，思科推断到2011年，北美地区的月度互联网流量将猛增264%，超过780万太拉字节，即相当于40万亿封电子邮件的流量。如果网络流量按这样的速 度递增，许多人相信互联网可能会崩溃，或是至少慢得像虫子爬。

　　“人们对网络运营商的频宽需求日益增长，这种局面很快就会演变成一场危 机，”ABI Research的研究主管斯坦•斯查特(Stan Schatt)在最近的一份报告中指出。有些人则不以为然。即使预测网络流量将大幅上升的思科公司也认为，网络服务提供商们能够应付得了。

　　目前，信息在网络的传输过程中被分为许多微小的信息包，接着通过流量最少的网路抵达目的地。一旦信息包抵达后，它们又被组合为原有的形式。现在的问题是文件越来越大，如视频节目等，它们让处理网络流量的设备不堪重负，导致一些信息包迷路或丢失。

　 　为了解决上述问题，许多初创公司推出了新设备或软件，旨在加快网络流量，或是增加网络的容量。这其中就包括博萨克和罗伯茨的公司，以及Riverbed Technology Inc.和Big Band Networks Inc。其他一些公司，如BitGravity Inc.和Limelight Networks Inc等，则推出了“平行网络”，它们是互联网的缩微版，主要是为了逃避拥挤不堪的现行网络。

　　这些初创公司的目标客户是网络服务提供商以及那些拥有大型卫星办公室网络的大公司。例如，企业采用的网络设备能影响分公司的电子邮件和其他文件的收发速度。

　 　不过，许多这类初创公司恐怕难以生存下去。在上世纪九十年代末曾经冒出Celox Networks Inc.、Chiaro Networks Inc.以及Centerpoint Broadband Technologies Inc.等初创公司，争夺不断增长的网络流量。然而，这些小公司后来全军覆灭，不是申请破产就是关门大吉，成了电信业泡沫的牺牲品。

　　如今控制网络流量的初创公司“的确有一套行之有效的办法，”Network Strategy Partners LLC的网络顾问迈克尔•肯尼迪(Michael Kennedy)说。“技术并不是万能的。”

　 　罗伯茨在很多年前就开始对互联网基础设施感到担心了。即使在研制APRAnet的时候，他回忆说他那时也不确定这项技术能用多久，尤其是该系统并不能确 保信息包一定能抵达目的地。到了上世纪九十年代晚期，当罗伯茨看到企业开始通过拨打网络电话、消费者们开始涉足网络视频时，他的忧虑终于变成了现实。

　　“设计互联网可不是用来让人们看电视的，”他表示。“我很清楚这一点，因为我就是设计者。”

　 　罗伯茨于1971年离开了美国国防部，之后在几家网络初创公司工作过。1998年，他成立了一家名为Caspian Networks Inc.的初创公司。他从风险投资那里筹集了3.17亿美元，用来生产基于流量的路由器，它能分析网络流量并加以改进。但这种设备的售价为每台50万美元 左右，对于众多客户而言实在太贵了。

　　罗伯茨于2004年离开了Caspian，这家公司也于去年关门大吉。然而，这位科学家希望改进网 络基础设施的抱负并没有因此消退。在离开Caspian的两个月后，他又在加州创建了Anagran，并获得了2,200万美元的风险投资，继续追求他的 事业。罗伯茨表示，这次Anagran的产品会比较便宜，只要70,000美元，而且如今对此类设备的需求也更为迫切了。

　　“拉里想把事情做好，”加利福尼亚州ArrowPath Venture Partners的风险投资家丹•布朗(Dan Brown)说。该公司对Anagran进行了投资。

　 　Anagran早已锁定了自己的客户，如为大学建立网络的密歇根州非盈利组织Merit Networks Inc.和西北大学的高级互联网国际研究中心(International Center for Advanced Internet Research)。“拉里的设备是为较为复杂的网络流量设计的，如网络电视等，”西北大学网络部副主任Jim Chen说。“这对我们来说再合适不过了。”

　　XKL的故事则始于1991年的西雅图。1990年时，博萨克和他的前妻、思科公司的创始 人之一桑迪•勒斯勒(Sandy Lersner)被迫离开了思科。当时思科刚刚上市，而公司的风险投资家们认为夫妇俩不能继续经营这个不断壮大的公司。于是，博萨克很快卖掉了手中的大部 分思科股票，将精力放在了XKL上。在这里，他专注于通过光纤提高互联网的容量，因为光纤的信息传播量是传统网线的一百倍以上。

　　在过去的十多年里，博萨克一直悄无声息地开发这项技术。与此同时，他开始注意到企业和消费者无意之间为互联网开发的一些新用途，例如视频会议等。“其中的一些用途给网络带来了沉重的负担，”他表示。

　　因此，XKL在上个月推出了DMX光纤传输系统。这种售价为10万美元的设备能让企业和服务提供商，而非电信公司，来管理和连接光纤线路。博萨克说，XKL才刚刚开始获得客户的合同。

　　罗伯茨和博萨克并没有见过面，但两人都听业内人士说起过对方。他们表示，两人之间是互相学习借鉴的。

　　“我们致力于同一件事，”博萨克说。“人们需要比现有产品更好的东西。”

Posted by Goranka Bjedov, Senior Test Engineer

This post is my best shot at explaining what I do, why I do it, and why I think it is the right thing to do. Performance testing is a category of testing that seems to evoke strong feelings in people: feelings of fear (Oh, my God, I have no idea what to do because performance testing is so hard!), feelings of inadequacy (We bought this tool that does every aspect of performance testing, we paid so much for it, and we are not getting anything done!), feelings of confusion (So, what the heck am I supposed to be doing again?), and I don't think this is necessary.

Think of performance testing as another tool in your testing arsenal - something you will do when you need to. It explores several system qualities, that can be simplified to:

• Speed - does the system respond quickly enough
• Capacity - is the infrastructure sized adequately
• Scalability - can the system grow to handle future volumes
• Stability - does the system behave correctly under load

So, I do performance testing of a service when risk analysis indicates that failing in any of the above categories would be more costly to the company then performing the tests. (Which, if your name is Google and you care about your brand, happens with any service you launch.) Note that I am talking about services - I work almost exclusively with servers and spend no time worrying about client-side rendering/processing issues. While those are becoming increasingly more important, and have always been more complex then my work, I consider those to be a part of functionality tests, and they are designed, created and executed by functional testing teams.

Another interesting thing about performance testing is that you will never be able to be 100% "right" or 100% "done. Accept it, deal with it, and move on. Any system in existence today will depend on thousands of different parameters, and if I spent the time analyzing each one of them, understanding the relationships between each two or each three, graphing their impact curves, trying to non-dimensionalize them, I would still be testing my first service two years later. The thought of doing anything less filled me with horror (They cannot seriously expect me to provide meaningful performance results in less then a year, can they?) but I have since learned that I can provide at least 90% of meaningful information to my customers by applying only 10% of my total effort and time. And, 90% is more then enough for vast majority of problems.

So, here is what I really do - I create benchmarks. If I am lucky and have fantastic information about current usage patters of a particular product (which I usually do,) I will make sure this benchmark covers most operations that are top resource hogs (either per single use or cumulative). I'll run this benchmark with different loads (number of virtual users) against a loosely controlled system (it would be nice to have 100 machines all to myself for every service we have, which I can use once a day or once a week, but that would be expensive and unrealistic) and investigate its behavior. Which transactions are taking the most time? Which transactions seem to get progressively worse with increasing load? Which transactions seem unstable (I cannot explain their behavior)? I call this exploratory performance testing, and I'll repeat my tests until I am convinced I am observing real system behavior. While I am doing this, I make sure I am not getting biased by investigating the code. If I have questions, I ask programmers, but I know they are biased, and I will avoid getting biased myself!

Once I have my graphs (think, interesting transaction latencies and throughput vs. load here) I meet with the development team and discuss the findings. Usually, there is one or two things they know and have been working on, and a few more they were unaware of. Sometimes, they look over my benchmark and suggest changes (could you make the ratio 80:20, and not 50:50?) After this meeting, we create our final benchmark, I modify the performance testing scripts, and now this benchmark will run as often as possible, but hopefully at least once a night. And, here is the biggest value of this effort: if there is a code change that has impacted performance in an unacceptable way, you will find out about it the next day. Not a week or a month later (How many of us remember what we did in the last month? So, why expect our developers to do so?)

Here is why I think this is the right thing to do: I have seen more bad code developed as a result of premature performance optimizations - before the team even thought they had a problem! Please don't do that. Develop your service in a clean, maintainable and extensible manner. Let me test it, and keep regression testing it. If we find we have a problem in a particular area, we can then address that problem easily - because our code is not obfuscated with performance optimization that have improved code paths that execute once a month by 5%.

I can usually do this in two - four weeks depending on the complexity of the project. Occasionally, we will find an issue that cannot be explained or understood with performance tests. At that point in time, we look under the hood. This is where performance profiling and performance modeling come in. And, both of those are considerably more complex then performance testing. Both great tools, but should be used only when the easy tool fails.

Tools, tools, tools... So, what do we use? I gave a presentation at Google Test Automation Conference in London on exactly this topic. I use open source tools. I discuss the reasons why in the presentation. In general, even if you have decided to go one of the other two routes (vendor tools or develop your own) check out what is available. You may find out that you will get a lot of information about your service using JMeter and spending some time playing around with it. Sure, you can also spend $500K and get similar information or you can spend two years developing "the next best performance testing tool ever," but before you are certain free is not good enough, why would you want to?

Final word: monitor your services during performance tests. If you do not have service related monitoring developed and set up to be used during live operations, you do not need performance testing. If the risks of your service failing are not important enough that you would want to know about it *before* it happens, then you should not be wasting time or money on performance testing. I am incredibly lucky in this area - Google infrastructure is developed by a bunch of people who, if they had a meeting where the topic would be "How to make Goranka's life easy?", could not have done better. I love them - they make my job trivial. At a minimum, I monitor CPU, memory and I/O usage. I cannot see a case when you would want to do less, but you may want to do a lot more on occasion.

这篇文章，将是我个人关于“公民记者”话题这段时期里的最后一篇思考文字。基本上，这篇东西算是对于周曙光同学“我不是你们心目中的公民记者”的回应，也是对我前三篇关于“公民记者”的评论的回应（一、二、三）。毕竟，周曙光同学在我对他的评论里回复说：

你如果能把公民新闻的提供者起另一个不让你迷惑的名字,那你就起一个能去掉”公民记者”后面两个字的名词吧. 或者你来告诉我,你心目中的公民记者是什么样的。

我得说些什么。

周曙光同学在他的文章里说，公民记者是公民。这个说法的确有点让人费解。如果是一个没有被剥夺公民权利的正常人（非罪犯），那他/她自然就是公民。硬加一个记者，又何必呢？

有朋友评论我的文章说：你是在钻名词的牛角尖。我认为，有些名词的牛角尖不用太计较，有些名词的牛角尖还真得钻上一钻。

一个公民，享有天赋的表达自由权利，这是任何一个无论是实质还是表面要追求宪政的社会的共识。公民不需要再加任何前缀或者后缀，就可以进行他们的表达。 Blog的诞生，使得他们的表达可以传到更远的地方（比如阿拉斯加），也可以传播给更多的人听到（不再只是身边的好友）。这是一项技术给人们带来的关于表达自由的便利。

但表达和报道是截然不同的事情。当我看到一个年轻人在咒骂一个老年人的时候，我可以立刻到我的blog上去说，唉，人心不古啊，现在的年轻人怎么这样不尊老爱幼。但如果是记者，就必须去核实一下：为什么年轻人要咒骂老年人？也许，这个老年人刚刚偷了年轻人的钱包，有错在先造成的。

在正统的新闻报道学习中，五W一H是非常重要的新闻元素。一篇合格的新闻报道，必须具备这些元素。记者不是看到什么就写什么，他/她必须去过问一下是什么造成的。所谓深挖事实根源，我个人以为，大致就是这样了。如果仅仅是看到什么就写什么，那叫报料，不能叫报道。这是有相当大的本质区别的。报料者可以忽视真相，报道者不可以（虽然很多时候不容易做到）。毕竟，我们都知道，眼见未必是实。

所以，blogger是报料者，不是公民记者。这是很常见的blog现象。大多数blog都能完成这个职责。

但有些blog并不满足于此，看到什么说什么显得没有思想性，于是他们开始思索，发表对于这些已经暴露出来的事实的见解。比如说，最近闹得很凶的腾讯和珊瑚虫的案子，我就看到过很多blogger在那里起劲的讨论。我不觉得他们是记者，更多的，象是评论员：对事情的评头论足，从自我主观立场出发，发表自己的见解。

这是blog最重要的使命。

当代伟大的公共知识分子之一哈贝马斯提出过“公共领域”的理论，很多学者都认为是空想。我不这样认为。我认为blog能够去完成哈贝马斯的“空想”，所以当我过去的导师问我你最近在忙什么的时候，我半开玩笑半当真地回答：我在实践哈贝马斯。

哈贝马斯思索欧洲资本主义革命的原因，他发现“沙龙”是一个很重要的环节。当时有不少贵族或者新兴贵族在家里开party，邀请知识分子思想者一起来聚会，并在聚会上进行讨论。他们的思考在讨论中撞击出火花，之后被散播出去。这是导致思想领域启蒙和革命的重要原因。当然，他认为，在当代，公共领域已经被商业和政治染指，他呼吁要净化公共领域，这是后话。

对于blog扎堆的地方，就有一个名词：Blogosphere。这个词不像很多人以为的那样是blog+sphere，而是Blog+logos+sphere，请注意，blog和sphere之间多了一个o。logos是什么东西？逻各斯，中译为“智慧”。

Blog进行事实的再评论，就是智慧的撞击，就是主观看法的撞击。Blog最适合承担这样的职责，而不是去报道什么事实真相。

所以，我说，我是独立评论员，或者再大一点：公民评论员。这就是我对于Blog的类名词定义。至于说我心目中的公民记者是什么样的，对不起，我从来不认为这四个字可以存在。或者，能存在于某些极少的人（包括这些人的极少的一个时间段），但不存在于一个固定的群体中。keso说的，也只是keso的主观看法。

至于有些blog，自费跑到祖国大好河山去漫游，然后写当地的风土人情，这有点当年的徐霞客的风范了。不过，我想，从来没有定义过徐霞客是记者罢！

事实上，对于老虎庙先生的这番游历，BlogBus是大力支持的。如何支持法，可以自行询问老虎庙，他说，比我说来得强。反正绝对不是仅仅大力支持四个字。

最后再顺便说一下一点小小的私心。中国网站报新闻是要牌照的，以前三大门户有，现在百度也加了进来。绝大多数网站没有新闻牌照，自然也包括blog。 blogger做公民记者，那叫公然违法，在这种事情上，和政府对着干，毫无意义。倒是搞搞评论，评论不需要额外牌照，一张ICP备案即可。是不是轻松得多呢？

Share This

1. JDK. In May 2007, I released details on an interesting bug in the ICC profile parser in Sun's JDK. The bug is particularly interesting because it could be exploited by an evil image. Most previous JDK bugs involve a user having to run a whole evil applet. The key parts of code which demonstrate the bug are as follows:
   

   
TagOffset = SpGetUInt32 (&Ptr);
if (ProfileSize &lt TagOffset)
  return SpStatBadProfileDir;
...
TagSize = SpGetUInt32 (&Ptr);
if (ProfileSize &lt TagOffset + TagSize)
  return SpStatBadProfileDir;
...
Ptr = (KpInt32_t *) malloc ((unsigned int)numBytes+HEADER);


   
   Both TagSize and TagOffset are untrusted unsigned 32-bit values pulled out of images being parsed. They are added together, causing a classic integer overflow condition and the bypass of the size check. A subsequent additional integer overflow in the allocation of a buffer leads to a heap-based buffer overflow.


2. gunzip. In September 2006, my colleague Tavis Ormandy reported some interesting vulnerabilities in the gunzip decompressor. They were triggered when an evil compressed archive is decompressed. A lot of programs will automatically pass compressed data through gunzip, making it an interesting attack. The key parts of the code which demonstrate one of the bugs are as follows:
   

   
ush count[17], weight[17], start[18], *p;
...
for (i = 0; i &lt (unsigned)nchar; i++) count[bitlen[i]]++;


   
   Here, the stack-based array "count" is indexed by values in the "bitlen" array. These values are under the control of data in the incoming untrusted compressed data, and were not checked for being within the bounds of the "count" array. This led to corruption of data on the stack.



3. libtiff. In August 2006, Tavis reported a range of security vulnerabilities in the libtiff image parsing library. A lot of image manipulation programs and services will be using libtiff if they handle TIFF format files. So, an evil TIFF file could compromise a lot of desktops or even servers. The key parts of the code which demonstrate one of the bugs are as follows:
   

   
if (sp->cinfo.d.image_width != segment_width ||
    sp->cinfo.d.image_height != segment_height) {
  TIFFWarningExt(tif->tif_clientdata, module,
    "Improper JPEG strip/tile size, expected %dx%d, got %dx%d",


   
   Here, a TIFF file containing a JPEG image is being processed. In this case, both the TIFF header and the embedded JPEG image contain their own copies of the width and height of the image in pixels. This check above notices when these values differ, issues a warning, and continues. The destination buffer for the pixels is allocated based on the TIFF header values, and it is filled based on the JPEG values. This leads to a buffer overflow if a malicious image file contains a JPEG with larger dimensions than those in the TIFF header. Presumably the intent here was to support broken files where the embedded JPEG had smaller dimensions than those in the TIFF header. However, the consequences of larger dimensions that those in the TIFF header had not been considered.