读了Intel和McAfee的官方blog，对此次收购的双方意图解析如下：

Intel：结合安全厂商，扩大无线设备的战略。这次收购咖啡是组合拳中的第二拳。第一拳来自对Wind River的收购，Wind River是嵌入式软件厂商，在被收购后即推出Secure Embedded Linux，这次收购咖啡应该是对Security的再次补充军力(从Linux内核patch可以看出McAfee在嵌入式安全领域一直有所投资，并收购过secure computing，cyberguard， snapgear 等公司)。

无线设备是Intel的支柱之一，而显然现在多元化的终端设备中移动嵌入式设备是主力，而且移动嵌入式设备也给安全领域带来新的挑战，作为硬件厂商的Intel结合成熟安全厂商的技术，很想在移动设备安全领域有所进展，同时促进Intel的移动设备战略。

McAfee：对于安全领域的循序渐进不再满足，希望通过软硬结合来弥补安全领域中攻方和守方的gap。这是McAfee CTO的解释。但是我的理解是，借用Intel硬件铺平的渠道，平台，市场来大展安全的身手才是她的重要意图。现在看来，合并暂时会更多利于面向consumer的终端安全，但可以预见移动设备会通过商务领域渗透入企业领域，从而影响到企业安全相关产品。

总的来说，个人理解这次收购对于Intel是一小步，对于McAfee是一大步，双方能否同步期望值，达到真正双剑合璧，我持观望态度。从技术上看，软硬结合的安全策略也没有想象中那么容易达到。

现在的网卡可以接收/发送包的速度已经开始让宿主机的CPU难以跟上。而由于单个CPU的处理能力也慢慢变得难以提升，那么把数据包分布到多个CPU上处理就变得很有必要。在2.6.35内核中，来自Google的Tom Herbert提交了RPS的系列patch，实现了此机制。（对于发出的数据包，已经不存在这样的问题了，因为发送数据包的进程本身就是分散在CPU上运行的。）

Tom的实现非常简单，在netif_rx()和netif_receive_skb()这两条内核收包必经之路上做了以下处理：

1. 为每个包做一个hash(根据源IP，目标IP，端口)
2. 根据hash把包放入相应CPU的backlog队列
   • 用户可以通过/sys/class/net/<device>/queues/rx-<n>/rps_cpus设置一个mask，指定特定网卡或者网卡上的某个接收队列(如果支持多接受队列的话)可以包交给特定的几个CPU处理。
   • 包的hash值和rps_cpus的值共同决定了该数据包会放入哪个CPU的backlog队列。

经过以上修改，内核可以支持：

1. 为网卡或网卡上的接收队列指定数据包可以在哪些CPU上被均衡处理。
2. 来自网卡的数据包不再被一个CPU的计算瓶颈限制，可以被分布到多个CPU上处理接收。
3. 由于hash值是根据源IP，目标IP和端口计算得出，因此同一个transaction的包被同一个CPU处理，可以达到很好cache命中率，从而提高性能。

Google的生产线上已经使用了RPS，效果不错。这里是Tom给的一些测试数据，明显看到CPU利用率提升以及网络PPS和TPS的提升。

e1000e on 8 core Intel
Without RPS: 108K tps at 33% CPU
With RPS:    311K tps at 64% CPU

forcedeth on 16 core AMD
Without RPS: 156K tps at 15% CPU
With RPS:    404K tps at 49% CPU

bnx2x on 16 core AMD
Without RPS  567K tps at 61% CPU (4 HW RX queues)
Without RPS  738K tps at 96% CPU (8 HW RX queues)
With RPS:    854K tps at 76% CPU (4 HW RX queues)

但是同时，这里有一些limitation。

1. 一个数据包到达后，中断所到达的CPU负责分配，这时会通过SKB内容计算hash，由于是第一次读这个SKB，所以发生cache miss正常。但是之后这个数据包可能会被分配到其他CPU上处理，对于另一个CPU来说，SKB仍然是一个未知内容，所以cache miss又会发生，这次的cache miss就是RPS带来的新开销。不过幸好，很多网卡都天生支持计算这样的hash，驱动只需要把该值存入SKB，就可以提高cache hit，以及计算机整体性能。
2. rps_cpus可以在运行时被动态改变，但是这样的改动可能会导致包的乱序。因为改动前某个transaction的数据包都是由某个CPU处理，而rps_cpus改变，可能导致该transaction的包被发往另一个CPU上处理，如果后到的包在第二个CPU上被处理的速度快于先到的包在第一个CPU上被处理的速度，就会发生乱序。所以尽可能不要频繁改变rps_cpus的值。

# yum install miredo

Then launch miredo by root account.

#/usr/sbin/miredo

Now you have a new network interface “teredo”

Then you can do “ping6 -c 4 ipv6.google.com” or use browser to access http://ipv6.google.com.

It’s simple haah.

But be noticed that some ISP add extra head when do DNS, you can use google’s public DNS “8.8.8.8″ instead.

Good Luck.

生命的永恒在这部电影里看起来不那么美好，虽然凡人对此羡慕不已。

片中的所有出场人物是8个（另外还有两个搬运工，出场10分钟），从头到尾就是个谈话节目，场景只有一个小屋及屋外一些片段。

看官如果想要搜索Chuck Norris相关信息时，不要搜索“Chuck Norris”，因为它和美国的电影演员查克·诺里斯（空手道世界冠军，《猛龙过江》中在古罗马竞技场与李小龙搏击）同名。请搜索“Chuck Norris router” J

病毒每天都有，Linux病毒也不是第一次有了，看来也没有什么好惊奇的。但是Chuck Norris还是给笔者敲响了警钟。互联网安全已经不单单是计算机安全的问题了，智能设备的安全堡垒也在慢慢被攻破。IP-TV也许很快就是下一个被攻击对象了，接下来就是接入网络的家电设备。就像禽流感不单单感染鸟类同时还感染人类一样。

另外，随着云的发展，计算终端会慢慢泛化，各种接入设备都可以成为云终端，那么谁来负责设备安全呢？计算机安全只是个小蛋糕，设备安全的蛋糕会更大。

As we know, Linux Kernel have a lot of different kind of active contributors including Non-profit and corporations. For corporations, there are also lots of different kinds and make the contribution be done on different kernel subsystems. We can simply attribute the corporations to distro vendor, hardware vendor, software vender and IT vendor, and pick up some representative corporations from each class to see what those giants are interesting in and bring them on contributing.

1) Distro Venders which sell Linux Distributions and provide support service

a) Red Hat

• kernel/trace/:  No surprise that an OS development company uses a lot of effort to focus on how to monitor and debug kernel.
• arch/[x86|sparc*|ia64|powerpc|x86_64]/:  As we will see, although other companies also cover some parts of arches,  such as x86(Intel), PowerPC(IBM) and ia64(SGI), no one completely covers so many arches as a kernel contributor. A distro vendor should take care of arch code as seriously as platform vender.
• drivers/[net|char|scsi|media|ata|md|...]/:  Also no surprise, although some hardware vendors provide Linux driver for their products, distro vendors still need to take care of some orphan devices or integration bugs.
• fs/gfs2/:  Not only as a Distro Vender, Red Hat plays some role of IT vendor too and provide integrated solution for costumers. The Red Hat’s product – GFS is the file system which used for manage cluster servers for enterprise deployment.
• Red Hat are involved in a lot of other areas to which the contributions are not as shining as those mentioned before, however they are still huge ones compared to the contributions of companies after TOP10 contribution. Details can be referred by the KPS statistic data.

b) Novell

• sound/pci/: As Novell claimed “SUSE Linux Enterprise Desktop is the market’s only enterprise-quality Linux desktop”, SUSE also aims on desktop market. Providing great sound subsystem seems be consistent to that target.
• drivers/*/: Also consistent to the desktop market target, Novell provides more driver development efforts than Red Hat. Greg KH as one of the Novell employee costs a big part of his time on Staging Drivers to help Linux Kernel to support more and more new cool drivers.
• fs/fuse/:  I can’t see obvious reason that why Novell support fuse such dedicated.

2) Hardware Venders which mainly sell hardware for profit.

a) Intel

• drivers/net/:  Who are the biggest NIC and Wireless NIC vendors on the world? I think Intel must be one of the them.
• drivers/acpi/:  As the biggest platform vendor, Intel leads the hardware and software development of power management.
• arch/[i386|ia64|x86_64]/:  Who made the CPUs? As the biggest CPU manufactory, Intel should take care the arches which her CPUs support.

b) Renesas

• arch/sh/:  SuperH arch’s biggest manufactory supports the sh kernel without any surprise.

c)  Analog Devices

• arch/blackfin/: Most of her efforts focus on her own platform – blackfin.

3) Software Venders which mainly sell software(except OS) and service for profit.

a) Oracle (before acquiring Sun, Oracle is more like a software vendor)

• fs/[btrfs|ocfs2|nfs]/: As the biggest OSS contributor of software vendor, Oracle is carrying a lot of OSS projects on. The Linux kernel filesystems are just the typical area Oracle is focusing on. As a database maker, Oracle is enforcing some filesystems of Linux Kernel and keeping creating new filesystems to tie in with their database or middleware products.
• block/:  No surprise, Oracle should not only spend efforts on fs subsystems and also block IO subsystems to support their database solutions.

b)  Parallels

• net/[ipv4|ipv6|core]/:  As a virtualization software maker, Paralles’s engineers did a lot of jobs to refine network namespace, which can support network virtualization better.

4) IT Venders which sell whole solutions including hardware, OS, middleware and applications, and of course service for profit.

a) IBM

• arch/[powerpc|s390|ppc64]/: IBM created those arches and provided Linux kernel which can be run on those platforms.
• kernel/:  As the No.2 kernel contributor following Red Hat, IBM did a lot of work to core kernel part, such as kernel synchronism, cpu control, kprobe and etc.
• fs/[cifs|ext3|ext4]/: IBM also hired some active community engineers who work on filesystem area. As we all know, Ted is working as ext3/4 maintainer, IBM employee and TLF consultant.
• Linux Test Project: Although my statistic analysis only includes kernel source code, the great work of LTP makes me have to mention it. As a synchronous-with-kernel and individual project, LTP keeps updating its test cases for kernel and makes a lot of Linux related IT vendors to have a easy day to do QA work for kernel. The LTP project is a special contribution to Linux Kernel.

b) SGI

• fs/xfs/:  As a product of SGI, XFS got wonderful support from SGI. A storage solution and HPC vendor taking some efforts on filesystems is totally unsurprising.
• mm/:  Former SGI employee Christoph Lameter did a lot of contribution to memory management subsystem.
• arch/ia64/: SGI and HP are the initiators of IA64, thus for IA64, SGI did a lot of work as well as HP, Intel.

c) Fujitsu (my former employer )

• kernel/trace/: As a whole IT solution vendor, Fujitsu are doing a lot of work to enhance Linux Kernel’s trace and debug features to provide customer a more robust, maintainable and higher availabilty IT environment.
• drivers/pci/:  During integration, Fujitsu enhances drivers to ensure a high quality hardware environment of server.
• mm/:  Memory controller is maintained by Fujitsu and Google engineers to provide user a more flexible IT environment.

As we can see, corporations are dedicating themselves to kernel contribution for their product lines or services and trying to feed back to community when they gain from community. They are taking the responsibility to make sure the enterprise using components of kernel to be as healthy as customers want.

Let’s see the non-profit contributors are focusing on what areas, which maybe different from that of corporations.

Hobbyists (No one pays them for doing kernel contribution)

• drivers/media/:  As we know, no commercial companies focused on this area. But hobbyists committed 3818 patches(2.4% of total patches of kernel since Linux-2.6.12) to drivers/media/. That  is the amazing phenomena that desktop users are doing such great works to kernel development.
• drivers/[net|ide|staging|usb|video]: A lot of hobbyists are taking care of the stuff which enterprise users maybe don’t want to care.
• arch/[x86|arm]/:  The hobbyists’ most favorite platforms are x86 and arm

That’s the brief introduction about who are interesting in what subsystem of kernel.

For detail information about other corporations and non-profit population who are not mentioned here, such as Google, HP, Academics etc. please refer to the statistic.

但最近Canonical发布的新条款，让人不禁对此产生怀疑。难道Canonical只是一家利用开源做私有软件的公司？

新条款确实有一些不厚道的地方，可能会减少Ubuntu粉丝的贡献度。比如：Canonical will ordinarily make the Assigned Contributions available to the public under a “Free Software Licence”, according to the definition of that term published by the Free Software Foundation from time to time. Canonical may also, in its discretion, make the Assigned Contributions available to the public under other license terms. 很多开源贡献者并不想把自己的代码交给那些会把它变成”Free Software Licence”的人，更何况，根据本条款，Canonical还可以把其他许可权条款加到代码上，而“其他许可权”很有可能就是私有软件许可权。

Canonical会不会在未来进一步对这个新条款做解释，我们将拭目以待。

这个Geeker觉得现在计算机的电源管理功能太弱,比如看电影时会自动屏保,休眠之类的.

于是开发了一个通过声纳系统来精确探测室内人员的系统,主要是使用每台计算机都具备的speaker来发出超声波,然后通过计算机的话筒(有些笔记本会自带)来接受回声,从而像雷达一样判断活动物体.

想法是挺好的,但是我不敢用,因为不知道超声波到底对人体有没有影响,特别是对我们家未来的孕妇和胎儿来说,还是安全第一.

虽然有很多其他男性社区开发人员为Mark辩解，但是女性开发人员仍然认为Mark欠她们一个道歉。目前Mark本人还没有表态。

从我的观点来看，Mark的话无疑把“girls”等价于”不懂软件开发技术的人”，确实是个冒犯。但冒犯女性不是他的本意，所以也可以看作是无意的冒犯。很可惜，无意的冒犯，也需要一个道歉来回答。

据说，以下言论也有大男子主义倾向：

“A release is an amazing thing; I’m not talking about the happy ending..”

“Your printer, and your mom’s printer, and your grandma’s printer”

所以大家以后在公共场所发表技术言论时一定要注意玩笑的尺度

Due to no support from Google, I’ve dropped the android code from the staging tree for 2.6.33.
不过Google的职员的对应相当迅速，David（虽然不负责Android开发）质疑了Greg的“no support from Google”指责，表明对于是否删除Android代码没有意见，但是对于Greg给出的理由表示了不满。明显Google对于Android给予了一定的支持，但是由于和开源社区的开发流程不能很好融合的原因，导致了对于驱动的修补反应较慢。
那么Android驱动在Linux内核中的命运到底如何？这可能还要看Android开发者们跟社区是否能够更好的合作，Greg目前还没有收回删除Android驱动的想法。

1. How much effort the release candidate period should give?

2. Does the quality of stable kernel(stable kernel without update) becomes better or worse?

To figure out the questions, I gathered the following datum.

1. Pre-RC Changed Lines: The lines of source code changed between 2.6.(n-1) and 2.6.n-rc1. These source codes are confluxed during merge window period of each version of kernel. They are mostly implemented for new features of a new version of kernel, which needs a long period of testing and fixing after merge window closes.

2. Defects found during RC: Because mainline almost only accepts bug fix patches in RC period and we encourage one patch per bug, the patch set quantity of RC approximately represents quantity of defects found in RC period, which we call internal(inside development community) testing period. This data comes from git-log between 2.6.n-rc1 and 2.6.n.

3. Defects found after release: After stable kernel release, users and developers themselves will find some bugs and fix them. To eliminate the unfair caused by different release time, I only collect the stable kernel defects which was fixed before next 2.6.x stable release. For example, if 2.6.n was released on 2009.A.B and 2.6.(n+1) was released on 2009.C.D, the “Defects found after release” means the fixes for 2.6.n stable kernel before 2009.C.D. Actually, I dig the data from GregKH’s stable git trees.

By putting the RC defect ratio(”Defects found during RC”/”Pre-RC Changed Lines”[kstep]) to X-axis and Stable defect ratio(”Defects found after release”/”Pre-RC Changed Lines”[kstep]) to Y-axis, I got some interesting graphics here.

Wait… What do you expect to see? More RC fix bring higher quality of stable kernel?

1. Picture-1 maybe disappoints you. We see here: the more bugs got killed during RC the more complaint from stable users or developers.  Why? I don’t remember who said this, but I remember these words “Finding MORE defects means as MORE defects unrevealed”. RC defect rate doesn’t mean that the more bugs fixed the higher quality of release. Instead it tells us whether new features have a trustful quality before being sent into merge window. Developers should well test their patches of new feature as well as the patches for RC. So here comes another question: we can’t keep doing RC forever, thus when should we stop RC and goto release.

2. Picture-2 shows that RC fixing increased nearly as linear trend according to different Pre-RC code quantity. But trend is trend, some kernel releases didn’t have enough defects be found during RC and some had above-average RC defects ratio. Let’s go back to Picture-1, we can see densest RC defect ratio region is about 2.5-3.0 defect/kstep, and the average RC defect ratio is about 2.87 defect/kstep, which is marked by the red ordinate. Below the average RC defect ratio, four of ten releases have above-average stable defect ratio. If we set a rule to not allow ending RC when the RC defect ratio is still below average, we can make “the four” releases more stable.

Now we have seen two pictures of whole kernel defect ratio, but how about subsystems?

X-axis: Pre-RC Changed Lines, Y-axis: Defects found during RC

3. Not only whole kernel should have a RC defect ratio gate, each subsystem also should not allow too low RC defect ratio. Let’s see some.

Network subsystem is almost like whole kernel, stable defect ratio increases as RC defect ratio increasing. “core kernel”, “fs”, “arch” and “block” are almost as same, which I don’t paste here to save my host’s space

network subsys, X-axis: RC defect ratio, Y-axis: Stable defect ratio

Sound subsystem is some kind of strange.  When RC defect ratio exceeds 3.0 defect/kstep, stable defect ratio begins to descend. In my superficial opinion: very strong RC effort(seven times of average) causes higher stable quality. At this point, very high RC defect ratio no longer means “Finding MORE defects means as MORE defects unrevealed”, but means “Highly quality control reduces unrevealed defects”.

sound subsys, X-axis: RC defect ratio, Y-axis: Stable defect ratio

Memory Management looks like an ideal descending trend, if we ignore 2.6.16, 2.6.20 and 2.6.21. In mm, RC defect ratio is very higher than any other subsystems, because mm is essential part of core kernel and rarely changes.  I don’t recall what happened on the three releases, maybe something like virtualization supporting can cause such a defect boom.

mm subsys, X-axis: RC defect ratio, Y-axis: Stable defect ratio

4. This is the last graph which answers my question about “Does the quality of stable kernel becomes better or worse?”. From 2.6.14 to 2.6.30, stable kernel has an average defect ratio about 0.32 defect/kstep. Since 2.6.23, kernel tends to keep a lower stable defect ratio, although 2.6.27 and 2.6.28 departed from the trend. I’d like to say maybe we are releasing kernels of better quality.

Stabe Defect Ratio Trend

As Linus said at Linuxconf this week :”Linux is bloated“,  it doesn’t only means that kernel got bigger and bigger, but also means that kernel grows up faster and faster. So when to release a new kernel not only depends on time and RC rounds, but also depends on defect ratio and new feature’s influence scope.

Facebook 和 Google Search应该是现在互联网上的两大当红应用，但是近日发生的两件事情让我们不得不小心地去使用它们。

事件一：19岁的Jonathan Parker受Facebook毒害严重，日常生活几乎不能没有Facebook，甚至在他入室盗窃的那小会都惦记着自己在Facebook中的社会关系，并且在网瘾的驱使下使用被盗人的电脑登入了Facebook，检查了自己的留言箱。显然如此不专业的行为影响了小偷的工作专注度，在离开现场时，他居然没有退出登入。当然Jonathan在数小时内就被捉拿归案了。

教育意义：此事件告诉我们，工作就是工作，如果上网影响了工作，那么就会丢掉工作。另外在他人电脑上登入帐号后，一定要记得退出登入。

事件二：美国法官命令陪审团在案件审理期间不允许使用个人电子设备访问外部信息。众所周知，美国的陪审团制度要求，为了公平理性地审理案件，陪审员不能在审理期间阅读报纸或电视新闻中有关本案的内容，以免被媒体观点左右。但随着互联网技术的发展，人们现在可以非常容易地通过iPhone访问Google来搜索信息。因此最近有法官准备让陪审团在开庭之前签署一份协议同意不使用移动设备查看任何跟案件有关的外部信息。

教育意义：信息透明和对等不是普适的，在最民主的国家，维护民主的法律却需要信息的封闭来保证得以执行。

你有碰到过由于估算的失误导致开发团队加班加点还无法满足客户的抱怨吗？

本文将向你介绍基于实战的具体估算方法来避免以上的悲剧发生。 

任何项目启动初期都会进行项目估算，当然软件项目也不例外。首先不提那些不做项目估算的项目，目前很多项目就算进行了所谓的项目估算，实际的执行也往往和估算差之千里。笔者认为，既然是估算当然允许误差，但是这并不代表所有的估算都会有很大的误差。我们有很好的方法可以帮助软件项目经理在估算时做到尽量的接近目标。 

这里要先提一下项目估算中的2423法则，通过这个法则我们发现差的估算会让项目团队陷入吃力不讨好的境地。如下图中所示，项目初期对于真正的困难会自然地察觉不到(注意:这是很正常，也难以避免的)，因此把4个单位的项目规模估算为2个单位，接下来在初期设计完成后，开发团队对于项目有了更深入的了解后，发现原来需要做的工作有4个单位。这时再跟用户商量时，用户自然产生不满(试想：你家装修到工程的一半时，装修公司跟你说价格要翻一倍，这如何能接收)。为了尽量满足用户，开发团队就不得不在不可能的情况下加班加点，而这样也顶多完成3个单位的工作，结果为了支付加班费，公司多花了很多钱或者亏本，而最后的成绩也不被用户认可。

2423法则

既然在项目初期很难避免要件的忽视，那么我们有什么办法可以在估算中尽量做到准确呢？答案是根据项目类型使用系数调整。试想如果估算初期就把2个单位的工作×2得到4个单位的工作规模的话，一切问题不就迎刃而解了吗。当然，我们不能拍拍脑袋，随便往任意一个估算上都乘以2。那么到底需要考虑哪些影响系数的因素，每种影响又有多大的系数呢？笔者将根据经验给出以下调整点。

• 开发对象的特质

a) 上层应用软件/底层基础软件：开发对象是接近用户的上层应用呢，还是底层操作系统内核？【0.6(上层) ～ 2.0(底层)】

b) 逻辑/GUI：开发对象是以逻辑为主体呢，还是界面为主体？【0.6 (GUI) ～ 2.0(逻辑)】

c) 动态/静态：开发对象是动态处理(动态获得数据)居多，还是静态处理(数据定义，HTML描述)居多。【0.3(静态) ～ 1.0(动态)】

d) 新开发率：开发对象有多少是完全新的代码，有哪些是既有的修改。比如开源项目的参与开发，由于需要在原有代码上修改，虽然修改量不大，但是付出的劳动跟数倍于它的新开发差不多。【0.5(100%新) ～ 2.5(新开发率低)】

e) 需求的确定性：用户对于开发对象的需求是否确定。【0.7(确定度高) ～ 2(确定度低)】

• 技术/工具

a) 开发技术的成熟度：对于开发对象所需的技术成熟吗？比如有现成的框架可用。【0.6(成熟) ～ 2.0(不成熟)】

b) 开发语言/工具：开发语言是高级语言还是低级语言？基准语言设定为C语言，其他语言跟它的比较可以通过组织内的历史代码得出。【0.6(高级语言) ～ 2.0(低级语言)】

以上因素累积乘以通过一般方法估算出的结果(代码量，文档页数，测试case数)，一般都会得出一个1.5～2.0倍的新估算结果。这个结果和代码量，文档页数等不同，它才是真正的规模，通过它来跟客户讨论要在合同上签多少钱的单。

看到这，整天抱怨自己的项目是一个火星项目，在组织内没有可供参考的生产性数据的项目经理们也可以停止抱怨了。不用自己去定制生产性，只需根据以上规则调整开发规模即可。

1. 输入关键字,例如”FBI’s most wanted”.

2. 搜索结果中会出现一个相册,相片里会提供跟关键字关联的图片,例如一组被FBI通缉的疑犯照片.

3. 点击你需要查看的图片.例如点击拉登的照片.

4. 显示所有跟拉登相关的网页搜索结果.

这种新的搜索模式,可以弥补现在完全基于文字的搜索的不足.

例如你在家里打扫卫生时,发现一只完全不认识的蜘蛛,你不知道它有没有毒,也不知道它的学名是什么.这时你就可以上Bing,搜索”spider breeds”,然后从相册中挑选一个长得跟你家蜘蛛一样的家伙,点击搜索你就可以知道它叫什么蛛以及是否有毒.这样的便利是现在的文字搜索所不能提供的.

笔者在数年前曾经有过这种类似的想法,当时希望:如果把一个不认识的物体用手机拍照后上传计算机,然后把图片作为搜索的关键字传给google就能得到相关信息.看来微软已经先行一步,通过静态的相册达到视觉搜索的目的,下一步应该就是笔者期望的动态图片关键字搜索了吧.

PS:

1. 目前的Bing视觉搜索只有美国版提供,地区版会自动跳转到各地域的Bing服务器,只要主动选择美国服务器后,再次选择视觉搜索即可.

2. 微软的Bing视觉搜索服务需要客户端软件SilverLight支持,使用Bing时会提示用户下载和安装此软件.

OK, 去试试吧,看看你家楼下的小狗是什么品种

Linux驱动维护者GregKH在为Linux-2.6.32的merge window做准备时整理了现有的staging目录。对于微软提供的虚拟机hv驱动代码发表了一下的观点：

目前的hv还没有进入mainline，但是在Greg的patch队列中可以看到hv的代码确实来自于微软。微软在2009年七八月份时把她的Hyper-V技术相关的驱动代码以GPLv2的许可权方式贡献给了Linux内核社区。其主要目的是希望Linux可以运行在Windows2008及其Hyper-V虚拟机之上。

对于如此巨大的贡献，Greg自然非常乐意接受，可是在Greg提出一系列TODO后，微软的开发人员反应非常缓慢，导致Greg发了以上的观点。虽然hv还是有可能在2.6.32的merge window期间加入mainline，但是如果微软的工程师继续不理会Greg的要求的话，hv也有可能在2.6.33的开发期间被移出。

好在微软又做出了反应，这次的微软Linux合作得以有继续的可能，我们也将拭目以待这次重大的合作是否能给微软和Linux带来双赢。

1.  patch制作

1.1 bug修正

bug修正时请注意以下几点：

• 是否没有多余的注释。
• 注释是否符合kernel doc format。
• 是否include了多余的头文件。
• 函数原型是否用了#ifdef。
• 一个画面内不能显示#ifdef和#endif时，是否添加了/* CONFIG_NAME */ 这 样的注释。
• 应该使用EXPORT_SYMBOL_GPL()的地方是否使用了EXPORT_SYMBOL()。
• 使用scripts/checkpatch.pl检查一下。
• 修正后是否再次编译并测试。
• 修正后编译是否有warning。

1.2 生成patch

生成patch时请注意以下几点：

• patch是否太大超过邮件服务器接收单封邮件的上限。
• 一个patch只修正一个问题。类似patch分为多个作成系列，用[n/m]的形式发送。
• 是否明确描述了patch的目的。patch被采用时，这些说明会直接放入Changelog。尤其是反映了社区的意见后再次投稿时容易忘记，请注意。
• 是否对正确的版本制作的patch。
• patch制作时的当前路径是否是新旧两个版本所在路径的父目录。
• patch制作后是否应用并再次测试过。
• 内核patch最好使用git生成。
• diff的参数尽量使用 -Nurp

2.  patch推进

如果推进时已经有人正在社区中推进相关内容的话，请停止patch的提交，而只参与讨论。

2.1 问题再现方式

• 请假设将要面对的社区的维护人员不能理解你在source层的解释，他只能理解更浅显的说明方式。
• 再现的程序尽量是一组command的组合。
• 如果有多种情况可以再现同一个bug的话，那请挑选最自然的方式。假设有个bug导致任何l打头的命令都不能使用。再现方法有多种，以下三种，哪个更好？

a.#lamnotacmd

b.#lshal

c.#ls

首先abc确实都能再现bug，但是a使用了一个不存在的命令，b使用了一个存在的命令，但是并不常用，显然c在实际应用中更加频繁和自然。c作为再现方式的话更容易被社区的维护人员理解和接受。

• 如果这个bug有时会引起kernel panic，有时不会，那请不要忘了告诉社区kernel panic的事，这样可以引起重视。

2.2 邮件格式

• 邮件的标题是否合适。
  • 投稿多个不同的patch时，必须分别采用不同的邮件标题。(标题为 patch名。例:”Subject:[PATCH] mm: fix a bug in container driver” → fix-a-bug-in-container-driver.patch)
  • 投稿一个系列的patch(为了一个目的制作的patch，因为太大的原因 而进行了分割)时，标题上必须添加编号。例：”Subject:[PATCH 1/4]…”
• 邮件采用纯文本格式，并且每行字长小于72字节，不要使用英语以外的文字。
• 邮件的签名不要使用公司统一的复杂签名。
• 邮件作成后，直接另存为*.patch，用这个patch再试验一次是否能打上。因为社区维护人员大都直接把mail另存后作为patch使用。
• 是否添加了必要的Signed-off-by， Reviewed-by， Tested-by。

• Thunder Bird 发送patch时的配置(防止tab自动转换为空格):
  • 1 工具->邮件/新闻账户设置 选择“通讯录”去掉“以HTML格式编写消息”的选框
  • 2 在C:\Documents and Settings\YourName\Application Data\Thunderbird\Profiles\xxxxxx.default目录下生成user.js文件，文件内容如下
    • user_pref(”mailnews.wraplength”, 0);
    • user_pref(”mailnews.send_plaintext_flowed”, false);
  • 3 重启ThunderBird就可以了

2.3 和社区讨论

向社区投稿时请注意以下几点：

• 投稿地址是否正确。(查看MAINTAINERS中相关人员后To or CC)
• 讨论时回复邮件请不要置顶回复，应该在对方的邮件的正文中插入回复。

2.4 patch采用后的对应

patch经过社区review后，认为没有问题，就会被采用。 但是采用后，发生问题的可能性仍然存在。 比如，某个服务器制造商在自己的服务器上运用patch后，可能会由于硬件平台的差异，引起新的障害，这个时候大家就会讨论是否要把patch退回。 因此，出现这种问题后，需要迅速对应，否则很有可能被采用的patch又被退回。

What I am focusing on is the development status of kernel. And by the KPS tool,  I found some interesting points below.

1. The new joining engineers increased since 2.6.29 after a long time continuous decline since 2.6.25, when one and half years ago. 

Linux Kernel New Joiner

2. Although more enginners joined kernel development, involved companies declined 2.6.29.

3. To look at Report, Review and Test, we can find out that more and more people are contributing to Linux by doing QA job. 

Linux Kernel QA

4. Not like USA or Europe, Chinese engineers joined kernel development these years, their contribution become more and more recently.

Chinese Patch contribution

前文已经讲过，云计算具备最基本的三个环节：分布计算节点，计算能力集群和再分配的云，计算能力的用户节点。这三个环节中的任意一个出现安全问题，或者任意两个的连接处出现安全问题，都有可能带来整个云的崩溃。由此可见，对于云计算的安全管理问题要远远比企业内部服务器或者是PC的安全管理来的更复杂。

首先，对于分布计算节点这个环节，安全管理要相对比较简单，这个环节的安全监管和目前企业内部服务器以及PC的传统意义上的安全监管类似，需要对每个分布计算节点进行普通的安全管理。在这个环节要至少保证分布计算节点被入侵的成功率尽量低。就像发电厂内的工作机组一样，单单一个发电机组不工作，对于社会的供电是不会有影响的。但是每个机组至少要有相应的防火或点检措施，保证大多数发电机都能正常工作。不过值得注意的是，后云计算时代的“终端即计算能力”模式中，分布计算节点可能已经不单单是数据中心里的计算节点，而可能就是一台在使用云的用户终端。那么这样的分布计算节点在我们的安全框架下是很难照顾到的。我们不能要求使用云的用户都在其终端上安装指定的安全模块。所以下一个环节的安全是非常重要的，它负责替分布计算节点做掩护。

那么，计算能力集群和再分配的云环节，也就是云计算的核心环节需要哪些安全措施呢。

1. 首先是数据加密处理，由于云内数据最终运行在分布计算节点上，而前面讲分布计算节点的安全性不是百分百，因此万一有分布计算节点被入侵，被入侵节点内存中的用户数据将完全暴露。真的是一粒老鼠屎坏了一锅汤。所以云计算核心在分配计算任务前，数据需要经过加密。同样，在分布计算节点返回数据时，云计算核心也需要有相应的校验方式来确保数据没有被篡改。
2. 其次是虚拟化安全性，整合后的资源通过虚拟化重新分配，而虚拟化的hypervisor有保证各虚拟系统/应用互不影响的义务。因此各虚拟系统/应用之间的通信将被划入本安全框架内，以防止某个虚拟系统或应用被破坏后，影响到云支持的其他服务的安全。就像电力系统中的区域性的电力控制能力，可以保证切断某个区域的电力，而不影响其他区域。在这方面，VMware和Citrix和安全供应商（reflex, Altor, Catbird）合作，提供了较为完善的hypervisor安全功能。
3. 最后是对计算资源的保护，由于云计算核心对分布计算节点有很大的控制能力，而一旦云计算核心，比如任务分配系统，或是虚拟宿主等遭到入侵后，云内计算资源都面临很大的危险。因此需要在本环节加入主动防御功能，比如目前的蜜罐技术，通过设置诱饵来引诱入侵者主动攻击云内某些计算单元，以此避免有效计算单元的损失以及快速找出入侵者。

当然正如电力系统中的供电局一样，他需要负责协调两端电压以及灾害隔离来保证其两端以及自身的安全性。

最后，在计算能力的用户节点中，还是有可能面临一些由于云内安全不够或自身安全不够等引起的威胁。（注：这里的计算能力的用户节点不是指服务的最终用户，而是指使用云的那些服务。比如gmail的用户不是计算能力的用户节点，而gmail服务就是计算能力的用户节点了）

1. 用户节点首先要有威胁隔离能力，这里的隔离是指，当使用同一个云的邻居用户被入侵后，通过该邻居对本用户节点产生的威胁被隔离。假如gmail服务和twitter服务都使用同一个云，当twitter的web服务虚拟主机被入侵后，想要通过twitter的web服务虚拟主机再入侵gmail的数据库虚拟主机的企图不会得逞。
2. 防御宿主的攻击，宿主机在种种安全措施下虽然很安全，但是万一也被入侵的话，通过虚拟API就可以对用户节点造成很大的伤害。因此用户节点在给宿主机很大控制权的情况下，要保留拒绝管理的能力。当然这样的防御策略比较难制定，但却不可或缺。
3. 灾害隔离能力，这是指在用户节点被破坏后，要有自动隔离不让本区域的灾害蔓延到其他用户节点，这就有点类似家庭电力系统的保险丝，通过保险丝来防止自家电力问题蔓延到邻居家或整栋建筑物内。

总之，云计算给安全领域带来了很多新的挑战，而这些挑战不可能由一家安全厂商或一个安全框架就能解决，因此云计算的安全性问题也给业界带来很多新的机遇。如果云计算在以上三个环节中能够保证高度安全性的话，云计算将会比传统计算具备更高的安全能力。就像电力革命之后的社会电力系统的安全性要远远高于某个企业内部维护的电力系统的安全性。

你可以拥有真实世界的建筑，建造房子，城堡和摩天大楼来赚取租金。同样你也可以使用各种机会卡来搞破坏。哈哈！

新鲜出炉的自主品牌WCN，以及其LOGO。（浏览器标签栏和地址栏也能看到一个小的favicon哦）

WCN logo

在电力革命的时代，人们发现电是一个好东西，不仅企业开动机器需要电，家庭照明娱乐都需要用电。于是工厂开始购入发电机自己发电，甚至连家庭也有小型发电机。一副全民发电的势头让发电机生产商着实赚了一笔。 可是大功率的发电机不是所有人都能买得起的，因此电并没有普及到人类的生活中。就像90年代初，计算机对于中国居民还是一件奢侈品一样。

进入“爱迪生时代”后，美国的纽约建立了第一座发电站，拥有6台发动机。可以供应发电厂附近的邮局，教堂和旅馆的用电。从此，随着发电厂的增加，电力被送向千家万户，这时电才真正的普及到了人们的生活中。就像我们现在可以非常容易的通过一台家用计算机访问新浪新闻服务器来获得它提供的强大的存储和信息处理能力一样。

爱迪生时代之后，关于电的革命并没有结束。每个发电厂供应附近区域电力，随着发电厂的剧增，电力覆盖的面积越来越广。但是发电产能和消费并不总是吻合，往往会出现有的区域的电不够用，而它附近一个区域的电却产能过剩。于是出现了一些公司专门负责把邻近区域的电网连接起来，然后付钱给产能过剩的电厂买下电能，转手再卖给电产能不足区域的用户。很快这种生意就变成了非常有利可图的行业，于是电力公司成立，在我国则称为“供电局”。他们不负责生产电能，只负责负载平衡，电力传输，终端计费等。而供电局模式将成为云计算的主要模式来为人们提供更高的信息普及。

类似以上的电力消费演变史，信息消费也将在技术及外形上产生变革。正如电力消费革命的两次转变中的两个重要技术（集中发电，电力整合）一样，云计算的信息革命也建立在两种目前日趋成熟的技术之上：

1. 集群/网格计算：整合分布的小型处理能力，产生一个巨大的处理能力。就像电厂集中了众多的发电机组。
2. 虚拟化：把整合之后的巨大计算能力再次分割后出售给用户，用户完全觉察不出他自己到底是在使用一个物理运算单元，还是云提供的运算能力。就像我们每天使用电，却不知这个电是县发电站产生的还是市发电站产生的。

像电消费革命末期的工厂能源主管，再也不必去维护独立的发电机（备用发电除外），也不用担心由于发电厂产能不足导致停电，甚至不用亲自去交电费那样，现代企业的CIO们也不用去理会获得计算能力的背后到底是个什么云了，只要按照信息流量（包括存储，处理，传输）来付费即可。很有可能一次天气预报的计算使用的计算能力由美国，日本，中国的几万台服务器联合提供，而这些服务器上的部分计算能力可能还被“开心网”用户使用着

不过正如工厂使用备用发电机一样，CIO们在考虑到安全的前提下，也许还需维护数台内部备份主机。而这么做的原因，是由于对云计算的不信任（正如对停电的担心一样）。那么云计算背后到底存在什么样的安全隐患，会让CIO们如此担心呢？笔者下次仍将使用本帖的电消费说明模式来分析一下云计算中的安全问题。

总体感觉：不会买。因为：

       － 虽然是法系车，但是作为A0级小车，车皮太薄，和日系车相当。（我不抵触日系，但不想买法系薄皮车）

       － 1.4排量＋小车身，按说应该挺匹配的，但是明显感觉动力不足。

       － 其他的选择都要比它强。（Fit，Polo，Fabia，Lova）

其实207优点还是挺多的，我主要不买的理由，即第三条，还有很多其他更好的选择。说说207的优点：

       － 手动档档位清晰

       － 外形时尚，内饰也比较活力，我感觉在视觉上和新嘉年华一样都挺入眼

       － 价格很便宜，还有1年的免息免手续费贷款。光从价格上看很适合我这样的杨白劳

       － 空间绝对不是缺点，小归小，完全放的下儿童座椅，后备箱放折叠自行车和儿童手推车都没有问题。

从虚拟平台的角度来划分的话，主要分为全虚拟化和类虚拟化：

1. 全虚拟化是指VMM虚拟出来的平台是现实中存在的平台，因此对于客户机来说，并不知道自己是运行在虚拟的平台上。正因为此，全虚拟化中的客户机操作系统是不需要做任何修改的。
2. 类虚拟化是指通过对客户机进行源码级的修改，让客户机可以使用虚拟化的资源。由于需要修改客户机内核，因此类虚拟化一般都会被顺便用来优化I/O，客户机的操作系统通过高度优化的I/O协议，可以和VMM紧密结合达到近似于物理机的速度。

对于全虚拟化来说，从虚拟化支持的层次划分，主要分为软件辅助的虚拟化和硬件支持的虚拟化：

1. 软件辅助的虚拟化是指通过软件的方法，让客户机的特权指令陷入异常，从而触发宿主机进行虚拟化处理。主要使用的技术是优先级压缩和二进制代码翻译。

a)       优先级压缩是指让客户机运行在Ring 1级别，由于处于非特权级别，所以客户机的指令基本上都会触发异常，然后宿主机进行接管。

b)       但是有些指令并不能触发异常，因此就需要二进制代码翻译技术来对客户机中无法触发异常的指令进行转换，使之无法逃出宿主机的控制。

通过软件级的全虚拟化，可以让一台x86的物理机运行64位操作系统。更有胜者，通过IA64机型模拟古老的Mainframe虚拟机，从而把Mainframe机器的系统迁移至新机型中。

1. 硬件辅助的虚拟化主要是由于在技术层面上用软件手段达到全虚拟化非常麻烦，而且效率较低，才由Intel等处理器厂商直接在芯片上提供了对虚拟化的支持。硬件直接可以对敏感指令进行虚拟化执行。比如Intel的VT-x技术。

从实现结构来看，主要分为Hypervisor型虚拟，宿主模型虚拟，混合模型虚拟：

1. Hypervisor虚拟是指，硬件资源之上没有操作系统，而是直接由VMM作为Hypervisor接管，Hypervisor负责管理所有资源和虚拟环境支持。这种结构的主要问题是，硬件设备多种多样，VMM不可能把每种设备的驱动都一一实现，所以此模型支持有限的设备。目前主要的产品是VMware EX Server，是当前最高端和成熟的虚拟化产品。
2. 宿主模型，是在硬件资源之上有个普通的操作系统，负责管理硬件设备，然后VMM作为一个应用搭建在宿主OS上负责虚拟环境的支持，在VMM之上再加载客户机。此方式由底层操作系统对设备进行管理，因此VMM完全不用操心实现设备驱动。而它的主要缺点VMM对硬件资源的调用依赖宿主机，因此效率和功能受宿主机影响较大。目前主要产品是VMware Server，Virtual PC/Server。
3. 混合模型，是综合了以上两种实现模型的虚拟化技术。首先VMM直接管理硬件，但是它会让出一部分对设备的控制权，交给运行在特权虚拟机中的特权操作系统来管理（称之为Domain 0）。VMM和Domain 0合作搭建起虚拟环境，在其上运行客户虚拟机(Domain N)。这个模型还是具有一些缺点，由于在需要特权操作系统提供服务时，就会出现上下文切换，这部分的开销会造成性能的下降。目前主要产品有Windows 2008， Xen。

Google又惹官司。由于最近Google联合一些电子书发行商公开了大量的电子书籍，此举明显威胁到同样也在做书籍扫描的Amazon。因此Amazon上述纽约的地方法院，要求其介入干预Google的电子书联盟。

Amazon虽然也发布电子书，但是其宗旨是绝不在没有经直接授权的情况下发布有版权的书籍扫描版。而Google认为，由于提供的是书籍片段或摘要，所以即使有版权的书籍也可以发布电子版。在这种情况下，Amazon的竞争优势显然降低。因此诉诸于法律是再正常不过了。

对于用户来说，多了一个电子书阅读的可选方案无疑是件好事，而对于当事者Google和Amazon来说，其成败将决定新的行业规范，胜者不一定获利，而败者也说不定能够获得意料之外的机遇。

git使用了curl，因此设置了curl的代理服务器就可以让git使用代理了，有两种方法：

1. export http_proxy=”10.167.129.20:8080″

2. 编辑配置curl配置文件：~/.curlrc，把代理地址写进去

然后尝试下面几种方法，以下载util-linux-ng为例：

1. git-clone git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git

结果：失败，因为这样不是通过http连接（注意开头是git://）。

2. git-clone http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git

结果：连接成功，但是下载了一点就中断。

3. git-clone http://www.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git

结果：结果同2。

4. git-clone http://www1.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git

结果：成功。

将www改成www1就行了，这应该跟mirroring有关，不使用镜像，直接选择一个真正的服务器，就成功了。 2的失败原因跟3的原因应该是一样的。

要下载linus的kernel tree的话，就可以这样了：

git-clone http://www1.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

2005年eBay花了4.1亿美元购入Skype，今年9月1日，eBay正式出售Skype的绝大部分股份，总价2.75亿，缩水为购入时的65％。

eBay剥离Skype的主要理由是，购入Skype后没有能够达成预期的目标。具eBay CEO说当初购入Skype的主要目的是提供在线商户语音交易的平台。而4亿美元的巨额收购，应该不会仅仅是提供交易的语音平台这么简单，很显然eBay也看重Skype作为崭新的语音平台的领军者的潜力，期望能在在线交易之外的领域有所拓展。

而近几年Skype走的却很不顺。AT&T禁止Skype和一切互联网电话程序在3G网络下使用；Skype创始人和eBay之间的官司等等，让以后Skype的走向很不明朗。

此次接下Skype股份的是一个私募基金集团，其中包括了Marc Andreessen，Marc是网景的创始人之一，后为VC，投资过Facebook，twitter，Digg等目前快速成长中的互联网公司。不知道他是否有神来之笔，可以让Skype再次成为神话。

At this moment Chrome OS is still a mystery, but we can imagine its future a bit and help Google to figure out what Chrome OS shouldn’t be.

What Chrome OS shouldn’t be:

1. Another universal operating system of PC. We already have Windows, MAC, Fedora (Ubuntu, OpenSUSE…) and OpenSolaris. If Chrome OS only wants to use Linux kernel and do what XWindow and shell can do, it will fail because it depends on Chrome, which is a web browser, too much. Any of the above OSes can provides flexible interface and abundant applications, which Chrome OS doesn’t have. 
2. Another mobile phone OS. Every mobile phone vender has its own favorite OS. We already have Maemo, Symbian, Android, RIM, etc. and Chrome OS even can’t support dialing.
3. Another netbook or smartbook OS. Ooh NO. People buy netbook not only for Internet accessing. Most of them hope netbook can do something else without Internet connection.

To be consistent with Google’s strategy: do things that matter to a large number of people at scale. Chrome OS most likely to be a webook or an adbook OS. Of course, your editor coined the name of webook and adbook.

As your editor imagine webook is a mobile device that is

1. A client or terminal of Cloud Computing Service.
2. Light enough to handhold.
3. Has Multi Network access interfaces. (Wi-Fi, LAN, etc)
4. Price lowers than netbook. (Actually netbook can be eliminated by webook and notebook)
5. Powerful graphic computing ability to replay the video form net.
6. Plenty software support for Internet.
7. High security.

We can use webook like that:

1. Hold it when we take train, use it to check email, twitter and youtube when boring.
2. Connect it to a monitor; use it as a pc, except we want to do development, or play hardware depended games.
3. Put it on the car and as a GPS device.

And hope one day PSP can be OEMed by Chrome OS too.

—————–Below is Chinese Version—————–

—————–原创之中文版分隔线—————–

虽然目前Chrome OS对于我们还是一个谜，但是我们还是可以展开丰富的想象力来看看未来Chrome OS到底可以做些什么，也同时帮助Google考虑一下至少不能把Chrome OS做成什么。

Chrome OS不能成为:

1. 另一个泛用性个人电脑操作系统。因为我们已经有了Windows, MAC, Fedora (Ubuntu, OpenSUSE…) 和OpenSolaris这些PC操作系统典范。如果Chrome OS只是想在Linux内核之上做XWindow和shell的工作的话，它肯定会失败，因为Chrome OS太多依赖Chrome这个浏览器，这会是此操作系统的先天局限性。以上的任何一款操作系统都能提供比Chrome OS更灵活的使用接口以及丰富的软件
2. 另一个手机操作系统。每个手机制造商都有其面向的操作系统。目前Maemo, Symbian, Android, RIM等系统都表现非常出色。而Chrome OS甚至不支持电话功能。
3. 另一个面向netbook 或 smartbook 的OS。千万不要。人们购买netbook不仅仅是为了访问互联网。很多人需要使用netbook来做很多其他和网络无关的事情。

为了顺应Google自己的战略: 只作能够影响很多人的事情。 Chrome OS更有可能会成为一个webook或adbook的操作系统。当然webook和adbook是笔者杜撰的名字。

笔者假想的webook是具有如下功能的移动设备：

作为访问云计算服务的一个客户端或终端。

1. 轻便，利于携带。
2. 具备多种网络接口。 (Wi-Fi, LAN等)
3. 比上网本的价格更低。(实际上如果webook能够成长起来的话，必将和笔记本一起把上网本这个过渡产品取代)
4. 足够的图像处理能力以满足网络视频的播放。
5. 丰富的网络相关软件的支持。
6. 高安全性。

那么我们可以像这样使用webook:

1. 乘坐交通工具时用来收邮件，上twitter以及看youtube。
2. 如果不是用来开发或玩要求比较高的游戏的话，把它连接到一个显示器，作为一台个人电脑使用。
3. 作为一个车载GPS设备。

最后希望PSP有朝一日也能搭载Chrome OS。

twitter从上线开始没有多久就开始火了起来，并很快和NTT合作，借用了NTT的网络平台。作为一个日本通信运营商，NTT对于品质的关注一直非常高，而极高的可用性（运转率高达99.9999%）正是其特色。但是NTT在2008年开始和twitter合作的时候绝对不会想到twitter会这么火，并在短期内飞速发展成为人们日常交流的重要工具之一。同时，最近美国NTT的服务器经常遭受一些小规模的DDos攻击，正常的服务在这种规模的攻击下是不会受到影响的，但是要求高吞吐量的twitter则不然。

按照目前twitter的成长速度，其实它应该像Google和Facebook那样拥有自己的基础设施和服务器，而不能再租用NTT提供的公用数据中心了。而恰恰在这个时候，老大哥NTT非常体贴地在美国加州特地新开了一个超大的数据中心。虽然NTT口头没有说这个数据中心就是为了支持twitter的高可用性，但是如此巨大的投入和最近twiiter的不良表现暗示，只有twitter这个超级潜力应用才是此新数据中心的主人。

而VMware方面没有具体的表态。让人不禁暗自猜测此次收购的意图。

首先可以肯定的是VMware准备大张旗鼓做些什么了。种种证据表明VMware已经不甘心在虚拟化和云计算的革新大潮来临之际再继续做一个软件供应商了。VMware提出了PaaS（平台即服务），并具备了vSphere这把利剑，与此同时还顺手从Google签走了几个云和搜索API的大牛，看来VMware可以在平台供应商的舞台上大战身手了。

其次从竞争对手的角度来看，有三个竞争对手促使VMware先下手为强，

1. RedHat，杀手锏是RHEL＋JBOSS＋虚拟化。全方位的解决方案，在PaaS中，特别是开源的PaaS领域占有极大优势。可是Mr. VMware和Ms. SpringSource的全新组合有可能改变未来PaaS领域的格局，带来更多创新和商机。SpringSource把之前带给用户的快捷，实用的服务开发和部署能力注入VMware的云技术中，使未来的用户可能在云平台上也能轻松搞定应用的编译，运行和管理。而RedHat如果对应不力的话，在这方面可能完全失去优势。
2. 微软的Windows7将提供完美的虚拟化方案，而Visual Studio也将提供在云环境下的快速应用部署功能。在此形式下，如果VMware还不提供更接近最终用户的应用部署方案的话，势必会沦落为Windows平台上的一个虚拟软件供应商。而VMware选择了开源的Spring，也正是通过差异化竞争，防止老情人微软的醋意大发。
3. Google App Engine，最近App Engine的宕机并没有让其fans失望，反而在稳步的走向PaaS的模范之路。VMware在和Google做生意的同时，也学习到了Google的战略思维，在自己不具备开发App Engine的实力时，出手收购了SpringSource。虽然一个搞Java，一个搞Python，看似互不影响。但是挖墙脚的事情总让人不踏实，而谁知道呢，说不定这样的人员流动是在Google的默许之下呢？

最后再看看SpringSource对社区的承诺。几乎每个社区支持的商业化开源软件在换东家时都会向社区承诺其江湖义气。MySQL不也是吗？但是嫁了人的姑娘，即使在郎君允许下可以和以前的哥们情人见面，但是多少多了些限制，跟新郎官的roadmap不符的事情可就千万不能做了。

When a webmaster wants to make more money from a website, he/she naturally consider display google adsense on the pages. Then the webmaster can earn money from clicks of adsense links by readers. Different kind of links can offer different money for one click. It’s according to the “keyword price” of the google adsense / adword. Actually google adword determines the keyword price of google adsense.

So there are a lot of people posts his/her experience about what google adword keywords are the most profitable ones. You can search such topic on google adsense forum and find a lot of it. But as we always find that people only posted some static keywords list to show which keywords of adword are the topX profitable ones. That lists sometimes focus on narrow fields (poker, computer… etc). And along with dynamic changing of adword keyword price, some keywords maybe fall out of the list.

Here your editor is introducing a method to dynamically find out what is the most expensive google adword about your site content. This method originally comes form this Japanese site.

As your editor said, the advertisement’s keyword price is determined by google adword, not by google adsense. So we will start from adword.

1. Register a google adword account.
2. Login that account and open the link of “Keyword Tool” (“关键字工具”in Chinese, “キーワード ツール”in Japanese)
3. According to your site’s content give the keyword tool a keyword. For example: If you are running a poker skill site, you can input “poker” as the keyword seed.
4. Search the keyword’ information and you can ask the tool to show you the “estimate price” of ads click. Of course, you can sort the keywords list by “estimate price”, and then you can see the most expensive keywords. Note: the price is how much adword user should pay to google, not the google will pay to adsense user. But the more adword user pay to google, the more google will pay to adsense user

OK. After you know the keyword price, please make your page content compliant to more expensive keyword and make more money.

MOST IMPORTANT: website’s content is all, boring content bring no ads click even if most expensive ads are shown.

－――――原创之中文版分隔线――――――――

如何知道哪些Google Adsense / Adword 关键字价格最高

目前很多站长都会通过显示google adsense来给网站增加收入。网站的用户点击adsense广告的话就会给站长带来一些钱。不同的广告的每次点击带来不同数额的收入。主要是根据google adsense 或 adword关键字价格来支付的。不过实际上，真正决定google adsense关键字价格的是google adword。

互联网上也有很多人发了很多关于最贵google adword关键字的经验贴。读者也可以在google adsense forum找到很多这样的话题。但是当大家读了这些帖子后会发现很多人贴的一般是某个时间点的静态最高价关键字列表。这些列表虽然列出了一些前几名的最贵关键字，但是一般都局限于某个领域（例如poker扑克，computer计算机之类），对于其他领域的站长根本无用。并且随着时间，关键字价格改变，在未来的某个时间，列表中的关键字可以能已经不值钱了。

在这里笔者介绍一种动态查看针对读者网站内容的高价google adword关键字的方法。这个方法最早是来自于这个日本网站。

笔者之前说过，广告关键字的价格由google adword而非google adsense决定，所以我们得从adword入手。

1. 注册一个google adword帐号。
2. 登入adword帐号，并且打开“关键字工具” 链接(“Keyword Tool”英文站点, “キーワード ツール”日语站点)。
3. 根据读者自己站点的内容输入一个相关的关键字。例如：如果你的网站是一个关于poker skill－扑克技术的论坛的话，那么输入“poker” 作为关键字的种子。
4. 然后就可以根据这个种子来查找相关关键字的详细信息了。可以通过“选择要显示的列”来要求显示“每次点击广告的估算价格”，当然可以通过排序来看最高价格的关键字。注意：这里的价格是指adword用户需要支付给google的价格，而不是google支付给adsense用户的价格。不过，显然，越贵的关键字被点击后，adword用户需要支付更多给google，而google也会支付更多给adsense用户。

好了，现在你知道什么关键字最贵了吧？那么尽量让你的网站内容贴合高价的关键字来赚更多钱吧。不过。。。

超级重要：网站的内容才是决定胜负的关键，无聊的内容是无法带来任何点击的，再高的关键字也无法在没有点击的情况下创造效益。

 afbackup [Free]
afbackup是一个CS架构的备份系统，它允许多台工作站（同时或逐个）备份至一台中央服务器。备份动作可以由中央服务器主动启动，也可以由各客户端通过定时服务（crond）来启动。

支持Linux / Unix。

 AMANDA [Free]
Advanced Maryland Automatic Network Disk Archiver支持局域网管理员配置一台单独的备份服务器，该服务器控制多台主机把内容备份至一个单独的大容量磁带驱动器。

支持 Linux / Unix。

 Bacula [Free]
Bacula是一组应用程序。提供了诸多的功能：管理备份，恢复，检查数据完整性。

支持 Linux, FreeBSD, SunOS/Solaris, Windows.

 BrightStor ARCserve Backup for Linux
除了简单的数据保护功能外，BrightStor ARCserve Backup还支持多种数据验证方法来保证最高的数据完整性和恢复能力。

支持 Linux.

 Mondo [Free]
Mondo是一个基于光盘和磁带的数据灾难恢复套件。它支持几乎所有的文件系统，支持LVM，RAID。

支持： Linux, Windows.

 NDMP [Free]
虽然不是一个具体的备份应用，但是NDMP (Network Data Management Protocol)协议允许备份或网络文件服务器厂商集中致力于备份方案的功能性而非操作系统之间的兼容性或移植问题。它是一个面向基于网络的备份以及NAS（网络存储）方面的开源标准。

 UBT [Free]
UBT (Unix Backup Tool)是一个用Tcl/Tk写的工具，通过Expect程序来控制用户的交互。它能通过设置自动创建备份主机和文件系统。该工具具有良好的界面，可以很容易的修改选项以及跟踪备份过程。

支持： Linux, Solaris, SunOs.

――――――――免费的分隔线―――――――――

Arkeia
针对异类网络环境，Arkeia提供了快速，自动的备份和恢复系统。

支持: Linux / Unix, Windows, Mac OS X等.

 BackupEDGE
Microlite的BackupEDGE是基于磁带，CD，DVD和很多其他媒体的备份，存储和数据恢复产品。

支持: Linux / Unix.

 Backup Express
Backup Express是针对异类网络环境的企业级备份和存储解决方案。它独有的分布式架构提供了中央控制的备份和存储方案。

支持: Linux / Unix, Windows.

 LCR by Unitrends
LCR(Linux Crash Recovery)可以让系统管理员在十分钟内恢复Linux系统。

支持: Linux.

 Lone-Tar
Lone-Tar具有快速和精确的备份功能，因此也往往成为备份和恢复的可选软件。

支持: Linux / Unix.

 The Networker Line
Legato的产品线Networker line具有一系列产品，可以提供在异类网络环境下的备份和关键数据管理的解决方案。

支持: Linux / Unix, Windows.

 NovaNET 8 for Linux
NovaNET可以备份和恢复数据至网络内的任何计算机，不管它们是运行Windows, Linux, 或 NetWare。

 Time Navigator for Linux
Linux用户通过它提供的全面的专业备份解决方案，可以在包括Windows, Unix, NetWare 或 VMS 组成的异类网络中完整地保护数据。

支持: Linux.

 Unisol Bart
作为一个不为人注意的备份系统，Unisol Bart包括了归档，恢复，磁带管理功能。可以非常容易地定时安排整个网络内的文件系统备份，跟踪备份磁带，允许用户基于在线磁带数据库定时执行文件恢复。

支持: Linux / Unix.

但是该站的git服务主要是提供给跟Linux内核开发相关的项目，虽然并不严格限定必须是内核代码才能使用git.kernel.org，但只有极少数跟内核紧密相关的用户空间工具可以使用git.kernel.org。

那么如果Linux或者开源软件开发人员想要把自己的代码开源并且利用社区的力量一起来完善开发的话，该如何使用git工具呢？最大的问题，就是git hosting的问题。

不过现在有一些免费的git服务器为大家提供了强大的支持，使用下面的服务器，大家的开源代码就有落脚之处啦！！！

repo.or.cz：第一个公共git服务器。也是目前社区使用最多的git服务器。

github.com： 同时为开源软件和闭源软件提供git服务。开源软件使用github免费，而闭源软件需要付费。

indefero.net： 提供了250MB的免费空间。

Nokia N900装配了强力的ARM Cortex-A8处理器，高达1GB的应用内存以及OpenGL ES 2.0图像加速。所有这些都将给N900带来个人电脑的多任务属性。你也可以非常容易地定制桌面上的快捷方式，widget，应用程序。Nokia N900具有高解析度的WVGA触摸屏以及快速的网络连接功能（10/2 HSPA 和 WLAN）。Nokia N900的网络浏览器使用了Mozilla引擎来提供丰富的交互内容。而完全支持Adobe Flash 9.4的情况下提供了在线视频和互动应用功能。

如果你喜欢使用短消息，即时通信软件，或者Twitter，你可以通过N900的全尺寸QWERTY键盘来进行输入。你还可以使用诺基亚消息服务机制来同时使用10个个人电子邮箱。Nokia N900具有32GB的microSD存储空间，而且可以扩充至48GB。另外配备了卡尔蔡司镜头的500万像素的相机功能可以让你捕捉美丽瞬间。

基于Maemo 5的Nokia N900特性：

    * 110.9 × 59.8 × 18mm的尺寸，181g的重量
    * ARM Cortex-A8 600 MHz 中央处理器
    * 1GB的应用程序内存，包括256MB RAM和768MB虚存
    * 最新版Maemo 5操作系统
    * Mozilla引擎的Maemo浏览器
    * OpenGL ES 2.0图像加速
    * 3.5″ WVGA触摸屏，分辨率800 × 480
    * 500万像素，卡尔蔡司镜头
    * 848 × 480 像素宽屏，25fps帧率录像
    * 32GBmicroSD存储空间，可扩充至48GB
    * 全尺寸QWERTY键盘
    * 1320mAh 电池
    * 10/2 HSPA 以及 WLAN网络连接
    * Adobe Flash(TM) 9.4
    * 四波段GSM/GPRS/EDGE, WCDMA 900/1700/2100, Wi-Fi, A2DP蓝牙

上映日期: 1976-01-29

imdb链接: tt0072890

1.虽然热天是基于真实事件改编，但是导演Lumet鉴于真实事件太暴力而做了很大的改编。

2. 真实的Sal只有18岁，但是实在找不到合适的演员，所以Sal的扮演者用了教父中的二哥。其实这也是Al的强力推荐，虽然导演Lumet一开始很不情愿，但是当试镜时，Lumet却立刻决定使用“二哥”John Cazale。（此人果然很牛）

3. 真实的Sunny在抢银行当天还看了教父，而Sunny和Sal的扮演者Al和John都出演了教父。

4. 室外场景其实是在天气比较冷的时候拍摄的，为了不让演员说话时冒气，在演员的嘴里都先含过冰块。

5. Sunny他们最后出逃时准备搭乘的飞机属于Moddern Air，而那家公司正是在影片上映（1975年）时倒闭了。

6. 除了哪些假的汗，电影中没有使用其他化妆技术。

Download

http://www.kernel.org/pub/software/scm/git/

Install GIT

• 1. make prefix=/usr install /*this operation will install gitweb also*/
• 2. mkdir /pub/git

Install GITWEB

/* make prefix=/usr gitweb/gitweb.cgi

we don’t need to do this operation, becasue [Install GIT] does the job */

• 1. cp gitweb/git* /var/www/cgi-bin/
• 2. mkdir /var/www/html/gitweb
• 3. cp gitweb/git* /var/www/html/gitweb
• 4. now you can access the web by:
  • http://youdomain.com/cgi-bin/gitweb.cgi/

Setup GITWEB

/* Your web interface of git must be urgly by default, here you need a config file to setup gitweb runtime */

• 1. create a file “gitweb_config.perl” in /var/www/cgi-bin
• 2. here is the file

$feature{’blame’}{’override’} = 1;

$feature{’pickaxe’}{’default’} = [1];

$feature{’pickaxe’}{’override’} = 1;

$feature{’snapshot’}{’default’} = ['zip', 'tgz'];

$feature{’snapshot’}{’override’} = 1;

$home_link_str = “LTC projects”;

@stylesheets = (”/gitweb/gitweb.css”);

$logo = “/gitweb/git-logo.png”;

$favicon = “/gitweb/git-favicon.png”;

$site_name = “LTC git trees”;

$projects_list_description_width = 50;

How to let maintainer public his/her git tree

• 1. vipw and add figure info for the maintainer
• 2. vigr add maintainer to “git-admin” group
• for example, if you want to let foo to be a maintainer. The /etc/passwd and /etc/group should be like this

2. Create and maintain a git tree

Create a repo

• cp your_project /pub/git
• cd /pub/git/your_project
• git-init
• git-add .
• git-commit -m “init”
• git-update-server-info

Self Intro

• git config –global user.name “Wang Chen”
• git config –global user.email wangchen@cn.fujitsu.com

Per-repository gitweb configuration

• edit file “description” under your project’s .git directory

How to dev by git

• maintainer should public his tree on ltech server
• maintainer should develop his project on his own machine
• maintainer should use git-push to update the public tree
• before releasing a new version, maintainer should git-tag his tree
• example
  • git-clone a main tree to my public directory on ltech server
  • git-clone a main tree to my own machine as my working server
  • make any change
  • git-tag v-x.y
  • git-push –tags ltech.fnst.cn.fujitsu.com:/pub/git/project_dir/.git to update your change to web

• common developer should clone maintainer’s tree
• common developer can only push his word to his own tree
• common developer can only send patch to maintainer, if he want to change maintainer’s tree

2.require用相对路径的时候
当A引用B，而B又引用了其他文件C时，C的路径如果是相对路径，则是相对于A的路径，而不是相对于B的’

3. include() && include_once()：程序执行到那里才执行
require() && require_once()：不管放在页面的哪个地方都先执行

上网本目前在国内大有取代笔记本的趋势,主流上网本采用Intel的Atom平台,和笔记本相比处理能力接近,足以应付访问Internet,处理文件,欣赏多媒体等应用。

而智能本目前市面上还没有产品出现，那什么是智能本呢？

智能本（Smartbook）这个词来自于智能手机（smartphone）和上网本（netbook）两个词的组合，那理所当然它就成为了兼备智能手机和上网本两者特点的移动设备。智能本主要的特点是：常时开机，耐久电池，3G支持，GPS支持，并配备全尺寸键盘或触摸屏。通常情况下，智能本不同于上网本，它不是由IT设备商销售，而是由无线运营商许可销售。

最早的设计是基于高通（Qualcomm）的高性能实时ARM平台Snapdragon，但现在其他的一些ARM芯片制造商，如飞思卡尔(Freescale)也开发了一些低能耗的ARM芯片参与竞争。

智能机的屏幕可能是5英寸高分辨率触摸屏，也可能是12英寸类似于上网本的屏幕。重量小于900克，厚度小于2厘米，待机时间可达一周。

Snapdragon平台的智能机可能提供1200万像素的相机，移动电视(MediaFLO, DVB-H and ISDB-T), 720p高清摄像机以及高清回放(WXGA 1280 x 768)功能。主要面向的用户是需要随时随地进行内容消费和多媒体录放的人群。例如：通过智能本消费者可以获得目前所在位置附近的餐饮，银行，交通等信息；可以用智能本记录事件并立即上传互联网。

通过安装插件wp-utf8-excerpt（中国人写的哦），即可解决包括中文在内的摘要显示问题。

此插件的安装和使用也比较简单。

首先，按照正常方式上传插件，然后激活。

然后，修改模板文件。

          1。index.php修改后，可以让首页显示摘要。

          2。archive.php修改后，可以让归档页面显示摘要。

        修改代码：

- <?php the_content(); ?>

+    <?php
+        if (is_single() or is_page()) {
+            the_content();
+        } else {
+            the_excerpt();
+        }
+    ?>


复杂数据结构指，由一些简单对象组成的复杂对象。对象可以被增加至该结构，也可以从中删除。实现复杂数据结构的比较好的方法是使用抽象数据类型。

抽象数据类型

抽象数据类型的主要思想是把一个数据结构的实现完全封装起来，并且只提供一套健壮的接口来操纵它。这样做的好处是做到了干净的隔离。实现数据结构时完全不必了解谁来使用它，使用者也不必知道数据结构的内部实现。双方都只要基于接口来实现代码。

另一方面，由于接口的抽象特性带来了一定的代价。抽象一个接口的关键是去除不必要的细节。这对于初学计算机的学生来说也许不错，但是对于内核程序员来说却有问题了。对于内核编程来说，性能非常重要(仅次于正确性和可维护性，或者超过可维护性)。不是所有的内核代码都是性能关键路径，但是大多数都是。而且同一个数据结构既被用于性能关键路径也被用于非关键路径。所以数据结构不能完全抽象化，所有的实现细节必须对程序员可见，这样他们才能用最佳的手段使用数据结构。

Linked Lists

先从简单的开始，我们来先来研究一下双向链表。它的代码在<linux/list.h>中实现。所有处理链表的代码都非常简单，所以可以用inline函数实现。因此把它用于其他GPLv2的项目也是很简单(译者就经常把list.h拷贝到用户空间，稍加修改就能使用)。

List中有两个方面很值得关注，因为他们表明了可能的模式。

1. list_head

它不仅作为链表的头，也是链表中某个项的定位器。笔者曾经见过其他的链表实现。这种实现要求任何数据结构的第一个和第二个域是”next”和”previous”指针，这样才可以对该数据结构实现链表遍历。但Linux内核的list不需要受这种罪。list_head结构可以被嵌入数据结构的任何位置，而且该类型的多个实例可以通过list_head链接起来。通过list_entry()可以找到list_head对应的容器结构体。

这样做至少有2个好处。第一个好处是：程序员拥有对容器结构体的完全布置权，特别是当他们需要把一些重要的域放在一起来提高cache利用性时。第二个好处是：一个容器结构体对象经常会处于多个链表，只要通过在结构体内放置多个list_head域就可以实现了。

把一个结构体嵌入另外一个，然后通过container_of()从子结构体得到父结构体的应用在Linux内核中是很普遍的。并且有点类似面向对象编程的感觉。容器就像是子结构体的一个继承。

2. for_each

list中另外一个值得注意东西就是for_each的各种衍生宏。这些宏用来遍历链表并返回各节点对应的容器对象。大概有20个这样的宏。

这样做的理由有很多，最简单的理由有：

• 我们有时需要反向遍历(根据”prev”)。这里支持5种反向遍历和15种正向遍历。
• 我们有时想从链表的中间开始遍历，这里有4种”continue”宏和3种”from”宏。
• 我们有时想要遍历链表同时访问容器结构体。这里有13种for_each_entry宏可以使用。

我们有时想要删除”current”项，但又不影响正在进行的遍历。这需要在对当前项进行操作前先取得它的”next”指针的拷贝。由此产生了8种for_each_safe宏。抽象数据类型风格的实现会只提供safe版的接口来隐藏细节。但是内核程序员不想在不需要的地方使用safe版的接口来浪费存储空间和效率。

事实上有两种具有细微差别的链表。常规的链表使用list_head作为链表的头。这个结构体包含了一个指向链表开始的指针和一个指向链表结尾的指针。但是在一些情况下，没有必要知道链表的结尾。这样的情况下减少链表头占用的一半空间很有价值。哈希表就是其中的典型，所有的链表头都要放入数组。我们在内核中有hlist，它类似于list，不过hlist_head中只有一个指针。内核中有6个for_each是跟它相关的。

如果我们把正向遍历，反向遍历；途中遍历，非途中遍历；查找容器，非查找容器；安全，非安全；常规链表，hlist进行一次全组合的话，将会有32个不同的宏。但实际上，只有19个被实现并使用了。我们可以实现剩下的，但是由于没有谁会使用它们，所以完全没有必要。

细心的读者会发现以上的数字中有矛盾的地方。20个宏中，有一个不属于以上全组合。这个宏可以让大家理解内核开发者是如何重视性能。这个宏是__list_for_each()。其他的宏都用了prefetch功能，这样的话，在每次循环的开始，CPU都先取得->next指针。这样下次循环开始时链表节点就已经在cache中了（虽然safe模式不是这样）。虽然这样可以提高性能，但是在某些情况下，是会引起性能下降的。当对链表的遍历经常很早就结束，比如说访问了第一个节点后就退出，那么prefetch会浪费很多效率。__list_for_each()一般用于这种情况(网络子系统中很普遍)。

从这个简单的数据结构，我们可以看到两个很有价值的模式。

• 嵌入式定位器（Embedded Anchor）: 在数据结构中包含通用对象的一个方法是，把通用对象的定位器放入数据结构中，然后围绕定位器建立数据结构。通过定位器以及container_of()就能找到相应的对象。
• 丰富的接口（Broad Interfaces）: 不要陷入“one size fits all”的思维中。虽然使用20多种类似的宏实现类似的功能并不常见，但是对于不能找到最佳解决方案的复杂情况来说，却很合适。试图把所有可能性都压缩后放入一个狭窄的接口会无法满足所有的可能性。把所有的变数都考虑到的丰富接口可以鼓励开发人员使用最适合的工具来完成工作，而不是寻找折衷方案。在2.6.30-rc4中，list_for_each_entry()用了3000次，list_for_each_entry_safe()1000次，list_for_each()用了500次。其他剩余的一共使用了1000次。事实证明，就算有些接口很少使用，但不能证明它们是不重要的。

RB-trees

下一个要介绍的数据结构是红黑树。它是一个半平衡二叉搜索树。它通常具有时间复杂度为”log(n)”的搜索，插入，删除操作。在<linux/rbtree.h>和lib/rbtree.c中实现了它。和list非常类似，红黑树也在数据结构中植入定位器（struct rb_node），由此组建数据结构的树。

有意思的是红黑树中没有实现搜索函数。搜索红黑树是非常简单的操作，在rbtree.h的顶部有个例子，只要几行代码就可以实现搜索。虽然如此，但是红黑树的作者还是选择不去实现它。原因就是。。。对了，就是性能！为了写一个搜索函数，需要传递”compare”函数指针给搜索函数，但是compare一般都很简单，而根据函数指针调用compare函数的开销往往比compare本身更大。这样的话，为了效率，需要让整个操作（比较，遍历）被编译成一个函数。另外，虽然也许可以通过inline和宏来达到同样的性能，但是由于搜索本身很短，看来也不值得。

请注意rbtree也没有提供插入函数。更确切的说是：整个插入应该是“开发者需要自己实现查找函数，如果查找失败了，新节点才需要被加入，并且树必须重新调节平衡。”虽然以上的插入过程没有实现，但是最后的加入函数以及调节平衡的函数已经被实现了。

把查找和插入的责任交给开发者，rbtree的库于是有了更多的自由度。“查找某个节点，如果它不存在，就加入一个新的节点”这样的模式是很常见的。但是在查找和加入之间的细节部分通常都是不一样的，以至于这些不能在库里面硬编码实现。通过提供基本的工具并且把细节留给用户，让rbtree的用户感觉到他们获得了自由，而不是必须使用一个“实现了不精确功能”的库。

Rbtree的例子加强了“嵌入式跟踪器”的模式，并告诉我们，提供有用的工具要比提供一个完全的解决方案要实在。在rbtree的例子里，内核只提供了基本的数据结构以及加入，删除，重平衡等工具，但是基本上每种使用情况都可以通过这些基本的素材来提供解决方案。

本模式和内核中的哈希表的实现很类似。哈希表是非常常见的数据结构，但是内核中没有一个确定的实现。当然作为哈希表的基石的hlist和array，以及一些用来计算哈希的通用函数(<linux/hash.h>)还是存在的，但是把这些素材加工成适合某一使用目的工作还是由用户自己来做的。

因此我们有了另一种模式:

• 工具盒（Tool Box）: 有时候，为了一个通用的目的，只提供一套可以组成自定义解决方案的工具，比提供一套完整的解决方案要好。

Radix tree

本篇介绍的最后一个数据结构是基树。Linux内核对于基树有两种实现。一个在<linux/idr.h> 和 lib/idr.c中；另一个在<linux/radix-tree.h> 和 lib/radix-tree.c中。两者都提供了从一个数字(unsigned long)到任意指针(void *)的映射。本文为了介绍设计模式，因此只拿出radix-tree来介绍一下。

radix-tree和list类似的是，它也提供了很多接口而不是一个功能强大的单一接口。List有20个for_each宏，radix-tree也有6个lookup函数。我们可以根据各种情况来使用这些接口，例如是要查找一项还是一个范围，或是否要根据标签进行严格查找，或是要找到指针所在位置，还是要找到指针。

但是radix-tree没有嵌入式跟踪器模式。这也正是它比较有意思的地方。对于list和rbtree，存储它们所用的空间和它们的个数是成比例的，即每个节点占用相同的空间，因此把它们嵌入对象容器内是没有问题的。但是对于radix-tree，每个节点并不代表一个项目(只有叶子节点是)，所以它需要额外的空间来管理中间节点。这导致了一些有趣的结果。

在前面讲到的数据结构中，我们没有提到锁。如果需要锁，调用者会自己去实现（我们称之为调用者锁(caller lock)，这与被调者锁相对(callee lock)）。List和rbtree在内部没做什么需要锁的事情，因此这样没有问题。

但是如果有分配内存的需要时情况就有所变化了。如果一个进程需要分配内存，那么很有可能在内存管理子系统把数据写入磁盘（以获得空闲内存）的时候进程睡眠。而进程睡眠时，可能会有各种各样的锁被持有。那么在radix-tree内部的内存分配，和radix-tree外部的锁之间就会存在很大的相互影响。

一旦知道了问题所在，那么这个问题的解决方案就很明显了：在获得锁之前，就把需要的最大内存量预先分配好。这在radix_tree_preload()函数中实现了。这个函数管理一个有效基树节点的每CPU池并且保证池是满的，这个内存池也不会被其他基树操作使用。在radix_tree_insert()之前调用radix_tree_preload()，之后调用radix_tree_preload_end()可以保证radix_tree_insert()不会由于缺少内存而失败。那么这样的话，就不会和外部的锁之间产生干扰。

结论

好了，我们开始总结一下和数据结构结合的比较好的设计模式。

• 嵌入式定位器（Embedded Anchor）：对于list很有用，并且如果你研究一下koject的话，也会发现同样的模式。
• 丰富的接口（Broad Interfaces）：它提醒我们不必把所有的使用情况都用一个窄接口来概括。完全可以提供多个函数作为接口（当然要使用易懂的统一名称）。
• 工具盒（Tool Box）：有时不必为某些机制提供非常完全的解决方案，而只要提供一套基本的工具，用它们来定制各种不同的解决方案。
• 调用者锁（Caller Locks）：当不确定该由调用者还是被调用者来加锁时，请选择让调用者来加锁。 这样可以让调用者有更多的控制权。

在锁之外分配内存（Preallocate Outside Locks）：虽然这点很明显，但是由于在内核中太常使用了，所以在这里特别提一下。

设计模式最早来源于建筑学，后被计算机科学引用。简单来说，一个设计模式描述了某类设计问题，并且针对此类问题给出了一个被实践证明有效的解决方案。

Linux内核的开发中也遇到过很多设计问题，并且针对这些问题，内核开发者给出了很好的通用解决方案，只不过长久以来没有人很好的归纳和文档化这些设计模式，导致不是每个开发者都能对这些设计模式心知肚明。

以下介绍了几种Linux内核的常用设计模式

Reference Counts

使用RC来管理一个对象的生命周期是很普遍的。RC的主要思想就是，使用一个计数器，当对象被引用时递增计数器，当引用被解除时递减计数器。当计数器的值为零时，对象所使用的各种资源可以被释放。

管理RC的机制看起来是很直接的。然而，有些微妙之处会使得这个机制产生问题。由于这个原因（当然还有其他的一些原因），Linux内核中出现了一个数据类型”kref”以及围绕它的一些辅助函数(参考Documentation/kref.txt, <linux/kref.h>, and lib/kref.c). kref封装了一些容易引起问题的“微妙”，值得一提的是，它们还显式地告诉程序员，某个计数器是作为RC来使用的。由于命名对于设计模式来说是非常重要的，所以在这里提供kref这样一个名字给内核开发人员来使用，会让评审者更加轻松。

Andrew Morton说:

我很希望看到一个patch时，我可以说”啊哈，它用了kref。我了解这个玩意儿，我知道它很安全而且考虑了各种出错处理。”我不希望说：”哦，该死的，这个patch居然实现了它自己的RC方式，我需要review这个实现是否有问题。”

从内核显式地支持设计模式这方面来看，引入kref，可以说即成功又不足。说成功是由于，kref非常清楚地把一种重要的设计模式具体化，并且被很好地文档化，其使用也是高可视的。说到不足，由于kref只是包装了RC的部分情形。内核中还有一些用到RC的地方无法用kref模式来很好的解决。一个不能提供完全功能的RC机制实际上在鼓励错误，因为大家可能会在不适用的地方使用kref并且还以为kref可以搞定。

为了理解RC的复杂性，需要先理解:一般来说，有两种截然不同的引用对象的方式。我们称之为外部引用和内部引用，在某些场合也会被称为强引用和弱引用。

我们通常想到的是外部引用。一般通过get，put来改变计数器。并且在这种模式下，一个子系统的对象可以被其他子系统的对象引用。存在一个外部引用表示：对象正在被使用。

相反的，一个内部引用一般是不会被计数的，并且只被对象所属的子系统内部持有。不同的内部引用可以有完全不同的意义以及不同的实现。

也许最常见的内部引用实例是：提供”lookup by name” 服务的高速缓存。如果你知道对象的名字，就可以在高速缓存中找到这个对象，并获得一个外部引用。这样的高速缓存中的对象是通过一个链表串起来的，而对象在链表中的“存在”就是对象的一个内部引用。不过它并不是一个计数性质的引用。它不表示“对象正在被使用”，只表示“对象被索引以备有人想用它”。这种情况下，只有当此对象的所有外部引用都被解除时，对象才会从链表中删除或者延迟一段时间后删除。很明显，内部引用的存在以及其特性会对RC的实现造成很大的影响。

通过对put操作的实现可以看出不同的RC类型的区别，而get操作上是没有什么区别的。It takes an external reference and produces another external reference. get一般是如下的实现:

assert(obj->refcount > 0) ; increment(obj->refcount);

or, in Linux-kernel C:

BUG_ON(atomic_read(&obj->refcnt)) ; atomic_inc(&obj->refcnt);

注意：get必须在对象已经被至少一处引用时才能使用。一般来说对象初始化时会把RC置1.

“put”操作有三种变种。

1      atomic_dec(&obj->refcnt);

2      if (atomic_dec_and_test(&obj->refcnt)) { … do stuff … }

3      if (atomic_dec_and_lock(&obj->refcnt, &subsystem_lock)) {

….. do stuff ….

spin_unlock(&subsystem_lock);

}

The “kref” style

从中间的开始，2号变种正是kref的类型。这种类型适合在最后一个外部引用解除后就失效的对象。当RC为零时，对象需要被释放。因此需要在此用atomic_dec_and_test()来判断是否满足条件。

适合这种类型的对象不需要担心任何内部引用。sysfs中的对象就是这种类型，它大量的使用了kref。然而，如果一个使用kref类型的对象有内部引用的话，它不允许根据内部引用来创建外部引用，除非存在其他的外部引用。必要的话，可以使用如下的原语:

atomic_inc_not_zero(&obj->refcnt);

如果计数器不为零，它会递增计数器并且返回一个结果来表示是否成功。atomic_inc_not_zero() 是一个相对比较新的函数，出现在2005年的”lockless page cache work”系列patch中。因此它还没有被广泛使用，悲哀的是，kref并没有使用这个原语。

此类引用中没有使用kref，甚至没有使用atomic_dec_and_test() 的两个例子是结构体super_block中的s_count和s_active。

s_active 正好适合kref类型的RC，一个超级块从s_active置1(alloc_super()中置1)开始它的生命周期，并且当s_active变为0时，没有新的外部引用可以再被获得。这个规则存在于grab_super()中,虽然并不是一幕了然。现在的代码由于历史原因，当s_active为非零时，在s_count之上加了一个非常大的值(S_BIAS)， grab_super() 中会判断s_count是否大于S_BIAS，而不是判断s_active是否为0。这里其实只要简单地用atomic_inc_not_zero()来判断就可以了，而且可以避免使用spinlocks。

s_count 是另外一种引用，它既有内部的也有外部的。它是内部引用，由于它的语义要比s_active 这种计数的引用更弱。s_count 记录的引用仅仅表示”这个超级块目前还不能被释放” ，而并不声称它是活动的。它是外部引用，因为它很象一个kref，从1*S_BIAS 开始它的生命周期，当它变为0(in __put_super())，超级块就被释放。

因此这两个RC可以被替换为两个krefs, 并且:

• S_BIAS 设为 1
• grab_super() 使用atomic_inc_not_zero()而不是判断是否大于S_BIAS

spinlock 也可以不要了。

The “kcref” style

Linux内核并没有”kcref” ,但是它可以用来作为下一类RC的名字。”c”是”cached”的缩写，因为这类RC经常在高速缓存中使用。所以它是Kernel Cached REFerence.

kcref 象上面所说的变种－3一样，使用atomic_dec_and_lock()。因为在最后一次put时，需要释放对象或者做特殊处理。这需要在锁的保护下进行，以防止在满足释放的条件时，又有新的引用产生。

在结构体inode中有一个简单的例子i_count。以下是iput()中的一段重要代码:

if (atomic_dec_and_lock(&inode->i_count, &inode_lock))

iput_final(inode);

iput_final()中检查inode的状态并决定是销毁它呢，还是留在高速缓存中以备后用。

inode_lock用来防止基于内部引用(inode哈希表)创建新的外部引用。所以，只有在持有inode_lock时才能从内部引用创建外部引用。很正常的， iget_locked() (or iget5_locked())就是用来做这个事情的。

另外一个稍微复杂一点的例子是结构体dentry。它的d_count就类似kcref。不过它更复杂的是，在我们确保没有新的引用可被创建时，需要用2个锁来保护，即dcache_lock和dentry->d_lock。这要求我们持有它们中的一个，然后用atomic_dec_and_lock()来锁另外一个（prune_one_dentry()）；或者我们用atomic_dec_and_lock()来持有dcache_lock，然后请求获得de->d_lock并且重新判断RC(dput())。这是一个很好的例子，可以用来证明，你永远无法保证可以把所有的RC类型都封装起来。需要两个锁的情况是很难预计到的。

一个更复杂的kcref类型的RC是struct vfsmount.mnt_count。它复杂在两个RC直间的相互影响。首先，mnt_count很明显是一个外部引用的计数器。然后，mnt_pinned，它是来自进程统计模块的内部引用的计数器。很特别的是它记录了有多少个统计文件被打开了。这里的复杂在于，当只有内部引用存在时，它们将全部转化为外部引用。你可以深入研究一下细节。

The “plain” style

最后一种RC类型是只递减计数器而不做任何其他事情。这种类型在内核中比较少见。理由很简单，把一个不再被引用的对象留在原地并不是个好主意。

struct buffer_head使用了该类RC（fs/buffer.c and <linux/buffer_head.h>）. 看一下这个函数put_bh():

static inline void put_bh(struct buffer_head *bh)

{

smp_mb__before_atomic_dec();

atomic_dec(&bh->b_count);

}

这样做是没有问题的，因为buffer_heads的生命周期严格地和页生命周期绑定。一个或多而buffer_heads使用同一个页。buffer_heads们都会保留在页中，直到页被释放，到时所有的buffer_heads都会被清除(drop_buffers())

总而言之，”plain”型适用于：开发者知道总有一个内部引用保持对象不会释放，并且在某处这个内部引用会最终被用来找到和释放该对象。

反模式

设计模式是被证明有效以及应该被鼓励的方法，反模式是历史证明无效的并不被鼓励的方法。

笔者认为在RC中使用”bias”就是一个反模式的例子。在这里”bias”指在RC上加上或减去一个很大的值，而它仅仅是为了保存一个bit的信息。我们在前面的s_count例子中就看到了bias。在那个例子中，bias仅仅指明了s_active为非零，而这完全可以直接判断。所以bias在此完全没有价值，反而会掩盖代码的真实意图。

另外一个bias例子在struct sysfs_dirent(fs/sysfs/sysfs.h and fs/sysfs/dir.c)。有趣的是sysfs_dirent有两个refcount，就和superblocks一样，而且也叫s_count and s_active。在此，当对象被解除有效时，s_active有一个很大的负bias。这样的信息其实可以放在s_flags中。因为在flag中存储一个bit的信息是最容易理解的。

总而言之，使用bias不能增加代码的可读性，因为它不是一个通用的模式。对于refcount来说它是一个反模式，并且必须避免。

结论

简单地使用”kref” ， “kcref” ；以及 “external” ， “internal”这样的术语可以很好地看出不同RC类型之间的区别。用代码来具体化它们，并且尽量使用这种封装，这对于开发人员来说，可以帮助它们更好的选择RC的模式；对于review者来说可以更好地看清代码的原意。

本篇所介绍的设计模式:

• kref: 如果当最后一个外部引用解除时，对象的生命周期就结束，那么可以使用kref。如果对象有内部引用的话，内部引用必须通过atomic_inc_not_zero()被提升为外部引用。例如：struct super_block.s_active/s_count
• kcref: 当最后一个外部引用解除时，对象的生命周期并不结束，这种情况可以使用带有atomic_dec_and_lock()的kcref。只有当持有锁时，一个内部引用才可以变为外部引用。例如：struct inode.i_count
• plain: 当对象的生命周期从属于其他对象时，可以使用plain模式。非零的RC必须被当作传递给父对象的内部引用。而内部引用提升为外部引用的规则必须和其父对象的规则一致。例如：struct buffer_head.b_count

biased-reference: 当你觉得想要在RC上使用一个bias来标志一些特殊状态的时候，请不要这样做，而应该使用一个flag。

还是使用Adsense Deluxe Revived，通过设置添加一个正方形adsense。

然后进入外观设置，编辑single.php，在其中修改：

<div <?php post_class() ?> id=”post-<?php the_ID(); ?>”>
   <h2><?php the_title(); ?></h2>

+   <div style=”float:left;padding:4px;”>
+   <?php adsense_deluxe_ads(’insidearticle’); ?>
 +  </div>

   <div>
    <?php the_content(’<p>Read the rest of this entry &raquo;</p>’); ?>

枣味甘、性平，入脾、胃经；

有补益脾胃，滋养阴血，养心安神，缓和药性的功效；

用于治疗脾气虚所致的食少、泄泻，阴血虚所致的妇女脏躁证，病后体虚的人食用大枣也有良好的滋补作用；

本品甘温益气，质润养血，味甘又能缓和药性，用于气血亏虚及缓解药物的毒烈之性。

养血安神：适于血虚面色萎黄及心失所养、血虚脏躁者；

补中益气：用治中气不足、脾胃虚弱所致诸证；

缓和药性：与祛邪药配伍，可缓其毒烈之性，以护正气。

能提高人体免疫力，并可抑制癌细胞：药理研究发现，红枣能促进白细胞的生成，降低血清胆固醇，提高血清白蛋白，保护肝脏，红枣中还含有抑制癌细胞，甚至可使癌细胞向正常细胞转化的物质；

经常食用鲜枣的人很少患胆结石：这是因为鲜枣中丰富的维生素C，使体内多余的胆固醇转变为胆汁酸。胆固醇少了，结石形成的概率也就随之减少；

枣中富含钙和铁，它们对防治骨质疏松产贫血有重要作用：中老年人更年期经常会骨质疏松，正在生长发育高峰的青少年和女性容易发生贫血，大枣对他们会有十分理想的食疗作用，其效果通常是药物不能比拟的；

CPU(￥740 )         Intel 7400散

显卡(￥595)        影驰9600中将版

硬盘(￥565)        WD SATA 1T

机箱(￥400)        酷冷S500

电源(￥360)        酷冷RS400-A

内存(￥348)        金士顿DDR2/800 2G×2

制冷(￥230)        九州黑虎鲸

键鼠(￥200)        罗技Pro2400无影手

无线(￥105)        TP-Link PCI

线材(￥ 25)        HDMI1.5M

总价 4558元

几点值得一说的：

1. 我没有配显示器，因为这台HTPC基本上在客厅电视旁负责播放电影，因此50寸松下等离子作为显示器即可啦。

2. 由于离电视机有4M远，所以使用了信号较强的罗技Pro2400，据说有效距离是10M，有次厨房有锅子烧开了，我抱着键盘跑去厨房，手不小心按到了键盘，就听到客厅发出咚咚的声音，回去一看原来是按下键盘仍然有效。

3. 由于作为HTPC，所以显卡稍微买好点，不过也用不着太好，毕竟很少玩游戏，买一个够用的就行，否则过高的发热量会使静音发生问题。

4. CPU也同理，7400对于HTPC已经足够，4核完全没有必要。

5. 主板本来看的是P5Q，但是没有货，所以只能另觅，正好发现今年早些时候属于牛板的DS5大降价，立即出手，虽然牛板的很多功能我也用不上，但是价格合理。

6. 电源，制冷，机箱我都研究了很久，但是发现HTPC的整机功率不会非常高，而且现在的静音机箱基本都能达到很好的静音效果，所以当初考虑的Antec等都没有买，现在家里的配置很好，功率完全足够，一点噪音都没有，散热也没问题，cpu和硬盘温度一直保持较低的水平。

7. 内存频率没有必要买太高的，需要和CPU频率，以及主板主频相匹配。对于Intel平台来说，可以算一下前端总线带宽与内存带宽，以达到合理配合，内存带宽＝内存频率x8x通道数（单通道1、双通道2），CPU前端总线带 宽＝前端总线频率x8，二者尽量相等或内存带宽大于前端总线带宽。例如，DDR2 533内存带宽533×8＝4.3GB/s，双通道就是8.6GB/s，与前端总线1066的CPU（带宽1066×8＝8.6GB/s）匹配。

经过四十亿年的漫长演变，地球变成一个物种繁多、资源丰富、奇特美丽的蓝色星球。然而自人类出现以来，我们只用了二十万年的时间，便将地球的宝贵资源消耗殆尽。珍稀物种灭绝，原始资源奇缺，污染日益严重，人类以及地球的明天将何去何从？
导演扬恩•亚瑟经过15年的筹备，历访50多个国家拍成此片。本片素材长达488小时，拍摄周期为21个月，共动用88,000名员工，从澳洲海底的大 堡礁到非洲肯亚高原的乞力马扎罗山；从亚玛逊热带雨林到戈壁沙漠；从美国德萨斯州连绵不断的棉花田到中国上海、深圳的工业城镇。影片以上帝的俯瞰视角向世 人展现地球的绝美以及日趋危急的现状。明天并不遥远，但我们该选择怎样的未来?

虽然看的是480p的片源，但是鸟瞰我们行星的壮丽画面还是重重地撞击了我的魂魄，准备下1080p再看一遍。也许这样的地球在100年后只能通过影片才能看到了。而那时的行星地球是否已经成为了一个彻底的行星坟墓呢？这个答案只有我们自己能回答。

我们是否能减少温室气体的排放，避免北极冰山的融化甚至永冻带的甲烷释放导致海平面上升。

我们是否能够减少滥伐，避免水，土，大气的失衡。

我们是否能够利用可持续的新能源，避免不可再生能源的耗尽。

我们必须能够，否则我们将再也看不到下面的壮丽画面，我们的墓碑上将刻上自杀者的称号。

下面的图片来自good planet

我们熟悉的地球：

澳大利亚的珊瑚

湿地的象群：

火山中的地球生物祖先“古细菌”：

人们正在为重建家园做出努力：

丹麦海岸风力发电

德国的生态社区

海浪发电的“电鳗”

停止钻孔，抬头向天空寻求能源

ADR支持任意处的adsense代码，但是这些代码都需要手工添加。
如果需要一些通用的adsense，比如在首页放个横幅，右边侧栏上方添加摩天楼ad等，则需要通过”Apearance”->”Editor”修改WordPress的模板代码。不过也不难啦。只要使用ADR自带的php函数即可。

ADR还有一个比较好的地方是：可以保存多个adsense条目，并根据命名来区别，这样在调用处通过不同的名字就可以使用不同的adsense条目。

现在在日语单词系统中,主要使用首页横幅的方式来粘贴adsense代码.一开始默认的方式无法中间对齐,后来在adsense代码之外加了<div align=”center”></div>解决了.

好! 从今天起开始盼望第一个10$!

特别申明:本帖内容无鼓励读者点击本站广告之意,请成全我诚实地作人.