技术

刚刚弄明白了 Mashup 的意思，现在总算知道别人在讨论 Mashup 的时候是在说什么了..

现在我的 email client 是 Thunderbird，前不久发现它居然也包含有一个很酷的 Mashup 应用：就是如果你在 addressbook 里面给联系人指定地址以后，会出现一个 "Get Map" 的按钮，点击后进入 google map 自动搜索。是不是足够有创意？至少 gmail 现在还没有这个功能

不过 thunderbird 是去美国查找，可以说本地化很不好。期望着有谁能做一个 Thunderbird 插件，去 go2map 或者什么别的地图查中文地名就好了

关于这条 MySQL 技巧好像很多人都还不知道，所以这里说一下。

那天在用 phpmyadmin 的时候，无意中发现 varchar 字段有一个"整理"的属性，怀着好奇之心看看都有什么选项，结果发现有 gbk_chinese_ci。怀着激动的心情测试了一下，果然和我预想的一样！加上这个属性后 order by 就会按照汉语拼音去排序结果！！即使数据是按 UTF-8 编码存储的仍然如此！！！

这个特性真的很不错，以前还特意写了一个 PHP 函数来做拼音排序，现在直接从 MySQL 的结果集里面查询就好了。

呵呵，看来从 phpmyadmin 里面也能发现宝藏... 比啃 MySQL 手册强多了

当前的 Linux 发行版，选择中文环境后，缺省的 Locale 设置基本都是 zh_CN.UTF-8。由于我们Win32缺省的字符集环境通常是 GBK/GB18030，导致 putty 登录上去后访问 UTF-8 编码的中文文件不正常。以前我只是修改环境变量为 zh_CN.GB2312，然后只操作 GB 编码的文件；最近已经完全调整为纯的 UTF-8 工作环境了。

首先选择一个中文字体，可能有人喜欢 Fixedsys (我以前一直用的是从 NetTerm 提供的 isi_oem 字体)，但是很遗憾，必须选择一种 TrueType 字体，比如新宋体才能在 UTF-8 环境下用。

然后将字符集转换(charactor set translation)从 "Use font encoding" 改为 "UTF-8"

现在你就可以在 putty 里面自如的阅读和输入 UTF-8 中文了！

经常可以看到这样的需求：需要给用户开建 sftp 或 cvs 帐号，但不希望给其一个 shell。今天发现有一个工具叫 rssh，正好可以用来干这个。

rssh 还有另外一个很重要的功能，就是使 sftp 用户登录后被 chroot，不能进入到其它目录。这样也没有必要去安装什么经过 chroot 补丁的 sshd 了。

用 yum 或者 apt 安装 rssh，缺省的几个比较重要的文件应该是安装在

/etc/shells 文件里面也应该包含有 /usr/bin/rssh

或者您自己编译源码，然后手工修改 /etc/shells 去，强烈建议新手这么去 configure：

修改用户的 shell 为 /usr/bin/rssh , 这样这个用户就不能 ssh 登录了

然后创建用户 sftp 的 chroot 目录。本来 rssh 自带一个脚本，不过在我的 ubuntu 工作有些问题，主要是 ldd 获得所依赖的库不准确。所以修改了一下，见附件。

给对应的 test 帐号设置一个 chroot 目录的命令：

最后修改 /etc/rssh.conf：

习惯了 mysql 的转义函数，在开发 PyMobileSync 的时候碰到了问题。最后在一篇中文blog里面发现了方案——表示成两个单引号来转义，相应的别的字符就不用转义了..

另：Python 2.5 final 正式发布了！

我们老板总说，叶忻可算是"中国CTO第一人"。这个称呼怎么来的不去细究，但先后在搜狐、中关村科技、掌上灵通担任 CTO 之职，可见确有独特之处。

其实仔细回想，今天的会议里叶忻并没有什么特别出彩的地方，就是一个观点和我不谋而合——"一堆程序员捆在一起封闭开发没有好结果"。自己的想法能亲耳听到一个牛人也同意，小小得意一下。另外就是他非常强调开发人员(其实包括任何工种)的责任感和自主能力，具体技术反而没有怎么说。和新浪李嵩波相比是两种完全不同类型的人，不过他们俩我都很喜欢。

叶忻说：百度的发展途径很好，非常稳健，不要急于扩张。

还提到：cisco 购并公司后，能把原来公司的领导留下来继续做老大，但 CA 合并公司后人事动荡就很厉害。所以 cisco 做的好。

回头搜索了一下叶忻的资料，发现多年前的一篇专栏《程序员》：直面CTO，里面的一些观点还是挺有趣的，推荐阅读

另外，叶忻说起他的女儿现在高二，每天泡 myspace，立刻让我想起了以前看到的麦田的文章..看来 myspace 就是美国的 QQ 啊..怪不得火

知道李嵩波这个名字是因为他去年替换严援朝成为新浪的 CTO，当时以为是一位海龟，特地搜索一下，没想到是新浪的老臣子。辛苦近十年，终于修成正果走上台面。

周一去新浪，在别人的介绍下就网站的研发和运营维护去请教，双方进行了热烈友好而又卓有成效的会谈。可能是担心自己并不是在第一线工作，李嵩波特地找了一位新浪具体负责运营的同事参与了讨论，但实际上这位发言的机会很少，绝大部分的技术细节李嵩波都很清楚，这着实让我有些吃惊，可以看出虽然他在比较高的位置上，但还是掌握的东西还是很细致全面，这里小小的表示佩服一下。

不过李嵩波应该是更偏重于运营，所以我这里的佩服也是有限度的——比如网易的云风我是真正佩服的。从李嵩波顶替严援朝开始，就能看出新浪把技术的重心更多放到了运营而不是产品开发上。另一方面，那批老同志其实也早就在互联网里面落伍了。

会议室据说就在黄冬附近，但他重感冒，没有见到，有些遗憾。

附：最近见到另外两个技术总监级的人物，一个公司吵吵嚷嚷计划上市，另一个是 Web2.0 后起之秀貌似很有前途，和他们接触以后让我感觉如果我去找个 CTO 干干似乎还是很可以很安全的混下去的，哈哈..

本来写了一个 Python 2.4.x 的 patch，让 Python 可以 native 支持 IrDA socket。但是 Python 的维护者告诉我 Python 2.5 早就 freeze，除非 bugfix 否则不考虑接受新的 feature。因此就做了一个 Python 扩展，至于维护人员认可会这个 patch 并加入到 2.6 里面去就看我的努力吧。

扩展大约一周前就做好，在邮件列表上发布了，但是无人响应，似乎是 Python-CN 的用户有红外设备的不多。所以还是在 Blog 上贴出来：如果你希望用脚本语言对红外设备（手机、PALM、PDA）通信编程，请考虑我的这个扩展。

扩展这部分的代码大部分是修改 Python 的 socket 模块的，所以 License 当然也是 Python 的。

代码 checkout 地址：
http://pymobilesync.googlecode.com/svn/trunk/irdasocket/

预编译好的 Py2.4 for Win32 的包下载：
http://www.dup2.org/files/irda-0.1.win32-py2.4.exe

该 win32 版本是在 Visual C++ Toolkit 2003 + .NET SDK 1.1 + Windows Platform SDK 环境编译。感谢Compiling Python 2.4 extensions with Microsoft VC Toolkit 2003这篇文章教我们如何让 distutils 和这些免费工具一起工作。

下面是测试代码：

从 Oversized/Undersized explanations - Doom9's Forum 翻译而来

XviD 论坛有一个问题被反复提出：压缩后的文件大小和和指定的大不相同。本文试图解释文件大小不一致的原因，并指出解决之道。

让我们从基础知识开始，要知道弄明白问题发生的根源后就离解决它很近了。

基础知识

1. 量化
XviD 属于有损压缩，即它会把一些认为无用的画面细节忽略掉。每一帧画面会指定一个 quantizer (中文翻译为"量化因子")，然后据此进行压缩。
那么：
量化因子为 1("Q1") 意味着最高质量的图象和最大的文件(高码流)
量化因子为 31("Q31") 意味着最低质量的图象和最小的文件(低码流)

我们的目标是尽可能高的质量，以及尽可能低的码流...
=> 通常不用 Q1 做压缩，因为码流太高了(如果要备份 DVD，还不如保留原始的 MPEG-2 流)
Q2 则能得到很好质量的图像，而且比 Q1 来要小很多(quality/bitrate并不是线型的)。MPEG-4 被设计为低码流应用(相比较 MPEG-2 而言)，我们可以假定对于 XviD 压缩来说，Q2 就是最高质量的压缩了。

2. 文件大小
相同的量化因子前提下，不同的视频源压缩后的大小也是不一样的。有的容易压缩，而高分辨率、大量细节、快速动作、明暗变化大的电影则很难压缩。

3. two-pass 压缩(或写成 2-pass)
为了在指定文件大小的情况下得到最大的质量，XviD 提供了 two-pass 处理模式。
- 首先固定量化因子为 2 压缩一遍，产生一组参考数据(stat 文件)
- 根据参考数据进行二次压缩，编码器不断调整码流来优化整体质量

那么就产生了三种情况：
● 1st pass 得到的文件比预料的大，在 2nd pass 压缩中编码器就不得不采取更高的量化因子
● 1st pass 得到的文件比预料的小，那么 2nd pass 中编码器就会在某些帧用 Q1 进行压缩
● 1st pass 得到的文件和预料的一模一样...当然从统计学上来说这是不可能发生的，而且这种情况下我们也不用再继续讨论了

现在问题发生了

有的视频太容易被压缩了(或者说 1st pass 得到的文件比指定的要小很多)，于是过多的 Q1 帧被产生，但这会扰乱编码器的码流控制系统，最后就得到了一个 oversized 结果。

oversize的解决方案

1. overflow treatment 设置的调整
该设置被用于在 2nd pass 压缩中，设定码流控制进行调整的强度。取值越大，越能有效平衡 Q1 帧。
那么我的建议值是：
("Encoding type" > Two-pass - 2nd pass > "more...")
- overflow control strength: try 10 or 20
- Max overflow improvement: try 10 or 20
- Min overflow degradation: try 10 or 20

2. Quantizer capping
很简单，就是避免 XviD 用 Q1 压缩。
把每种帧类型[I/P/B]的最小量化因子都设成 2 (最大值还是保留 31)
1.1.0-final 之前是
("Advanced option" > Quantization)，
从它以后是
("Quality preset" > Userdefined > "more..." > Quantization)
这样就不再会得到一个超大文件了。但...这种方式也导致根本不再有提高质量以得到预期码流的余地了。

除了上述两种编码器相关的解决方案，其实还有更好的思路：我们的目的是填充剩余的空间，那么就可以用更高的分辨率，更高的音频质量，更高质量的定制矩阵...等等

undersize的解决方案
从上面说的去举一反三吧...

如何提前预料到文件大小无法控制呢？
上面已经提到，1st pass 将产生一个日志文件，里面就包括 Q2 压缩结果的大小。那么如果这个数字和你预期的相差非常远，就很可能发生该问题了。

怎么看到 "size" 信息呢？
用 StatReader 打开该日志文件就可以看到了。该程序被包含在 official release 里面(比如 Koepi build)

gnome 2.16 发布、MIPS/IRIX 即将退出舞台。

感觉最近 solidot 的人气下降了很多. 也没有什么心情把这些新闻贴出来了。

其实 100k 确实便宜，但委实没有太好的商业模式，而且团队前段时间的彷徨会让社区成员更加迷茫。即使它有了新主人，想挽回颓势也是相当的困难。

昨晚和老冒在 gtalk 上聊了好多东西，深深感到，管理团队太重要了。