技术

前不久说过 MacBook 上首先引入了该特性，现在看 Thinkpad 也能跑了：Win32、Linux.

Thinkpad/Linux 是需要 hdaps 加载的，建议使用 tp_smapi

总体来说，这东西还是对 Fennec 有意义，摇晃一个 notebook 或者哪怕是 netbook 都够傻的

由于这次 xorg 1.7 跳票十分严重，Peter Hutterer 建议对以后的版本开发以及发布进行改进，主要就是两点

1. master 只对 release manager 开放，和 Linux 开发模式类似——每个人在自己的分支上工作，由 Linus 负责合并其他程序员提交的 patch

2. master 维护阶段分成3步，merge window、bugfix、release freeze。他目前建议是 3M + 2M + 1M 的时间段，这样正好每半年做一次发布，也和 GNOME、Ubuntu/Fedora 的发布节奏吻合。

这种基于deadline的发布比起基于feature的发布来，商业性的意味更强一些，而少了工程师理想化的色彩....

最后要说的是，我注意观察了一下 QQ Mail 的更新周期，大概是每三周一次。现在我们团队正在实验类似的更新模式，对互联网产品来说，这种模式还是值得借鉴的。

见：http://wuhongsheng.com/it/2009/09/ssl-hijack/ ，现在这个所谓的漏洞已经得到修补，暂时不打算跨省追捕这个吴洪声

附带宣布一下，继 vip.sohu.com 提供 https 服务之后，mail.sohu.com 也计划提供全程加密的 https 连接。技术在 vip.sohu.com 上已经证明可行——主要是灵活处理 URL，在普通模式下静态资源比如图片/JS使用 CDN；在 https 模式下使用 https://mail.sohu.com。

引用：http://lwn.net/Articles/352863/

在"kernel 2.6.32 前瞻"里提到过，在和 BFS 进行了对比测试后，程序员们将在 2.6.32 里修复原来 CFS 的一些问题，这里都有些什么呢？？

首先是 NEW_FAIR_SLEEPERS 特性缺省会被禁止掉。这个功能是当一个进程结束睡眠返回运行队列的时候，gives it a small runtime credit。现在看起来这个东东实现得有些问题，未来解决后也许会重新打开。

该特性实际上现在就可以关掉。CFS scheduler 提供了 15 个 bool 值来控制其运行（原文是说它有32768种组合），我们只需要简单的

echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features

或许你的桌面就运转如飞了。

还有一个变化就是 Child-runs-first。【虽然我们在操作系统课里学到，fork() 之后的代码段究竟是 parent or child 首先执行是不可知的，但实际上操作系统的行为绝对不是完全随机的，我猜在 CPU 不那么多的系统上更是如此。】最近 Linux 的实现里，子进程会被安排优先执行，从概念上来说这样设计是对滴，因为通常意义上子进程的工作更重要；但这个有可能影响性能：在此时父进程的上下文信息被当前CPU、TLB保持，立即切换到子进程会有些延迟。在 kernel build 测试里，Parent-runs-first 性能有了显著提高。

有人提出质疑，说这样的变动可能导致那些假设子进程会首先运行的程序异常。尽管我觉得那些不按理论规范只凭经验写程序的人碰到麻烦是咎由自取，2.6.32里还是很厚道的留下一个kernel.sched_child_runs_first sysctl调用去向前兼容。

最后是 cpuidle，为了社会和谐，现代高功耗的 CPU 都有这个 idle 功能。一方面是在低功耗模式下，切换到普通模式由于本身这个操作是相当耗能的，所以在低功耗状态下会执行得很慢；另外这种切换有一个性能损失造成延迟...甚至 BFS 也没有解决这个问题。有人已经弄出一个 patch 解决问题（具体算法去看 LWN 原文），有可能会被合并到 2.6.32 里。

先介绍一下现在内核的开发模式：一开始Linus大概花2-3周的时间从其它人的git里合并代码，他肯定不可能看懂所有的代码，但我们也知道他也会拒绝那些他不太喜欢的代码；然后关闭 merge window，发布一个rc1，理论上所有的功能都freeze，剩下的只是 bugfix；这里也有例外，要看linus的心情而定，比如2.6.31的rc2里是又额外添加了新feature的；接下来差不多每周发布一个新的rc，在 7-10个rc版本之后，一个新的内核版本就正式发布了。总之现在大约是每11-13周有一个新的2.6.x出来

下面看看2.6.32

1. 在 Greg KH 发出威胁后，微软的程序员终于在列表上开始了回应，似乎 Hyper-V 驱动还能继续在 stage 里呆着。微软必须学好怎么在 kernel 开发者社区中生存
2. 某些程序员在和 Brain Fuck Scheduler 进行了对比测试后，发现了当前调度器中的一些问题，在 2.6.32 中会得以修正。看起来 BFS 永远也不会被合并到tree里，希望它的一些概念能给我们使用 linux desktop 带来更好的体验
3. devtmpfs 是一个争议很大的特性，有几个人认为它很垃圾，但linus看起来不这么想。devtmpfs 又称为 devfs 2.0，好处之一是在内核自举的时候就把设备都挂到 /dev 上，节省了执行 udev 的时间
4. DRBD... 终于也要进入内核了，事实上 devtmpfs 受到质疑的原因之一就是它对 DRBD 设备的集成. DRBD 算是一个简易廉价的存储HA实现，我知道以前 zhanzuo.com 就在用这个特性

gmail的会话合并是通过主题来完成；而且没有参考Header里的字段——做一个简单的测试：回复一封信，换一个主题，然后可以看到回复信和原件并不在一个会话里。

根据主题来确定会话是一定要有的，几个中文webmail只有163、QQ、sohu正确的实现了In-Reply-To，为了更大的兼容性必须如此。

搜狐现在的方案是，同时根据Message-ID、In-Reply-To、References，以及信件的主题来做会话的归属计算。所以在 GMail 里看到的会话和 Sohu 里看到的会不太一样。

GMail 仅仅使用主题来计算可能是优化这种情况：发信人很懒，每次写信都是从读信页面里选择回复，然后换个新主题，删除掉所有内容，而不是重新写一封邮件。我们以后是否也换成这个策略等用户反馈吧

或者可以更智能的从内容里面的引用关系、相关度去计算会话？？现阶段还只能想象了。

某些情况下我们会主动 break 会话：

1. 和第一封时间超过 30 天的 （想象一下你订了一个服务叫“今日股评”）
2. 会话总数量超过 100 封 （太多了对阅读信件UI是一个灾难）

===============================================

有的时候，信箱里会有2封或多封Message-ID一样的邮件，最简单的情况是你写一封信给自己，这样已发送和收件箱里各有一封；或者你发一封信给邮件列表，邮件列表会重新给你寄一份。

在一个会话里看到两封一模一样的信不那么优雅，我们的规则是这样：

1. 首先隐藏不在本文件夹的信（比如一封信发给自己，那么在收件箱中，看到的是投递过来的信；在已发送中，看到的是发送出去的信）
2. 然后隐藏新邮件（这样也是为了防止攻击，恶意顶掉别人发的信件）
3. 最后保证，一个会话只显示一个 Message-ID

开源爱好者在系统选型的时候可能很少有人去仔细考虑商业产品的生命周期问题，但这个策略对系统架构实在是影响巨大。即使你是在运行CentOS这样的免费克隆，也应该对RHEL的相关知识了如指掌。详情去看 https://www.redhat.com/security/updates/errata/ ，我这里只是简单介绍：

1. 每个RHEL版本生命期是7年
2. 7年里分为三个阶段，Production 1 Life Cycle Phase、Production 2 L C P、Production 3 L C P。。。下面就用 p1 p2 p3 来缩写吧
3. 大致来说P1是头4年，P2是第5年，P3是剩下的2年
   
4. 不管产品在哪个阶段，都可以得到技术支持、安全方面的更新、以及bug修补。关于这个bug修补，RedHat是有选择的，只有那些被认为影响业务运行的才会被修补。
5. 在P1和P2阶段会发布Minor Release。就是Update1, Update2...或者说4.1、4.2. P1 阶段的Update相当于微软的ServicePack——这种Update并不只是简单的补丁集合，而会包括功能方面的扩展和增强——比如最近的 RHEL 5.4 一个显著变化就是加入了 KVM 的支持（Xen将被RHEL慢慢遗弃）；P2阶段的Update将不包括功能的变化。这种企业发行版本的一个特点也是在功能不断更新（4年之久）的情况下，还可以长期保证客户、ISV的向前兼容能力。P1阶段的每次Update都会发行新的安装介质，在P2阶段除非极端必要，否则不会有新的介质出现（这一点RHEL做得不如CentOS，哈哈）
6. 在长达7年的时间里，除了要应付业务和软件的变化外，另一个挑战就是硬件变化。在P1 阶段RHEL会积极的将最新硬件（我猜主要是认证厂商的服务器）驱动backport。P2阶段则是有选择的更新硬件驱动，上面说了P2阶段不会再有功能变化，因此只有那些不会影响软件堆栈的硬件驱动才会加入。如果你一定需要在尚不支持的硬件上运行P3阶段的RHEL版本的话，RedHat的方案是：现在已经进入了第6个年头，最新版的RHEL此时应该在P1或P2阶段，客户可以在新的RHEL上虚拟化上一个版本。

最后总结一下：RHEL的头四年可以获得最佳的软硬件支持，GNU/Linux Stack 对商业运行来说有价值的更新会被backport（epoll就曾经这样被移植回了RHEL3的2.4内核）；在第5年将只有部分的硬件支持，这个时候应该开始把业务迁移到新的RHEL上；在最后2年就只剩下bugfix，给客户一个平稳过渡的时期。

现在RHEL4的P2已经快要结束，还在使用RHEL4的同志们该开始考虑升级到RHEL5了；或者再等半年，2010Q1据说6就会发布了

大家在使用 GMail 的时候，有没有想过在会话列表里面，多个会话参与人是按什么原则显示出来的呢？

我们并没有去反向 GMail 的代码，只是按我们对会话阅读行为的理解，并参考了一下 GMail 的显示样式，定出如下规则：

1. 后端把该会话的所有参与者地址都返回JS，分成两组：第一组是会话第一封信到第一封未读的发件人，第二组是第一封未读到最后一封的发件人。排序为按时间排序，并排重；第二组有可能还携带信件是否已读的标记。剩下的处理都在前端js完成
   • 如果只有一组，则可以按一个固定的策略显示
2. 如果已读的第一个和未读的第一个发件人不同
   • 显示已读的第一个，即会话的发起者。跟随一个省略标记
   • 否则只显示省略标记
3. 然后显示未读邮件的第一个，即未读的最新的发件人。
   • 剩下的未读邮件发件人尽量全部显示出来 (如果开发这个功能有障碍，那就先只显示最新的一个人好了)
   • 如果不能完全显示，则尽量显示最新收到的邮件发件人；别忘了再增加一个省略标记
4. 为了尽量在这里展示更多的发件人信息，规则如下
   • 只显示 First Name，即："Yingbo Qiu" <qiuyingbo@…>，只会显示 Yingbo
   • 没有 Name 的，只显示地址前缀，即： <qiuyingbo@…>，只显示 qiuyingbo
5. 示例
   • Yingbo ... Xiaoyu, Jichuan, Yuan (全部已读)
   • Yingbo ... Xiaoyu, Jichuan, Yuan (全部未读)
   • ...Xiaoyu ... Jichuan, Yuan (会话的发起者也是 Xiaoyu，和第一个未读一致)
   • Yingbo ... Xiaoyu .. Jichuan, Yuan (混合了已读和未读)
   • Yingbo ... Xiaoyu ..Jichuan,Yuan (第二组中，Jichuan 信件已读。。。这种情况概率很小，一开始可以考虑不实现该特性；甚至让第二组返回的时候，只返回未读信件的发件人列表)

自从闪电邮箱的会话功能进行开发以来，我就一直在密切对比会话在我们这里，和 GMail 里的合并情况。碰到过几次信件已经在 GMail 那里形成会话了，但我们这里还没有收到。

一开始我很紧张，以为是我们这里拒信或者是什么其它的bug导致，后来发现，几乎都是因为 Google Group 的信件延迟造成——严重的情况下可能长达一个小时！

下面是今天收到的信件的 header：

Received: from mail-vw0-f137.google.com (unknown [209.85.212.137])
	by sohumx35.sohu.com (Postfix) with ESMTP id 5128ECAC2F8
	for ; Wed, 23 Sep 2009 14:25:14 +0800 (CST)
Received: by vws1 with SMTP id 1so470671vws.17
        for ; Tue, 22 Sep 2009 23:25:13 -0700 (PDT)
...
...
...
Received: by 10.220.68.102 with SMTP id u38mr167676vci.5.1253684010780;
        Tue, 22 Sep 2009 22:33:30 -0700 (PDT)
Received: by 10.177.112.39 with SMTP id p39gr101426yqm.0;
	Tue, 22 Sep 2009 22:33:26 -0700 (PDT)
Date: Tue, 22 Sep 2009 22:33:16 -0700 (PDT)

在从 10.220.68.102 发送到 vws1(mail-vw0-f137.google.com) 这台服务器的过程中，延误了50多钟。嗯嗯，不能全然迷信 Google

列表页面，发件人栏标识出了相关的参与者

信件阅读页面

会话功能目前只有部分用户可以使用，预计11月5日将正式发布