由于这次 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 的更新周期，大概是每三周一次。现在我们团队正在实验类似的更新模式，对互联网产品来说，这种模式还是值得借鉴的。
这个国庆假期是在江西过的，去了永新县的三湾，上了井冈山，今天又来到打响中共武装革命第一枪南昌，几乎可以算是一次“红色旅游”了
永新有名的是狗肉，有回一大早就在房里听到外面呜呜屠狗的声音，都说狗的智慧足够高，不知道狗狗们生活在如此的环境里会怎样发展身心，反正觉得这里的狗好像都挺和善。
永新县出了4位解放军中将和几十名少将，但是将军们的塑像和浮雕只是在给贺子珍纪念馆做陪衬。看起来他们为中国革命做的贡献皆不如这位女士，真是神奇的唯物史观
在三湾纪念馆里，陈列了经历三湾改编的几位将军的画像，其中有林彪和黄永胜。在井冈山烈士纪念馆里，2人则消失在朱彭陈罗谭粟等将星中。
为了接待全国参观学习的党员们，特别是为了接待中央和军队大员们，吉安地区规划出一个“井冈山市”，甚至市领导屈尊来兼任这个县级行政区的长官——我猜是为了名正言顺的全程陪同上级而不至于显得不务正业。不管怎么说，这个旅游点建设得不错：火车站极好，相比较看，通往这儿的火车就显得分外破旧了；市区是在茨坪这个海拔1000多米的地方凭空盖出来的，干净整洁。总体而言，井冈山很适合度假，我的意思不是旅游（vocation vs travel）；来这个安安静静住个几天就好，景点不过黄洋界等红色故地，没有太多逛头。
贴士1：我们在井冈山一直是在革命博物馆南边的南苑宾馆二楼餐厅吃饭，价格还算公道。它好像主要业务是晚上的团餐，如果晚饭得早点去，否则就招待不上了。
贴士2：在南昌是亲戚安排的百瑞四季酒店，四星。我们住的标准间貌似网上的报价是388，个人觉得还算物有所值。现在就在用它的免费宽带写blog。百瑞是杭州的酒店管理公司，2楼的餐厅的杭州菜很好吃。晚上赣江边秋水广场的音乐喷泉值得一看。
南昌最有名的景点应该是滕王阁了，可是我很怀疑它只是为了验证《滕王阁序》才有不断重建的必要。明日登阁，不晓得会否看到一堆游客长吟落霞与孤鹜齐飞？
见：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
gmail的会话合并是通过主题来完成；而且没有参考Header里的字段——做一个简单的测试：回复一封信，换一个主题，然后可以看到回复信和原件并不在一个会话里。
根据主题来确定会话是一定要有的，几个中文webmail只有163、QQ、sohu正确的实现了In-Reply-To，为了更大的兼容性必须如此。
搜狐现在的方案是，同时根据Message-ID、In-Reply-To、References，以及信件的主题来做会话的归属计算。所以在 GMail 里看到的会话和 Sohu 里看到的会不太一样。
GMail 仅仅使用主题来计算可能是优化这种情况：发信人很懒，每次写信都是从读信页面里选择回复，然后换个新主题，删除掉所有内容，而不是重新写一封邮件。我们以后是否也换成这个策略等用户反馈吧
或者可以更智能的从内容里面的引用关系、相关度去计算会话？？现阶段还只能想象了。
某些情况下我们会主动 break 会话：
会话总数量超过 100 封 （太多了对阅读信件UI是一个灾难）
===============================================
有的时候，信箱里会有2封或多封Message-ID一样的邮件，最简单的情况是你写一封信给自己，这样已发送和收件箱里各有一封；或者你发一封信给邮件列表，邮件列表会重新给你寄一份。
在一个会话里看到两封一模一样的信不那么优雅，我们的规则是这样：
开源爱好者在系统选型的时候可能很少有人去仔细考虑商业产品的生命周期问题，但这个策略对系统架构实在是影响巨大。即使你是在运行CentOS这样的免费克隆，也应该对RHEL的相关知识了如指掌。详情去看 https://www.redhat.com/security/updates/errata/ ，我这里只是简单介绍：
最后总结一下：RHEL的头四年可以获得最佳的软硬件支持，GNU/Linux Stack 对商业运行来说有价值的更新会被backport（epoll就曾经这样被移植回了RHEL3的2.4内核）；在第5年将只有部分的硬件支持，这个时候应该开始把业务迁移到新的RHEL上；在最后2年就只剩下bugfix，给客户一个平稳过渡的时期。
现在RHEL4的P2已经快要结束，还在使用RHEL4的同志们该开始考虑升级到RHEL5了；或者再等半年，2010Q1据说6就会发布了
在登顶启孜后，我已经从一个菜鸟成功升级为户外初级玩家，DKN店也去了有六七次，感觉DKN除了户外装备外，也蛮适合家庭购物买衣服买鞋的
迪卡侬有十几个自有品牌，分别对应不同类型的产品，我比较关注的东西包括：
novadry 差不多相当于广告泛滥的 Gore-Tex 技术，简单说就是防水透气，没有这个专利的防水产品，透气性就差些了。
这个定位是保暖，通常是抓绒衣？
这个定位是贴身排汗，买速干衣裤、内衣、袜子的时候注意一下有没有这个技术
这个不是迪卡侬自有的专利，是全球做登山鞋底的第一品牌。
这个主要是背包上使用，和背包另外一个相关的专利是 Symbium 背负系统 
，不过这个太专业了点儿，一般家用就不考虑了。
这个系列陪我上山的东西包括：
它的魔术头巾太没有性价比，而且花色只有一种。
在这里给我家达达买过一件速干T恤和一条速干的7分裤。
它家的品类实在是包罗万象，虽然有些项目从来不玩，但货架也值得一逛——比如马术系列，有人就发掘出这个手套着实不错。
最后要说的是，去迪卡侬之前先在官方网站上大致浏览一下，看看哪些东西缺货，哪些打折，一个城市内也货比三家，一定可以节省不少时间和金钱。
大家在使用 GMail 的时候，有没有想过在会话列表里面，多个会话参与人是按什么原则显示出来的呢？
我们并没有去反向 GMail 的代码，只是按我们对会话阅读行为的理解，并参考了一下 GMail 的显示样式，定出如下规则：
自从闪电邮箱的会话功能进行开发以来，我就一直在密切对比会话在我们这里，和 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
本站的feed
最新评论