Blog be moved...

博客搬家了.

- EOF -

Updating Linux kernel to 2.6.30 & Lowing CPU Temperature

升级内核后 处理器核心温度大幅度下降

将系统的内核升级到了前几天刚发布的 linux-2.6.30, 也解决了笔记本CPU温度总是比较高的毛病. 这文章主要是用于做备份, 毕竟用了这么长时间的Linux, 这回才是第一次手工编译升级内核. 囧
主要的参考资料:
How to: Linux delete or remove kernel
How to: Compile Linux kernel 2.6
3.3. CPUfreq Governor Types
更为详细全面的资料(不过我没有研究, 实在是太详细了, 应该是写给系统管理员的, 也是写给那些想要对Linux做系统裁剪的同学的):
Linux Kernel Configuration - Linux Kernel in a Nutshell

下面是总结的摘要.
---------------------------------
安装内核

Installation:
#1 Download the source-code from linux-kernel site. linux-2.6.30.tar.bz2
#2 Unzip it to /usr/src/.
   $ tar -xjf linux-2.6.30.tar.bz2 -C /usr/src/
   $ cd /usr/src/linux-2.6.30/
#3 **** Configure the kernel ****
   $ sudo make menuconfig
#4 Make and install.
   $ sudo make -j4
   $ su
   root$ make modules_install
   root$ make install
   root$ cd /boot
   root$ mkinitranfs -o initrd.img-2.6.30 2.6.30
   root$ exit
#5 Update the "grub file" menu.lst.
   $ sudo update-grub
#6 Reboot.
   $ sudo reboot

---------------------------------
在安装过程中, 需要注意配置声卡和电源管理选项.

电源管理

CPU Frequency Scaling:

对于 CPUFreq governor 选项的含义, 可以参考 Redhat 的文档. 简单点说, 就是 cpufreq_performance 注重将CPU的能力发挥到极限, 总是以最高频率运行; cpufreq_powersave 将节能摆在优先位置, 总是以最低可能的频率运行; cpufreq_userspace 允许用户代码自动调节处理器频率; cpufreq_ondemand 允许内核根据当前CPU使用情况自动调节运行频率; cpufreq_conservative 和 cpufreq_ondemand 差不多, 只是调节方式更加趋于保守.
默认的选项是 cpufreq_performance, 对于笔记本而言, 这是绝对错误的选择(当然, 如果处理器不支持动态调频, 那么这个选择也就无可厚非了). 我个人倾向于修改成 cpufreq_conservative, 无奈我的 Intel(R) Core(TM)2 Duo CPU T6400 貌似不支持这个选项, 最后还是以 cpufreq_ondemand 作为动态调频的方式. 对于使用Intel处理器的笔记本, 使用 cpufreq_ondemand 比 cpufreq_conservative 更加合适, 尽管看上去后者更加适合. 具体的原因参考这两条邮件列表中的信息(来自一款Intel开源实验室开发的PowerTop工具):
Ondemand vs. conservative governor
Ondemand vs. conservative governor
另外, 如果你希望拥有休眠 Hibernation 和挂起 Suspend 的功能, 也要注意在配置中加以设置.
这里有一组命令, 是在某个页面上直接摘过来的, 可以用于查看硬件配置, 可以参考一下:

lspci ( lists pci device)
lsusb ( lists usb device)
lsscsi ( lists scsi device)
systool
fdisk -l ( lists hard drive)
dmidecode ( lists hardware model, serial number, cpu, memory. This command was handy when i needed to find serial number without a visit to data center)
cat /proc/cpuinfo ( more on cpu)
cat /proc/meminfo ( more on memory)

一般来讲, 使用 sudo lshw 和 dmidecode 以及 lspci |grep xxx 就足够了.

声卡配置

这一点我开始忽视了, 导致内核编译安装后缺乏相应的声卡驱动模块, 结果配置了半天ALSA, 翻阅了无数BBS和maillist查找bug-report也没有搞定, 过了几个小时才恍然大悟可能是内核编译中缺乏声卡模块. -_-

这里有两个选项, 一般来讲选择第一个, Advanced Linux Sound Architecture, 也就是ALSA, 但是如果ALSA搞不定你的声卡, 你可以选择 Open Sound System, 也就是俗称的OSS, 来碰碰运气.
为了最小化驱动(要知道内核中最占空间的就是这一坨一坨的驱动), 我们要进入ALSA的自选项卡, 选择自己的声卡:

譬如我的就是 Intel HD Audio, 你可以运行 lspci |grep Audio 来得知自己的声卡类型.
---------------------------------
另外, 如果不是这次手工配置内核, 还真是没有感觉到传说中 Linux 强大的网络协议支持能力 囧:

---------------------------------
内核卸载

如果内核编译安装后, 发生了一些bug, 抑或是你感觉没有配置成功, 可以重新再 menuconfig -> compile -> install 一遍, 但是前提是你要先将安装好的内核卸载!
和一般的软件 make uninstall clean 不同, 内核卸载不是这么容易, 需要自己手工删除. 但是总体来讲工作量也很小, 这是由于Linux文件结构中良好的低耦合度所决定的.
需要删除的部分:

# /boot/vmlinuz*KERNEL-VERSION*
# /boot/initrd*KERNEL-VERSION*
# /boot/System-map*KERNEL-VERSION*
# /boot/config-*KERNEL-VERSION*
# /lib/modules/*KERNEL-VERSION*/

如果在 /boot 文件夹中还存在 vmlinuz System-map config 的软链接, 此时有可能会变成死链, 也要一并删除之.
删除完毕后重新 sudo update-grub 更新一下 menu.lst 就ok了.
---------------------------------
升级内核后, 可能是由于手工编译更加贴近硬件的实际状态, 处理器两个核心的温度大幅度降低(你可以通过安装 lm-sensors sensors-applet 检测硬件温度), 和视窗系统下的温度差不多, 都是30-35度之间. 波动大概10度, 可能会到达40-45度左右(对于编译内核这样的密集计算工作, 可能会使得处理器核心达到60-70度).

祝你内核配置之旅愉快.

ps1:
这里提供一个小技巧, 为了加快内核编译过程(从1-2小时压缩到20分钟甚至是10分钟左右), 一方面是要进行充分的配置, 将无用的驱动和模块统统删除, 另一方面可以使用 make -jn 将 make 进行分成n个并行作业, 一般来讲单个处理器核心可以分成2个, 如果是双核处理器, 拥有两个处理器核心, 使用 make -j4 就可以了.
ps2:
如何修改动态调频方式? 参考这份文档: How to make use of Dynamic Frequency Scaling - ThinkWiki

- EOF -

Green Dam become famous due to its STUPID

愚蠢的绿坝

绿坝开发者问到 - 未知长度的字符串还需要做截断处理?

是的, 你没有听错, 这就是绿坝开发者心里所嘀咕的问题, 国家花了4000万购买一年使用权, 要求所有在国内兜售的预装Windows视窗系统的PC所必须安装的「绿坝」!
密歇根大学的三名研究人员(一名研究系统安全的教授和两名研究生), 花了一天时间对绿坝展开逆向工程, 结果就发现了两处高危漏洞. 原始的调查报告在这里.

也许你不敢相信, 两处漏洞都是出于同样的编码错误, 试图用固定字长的字符数组来容纳未知长度的字符串. 相信任何对于计算机体系结构比较清楚, C语言功底扎实的朋友, 都会对这样两个错误嗤之以鼻.
下面简单说一下:
第一个, 由于绿坝读取url地址时所犯下的固定字长错误, 将会导致运行时栈溢出, runtime stack overflow.
此类错误绝对属于高危漏洞. 一般情况下, 普通的url不会产生什么问题, 但是经过精心编排的url字符串就可以利用这个bug轻松重写某段运行时栈, 用malicious data覆盖正常数据, 进而有机会掌握系统控制权.
第二个, 还是老问题. 由于blacklist的读取方式是文件line by line的读取, 而每一行也采用了固定字长的设定, 所以将会导致缓冲区溢出.

面对如此低级的错误和如此浅薄的计算机系统知识, 我们还能说啥? 愚蠢的绿坝. 跟着政府做开发, 你会一天天变得愚蠢, 就好比跟着国内的大部分学校做项目一样. 真是悲哀, sigh...

- EOF -

Green DAM is DAMN useless

绿霸 垃圾中的战斗机

「绿坝 - 花季护航」软件在不到一周的时间内, 占据了各大新闻版面的头条, 成为年轻人茶余饭后随口扯淡的焦点之一, 不能不说是个奇迹. 当然, 在这个神奇的国度, 这是不算啥的, 毕竟它的合作伙伴都是鼎鼎有名的「大户人家」, 工信部, 教育部, 财政部, 国务院新闻办. 这么一桩在我等普通民众眼中如此神奇的事情, 敬仰之余, 也很好奇这玩意儿究竟是何方神圣, 竟然能够让一个国家为其呐喊助威, 大笔一挥掏钱4000万, 而且还仅仅是一年的使用权?

网上的新闻已经足够多了, 但是百闻不如一见, 我昨天也测试了一番.
测试环境是VirtualBox v2.2.4虚拟机, 运行着Windows2000 SP4, 浏览器安装的是IE 6.0 + Firefox 3.0.10, 没有安装办公软件, 也没有安装安全类型的软件. 主要测试对象是针对其图像过滤功能和文字过滤功能, 以及传说中的自动关闭浏览器和字处理程序功能.
测试的「绿坝」版本是家庭版3.17, 在其官方站点下可以找到下载:


最后的测试结果就不罗嗦了, 大致总结一下:

1. 图像过滤.
可以在控制面板中选择是否开启图像过滤, 如果选择开启, 可以继续设置过滤级别.
技术上, 属于传统的肤色和脸部检测的综合识别, 没有什么新意. 只要出现了「大面积的黄色 + 脸型类似的图案布局」, 不论是 IE 6.0 还是 Firefox 3.0.10 都会被直接关闭. 大家可以尝试在 Google 中搜索 yellow, 对各类图像做一番测试.

2. 文字过滤.
这种过滤非常自吹自擂, 从网上一些朋友的测试结果, 譬如校园版软件的「学生玩摸球游戏」, 这款耗资4000万, 被国家大力推行的软件似乎并没有做什么语义分析, 而是直接根据关键字列表进行判断. 莫非是直接KMP匹配关键字, 然后吹嘘自己做了语义分析蒙骗工信部那些善良的老大爷老大妈?
不过, 我这里的测试结果并不理想, 很多传说的关键字都得不到过滤, 这一点比较汗.

3. 安装卸载.
可能很多人关心的是这个部分. 经过测试, 的确是可以被卸载的.
至于卸载是否干净, 不是特别清楚, 但是没有出现网上盛传的那么多流氓行为, 可能是我没有安装安全类软件的原因. 至于如何卸载, 是通过密码打开「设置」选项页面后, 通过「日常管理 - 卸载」来uninstall之.
如果有人再做测试, 可以在 cmd 中提前将 %Windows_Dir% 和 %Windows_Dir%\System32 文件夹中的文件做一个 dir 重定向, 然后安装, 继而卸载, 再做一番重定向, 将两份文件 diff 比较一番.
如果不出意外, 默认的卸载程序应该是可以卸载干净的, 咱们也不能太低估他们了不是. 囧

4. 密码部分.
网上盛传的伪造dll文件是真实的, 这个实际上是文本文件的 kwpwf.dll 文件, 包含了软件密码的md5值, 初始为 D0970714757783E6CF17B26FB8E2298F, 也就是112233的md5, 用户可以轻松将其修改成其他值. 一旦修改, 便可以通过 %Windows_Dir%\System32 下的 gn.exe 打开软件控制界面, 将软件卸载抑或是禁用.

至于目前最权威的分析评测报告, 应该是来自于这份文档了, 其中不仅仅分析了驱动模块和文件构成, 还指出了「绿坝」违背了所采用的 OpenCV 开源图像处理库的BSD协议.
BSD开源协议尽管是商业友好型的协议, 但是绿坝没有作出任何声明就擅自使用, 明显违背BSD协议的条款, 更何况绿坝还将自身申请了专利, 也是不合理的, 正常情况下, 只能够对算法做出专利申请保护, 而不能对整个软件申请专利保护. 当然了, 我们都知道, 绿坝根本就没有用什么新鲜的算法, 不然也不会这么遮遮掩掩.
其次, 我们在被破解后的关键字列表中也可以看到, 大部分关键字都是 Political-Related, 而非 Porn-Related, 国务院新闻办所发表的声明, 真实性还能够有几分?

总之, Green Dam is Damn useless. 国内GFW控制下的超级局域网确实不是一块净土, 可爱的互联网也不是, 但是, 如果真想让我们的孩子和青少年不受垃圾信息的毒害, 就要从教育抓起, 而不是通过一款「绿霸」一样的「绿坝」来强行关闭程序, 这不仅仅是没用的, 而且, 也是很愚蠢的. 甚至可以说, 这种方式连一种「临时应对之策」都称不上.

- EOF -

What a fucking bad luck

上个月的月底, 真的是非常的不走运, 近乎半个月的时间, 就这么在床上躺过去了.
人生最痛苦的事情, 不是人死了钱没花掉, 而是人醒着, 却在床上怎么也睡不着. 幸亏有广播和大量音频的陪伴, 才显得不是那么百无聊赖.
咱们就是比古人要幸福这么一点点, 尽管我们经常要躲猫猫, 而且还要提防那些以120码在闹市区狂飙的人渣.
---------------------------------
顺便还是罗嗦几句吧, 尽管在互联网上发泄牢骚对于整个事态的发展几乎没有任何帮助.

交警同学的「大概是70码车速」, 咱们也就不做太多的评论了, 明眼人一看, 也就知道, 说的文雅点, 就是「值得商榷」, 说的直接点, 就是「放屁还真打了草稿」. 「草稿」一说何来? 起初我不知道, 后来才明白, 在这条限速50码的街道上, 只要不是超速50%以上, 也就是75码以上, 都属于一般级别的超速, 自然, 在法律刑责上, 就会更加宽松. So, 瞧瞧人家这算术做的, 利索干净, 不留痕迹, 估计是小时候算术考试经常拿小红花的主.

那么地下改装车比赛呢, 为何屡禁不止? 有人提到了杭州的街道多弯道, 而且视野开阔, 很适合飙车, 给人以强烈的飙车欲望. 有人提到了杭州的交警们非常守时, 每晚准时下班, 决不延误每晚7点的新闻联播, 好努力学习上级精神加薪升职. 最可怕的是有人提到, 飙车党撞人事件, 其实从去年年底至今, 就已经发生了多起. 这难免让人联想, 如果不是因为此次事件影响太大, 会不会一样不了了之?
当然了, 咱们是了解的, 「不了了之」的代价是水涨船高的, 第一次50w, 第二次就得70w, 不然人家怎么给你定70码呢. 我提议, 街道的限速可以更高一些, 譬如100码, 那么所有飙车肇事司机就需要付出大约150w的代价来摆平此事, 政府的创收也会更加丰富, 更好的招商引资, 拉动内需, 克服全球金融风暴. 期待有政协委员将此提议提交给人代会商议.

前不久在 solidot 上还看到一个消息, 说迈阿密的警察局为了应对地下飙车比赛, 专门设立了「警车改装车比赛」, 25美金便可体验一把. 这算是明令禁止街头飙车比赛, 结果不太奏效的无奈之举了. 那么杭州呢?
咱们不应该低估杭州市政府的智商. 街头智能摄像头, 配合杭州这座无线城市的联网便利性, 追踪某辆车实在是很方便. 之所以屡禁不止, 一方面是因为地方法律对于此类事件的惩罚力度不够, 另一方面是因为地方执法机构执法力度不够.

我们所需要的工作, 不是发放一份文件就ok, 现在的老百姓, 不是愚民. 骗了一次, 就想骗另一次, 撒谎了一次, 就需要再撒一次来自圆其说, 这个环有尽头么? 恐怕智商为70的人都可以得出答案, 更何况这些一下子就可以说出70码, 幼儿园算术课上尽拿小红花的「法律厚黑」高手.

update:
今天看到一则消息, 车祸发生后赶到现场的法拉利车主, 也就是FDS Club, Fast Drifting Sport Club 极速漂移运动俱乐部的董事之一的翁某, 居然是杭州宣传部长的儿子. 难怪这么多蹊跷的事情得以发生.
惨不忍睹. 不仅仅是车祸的血肉横飞, 更是腐败滋生的官场风气. 社会的冷漠让惨剧作为茶余饭后的谈资, 社会的不公让正义无处声张. 围, 追, 堵, 截, 一个国家已经将话语权和知情权封闭的严严实实, 哪怕是百来人的针对当局的游行都会遭到驱逐和遣散. 说不出什么了. 罢了. 为死者默哀.

- EOF -