dpkg-deb常用命令
这个命令主要用于进行deb包的安装和查询等。
build deb包，示例：将/tmp/debian_packages目录下的文件打包成demo.deb文件
dpkg-deb -b /tmp/debian_packages ./demo.deb
查询deb包中的文件内容：
dpkg-deb -c demo.deb
安装deb包
dpkg -i demo.deb
修改MySQL表中字段的缺省值
网上搜了一下，居然有推荐“先删除字段，再重新添加字段”的做法。如果该字段原来有一些非缺省值的记录，岂不是就丢失了吗？ 这真是一点都没有爱啊。
比较有爱的做法是：使用MySQL提供的alter table语句对字段直接进行修改。
例如对tbl_local_users表中的moMaxCalls字段修改缺省值为1，可以采用以下语句：
alter table tbl_local_users alter moMaxCalls int default 1;
如果需要修改字段的类型或者变动位置，则需要用“change column”，例如：
alter table tbl_local_users change moMaxCalls int default 1 after emailAddr;
Chrome为什么会快些？
常见的理由是有一个强大的V8 javascript引擎。而最近在研究Ajax时，无意发现Chrome和IE在处理HTTP基础协议时，实际上也存在很大的差异，这些差异可以导致即使处理HTML/JS文件时，两者的处理速度也会很不一样。
测试时采用Apache 2.2.20（Ubuntu）作HTTP服务器。
在Apache中设置Cache-Control，指定no-cache，我们来看看Chrome和IE会怎么处理。
Chrome发送GET请求，包含If-None-Match以及If-Modified-Since等重要参数。Apache比较对应的ETag以及Last-Modified，发现文件没有改变，因此仅返回”304 Not Modified”。可见，Chrome直接使用了自己Cache的内容，并没有理会no-cache指示。
而IE呢？IE理会了no-cache指示，因此在GET请求中，老老实实地抹掉了If-None-Match以及If-Modified-Since参数，Apache返回200OK并重新携带请求的内容，IE重新处理返回的内容。
从对no-cache参数的字面理解看，IE的处理是正确的，而Chrome显得比较奸诈。
对于某些情况，我们确实需要强制浏览器端重新获取内容（尤其是对javascript文件），此时在Apache中不仅要设置no-cache，还必须设置no-store。
同时设置no-cache和no-store后，IE/Chrome都会向Apache重新请求内容，并刷新本地内容。
Kubuntu/Ubuntu中查看十六进制文件
在windows中我们可以安装HxD来查看十六进制文件的内容，在Linux下，更简单，直接使用hexdump命令即可。
例如，我们想查看sysTbl.dat文件的内容，可以使用以下命令
hexdump sysTbl.dat -C
一款很轻量级的HEX编辑工具
如何使用jQuery获取radio类型的值
在HTML编程中，经常使用radio类型的<input>作为输入选项，例如：
<tr>
<td>System audio</td>
<td><input type="radio" name="annID" id="annID_AA" value="0a080001" checked /> Automatic attendant </td>
</tr>
<tr>
<td></td>
<td><input type="radio" name="annID" id="annID_VM" value="02080004" /> Voice-mail greeting voice</td>
</tr>
我们可以通过id来获取对象，但是这种情况下，需要循环判断属性是否checked。
在上述例子中，radio具有同一个name属性，因此我们可以通过name来获取被checked的radio的值，采用jQuery实现则非常简单：
$("input:checked[name='annID']").val()
在Ubuntu/Kubuntu中以非root用户身份运行wireshark
缺省情况下，只允许以root身份运行wireshark，否则无法抓包，命令如下：
sudo wireshark
每次都这样启动实在是比较麻烦，最好还是允许普通用户也运行wireshark并抓包。为此，需要执行以下命令即可：
sudo dpkg-reconfigure wireshark-common
sudo chmod o+x /usr/bin/dumpcap
RFC4028的不足与SIP keep-alive方法
在SIP族协议中，只有RFC4028明确讨论了对话keep-alive问题。实际上这在工程应用、生产环境部署中，是个非常重要的话题，尤其是SIP基于UDP协议时，网络原因丢包是很常见的，另外还有软终端任意退出对话等情况。缺乏keep-alive保护的SIP服务器毫无疑问将会严重消耗资源，最终导致整个server被迫退出服务。
RFC4028协议考虑到有状态Proxy、无状态Proxy等情况，提出扩展Session-Expires以及Min-SE两个新的Header，并且通过reINVITE消息来keep-alive dialog。基本上，这个协议本身没有太多问题，按照它的思路，的确是可以解决keep-alive的问题，但是在实际部署中，该协议未必可取，有很大的缺陷：
（1）SIP运营商可能会拒绝reINVITE消息。实际上很多SIP运营商会拒绝reINVITE消息，这是出于SIP运营商媒体处理方面的考虑。最初应用reINVITE就是为了修改媒体流，而这毫无疑问会导致SIP运营商媒体服务器重新分配资源等情况出现。RFC4028中只是定义了新增Header和callFlow，不幸的是，却没有区分出这个reINVITE与更改媒体流的reINVITE，因此实际部署时是否有效，我们需要打一个很大的问号。
（2）采用reINVITE流程太过重型了。正如前面所说，keep-alive的reINVITE消息是没有与更改媒体流的reINVITE进行区分，因此可以肯定绝大部分SIP服务器或者终端，在收到这个reINVITE消息时，会启动媒体更改流程。对话内重改媒体毫无疑问是个很重型的流程，一旦对话内本身就可能有媒体类业务，例如Music On Hold等，就很有可能导致冲突。
如果不采用reINVITE消息，在4028协议中也同时建议可以采用UPDATE消息。在UPDATE消息中可以不携带SDP更改媒体。这种方式可能是比较可行，但是未必所有的SIP设备会支持UPDATE消息并用于keep-alive过程。
方案之二应该采用SIP最基础协议RFC3261中定义的OPTIONS消息。理由如下：
（1）该消息定义在RFC3261协议中，这个协议是整个SIP协议族的基础。基本上不可能有SIP设备（包括服务器、Proxy、终端等）会不支持这个消息。
（2）我们注意到，这个消息可以在对话内，也可以在对话外使用。在RFC3261中很明确地定义了：
An OPTIONS request received within a dialog generates a 200 (OK) response
that is identical to one constructed outside a dialog and does not
have any impact on the dialog.
（3）对话内使用OPTIONS，最显著的优点就是“does not have any impact on the dialog”，对现有对话没有任何影响，更不可能去更改媒体。
（4）对端设备如果由于某种原因已经退出，当然就不能产生200OK响应消息，此时可以理所当然地拆除当前对话，从而保护服务器自身资源，达到keep-alive的目的。
对于设备层级的keep-alive，采用OPTIONS没有任何问题。但是对于dialog层级的keep-alive，则会有问题。原因在于：dialog内的OPTIONS消息有可能被对端作为对话外的OPTIONS来处理。也就是说，如果设备是alive的，但是dialog的BYE消息丢失了，无论dialog内还是dialog外，设备对OPTIONS都可能会返回200OK。
Requests that do not change in any way the state of a dialog may be received within a dialog (for example, an OPTIONS request). They are processed as if they had been received outside the dialog.
方案三是采用RFC5626协议，对于UDP-SIP的情况，该协议建议采用STUN keep-alive方式。缺陷在于：定义有些复杂，而且很多SIP设备未必会支持。
呼叫服务器和媒体服务器合一的情况下，当然也可以由媒体服务器检测RTP/RTCP来keep-alive，不过这是另外一个topic了，这种方式可能更合适于SIP终端设备。
一路向北
这个不是周董的歌，而是一段广告词，相当有才：
出发，
无所谓先后，
一路向北;
登顶，
无所谓高低，
一路向北;
探寻，
无所谓昼夜，
一路向北！
kubuntu 11.10初体验
怀着对KDE不可名状的留恋，在得知最新的kubuntu发布后，又忍不住下载下来安装试试。由于没有单独的计算机安装，又不想在虚拟机里体验，因此利用了以前一个旧的移动硬盘进行安装。
从这两三天的体验情况看，kubuntu11.10比以前又有了很不错的进步，以前几个让人烦恼的问题都已经解决了，当然也有新的烦恼产生。
主要进步在于：
（1）界面比以前有优化，感觉比较流畅。在开始菜单中的有个细节改进估计是参考了Mint的实现，即进入多级菜单后，不是在左边用丑陋的箭头回退，而是在上方类似页面导航一样列出菜单的级别，回退非常方便，也很美观。
（2）Network management有很大的进步。以前的NM经常有各种各样诡异的问题，例如VPN无法断开、无线无法登录等等，这些问题都解决了。老实说，以前放弃使用KDE的一个重要原因就是这个NM造成的。现在体验还不错。
（3）默认安装LibreOffice套件而不是让人极度不爽的Koffice。以前的Kubuntu似乎也是采用OpenOffice作为缺省套件，不过其他的KDE发行版本似乎还是保留了Koffice，实在没有必要，除非Koffice能有突破性创新。
当然，新版Kubuntu也有问题：
（1）ibus的问题。这实在是没有想到，因为以前试过的所有kubuntu似乎都没有这个问题。即ibus启动后，能输入中文，但是看不到单词候选小窗口，也无法进行选择，这基本上就不能用！而且将ibus添加到自动启动后，系统启动及其慢，而且启动后，系统运行各项程序都很慢！将ibus删除后，就没有什么问题。最后不得不换上了fcitx（当然，现在发现fcitx输入法也相当不错）。
（2）CPU占用会突然占用100%，时间不长，但是会影响到程序运行，有明显的迟滞感。不知道是什么原因，感觉以前的版本没有这个问题。以前的感觉是一直很慢：-）
总体上感觉似乎可以将kubuntu作为稳定的工作环境继续尝试下去，而且对比之下，ubuntu11.10的Unity实在让人难以适应（而且速度比10.04版本差太远了）。