厨子读兵书兵家看菜谱

New Blog

2011-01-23T12:53:00.002+08:00

http://jtuki.cnblogs.com/

Tcl 多线程初步

2010-08-02T23:45:00.002+08:00

其实对线程和并发这一块了解相当少，基本上不太清楚究竟什么情况下应该使用并发模型、什么情况下不该采取此类模型。昨天在豆瓣看到一本书，《JAVA并发编程实践》。评价挺高，准备在淘宝入手盗版版本（不是俺想要支持盗版猖獗，只是卓越当当都没货啊。好吧，这其实不是借口…… 囧）。

这里简单的对 Tcl 语言的线程做一下阐述。算是备忘。后续对并发这一块，如果有机会深入了解的话，再补充更新吧。

Tcl 的线程模型主要内容（基于 ActiveTcl 8.5 中包含的 Thread 2.6.5 版本），仅说一下自己觉得印象比较深刻的几点：

线程的创建、保存、释放等操作。

thread::create ?-joinable? ?-preserved? ?tcl_script?
其中开启的 -joinable 参数，可以保证其他的线程来「join」这个线程，从而使得只有当这个线程结束时，join 它的另外一个线程才能够结束。
thread::wait
只有通过这条命令创建的线程，才会被启用引用计数机制，才能够执行正常的 thread::preserve 和 thread::release 操作。所有此命令之后的命令，会在线程被释放之后执行（貌似有点类似于析构函数的角色）。

任何时候，Tcl 如果是以开启线程的方式编译的，那么载入 Thread 包之后，便存在一个主线程。要确保这个「主线程」是最后被中止的。即，这个主线程退出时，不能够存在其他活动的、没有被释放的线程。这一点可以通过上述的 -joinable 参数来保证。具体参见这里。

线程间发送命令。

thread::send ?-async? $tcl_script
同步和异步的方式。前者阻塞（不再服务自身的 event loop），后者立即返回。

错误处理。
分成若干情况：创建线程、异步发送命令时出错，不写全局错误代码和错误信息，仅仅将错误信息反馈在标准输出上；同步发送命令时出错，错误信息和错误代码将反射到 sender 线程中。置位某个线程的 -unwindonerror 参数后，一旦其执行某命令（其他线程发送给他的命令）出错，此线程即中止。
线程共享变量。
每个线程其实都包含一个独立的 Tcl 解释器。然而通过 tsv::set array_name element_name "element_value" 命令创建的共享变量，却可以在各个线程间共享，且不需要考虑线程间写数据的锁机制，这个命令本身就是 atomic 的。在获取的时候之需要使用 tsv::get array_name element_name 就可以了。

互斥量。条件变量。

# thread::mutex
# thread::mutex create
# thread::mutex destroy $mutex
# thread::mutex lock $mutex
# thread::mutex unlock $mutex
# thread::cond
# thread::cond create
# thread::cond destroy $cond
# thread::cond notify $cond
# thread::cond wait $cond $mutex

具体的使用可以参考《Practical Programming in Tcl and Tk》第21章，或者这个链接。前者讲解的挺细致的。

线程池。
目前我对这个只有一点概念，勉强大致知道怎么回事。就不多说了。具体可以参考这个链接。
有一点印象深刻：当一个线程给某个线程池 post 命令之后，这条命令本身是 block 的，然而其本身依然是可以服务 event loop 的（并非彻底阻塞了）。
重复一下，相当于提醒自己。任何命令都需要注意区分，其是否存在阻塞和非阻塞的情况。阻塞情况下，又要注意区分，此命令执行后，该线程是否还能够服务于自身的 event loop 等等。

最后贴一段代码，写的比较乱，不过基本体现了上述的很多方面（包括线程、线程间共享变量、线程池等等），也体现了当前我对线程这一块的不熟悉。 >_<执行结果如下：

Commands: thread_2 --> thread_1.
Commands: thread_1 --> tpool.
Blocked, still with event loop service.
Commands: thread_2 --> thread_1.
Commands: thread_2 --> thread_1.
Commands: thread_2 --> thread_1.
Commands: thread_2 --> thread_1.
Commands: thread_2 --> thread_1.
tpool job 1 finish.
Commands: thread_2 --> thread_1.
Commands: thread_2 --> thread_1.
Commands: thread_2 --> thread_1.
Commands: thread_2 --> thread_1.
main thread: finished.
thread_2: finished.

使用SyntaxHighlighter高亮代码

2010-08-01T17:32:00.013+08:00

有时候，需要在博客中插入代码片段，一般而言，需求很明确：

能够针对某一段代码进行语法高亮。
能够针对某几行代码做「行高亮」处理。
使用过程中，不需要重复考虑格式化问题。
支持语言尽可能广泛，目前而言，我需要能够支持 C、Tcl、Python 三种语言。考虑到后续需求，最好也支持 Java、Ruby、Lua 等一票语言。

最后选择了 SyntaxHighlighter（下文简称做 SH）。SH 当前是 v3.0.83 版本，本身不提供 Tcl 语言的支持，我照着官方教程自己写了一份（下载试用）。
考虑到 Tcl 本身是基于字符串的语言（这种机制用多了觉得真是很强大），对于关键字的使用限定很少，譬如你可以写出类似如下的 Tcl 代码：上述代码的第一行、以及第三行中，三个单词分别是「关键字」、「变量名称」、「变量值」。而使用上述的高亮脚本，则不会对此处的命令做语法分析，而将会简单的、将这三个单词全都高亮。而至于这里所定义的 if 函数，直接把 if 给重载了……
不过考虑到 Tcl 语言本身束缚就少，至于可维护性和可读性，更是和使用人员的编程素质密切相关，所以这里也就不纠结了。

更多关于 SyntaxHighlighter 的信息：

更多配置方式。
SH 3.0 版本所引入的自动加载相应脚本机制。

- EOF -

Coming back

2010-05-16T22:33:00.029+08:00

回到这个博客了

绕了一整圈, 最后还是回来了.
继续用博客记录自己的生活, 工作, 和学习经历.

- EOF -

Blog be moved...

2009-07-01T21:48:00.002+08:00

博客搬家了.
doubanclaimeda46969f2e0a2a3

- EOF -

Updating Linux kernel to 2.6.30 & Lowing CPU Temperature

2009-06-12T15:39:00.016+08:00

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

将系统的内核升级到了前几天刚发布的 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, 对于笔记本而言, 这是绝对错误的选择(当然, 如果处理器不支持动态调频, 那么这个选择也就无可厚非了). 对于使用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

2009-06-12T15:17:00.006+08:00

愚蠢的绿坝

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

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

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

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

- EOF -

Green DAM is DAMN useless

2009-06-11T12:02:00.009+08:00

绿霸垃圾中的战斗机

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

2009-05-11T18:20:00.011+08:00

上个月的月底, 真的是非常的不走运, 近乎半个月的时间, 就这么在床上躺过去了.
人生最痛苦的事情, 不是人死了钱没花掉, 而是人醒着, 却在床上怎么也睡不着. 幸亏有广播和大量音频的陪伴, 才显得不是那么百无聊赖.
咱们就是比古人要幸福这么一点点, 尽管我们经常要躲猫猫, 而且还要提防那些以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 -

Learning Qt or Gtk+, The Good-Practice of Framework

2009-04-25T23:52:00.020+08:00

大型框架实践

去年暑假看了一把传说中的 SICP, Structure and Interpretation of Computer Programs, 一开始看得比较艰难, 对于 Scheme 函数式编程的思维模式, 也感觉不太容易接受. 但是渐渐的, 就逐步进入了状态, 越看越兴奋, 几乎将整本书都阅读了一遍. 可惜的是, 现在大脑里残留的, 貌似已经所剩无几了. -_-
究其原因, 还是构建大型程序的实践过于缺乏, 加之整本书看的太快, 很多东西没有真正的固化到大脑里, 所以这样的空中楼阁自然容易倾覆.

今天看到一段话, Beijing OpenParty 聚会上, 孟岩总结了云风等若干老大成为牛人的契机之所在, 几乎都有一个共同点, 就是在某个阶段, 做了一件非常有意义的事情 --- 阅读了高质量的架构性质的源码. 如果我没有记错, 似乎曾经看到云风的个人主页上有他大三的时候翻译的 Allegro, 一款游戏程序库, 的源代码分析. 豆瓣的技术总监flyconder也将大二期间反汇编「街头霸王2」的源码并还原成C代码看成是令其「茅塞顿开」之事. 还有那位先是做流氓插件3721转而做反流氓软件360安全卫士的周鸿㭏董事长, 据说也是从大学期间反汇编 DOS 起家, 工作后赶上互联网浪潮, 又与众不同的研究底层协议, 最终能够生产出流氓插件3721 囧. 当然周鸿㭏这事情并不值得称道, 但是作为个人技术发展历程, 其还是有可借鉴之处的.

这一次做毕设, 选择做 μC/OS-II 的调度改进就算是一次靠近了, 尽管说实话还离核心部分还很远, 而且个人习惯上还是有N多毛病, 譬如拖拉譬如晚睡晚起等等. 路漫漫啊.
前不久提到的项目问题直接就搁浅了, 老师和公司里的人前期沟通不够, 原本以为去做 CAN 控制局域网络的开发, 没想到他们是要找一个在 Windows 上做 MFC 的人, 真是汗啊, 囧, 这需求差别太大了, 何况 MFC 我只是在大二的 cpp 课堂上被迫接触了一些皮毛, 着实不喜欢 MFC 的开发风格.
不过尽管项目搁浅了, 回来后也查阅了一些做界面的框架, 啥 wxWidget Qt Gtk+ Tcl/Tk, 貌似都是可拓展性很强的框架, 而且开发语言的绑定, bindings of programming languages, 也很丰富. 但是个人感觉 Qt 和 Gtk+ 可能更加值得研究一些. 如果稍微做对比, 这条邮件列表里的回复挺到位的, 有些东西可能已经改变, 但是总体上来看, 貌似还是蛮值得一看的.

我在这里也粗浅的列举一下其主要的差异点 ---

#1 Qt是非纯粹的cpp, 这一点从其编译的时候使用的是qmake而非make也可以看出. 从一个QObject 出发定义了其他的类结构, 彼此之间可以直接进行 inter-object communication.
Gtk+是用C语言写就的. 不过也是采用了面向对象的思想. 但是个人感觉似乎框架上没有Qt那么豪迈和气魄, 而是更加符合linux所提倡的简约.
据称大型程序的代码量Qt要少于Gtk+而且结构会更加清晰. 这可能和前者是专业公司维护有关, 更何况Qt已经被诺基亚收购, 发展前景貌似也更好.

#2 Gtk+和Qt都不仅仅是图形界面编程的框架, 其内涵其实非常丰富, 所以不管哪一个都比较适合作为学习的素材. 但是据称Qt的API更加稳定, 这一点从Qt对于object的命名, 以及其无比规范的文档也可以窥见端倪(不过只是网上找到的传言罢了, 真实性不保证).

#3 Qt的可移植性比Gtk+要好, 但是从Gtk+构建的Maemo来看, 未来Gtk+可能也会迎头赶上吧. 但是无论如何, Qt现在绝对走在前面.

#4 文档方面, Qt做的太到位了. http://doc.trolltech.com/4.0/index.html
我下载了一个Windows版本的Qt SDK套装, 其中的Creator和Demo+Documentation的完整展示真是让人怦然心动. 囧

#5 如果想要使用Qt做闭源的商业软件, 那么需要交纳一定的版权费, 但是似乎并不是很贵. 如果你选择将软件按照GPL开源, 就毋需交纳版权费. 使用Gtk+就可以「真正的」免费使用.

还是先接触 Qt 再接触 Gtk+ 吧, 尽管我着实不愿意走cpp路线, 但是既然主要是关注架构层面, 也就不要顾虑语言方面的问题了. 出来混, 迟早都是要尝到的.

- EOF -

What happened on April 24th?

2009-04-25T17:41:00.011+08:00

历史上的昨天?

下面是我收集整理的几条 ---

1704年4月24日, 第一份人类历史上公认的长期出版的报纸, Boston News-Letter, 得到出版.

1915年4月24日, 亚美尼亚种族大灭绝的标志性开端. 这一天, 奥斯曼帝国在君士坦丁堡逮捕了200多名亚美尼亚学者和社团领袖. 至此之后, 无论性别年龄, 亚美尼亚种族遭受到了毁灭性的驱逐, 肉体上和精神上的摧残. 历史上的种族屠杀不止这么一次, 而这些可怕的历史离我们甚至还不到1个世纪.

1953年4月24日, 79岁的丘吉尔被伊丽莎白二世封为爵士.

1970年4月24日, 中国第一颗人造卫星, 东方红一号, 升空. 这个事件标志着中国航天事业的开端.

20年后, 1990年4月24日, 美国 Space Shuttle Program 第35次任务被执行, 哈勃望远镜, 发射升空. 标志着人类探索深空宇宙的另一个里程碑.

同时, 21年前的昨天, 上午10点50分, 我老妈把我给生了出来, 并从此之后一直埋怨了21年, 不该生这么一个让她又头疼又不放心的孩子. 回想这么些年, 确实让老妈老爸操心了太多, 该承担起来的东西没有努力承担, 该把握的事情没有认真把握.
在这个人生的关键坎儿上, 该改变了.

- EOF -

What is the User Convinence of OS?

2009-04-23T13:08:00.029+08:00

操作系统之用户易用性

标题太大, 容易被人扣下 zhuangbility 和标题党的帽子. 所以, 首先指出, 本文是有感而发, 随笔牢骚一篇. 主要是拿两大主流桌面操作系统 Windows 和 Linux 来说事儿. 我姑妄言之, 您姑妄看之, 有不同意见尽可留言就ok了.

案例1
关于字体的安装, 准确的说是「徐静蕾字体」的安装. 一开始是在 Ubuntu linux 系统下, 使用如下的命令进行安装:

jtuki~$ cp ./xjlFont.fon ~/.fonts/
jtuki~$ sudo fc-cache -fv

安装完成后, 在字体列表中找到 FZJingLeiS-R-GB 就可以使用了. 那么对于 Windows XP SP3 系统呢? 直接打开「控制面板」, 选择「经典视图」, 打开「字体」文件夹, 将 xjlFont.fon 拷贝进入, 就可以看到系统弹出的提示, 「字体安装完成」.
哪种更方便? 也就是所谓的「用户易用性」更高? 在得到最终结果前, 还是先分析一下.
为何要安装字体? 为了享受美观的字体带来的视觉舒适感.
是什么人想要安装这个字体? 也就是用户群体是哪些? 我可以很不负责任的说, 什么人都有. -_- 但是, 主要还是那些想要尝鲜的互联网重度无聊人士, 抑或是美工人员, 抑或是对视觉体验要求很高的完美主义者. 尽管用户群体覆盖面很广, 但是其共同点是一个, 就是希望最短的时间配置好这款新字体, 然后开始体验之. 这几乎是毋庸置疑的事情.
如果上面这一点达成了共识, 那么很明显, 完成这件事情的时间长短, 姑且可以称作时间成本, 就成了判断「用户易用性」高低的唯一标准, 而不论你究竟是用鼠标还是用键盘用大脑还是用臀部. 就好比「实践是检验真理的不二标准」一样.
时间成本如何进行确定性的计算? 我可以再次不负责任的说, 没有确定性计算的法则, 只有类似「薛定谔的猫」一样的概率模型可供参考. 一个熟悉字体安装的 Linux 用户, 不会对上述的 fc-cache 过程产生任何繁琐的感觉. 相反, 一个 Linux 新手可能就会直接抱怨, 「天, 这是多么复杂的系统. 安装一个字体都这么繁琐」. 同样, 一个不熟悉 Windows 系统的家伙, 可能找到字体所在的文件夹都需要花上很长的时间. 换句话说, 时间成本是因人而异的东西, 唯一能够做的, 就是依靠统计分析和扯淡一般的「感性归纳」, 也就是不完全归纳. 我敢打赌, 按照我这样的逻辑推演计算下去, 最终的结果一定是, Windows 太人性化了, 用户易用性非常好; Linux 太不人性化了, 简直称不上一款实用的「桌面操作系统」.

案例2
关于播放器, 准确的说, 是影音播放器.
Windows 系统上的影音播放器太多了, 什么千千静听, 酷狗本地音乐播放器, 超级解霸, 暴风影音, 影音风暴, xxplayer, yyplayer, 一大堆, 可谓是数不胜数. 而 Linux 呢? 乍一看, 真是太可怜了. 一般的 linux 标配系统, 一概不支持mp3音频格式, 你好不容易安装完了系统, 想要放一首美妙动听的歌曲来舒缓一下你紧张的神经, 结果却收到一条类似这样的系统提示, Invalid codec. Do you want to download the encoder right now? 选项自然是两个, -yes -no. 你点击 -yes, 结果收到类似这样的提示, We are so sorry to tell you that this codec format still can not be recognized. 你立刻就绝望崩溃了, 恨不得泪奔到大街上去抱着电线杆大喊「这老中医真是太有疗效了」.
先跑个题. 实际上, 这个问题反映的一个侧面, 就是很多人在遇到问题后, 并不是寻求解决问题的办法, 而是直接放弃掉, 或者是跑到论坛上去抱怨. 具体到这个问题, 如果稍加搜索, 就能够发现, mp3本身就不是一个版权开放的音频编码, 所以一般的 Linux 系统并不包含默认的对mp3的解码. 这种「默认不包含」的方式, 一下子就将很多小白击溃了. 殊不知 mplayer 已经足以应付几乎所有的影音格式, 安装之就万事大吉了. 如果你习惯使用用户交互界面, 还可以附加安装 smplayer, 界面风格和暴风影音很类似, 唯一的区别, 应该也算是一个大区别了, 就是没有广告和隐藏的x插件y插件z插件xyz插件.
回归正题. 哪种用户易用性更好? 肯定90%的人都会毫不犹豫的说, 当然是 Windows 系统嘛, 哪有操作系统连播放一首歌都需要费尽周折?

案例3
大学教室里传授程序设计课程的老师.
先要很不负责任的声明, 这里并不是针对某个具体的大学, 而是针对当前国内的一票大学.
这一类老师通常会选择不同的语言作为第一门 programming language 课程的「教学语言」, 有人选择 C 语言, 有人选择 java, 甚至或许有人会选择四不像, Cpp. 估计没有谁会选择 python 或者是 scheme 吧. 不过, 总的来说, 其开场白一般是这样的 ---

请同学们打开开始菜单, 对, 就是那个番茄花园, 然后打开xx集成编程环境, 输入如下yy程序, 点击上面的那个很象zz图样的图标, 再点击那个很象aa图样的图标, 最后点击bb图标, 好了, 各位同学, 你们看到弹出的那个写着 Hello, OS_WINDOWS! 的黑框了么?

接下来的事情估计也不用我罗嗦了吧.
在这么一个环境里, 哪款操作系统用户易用性更高? 当然还是 Windows.
---------------------------------
这三个案例都堪称典型.

第一个, 我一开始写的很严肃, 后来发现压根没法严肃, 所以放弃了严肃的念头. 这个案例真正是关于用户易用性的问题. 所谓易用性, 在我看来, 就是, 能够不让用户做的, 就尽量由系统自动完成. 试着想一想, 为何 Windows 能够直接安装字体? 技术上来讲, 可以称之为是一个 hook function, 钩子函数. 拷贝字体到默认的字体文件夹的行为, 触发了一个 hook function, 这个 hook function 又使得相应的安装字体的函数被激发, 从而安装 xjlFont.fon 这个字体文件. 那么为何 Linux 不这么做? 我想来想去, 貌似就想到了一条理由 --- 由于 Linux 系统的设计者们压根就没考虑过. -_-
尽管没有所谓的「默认字体文件夹」, 也就是说 /usr/share/fonts/truetype 可以作为字体文件夹, ~/.fonts 也可以, 甚至 /etc/xyz/abc 这种看上去和字体毫无关系的文件夹也可以. 但是这并不妨碍字体的简易安装. 所以在这一点上, Windows 确实考虑更加周到.
第二个案例呢? 没办法, 版权原因. 当然如果你运行的是红旗, 那么一开始就可以播放mp3, 毕竟这是一个在盗版 Windows 大行其道的国度里产生的 Linux 发行版, 版权问题自然不放在眼里囧.
第三个案例呢? 大学里的大环境所致. 环顾四周, 有谁整天正儿八经的用 Linux 来学习? 连实验室里都是盗版, 教授还成天鼓捣注册机和QQ麻将呢.
---------------------------------
唉, 此文写的有点像是发牢骚了.

之所以写这么一篇文章, 主要是因为昨天查询「徐静蕾字体」的截图, 想看看其在 Linux 上是否渲染的不错, 谁知道又在bbs上看到大家伙关于操作系统的争论... 其实我对这件事情的态度很简单 --- 喜欢用啥就用啥, 但是拜托您别对着啥东西说三道四打口水战.

正所谓没有调查就没有发言权. 口水战往往要么是混战, 要么是一方清醒一方糊涂, 很难见到两方都真正清醒能够良好交流的. 诸如下面的言论, 您今后都得悠着点说 ---

#1 使用 linux 的人, 就是为了装逼! 因为只要 linux 能干啥, windows 就能干啥!
#2 linux 太烂了, 这点功能都完成不了.
#3 vim 简直就是装逼的工具, 老子就要使用集成开发环境!
#4 windows 简直就是垃圾, linux 才是王道.

@1: Ture. 对于家用PC而言, 可以说差不多都是运行在 IA32 架构上. 至少你可以抛开OS层面从asm角度出发, 完成最后的功能. 所以, 这句话是正确的. 但是, 请在讲这句话前, 思考一下做事情的效率问题.
不妨试着想一想这个情景(当然, 这只是随手举一个例子) --- 从100k个1M的文本文档中查找包含有foo-bar和foo-hello-bar以及foo-_-bar的文档, 然后将所有这些文档中的这些词汇统统替换成foo-jtuki-bar. 过了几天, 需求发生了变化, 需要在这100k个1M的文档中查找所有的r字母, 将其替换成a字母.

@2: 把你发牢骚的时间, 用来google一番, 或许就可以找到solution. 如果中文关键字找不到, 就使用英文关键字.

@3: 您果然是「老子」么? 那我就代表「孔子」来告诉你 --- 首先第一, vim和IDE其实并没什么太大的冲突关系, 不要将两者混为一谈. 第二, 没谁不让您用IDE, 您爱用不用, 没谁管您. 但是, 在您说vim是装逼工具时, 先好歹安装一个gvim尝试一把再说. 记住哦, 不要刚玩了一个jkhl就跑过来嚷嚷:「天啊, vim居然只有上下左右的移动功能?」实在不行, 就安装一个 firefox 的插件 vimperator 体验体验. 可以参考我写的教程, http://jtuki.blogspot.com/2009/02/vimperator.html.

@4: windows不是垃圾, 有些应用还真是只能用windows, 譬如ppstream譬如招商银行专业版譬如某些的的确确无法被替换掉的专业软件.

罗嗦了.. 就此打住吧..
简单说来 --- 操作系统的「用户易用性」往往都是体现在小细节上, 譬如重命名的细节, 字体安装的细节等等; 其他类型的操作系统的「用户易用性」问题, 在我看来都是很扯淡的事情.

- EOF -

Protocols and Platforms

2009-04-19T13:38:00.014+08:00

感觉现在越来越对平台和协议感兴趣, TCP/IP 或许就是一个不错的起点.
备份文:
rabbit 站点上的 reference book: Learning TCP/IP in embedded systems, 直接进入介绍页面观摩.
一个小巧的开源 TCP/IP 协议栈实现, Main Page - uIP, 能够在非常有限的资源上运行. 其历史是从乐高头脑风暴, Lego Mindstorm, 开始的. 是不是有点囧呢.

μC/OS-II 研究系列 - 004

2009-04-17T18:14:00.030+08:00

事件控制块 & 任务间同步

在上篇中, 我出尔反尔了一回, 没有按照上上篇的「预告篇」来写这个系列. 在这篇里, 咱们继续出尔反尔. 囧
下周五要和一个老师去某公司谈一个项目的具体事宜, 所以接下来一段时间里, 除了毕业设计, 就是那个项目了, 争取两个月时间, 也就是这个月, 和下个月搞定之.
~~不知道这个「研究系列」还有没有时间来写.~~
至于这个「研究系列」的命运, 参考文章末尾.

ok, 步入正题.
对于一个操作系统而言, 任务和任务, 以及任务和中断服务子程序之间, 同步和通信是必不可少的.
既然需要同步和通信, 那么彼此之间发送的信号, signal, 就是其媒介了. 在 μC/OS-II 中, 信号被看作是事件, event, 而用于描述和表征「事件」的, 是被称为事件控制块的结构体, 简称做 ECB, 也就是 Event Control Block, 下文对「事件控制块」和 ECB 不加区分, 混合使用.
---------------------------------
三种同步方式
#1
信号量 Semaphore:
譬如, 对某资源A实施信号量保护, 也就是, 只有获得信号量的任务, 才能够访问资源A.
如果该资源允许 N 个任务同时访问, 那么信号量定义成 N 就ok了.
每被一个任务捕获, 信号量减一. 当信号量为0时, 所有试图访问A的任务都会被返回一个出错代码, 抑或是 suspend, 开始等待另外的任务释放信号量.
#2
互斥量 Mutex: 也就是 mutual exclusion.
如果打个比方, 就是「一山不容二虎」, 你可以先将其简单的理解成 semaphore = 1; 时的情况.
不过, 在 μC/OS-II 中, 千万不能这么简单理解, 否则代码就 100% 功能紊乱了. 下文中将加以详细的描述.
#3
事件标志组 Event Flag Group: 还是举例吧, 语言表达没有直接写代码迅速.
下文中将贯穿这个思想, 毕竟有时候, 读代码确实比看文字更容易理解整体的架构, especially when the author himself become impatient of writing the tedious article. -_-

首先指出, 下面的代码可不是能够直接用于 μC/OS-II 的代码, 是我为了方便描述而临时写的一段.

typedef unsigned long os_event_flag_grp;
/* 事件标志组中的某bit置1时, 表示某事件发生 */
#define FLAG_TYPE_SET 1
#define FLAG_TYPE_CLR 0

os_event_flag_grp flag_grp;
if (something_a)
flag_grp |= 0x0001;
if (something_b)
flag_grp |= 0x8000;
if (something_c && something_d && something_e)
flag_grp |= 0x0400;

明白了么? 譬如当 something_b 发生时, 标志组的第15个bit就会置一. 至于内核中具体的实现方式, 下文中将加以描述.
---------------------------------
事件控制块
这算是内核中最为重要的结构体之一了. 其重要程度, 丝毫不逊色于前面提到的「任务控制块」, task control block.
为了贯彻上文中提到的「写代码, 读代码, 少打字」的主张, 咳咳, 大家伙直接看源码吧:

#if (OS_EVENT_EN > 0) && (OS_MAX_EVENTS > 0)
typedef struct {
INT8U    OSEventType;                    /* Type of event control block (see OS_EVENT_TYPE_???)     */
INT8U    OSEventGrp;                     /* Group corresponding to tasks waiting for event to occur */
INT16U   OSEventCnt;                     /* Semaphore Count (not used if other EVENT type)          */
void    *OSEventPtr;                     /* Pointer to message or queue structure                   */
INT8U    OSEventTbl[OS_EVENT_TBL_SIZE];  /* List of tasks waiting for event to occur                */
} OS_EVENT;
#endif

这里要特别指出的是, 在v2.52的后续版本中, 此结构体还多出了一个 OSEventName[], 顾名思义, 也就是用来存储 ECB 的名字了.
#1
OSEventType 是事件类型, 也就是譬如 semaphore, mutex, message box, message queue 等等.
譬如, 信号量 sem 和互斥量 mutex 都是使用 ECB 来描述. 因此, 在调用相应的系统函数前, 就要先检查, 被处理的 ECB 究竟是被 sem 调用了, 还是被 mutex 调用了.
#2
OSEventGrp & OSEventTbl[] 用来存放正在等待此 event 的 tasks 的信息. 其原理和系统的任务就绪表一模一样.
#3
OSEventCnt 是一个16位的整型.
当事件是信号量时, 其用于表示信号量的数值.
当事件是互斥量时, 高8位用于存放 PIP, Priority Inheritance Priority, 低8位用于存放当前占用此 mutex 的任务的优先级.
#4
void *OSEventPtr 元素. 可以这么说, 在消息队列和消息邮箱中, 这个指针才会被真正用到, 所以这里就先不提了.
在「空余ECB列表」中, 用于指向下一个空余的ECB. 在信号量和互斥量中, 指向 NULL 指针, 也就是不被使用.
#5
事件控制块的数量是有限的.
这个最大数值由 os_cfg.h 中的 #define OS_MAX_EVENTS ? 指定.
系统中有一个所谓「空余ECB列表」, 由一个指针变量, *OSEventFreeList, 指向一串没有被使用的ECB, 形成一个单向链表. ok, 你或许已经联想到了, 和前面一篇文章的 *OSMemFreeList 一样的道理.
如果需要创建一个 sem 抑或是 mutex, 那么必须先从这个单向链表中分配到一个空余ECB.
#6
如何操控某个ECB? 也就是:
如何初始化ECB? 如何将某个任务添加到某个事件的 waiting list 中? 如何在事件发生时, 确定该由 waiting list 中的哪个任务捕获该事件? 如果任务等待了太长的时间, 超过了其「忍耐的极限」, 也就是 time out 的时候, 作何处理?
带着这些疑问, 请您分别阅读源代码中这几个函数:

OS_EventWaitListInit();
OS_EventTaskWait();
OS_EventTaskRdy();
OS_EventTO();

** 注意: 这几个函数都是 kernel 的内部函数, 供其他系统函数调用.
用户空间的代码严禁直接调用. 也就是说, 您可以和我一样, 出于对内核大换血的态度来研究之, 但是, 别在用户空间的 task 中直接使用之.
---------------------------------

---------------------------------
....
---------------------------------

彻底懒得写了. 太多了. 这个东西不是线性的描述, 而是图状的描述, 所以写起来感觉格外艰难. 如果只是写「API使用指南」倒是轻松多了, 毕竟外围的 API 都做了很好的粒度和范畴切分, 可以按照 linear 的顺序一步步介绍.
而且, 感觉这个 serial 貌似已经超越了起初 study-note 的初衷, 成为「内核剖析指南」了.
ok, 罢笔. -_-

下面将我没有写完的内容在这里列出来:

任务间同步: 信号量 Semaphore; 互斥量 Mutex; 事件标志组 Event Flag Group.
任务间通信: 消息邮箱 Message box; 消息队列 Message Queue.
基础结构: 任务管理 Task management; 时间管理 Time management.
其他: 就绪表, 任务调度; 任务切换, 中断里的切换; 时钟节拍; 系统初始化 & 启动.

然后大致说一下:
#1
信号量和互斥量一定要弄清楚. 特别是互斥量的 PIP 机制, 由于内核缺乏「优先级继承」的机制, 容易出现优先级反转的问题, 所以在互斥量中人为引入 PIP, 能够在一定程度上破解优先级反转.
#2
事件标志组也很重要, 而且范围广泛, 运用很灵活. 某一组事件发生后, 所有关联的 task 全部被激活. 这一点和信号量以及互斥量不同, 这也决定了其使用的场合也不同.
在使用时, 尤其要记得 wait_type | OS_FLAG_CONSUME 的组合等待模式设置.
#3
消息邮箱和消息队列非常重要, 是任务间通信的重要方式. 至于所谓「消息」, message, 本质上也就是一个 pointer 了, pointer 用于指向若干任务间通信的某个信息片.
#4
任务管理, 没得说, 创建任务删除任务挂起恢复任务都得靠它. 时间管理, 更加不用说了, 在时序系统中, 其重要性应该算是路人皆知了. 这两部分都是最基础的构件, 需要重点掌握.
#5
就绪表, 任务调度. 其实这部分的实现挺容易的. 就是讲述起来需要图文结合才行, 大家伙如果有兴趣, 就自己看看源代码, 看看我先前提到的 MicroC/OS II: The Real Time Kernel 吧.
#6
任务切换, 中断里的切换. 这两者是不同的.
具体的实现和硬件联系紧密, 移植时需要用汇编编写之.
不过我只是知道原理, 暂时还没来得及具体研究针对某个处理器的移植范例. 囧
针对处理器的移植范例可以在官方站点上下载.
#7
时钟节拍. 依靠硬件的定时装置, 定时运行 OSTimeTick(), TCB 中的 OSTCBDly 就依靠这个来定时自动减一, 一旦到0, 便进入就绪态等待调度.
#8
系统初始化 & 启动. 算是一个小综合部分了. 同用户空间 task 编写联系也很紧密.

ok, 到此为止吧. 我终于体会到那些英文原版的作者为何都要在 preface 中加上一句: 感谢我的家人没有对我日复一日的敲击键盘和不理不睬感到愤怒.
我在这里也写上一句, 算是后记吧, 哈哈哈哈. 囧

I hope you, the kind reader, will not find this serial be wordy or even tedious, though myself think it somewhat really is.
I will be very happy and proud if you step into the world of μC/OS-II & RTOS with this serial of articles.
Enjoy your adventure. You brave hacker. ;)

- End of Serial -

μC/OS-II 研究系列 - 003

2009-04-12T23:01:00.014+08:00

内存管理

在上篇中提到了「下篇预告」和「下下篇预告」, 这两部分尽管都已经研究过了, 但是似乎讲述顺序上不太合理. 所以这里要出尔反尔, 打乱一下讲述顺序了. 囧
内存管理是一个很重要的部分.
---------------------------------
为何需要内存管理
这似乎是一个很废话的问题, 但是对于我等没有接触过「操作系统」课程的, 曾经比较颓废的青年来说, 还是很必要的. 后悔莫及已经逝去的岁月, 罢了罢了, 已经过去的事情就不要谈了.
譬如, 你的用户程序需要 nmem_blk * blk_size 大小的内存块, 那么你可以使用 malloc(nmem_blk * blk_size) 来获取之. 但是这样有几个缺点: 这个函数的执行时间并不确定, 对于实时系统而言, 这不是一个好兆头; 经常的 Type *p = (Type *)malloc(N); free(p); 会导致大量的「内存碎片」产生.
说实话, 「内存碎片」这个术语我今天是第一次听说, 真的是很汗颜. 决定开始仔细研究OS相关课程, 包括「深入理解计算机系统」这样的书籍.
为了避免这样的情况, μC/OS-II 引入了自己的内存管理算法. 其执行时间是常数, 而且有效避免了内存碎片中的所谓「外部碎片」, external fragments, 也就是最让嵌入式开发头疼的内存碎片类型了.
---------------------------------
内存管理函数接口
如果不需要动态分配内存, 可以将其关闭, #define OS_MEM_EN 0, 反之开启, #define OS_MEM_EN 1.
接口函数:

/***********************
创建一个内存分区;
分区内含有nblks个内存块, 每个内存块大小是blksize个字节;
返回值是一个指针, 指向此分区的内存控制块.
***********************/
OS_MEM  *OSMemCreate (void *addr, INT32U nblks, INT32U blksize, INT8U *err);
/* 指定一个内存分区, 从中拿出一个空闲内存块; 返回值是一个指针, 指向这个内存块 */
void  *OSMemGet (OS_MEM *pmem, INT8U *err);
/* 将pblk指向的内存块, 放回pmem所控制的内存分区 */
INT8U  OSMemPut (OS_MEM *pmem, void *pblk);
/* 获取pmem所控制的内存分区的信息, 放入pdata中 */
#if OS_MEM_QUERY_EN > 0
INT8U  OSMemQuery (OS_MEM *pmem, OS_MEM_DATA *pdata);
#endif

---------------------------------
内存控制块
很重要的一个结构体, 用于控制内存分区. 每一个内存 partition 就会有一个 control block.

#if (OS_MEM_EN > 0) && (OS_MAX_MEM_PART > 0)
typedef struct {
void   *OSMemAddr;                    /* Pointer to beginning of memory partition                  */
void   *OSMemFreeList;                /* Pointer to list of free memory blocks                     */
INT32U  OSMemBlkSize;                 /* Size (in bytes) of each block of memory                   */
INT32U  OSMemNBlks;                   /* Total number of blocks in this partition                  */
INT32U  OSMemNFree;                   /* Number of memory blocks remaining in this partition       */
} OS_MEM;
#endif

注释里都阐述的很清楚了, 就不再赘述了.
---------------------------------
有点不想写了, 貌似写这类系列文章好麻烦. 篇幅太大, 时间不够. 直接就贴图吧. 反正主要是备份所需嘛. 囧
系统初始化时, 建立的空闲内存控制块链表:

创建内存分区 OSMemCreate() 函数, 将内存分区, memory partition, 中的所有内存块, memory blocks, 用一个单向链表连接起来, 这一点非常关键:

---------------------------------
具体的源码实现
不分析了, 大家伙下载阅读吧. -_-
这里说一下注意点:
#1
OS_ARG_CHK_EN 宏定义用于指出「是否检测给系统函数传递的参数」, 如果置零, 将会压缩一部分代码空间, 但是最好还是置一.
#2
内存控制块中, 有一个 void *OSMemFreeList; . 其用途有两个:
1. 当这个内存控制块未被赋值给某个内存分区时, 也就是当这个控制块依然是处于「空闲内存控制块链表」中时, OSMemFreeList 是指向链表中的下一个空闲内存控制块.
2. 此控制块被分配给某个partition后, OSMemFreeList 指向partition中的下一个free memory block 空闲内存块. 换句话说, 此时的 OSMemFreeList 指向分区中的空闲内存块单向链表的头结点.
#3
内存控制块中的 OSMemFreeList 内部标识符, 和系统的全局变量 OSMemFreeList 相同, 务必注意区分. 可以参考上面两张图片的第一张.
#4
释放某个内存块, INT8U OSMemPut (OS_MEM *pmem, void *pblk); .
牢记: 系统没法动态确认 pblk 指向的内存块是否是属于 pmem 控制的内存分区.
这需要我们自己小心. 不然随时可能会因为内存分配问题而程序崩溃.
#5
在某个 partition 没有free block 的情况下, 让某个申请内存块的任务暂时进入waiting状态, 是可以实现的.
系统并不支持, 但是可以对某个特定的内存分区使用计数型信号量, 就ok了.
#6
在阅读源码的过程中, 你可能会碰见类似这样的代码:

plink = (void **)addr;                            /* Create linked list of free memory blocks      */
pblk  = (INT8U *)addr + blksize;
for (i = 0; i < (nblks - 1); i++) {
*plink = (void *)pblk;
plink  = *plink;
pblk   = pblk + blksize;
}
*plink              = (void *)0;                  /* Last memory block points to NULL              */

OS_ENTER_CRITICAL();
if (pmem->OSMemNFree > 0) {                       /* See if there are any free memory blocks       */
pblk                = pmem->OSMemFreeList;    /* Yes, point to next free memory block          */
pmem->OSMemFreeList = *(void **)pblk;         /*      Adjust pointer to new free list          */
pmem->OSMemNFree--;                           /*      One less memory block in this partition  */
OS_EXIT_CRITICAL();
*err = OS_NO_ERR;                             /*      No error                                 */
return (pblk);                                /*      Return memory block to caller            */
}
OS_EXIT_CRITICAL();

我对于这两段代码非常惭愧, 因为我经常自认为对指针等非常熟练, 可惜这个指向指针的指针 *(void **) pblk; 让我想了差不多10分钟才想明白. 真是羞愧难当啊.
现在简单阐述如下:

pblk指向某物理地址addr_pblk;
(addr_pblk)中所存储的内容, 也是一个指针, 称作ptr_a, ptr_a指向物理地址addr_a, 也就是说, ptr_a中存储的是物理地址addr_a;
那么, pblk本质上就是指向指针的指针.
但是, 由于pblk的类型是 void *pblk, 所以如果简单的使用 *pblk, 得到的将是addr_pblk中的具体内容, 也就是物理地址addr_a的数值表示, 而非指针!
因此先强制类型转换 (void **)pblk, 再取值, *(void **)pblk, 就可以得到指向addr_a的指针了.

- EOF -

μC/OS-II 研究系列 - 002

2009-04-11T12:31:00.023+08:00

任务

有两种典型的嵌入式开发, 一种是所谓「前/后台系统」开发, foreground / background system development, 一种是基于某个操作系统做开发. 对于后者而言, 开发的主要工作就是编写快速而有效的用户空间任务, user space task.
因此, 研究操作系统对任务的标识和管理, Task Identification and Management, 非常重要. 这里针对 μC/OS-II 2.52 版本展开说明.
---------------------------------
如何创建任务:
有很多 API 函数用于操作任务, 包括创建任务 OSTaskCreate() OSTaskCreateExt(), 删除任务 OSTaskDel() OSTaskDelReq(), 任务堆栈检测 OSTaskStkChk(), 挂起和恢复任务 OSTaskSuspend() OSTaskResume(), 改变任务优先级 OSTaskChangePrio(), 等等.
这里仅仅是粗略介绍 OSTaskCreate() OSTaskCreateExt(), 详细的介绍将在后续文章「任务管理接口」中详细介绍.

#if OS_TASK_CREATE_EN > 0
INT8U  OSTaskCreate (void (*task)(void *pd), void *pdata, OS_STK *ptos, INT8U prio);
#endif

#if OS_TASK_CREATE_EXT_EN > 0
INT8U  OSTaskCreateExt (void   (*task)(void *pd),
void    *pdata,
OS_STK  *ptos,
INT8U    prio,
INT16U   id,
OS_STK  *pbos,
INT32U   stk_size,
void    *pext,
INT16U   opt);
#endif

首先要说明, 类似 INT32U 的类型, 就是表示32位的无符号整型, 譬如 #typedef unsigned long int INT32U, 依次类推 INT8U INT16U.
其次, 关于指针类型, 都是以小写字母 p 开头, 譬如 *ptos *pbos 等等.

ok, 下面介绍几个要点:
#1
宏标记 OS_TASK_CREATE_EN OS_TASK_CREATE_EXT_EN, 用意在于「可裁减性」, 也就是所谓的 scalable. 譬如, 如果用户需求很简单, 没必要使用扩展任务创建模式, 就 #define OS_TASK_CREATE_EXT_EN 0, 这样可以缩减所需的程序空间大小.
#2
任务创建函数 OSTaskCreate() 用于简单的创建一个任务, 需要指明任务入口 void (*task)(void *pdata), 被处理数据的指针 void *pdata, 任务优先级 INT8U prio 以及任务堆栈栈顶指针 OS_STK *ptos.
扩展型任务创建函数 OSTaskCreateExt() 用于创建一个能够更加灵活操控的任务, 除了需要指明上述的基本参数外, 还有 ---
INT16U id, 任务的额外标识, 当前, 这个参数无用. 目前, 任务的 prio 就是其标识, id 只是留作后续版本扩展用,
OS_STK *pbos, 堆栈栈底. 注意, 这里的栈底并非活跃堆栈的底部, 而是堆栈容量的底部, 也就是堆栈生长的极限位置.
INT32U stk_size,堆栈大小. 并非字节容量, 而是指针容纳量. 譬如32位的机器, 当 stk_size = 100U 时, 实际堆栈容量应该是400 Bytes,
void *pext, 指向某个自定义扩展数据块, 也就是除了 pdata 之外的另外一个能够被操作的数据块.
INT16U opt, 设定选项, 如 OS_TASK_OPT_STK_CHK OS_TASK_OPT_STK_CLR OS_TASK_OPT_SAVE_FP, 分别代表允许堆栈检测, 堆栈清0, 需要进行浮点操作; 用「位或」运算符来操作之, 譬如, OS_TASK_OPT_STK_CHK | OS_TASK_OPT_STK_CLR.
#3
关于任务堆栈.
由于处理器架构的区别, 有 high->low & low->high 两种堆栈生长方向. 譬如51系列单片机, 都是从低向高生长, 而对于 8086/8088 以及当下的 IA32 架构, 则是从高向低生长.
如果不太理解, 我在这里画了一个堆栈从高向低生长的示意图:

压入堆栈前:
high address
(0x2665) = 某地址a    --- top_of_stack
.....
...      = NULL
...      = NULL
...      = NULL
.....
(0x2600) = NULL
low address

压入堆栈后:
high address
(0x2665) = 某地址a
(0x2664) = (EFLAGS)
(0x2663) = (CS)
(0x2662) = (EIP)    --- top_of_stack
...      = NULL
...      = NULL
.....
(0x2600) = NULL
low address

μC/OS-II 的任务堆栈是彼此独立的, 各个任务的堆栈大小并非完全相同, 而是可以对每个任务指定堆栈大小. 这对于节约系统资源很有帮助.
在调试时, 可以通过 OSTaskStkChk() 来检测堆栈使用情况, 从而为每个任务划分恰当的堆栈空间大小. 此函数并非系统默认启动, 其详细信息, 后续文章会说明.
#4
大家肯定注意到了, 在 OSTaskCreateExt() 中, 既有 stk_size 堆栈大小, 又有 ptos 和 pbos 指针. 很明显, 三个变量中, 仅仅需要两个就ok了, 第三个可以通过计算得出.
那为何要传递三个变量呢?
这就是典型的以空间换取时间 --- 占用的 RAM 空间虽然增加了, 但是在某些应用上, 譬如计算堆栈使用量等等, 运行时间得到了压缩. 对于实时操作系统, 这是划算的.
#5
任务优先级. 数字越小, 优先级越高.
范围是 0~OS_LOWEST_PRIO, OS_LOWEST_PRIO 是自定义的常量.
最多可以定义的任务优先级数量是64级, 也就是0~63. 但是, 最低级永远都是给空闲任务 OSTaskIdle() 使用的. 而且由于将来扩展的需要, 最好 0~3 & (OS_LOWEST_PRIO - 3)~(OS_LOWEST_PRIO) 不要使用.
---------------------------------
用户任务的大致形式
永远不会返回的无限循环. 函数的返回值应该被设置成 void 类型, 而任务的参数应该是指向被处理的数据的指针, void *pointer_to_data_be_handled. 譬如,

void task_name(void *pdata)
{
/* 用户代码 */
while(1) {
/* 用户代码 */
}
}

---------------------------------
任务状态
主要是5种状态.
dormant 休眠, 也就是任务驻留在程序空间, 没有交付给系统进行调度.
ready 就绪, 也就是随时可以被调度程序调度.
running 运行, 整个系统中永远只能有一个任务处于运行状态.
waiting 等待, 譬如任务正在等待某个信号量被释放 OSSemPend(), 抑或是将自身延时某段时间 OSTimeDly(clock_ticks_numbers) 供系统做调度等等.
interrupt 被中断, 顾名思义也就是被中断啦.
参考示意图如下, 从书上抓图抓下来的. 上面附带了详细的状态转移函数调用.
点击查看大图.

---------------------------------
任务控制块
首先指出:
这是系统里最重要的一个自定义结构体. 定义在 ucos_ii.h 文件中.

typedef struct os_tcb {
OS_STK          *OSTCBStkPtr;      /* Pointer to current top of stack                              */

#if OS_TASK_CREATE_EXT_EN > 0
void            *OSTCBExtPtr;      /* Pointer to user definable data for TCB extension             */
OS_STK          *OSTCBStkBottom;   /* Pointer to bottom of stack                                   */

INT32U           OSTCBStkSize;     /* Size of task stack (in number of stack elements)             */
INT16U           OSTCBOpt;         /* Task options as passed by OSTaskCreateExt()                  */
INT16U           OSTCBId;          /* Task ID (0..65535)                                           */
#endif

struct os_tcb   *OSTCBNext;        /* Pointer to next     TCB in the TCB list                      */
struct os_tcb   *OSTCBPrev;        /* Pointer to previous TCB in the TCB list                      */

#if OS_EVENT_EN > 0
OS_EVENT        *OSTCBEventPtr;    /* Pointer to event control block                               */
#endif

#if ((OS_Q_EN > 0) && (OS_MAX_QS > 0)) || (OS_MBOX_EN > 0)
void            *OSTCBMsg;         /* Message received from OSMboxPost() or OSQPost()              */
#endif

#if (OS_VERSION >= 251) && (OS_FLAG_EN > 0) && (OS_MAX_FLAGS > 0)
#if OS_TASK_DEL_EN > 0
OS_FLAG_NODE    *OSTCBFlagNode;    /* Pointer to event flag node                                   */
#endif
OS_FLAGS         OSTCBFlagsRdy;    /* Event flags that made task ready to run                      */
#endif

INT16U           OSTCBDly;         /* Nbr ticks to delay task or, timeout waiting for event        */
INT8U            OSTCBStat;        /* Task status                                                  */

INT8U            OSTCBPrio;        /* Task priority (0 == highest, 63 == lowest)                   */

INT8U            OSTCBX;           /* Bit position in group  corresponding to task priority (0..7) */
INT8U            OSTCBY;           /* Index into ready table corresponding to task priority        */

INT8U            OSTCBBitX;        /* Bit mask to access bit position in ready table               */
INT8U            OSTCBBitY;        /* Bit mask to access bit position in ready group               */

#if OS_TASK_DEL_EN > 0
BOOLEAN          OSTCBDelReq;      /* Indicates whether a task needs to delete itself              */
#endif
} OS_TCB;

东西太多, 懒得总结了. 囧
大致就是根据 OS_CFG.h 中的宏定义, 裁减性的定义任务控制块 OS_TCB 结构体.
需要指出的是, 这里的 struct os_tcb *OSTCBNext; struct os_tcb *OSTCBPrev; 主要是用于构建空任务控制块单向链表 OSTCBTbl[], 以及系统当前任务的任务控制块list OS_TCB *OSTCBList; 指针所指向的双向链表.
前者是依靠 OS_TCB *OSTCBFreeList; 指向的, 每当一个任务被创建, 就将当前 OSTCBFreeList 指向的空任务控制块交付给此任务, 并将此控制块初始化, 而 OSTCBFreeList 指针也在单向链表中向后移动一位; 同理, 每当一个任务被删除, 也就是成为休眠状态后, 这个任务的控制块被清空并归还到单向链表中, OSTCBFreeList 也向前移动一位.
后者系统当前任务的任务控制块list双向链表结构, 也是很重要的一个结构. 时钟节拍函数 OSTimeTick() 就是用这个链表来刷新各个任务的 OSTCBDly 值. 这个双向链表的表头指针是 OSTCBList, 永远指向最新创建的某个任务. 如果一个任务A被创建, 那么就是插入到 OSTCBList 的前面, 而 OSTCBList 也指向这个最新创建的任务A.
ok, 或许你已经考虑到了. 由于系统优先级最多只有 OS_LOWST_PRIO + 1 个, 而任务的表示也仅仅只能够由 prio 来区分, 那么 OSTCBFreeList 所指向的空任务控制块单向链表中的元素, 最多也只能够有 OS_LOWST_PRIO + 1 个.

你看明白了么? 如果没有, 还是下载文档来看吧.
去 gigapedia 搜索一下我前面提到的那本书 MicroC/OS II: The Real Time Kernel, 就可以找到了. 毕竟人家花了N长时间写作, 所以更加全面. 我这里的介绍显得有些太快而且太简略了点.
不过呢, 最好还是下载源代码阅读. 在官方站点上就有最新版本的下载. google 可以找到以往的老版本, 譬如和文档配套的2.52版本.
---------------------------------
初始化任务控制块
再次指出: 这也是内核源码中很重要的一部分.
前面已经介绍了创建任务, 也介绍了操作系统对于任务的控制模块 OS_TCB. 也提到了在创建一个任务的时候, 对空任务控制块单向链表和系统当前任务的任务控制块list的影响.
这些影响, 都体现在任务创建函数, OSTaskCreate() 和 OSTaskCreateExt() 中. 而这两个函数, 其核心部分都是一个函数, OS_TCBInit().

这里跑题指出一点, 如果各位在内核源码中碰到了 OS_xxx() 形式的函数, 那么肯定是系统内部函数, 也就是不需要各位显式调用, 系统的内部封装函数罢了.

这段函数的源代码在 os_core.c 文件中, 基本的内容前面都指出来了, 不再赘述. 各位直接看源码吧.
---------------------------------
总结
本篇文章内容很多, 这里再次梳理一遍:
#1. 如何创建任务? OSTaskCreate() OSTaskCreateExt(), 两者的参数列表参见上文中的第一个section.
#2. 用户任务的大致形式? 一个无限循环, 永远不会返回.
#3. 任务有哪些状态? 一共5种. 休眠, 就绪, 运行, 等待, 被中断.
#4. 任务怎么被系统识别和处理? 通过任务控制块. 参见上述对于 OS_TCB 结构体的描述和源代码. 同时务必明确两个系统级别的链表, 空任务控制块单向链表, 以及系统当前任务的任务控制块list双向链表. 前者由 OSTCBFreeList 指针指向当前空任务控制块, 随时等待着被付给某个新创建的任务. 后者由 OSTCBList 指针指向最新创建的某个任务的任务控制块.
#4. 新任务被创建时, 操作系统如何初始化任务控制块? 主要做哪些工作? 参考上面的源代码, 以及上面的#3「任务怎么被系统识别和处理」.
---------------------------------
ok, 终于写完了.
我真是精神可嘉啊. 囧. 前不久肌肉训练过了头, 加之生活习惯不好, 经常熬夜, 导致颈椎部位的肌肉组织有点拉伤, 今天下午去武汉体育学院医院做了推拿和拔火罐, 舒服多了.
而且现在我的Ubuntu上设置了keyboard typing break, 每隔30分钟就强制关闭键盘响应2分钟, 活动颈椎肌肉, 做一做颈椎保健操. 很舒服.

下篇预告:
操作系统初始化, OSInit(),
操作系统启动, OSStart(),
下下篇预告:
系统任务就绪表 OSRdyGrp, OSRdyTbl[],
操作系统的任务调度器, OS_Sched(void),
如何给调度器加锁, OSSchedLock(void), 和解锁, OSSchedUnlock(void),
任务级别的任务切换, OS_TASK_SW(), 一般使用汇编完成, 这里仅仅是写出pseudo code就ok了.

- EOF -

因言获罪

2009-04-09T11:06:00.002+08:00

耻辱的司法体系, 无知无良的政府官员.
奸淫幼女堪比流氓地霸, 征用土地却道恐村民挥霍.
检查机关不愿查不敢查甚至不想查, 有良人士却遭多方恐吓.
勇气何在？良知何在？一潭死水悄然腐败滋生却高呼共建河蟹社会. 没有高度强健的执行力谈何河蟹？凭什么河蟹？空口号, 幻想.
只是隐约看到一种力量, 从外向内渗透. 阻挠很大, 却无法阻止这股力量的生长. 量变引起质变, 关键在于潜在而迅速的改变. 却思教育之败, 不免些许悲观. 罢了罢了, 现在思考这些无用, 继续研究我的实时操作系统罢了.

失望

2009-04-08T14:10:00.004+08:00

愤青对着法国怒吼, 一边焚烧着他们的国旗, 一边狂笑.
眼睛里看不见问题, 满眼都是金灿灿的麦子, 叹息有如耳边风一样, 吹过了却不留痕迹, 扬起尘土又悄悄落下. 物质至上, 犬儒主义. 真理? 自由? 笑话. 掩埋于爱情, 权力, 身份, 钱财的口水中, 无处站立. 谩骂, 讥诮, 甚嚣尘上. 对话无处藏身. 悔恨, 叹息, 四处可见, 反思难觅踪影.
所谓「不自由毋宁死」, 所谓「知识分子的批判精神」, 都有如一尊古希腊的神像, 破碎的只剩下零星的碎片, 残渣.

千年的佛寺在拉动经济的号召下, 成为昏头当权者签署的「十里温泉城」洗浴中心的附属品. 九龙石壁, 也可以被一纸欺上瞒下遮遮掩掩的文件推翻. 无法做到旅游胜地的宣传, 只求立竿见影的灰色产业链条. 有人哭, 有人笑. 佛教道义? 文化传承? 在哪里? 我怎么睁大了双眼却什么都看不见?
所谓「国际佛学会议」, 在政治的参与下, 显得这么荒谬. 西藏小喇嘛用不太利索的英语发言, 却稚嫩的有如不经世事生活在幻想中的少年. 厅堂中刺眼的上百盏大型吊灯, 燃烧着, 不时听到演讲者「能源危机」的呼喊.

依然记得杨家收费站, 106国道上的路障, 盘剥着百姓的血汗钱, 收费站工作人员无所谓的嘴脸. 没有爆光, 一纸文件能够停留数年, 在历史的跑道上, 磕磕绊绊, 麻木的人, 一级一级的阻碍. 宰相和俄罗斯贵宾欣赏舞台表演时的惬意微笑, 一阵恶心.

还有谁记得那位朝着茫茫草地跪下的诗人? 有谁记得豆腐渣工程下埋着的阴魂哭嚎?
信息闭塞的上层建筑, 却一直在呼喊「与时俱进」. 口口声声「国情复杂」, 是否因为落后的思维无法跟上时代的步伐? 形象工程, 低俗, 腐败. 有人哭, 有人笑. 法制社会? 权力之下的法制如此苍白, 信息传播的闭塞, 活像一具早已风化的木乃伊, 包裹着层层白布, 没人知道究竟发生了什么. 腐烂, 悄然进行.

只希望苍蝇能够吃掉尸体, 进化, 脱胎换骨. 这一天应该不会太远.
问题总是存在, 只是, 是否敢于面对, 能否接受挑战, 是否永远抱着一颗虔诚的赤子之心对待自己, 对待这个世界.

The Google Music Product

2009-04-08T11:54:00.008+08:00

我也来说谷歌音乐

都是一些老生常谈的问题, 但是在blog里从来没谈过, 就破例写一篇囧.

和菜头同学写了一篇向山寨致敬写在谷歌音乐上线之后.
如果说这是一篇「无厘头」的文章, 那么是可以理解的 --- 现状就是如此, 与其抗争, 不如顺应潮流, 「山寨」一把, 「无厘头」一回.
如果说这不是一篇无厘头文章, 而是正儿八经的讨论, 那么和菜头同学就大错特错了.
首先要指出, 谷歌音乐不是什么山寨, 百度mp3也不是啥山寨, 只是歌曲的来源不同, 拉拢客户的方法有所区别. 一个没有踏及法律的灰色地带, 另一个踩着灰色地带不愿退出来. 而在设计上, 真的没有必要在「词汇」上大做文章, 用户习惯才是王道. 譬如播放器的 UI 以及「收藏夹」之类的功能. 至于名字怎么取, 只要别太离谱就ok.
MP3本身就是一个颇具争议的东西. 谷歌音乐当前只对中国地区开放, 国外用户根本没法访问, 为啥? 就是顾及到世界各地的版权状态不一致. 打个不恰当的比方, Amsterdam 红灯区世界闻名, 你如果去了可以随便消费, 就好比百度mp3抑或是酷狗酷我之类的音乐客户端一样, 但是如果把这些红灯区放到其他国家, 就并非如此了, 起码得要遮遮掩掩的进行, 就好比 torrents 种子站一样. 谷歌音乐只是google全球战略的一个试点, 如果模式逐渐清晰, 很有可能全球推广, 同 last.fm 和 iTunes 之类的付费站点争夺客户. 当然, 到时候的模式究竟如何谁也说不清, 「不作恶」只是个大框架, 框架之下究竟如何实施, 条条大路通罗马.
所以, 如果真像和菜头所言, 取名「谷歌mp3」, 绝对是行不通. music 和 mp3 两个词汇之间范畴太不一样, 尤其是在唱片公司和经纪人眼中, 后者简直就是撒旦的代名词, 就好比 Hollywood 对待 p2p 就像如临大敌一样.
从20世纪40年代开始, 技术催生产业, 规模改变模式, 无一例外.

短期内, 让大众产生「盗版就等同于偷窃」的意识很不容易, 也不现实. 我的 Windows 操作系统就是盗版, 尽管我现在已经全面转向 linux, 但是诸如黑莓手机的「桌面管理器」, 还是必须得在 Windows 平台下进行, 尽管从技术上来讲, javaloader on linix 基本可以替代「桌面管理器」, 但是对于普通大众用户, 显然不现实, 哪怕是我这等喜欢折腾新兴事物之人, 也更愿意使用「桌面管理器」.
但是, 大多数互联网产品和传统的软件产品很不同. 就拿互联网音乐来说, 如果正版音乐和盗版音乐体验一致, 甚至更好, 譬如搜索结果更好, 没有死链, 音质更佳, 播放体验更好, 音乐社区更有互动更好玩, 那么, 年轻的用户, 以及大批潜在的「重要用户」自然会过来. 毕竟大家都知道, 互联网产品的赢利主要是10%的用户所带来的, 争取这一部分用户才是重中之重. 到时候, 就是轮到踩踏着灰色地带的mp3们来哭了. 当然, 到时候这些mp3也自然会改变策略, 迎合那时的市场规律. 毕竟, 达尔文的适者生存法则, 在市场规律中永远都不会失效, 何况互联网这个只有第一没有第二的领域.

当下, 正版与否真的只是一个概念. 除非有朝一日酷我酷狗都成了死链, 百度mp3没法mp3, 才是真正正版时代的到来. 可以预计, 到时候, 谷歌音乐也绝对不会这么开放, 让大家伙随意的免费下载了.

ok, 说了这么多, 谷歌真正该抓紧做的, 究竟是啥呢? 当然, 这轮不到咱们这些普通用户来说, 毕竟谷歌内部的互联网产品设计人士绝对不是吃素的. 但是, 根据我的看法, 当下谷歌一直没有触碰的, 就是「社区」这一块, 这也是谷歌和其他本土互联网产品的重要区别. 而谷歌音乐很有可能是一个极好的切入点.
豆瓣, 虾米, 这两个站点, 都有很多创新的模式, 很值得谷歌音乐产品组参考. 有时候, 音乐站点不仅仅只是歌曲数量多少的问题.

- EOF -

μC/OS-II 研究系列 - 001

2009-04-07T16:17:00.013+08:00

临界段代码处理.

所谓临界段代码, Critical Sections of Code, 就是这段代码在执行时, 不希望也不允许有中断发生.
所有使用了系统变量, 也就是全局变量, 的代码段, 基本上都是属于这一类, 除非使用信号量的方式对全局变量加以了保护.
---------------------------------
处理方法:
封装了两个宏, OS_ENTER_CRITICAL(), OS_EXIT_CRITICAL(), 分别用于进入临界段, 退出临界段.
封装方式:
OS_CRITICAL_METHOD 宏定义, 用来指示采用何种封装方式.
#1
直接定义为关中断, 开中断.

/* pseudo code*/
#if OS_CRITICAL_METHOD == 1
#define OS_ENTER_CRITICAL() __asm_tag__ (CLI;)
#define OS_EXIT_CRITICAL() __asm_tag__ (STI;)
#endif

上面是伪代码, 使用的两条汇编指令 CLI STI 是 IA-32 以及 IA-64 架构中的关中断 Clear Interrupt, 开中断 Set Interrupt 指令. 具体可以参考 Intel 64 and IA-32 Architectures -- Software Developer's Manual 的第一卷 5.1.11.
pros:
# 简便, 迅速. 对于处理器速度很慢的系统尤其适用.
# 有些系统仅仅能够使用此类方法.
cons:
如果系统本身就是关中断状态, 那么使用 OS_ENTER_CRITICAL() OS_EXIT_CRITICAL() 组合后, 系统中断将打开. 这时便有可能产生严重错误.
#2
先保存当前状态, 再进入临界段代码, 退出时恢复.
保存方式可以使用堆栈, 如,

/* pseudo code*/
#if OS_CRITICAL_METHOD == 2
#define OS_ENTER_CRITICAL() __asm_tag__ (PUSHF; CLI;)
#define OS_EXIT_CRITICAL() __asm_tag__ (POPF;)
#endif

也可以根据编译器提供的方式, 如,

/* pseudo code*/
#if OS_CRITICAL_METHOD == 3
#define OS_ENTER_CRITICAL() \
cpu_sr = get_processor_psw(); \
disable_interrupt();
#define OS_EXIT_CRITICAL() \
set_processor_psw(cpu_sr);
#endif

其中 cpu_sr 是和系统的程序状态字寄存器, Program Status Register, 大小一致的变量.
如8051中的 PSW 是8位, 就应该定义, typedef unsigned char OS_CPU_SR; OS_CPU_SR cpu_sr;. 如 IA-32 架构的 EFLAGS 是32位, 则应该是 typedef unsigned long int OS_CPU_SR;.
pros:
没有第一种实现方式的错误.
cons:
占用的时钟周期自然就增加了, 对于系统的速度有所拖累.
---------------------------------
总结:
这里所提到的两个宏定义, 都是在 OS_CPU.h 文件中, 用于移植所需.
至于移植时, 采取何种办法, 根据各类架构和应用而定.
如果对于「是否屏蔽了中断」不敏感, 那么使用第一种方式足矣. 如果敏感, 务必使用第二种, 否则系统定然崩溃或者挂起.
而在第二种中, 推荐使用编译器提供的方式, 而非内联汇编的堆栈操作. 因为有时候编译器对内联汇编支持不好, 可能导致对堆栈指针 SP 的处理出错.
---------------------------------
** 注意:
一旦进入临界段代码, 所有中断便随之关闭, 包括定时时钟中断 Clock Tick Interrupt. 如果在此时调用类似 OSTimeDly() 的延时功能函数, 便会导致系统挂起, 也就是死机, 因为时钟节拍中断无法得到服务. 谨慎起见, 调用任何功能函数前, 都要保证中断是开着的.
而且, 如果临界段代码太长, 占用时钟周期太多, 会导致系统对中断的响应变慢, 中断延时增加, 这对于商业实时系统是不可忍受的. 因此务必良好规划和设计, 将临界段代码压缩至最小, 切记切记.

- EOF -

μC/OS-II 研究系列 - 000

2009-04-06T22:35:00.015+08:00

状态很糟糕, 没法集中精神, 一天一天就这么过去, 非常不爽.
前几天颈椎疼, 转动起来居然还发出咯吱咯吱的声音. 休息了两天, 每天早睡, 现在缓和了很多.
明天开始, 一个星期时间, 研究 μC/OS-II 的内核结构, 并在此做详细的记录. 主要就是参考 μC/OS-II 的圣经, MicroC/OS II: The Real Time Kernel.
---------------------------------
Todo list

RTOS 基本概念, Basic Concepts,
临界段代码处理, Handling of Critical Sections,
任务标识, 任务状态, 任务控制, Task Identification, Task States, Task Control,
任务就绪表, 任务调度, Ready List of Tasks, Scheduling of Tasks,
锁定 & 解锁调度器, Locking & Unlocking Scheduler,
空闲任务 & 统计任务, Idle Task & Statistics Task,
中断服务程序 ISR, Interrupt Service Routine,
信号量, 互斥信号量, Semaphore, Mutex,
消息邮箱, 消息队列, Message Box, Message Queue,
内存管理, Memory Management,
时钟节拍, Clock Tick,
系统初始化 & 启动, Initialization & Starting of μC/OS-II.

- EOF -

eqo 中国推广之败北

2009-04-06T17:39:00.009+08:00

前不久提到了一些关于 eqo 的话题, 说:

我已经和他们的 support 发送了邮件, 过一段时间将会在这个博客上给出一个详细的说明.

现在看来是没戏了. eqo 在国内的推广活动和客户服务, 已经在2009年2.28停止. 可能是赢利问题上吃亏不讨好, 甚至看不到「讨好」的曙光吧. 不知道未来某天, 会不会重新开始呢?

在中国做收费的互联网产品的推广, 确实比较艰难. 另, eqo 总是登不上去, 可能对网络环境的要求较高.
我现在使用的手机im产品是 Nimbuzz, 能够通过 internet 直接和 skype 抑或是 msn 用户打电话. 可惜我的手机不支持 wifi, 而由于国内该天杀的流量限制, 通过 gprs 来聊天明显不现实.
如果想要找一款类似 eqo, 而且目前经营的比较成功的产品, 貌似 mig33 是个不错的选择. 不过我没用过, 就不说啥啦.

- EOF -

Blackberry 漫谈

2009-03-31T14:41:00.020+08:00

明儿开通 gprs 上网服务. 尽管手机支持 edge 的通信协议, 可惜我家居然没有 edge 的信号覆盖, 而且更为奇怪的是, 只要走下楼, 漫步到小区里的其他建筑物旁边, 就出现了 edge 的信号囧. 所以估计是有啥东西阻挡了 edge 的信号, anyway, 不管怎么说, 只能用较为慢速的 gprs 了.
这里做些备份.

如何做 jar 文件和 cod 文件的转换.
HOWTO: upload midlets (third party software) to your blackberry for all, even BWC!
简单来说就是下载黑莓的 JDE, 然后进入类似 C:\program files\Research in Motion\Blackberry JDE 4.2\bin\ 的路径, 运行类似如下的命令:

rapc import="c:\Program Files\Research in Motion\Blackberry JDE 3.7\lib\net_rim_api.jar" codename=Virca -midlet jad=Virca.jad Virca.jar
javaloader -usb load Virca.cod

如果需要卸载, 参考 HOWTO - installing JDE to use javaloader, 最重要的命令如下:

javaloader -usb load module_name
javaloader -usb erase -f module_name

其中第二条命令的 -f 选项是强制删除, 一般会令机器提示重启. 所以普通情况下使用时, 直接去掉 -f 选项就ok了, 出现删除不掉的情况时, 再添加 -f 选项.

XCalc - Free Java Graphing Calculator Works On BlackBerry
一款很强悍的计算器, 代码开源, jar 格式. 甚至可以做三维图形.
可惜的是我将其转换成 cod 格式后, 在我的8700上没法键值匹配. 全键盘也有全键盘的苦衷啊. 不知道有没有键值转换的工具.
XCalc / free download

Viigo | Living Life Untethered
完美的 rss 阅读工具 viigo, 能够读取 google reader 中的列表同步, 具体用法参见其FAQ ---
其实现使用了 Hecl, 一种专门为内存有限的移动设备设计的, 使用 java 实现的开源脚本语言. Hecl - The Mobile Scripting Language. 感觉很值得研究.

UCWEB v6.1 64k低内存版 for 黑莓全系列
非完美的网页浏览工具 UCWeb. 为何称之为「非完美」? 因为黑莓自带的浏览器能够进行便捷的快捷键操作, 但是流量 & 速度上比不上 UCWeb; 而 UCWeb 又不是专门为黑莓设计, 操作起来不是很方便, 起码没得快捷键, 或多或少有些不习惯.

顺便再介绍若干「重量级」的小软件.
BBScreen 最方便的黑莓截图工具
BB专用词典软件贝贝词典
BBer's SMS Manager, 支持导出短信时附带发信收信人姓名, 尽管机器里面放上10k甚至更多条的短信, 也不会占用多大的存储空间, 但是时不时导出 SMS 短信进行备份是个好习惯.
用 Mobipocket Reader6.0 看电子书详细安装使用教程, 这款软件不止是「看电子书」那么简单, 功能及其强大.
让滚轮机拥有“黑莓键” QuickWheel, 对于8700这样的滚轮机型, QuickWheel 模拟了滚轮按下的情况, 对于延长滚轮寿命帮助良多.
来电防火墙 iBerry Black&White List, 不想接听某人电话? 安装它就ok了.

- EOF -

三款网络电话服务

2009-03-30T22:06:00.032+08:00

VoIP 服务商也可谓是「日新月异」. 不论是价格策略, 还是运营范围, 都可谓是「士别三日, 当刮目相看」, 当然, 也可能是「士别三日, 当侧目相看」囧.
自然, 这里所介绍的内容, 其有效性, 仅仅能够保证到今天, 因为指不定到了明天, 用户协议就改变了呢?

首先指出 --- 这里提到的三款网络电话服务, 都是能够让大家伙, 通过低廉的资费, 很方便的从手机上直接拨打国内 & 国际长途的服务.
其次指出 --- 这里所提到的服务, 尽管资费低廉, 但是并非完全免费, 毕竟天底下没有免费的午餐.

EQO - Mobile VoIP, free texts, and free mobile IM with EQO
这是一个超级服务大集合, 又是 VoIP, 又是免费 EQO 短信, 又是 twitter, 又是 msn & gtalk & icq 等等知名 im, 又是 rss 阅读器. 囧
其国际化运营相当成功, 技术支持很强悍.
需要下载手机客户端. 不过客户端支持的手机 OS 类型非常广泛, 只要不是特别旧的老手机, 应该不必担心兼容问题.
这里要提到一个缺点, 就是 eqo 的资费标准似乎一直在变动, 而且帮助文档 & FAQ 都编写的较混乱, 不够明晰, 甚至有前后矛盾的地方.
我已经和他们的 support 发送了邮件, 过一段时间将会在这个博客上给出一个详细的说明.

JAJAH
和skype差不多是同一个时期的产品了. 无需下载任何客户端, 仅仅通过手机访问其站点, 就可以在线拨打低资费高通话品质的国内国际长途电话了. 属于 callback 类型的网络电话, 用来拨打国际长途非常合适.
你可以选择在拨通电话前, 是否接听一段广告. 如果选择接听广告, 那么将会有一定的通话折扣.
这里对 callback 类型稍作解释 --- 譬如你想要拨打某个国际长途电话, 那么你通过手机抑或是 PC 访问 jajah 站点(两者稍有不同, 前者访问的是 mobile 版本), 使用你的 id 登陆, 输入对方手机号, 选择「call」接通. 马上, 你就可以接收到一个电话, 你按下接听, 便可以听到一段广告(如果你选择了接听广告的话), 继而是嘟嘟的等待声 --- 也就是 jajah 在帮你接通另一位了. 等到另一位拿起话筒, ok, 你们可以通话了. 换句话说, jajah 进行的是一个「语音中转站」一般的操作.
值得注意的是, 如果你正在漫游, 那么一旦接听jajah给你打来的「国际长途」, 中国移动会不会征收高额的漫游接听费呢? 我没尝试, 不敢说, 哪位尝试了可以告知一声.
关于 jajah 所谓「free-calls」的说明, 可以参见JAJAH 免费全球呼叫计划, 自然, 不是彻底的免费 --- JAJAH公平使用原则.

和悦网络电话
在腾讯软件的首页上看到的. 不过可不是腾讯的产品, 而是香港启悦发展有限公司的产品, 2005年在香港成立, 号称是「目前亚洲市场上最大也是最优秀的互联网语音通讯服务提供商」.
如果你要注册成为用户, 必须是中国大陆的座机, 手机, 小灵通; 相比较而言, jajah 和 eqo 对注册用户运营商的类型支持更为广泛.
有「PC客户端」和「callback」两种方式, 前者更加便宜. callback方式的资费情况简直就是 jajah 的山寨化囧.

总结 ---
对于个人用户而言, 如果不是需要拨打国际长途, 此类服务的吸引力并不是很大. 毕竟国内长途有其他方式可以降低花费.
对于企业而言, 此类服务可能非常棒, 譬如多方通话, 在线会议等等. jajah & 和悦都支持类似的服务.
如果你并非特别频繁的拨打国际长途, 那么我推荐使用 jajah, 无需任何客户端, 话音质量良好, 而且价格低廉.
另外, 推荐这篇文章 --- 用EQO免费拨打国内长途电话, 但是这个办法似乎已经失效了囧, 大家伙姑妄看之吧.
如果特别频繁的想要和某人拨打国际长途, 那么还是使用 QQ 抑或是 msn 的语音聊天吧.

分布式 - 并行运算 - 服务器 - 数据库

2009-03-10T21:16:00.019+08:00

这里只是做备份, 很乱, 今后再来整理. 不断更新.
CS264: Peer-to-Peer Systems 哈佛大学p2p课程.
Geeking with Greg: Details on Yahoo's distributed database
Welcome to Hadoop! 从 Yahoo! 走出来的金凤凰.
Getting Started with Parallel Programming for Multi-Core - Intel® Software Network 有一份list of books, 很值得借鉴.
Memcached完全剖析
分布式基础学习【一】 —— 分布式文件系统 - Venus神庙 - 博客园一份系列文章, 不少资源值得参考.
Improving Running Components at Twitter 一份很有价值的幻灯片.

update:
2009年3月15日
接受了 TP-Link 的 offer, 系统测试工程师, 偏向软件, 关注硬件. 待遇大致是税后5k, 但是似乎没有扣除所谓的「五险」, 也没有所谓的「一金」, 也就是「住房公积金」, 不过也无所谓啦, 反正年轻人还是暂时别考虑买房的问题, 何况住房问题依靠「公积金」也很难解决, 还是勤奋工作比较靠谱. 目前估计, 扣完之后大概工资卡里是4.5k左右. 公司有班车, 接, 是肯定的, 送, 就不太清楚了.

研发部门的管理很扁平化, 这一点我相当喜欢.
每年加薪机会有两次, 一次是「拉开差距」, 一次是「绝对拉开差距」囧. 不过后者只是留给超级牛人的. So, 勤奋工作, 成为能够享受「绝对拉开差距」的加薪人员, 还是挺不错的.

因此, 上面这条「分布式并行」的发展方向就要暂时搁浅, 甚至彻底泡汤了. 毕竟, 术业有专攻嘛, 在什么类型的公司, 专注的点也必然集中在公司的主要业务上, 更何况 TP-Link 这类高度专注的研发类公司.

ps: 工行杭州软件开发中心居然还不来消息, 这速度 -_-, 果然是国企效率低啊. 还是去高速成长型企业比较适合. -_-
前方道路依旧未知, 但行好事, 莫问前程.

闭关闭关闭关

2009-03-08T22:49:00.008+08:00

工作的事情似乎应该搞的差不多了.

正在等工商银行的杭州研发中心的通知. 对于俺这种想要跨专业发展的应届毕业生来说, 这地方似乎还是相当不错. 不过, 不知道这个机会是否百分百真实可靠, 毕竟还没正式签约, 依然有些忐忑. 一星期后就有终极消息了吧. 真是夜长梦多啊. 阿弥陀佛, 菩萨保佑. 囧

昨天还面试了一家成都天用唯勤武汉分公司, 似乎是做建设银行的业务系统外包的. 我们进去之后的工作, 主要是在 linux 系统下使用 C 语言写基础构件.
说实话, 这个工作看起来倒是很锻炼人的. 只是待遇较低, 实习期三个月, 每月1200, 转正后2000, 需要经常长时间出差. 不知道每日出差补贴是多少, 不过想必不会太高.

3.12 和 3.18 还有两场在华科的供需见面会, 到时候去看看.
春季的校园招聘确实没有秋季那么火爆, 春节前那段秋季校园招聘, 我尽管没有怎么应聘 --- 就应聘了一个阿里巴巴的需求分析师和一个 TP-Link 的国际营销专员, 自然都是以失败而告终啦, 定位有些不够准确囧 --- 也能隐隐约约感觉到那种火爆的气氛. 现在就冷清多了, 起码在武汉这地方是如此. 可能和金融风暴也有较大的关系吧.

闭关闭关. 总是有些静心不下来.

> 数据结构 & 基础算法 --- 在 implementation 方面较弱, 毕竟写程序不够多.
--- Mastering Algorithms in C
在实现上要争取也能用 cpp 和 java 来做.
> cpp & java --- 在编程语言上相当弱, 务必加强.
--- C++ Primer
--- Professional C++
有较好的 C 语言功底的话, 学习 cpp 应该不算难. 只是运用好 Object Orienting 貌似真不是那么容易, 要避免因为 Object Orienting 所带来的复杂乃至多余的设计, 也要最大限度地发挥其优势. 如何找到平衡点, 个人感觉有些难度. 可能还是不够熟练, 而且没怎么接触过大型系统的缘故吧.
java, 迅速入门应该没问题. 现在也暂时不要奢求太多. 从 cpp 转向 java 应该还是蛮快的. 毕竟 cpp 是个有些臃肿和庞大的「集合体」.
某些非常值得研究的项目, 譬如 memcached, 虽然最初是基于 C 的实现, 但现在也有基于 java 的实现.
> 毕业设计.
老师给了一份题库, 不过俺似乎都不太满意, 于是自己定的一个题, 汗.
基于 linux 的 μC-OS II 实时操作系统之 80x86 架构移植, 以及其调度系统的研究和改进. 每天都要抽空来搞一搞, 希望早日搞定.
在操作系统这一块基础很弱, 非专科出身, 平时又没有自学这方面的内容. sigh.. 要抓紧要抓紧.

- EOF -

果核中的xxx --- 系列读本

2009-02-25T13:03:00.008+08:00

就是简明扼要的指导手册了, O'Reilly 出版社的 xxx in a Nutshell 系列图书. 不过可不一定是入门读物, 大多数似乎都是给原本就已经熟悉某种语言或者某项技术的同学提供一个类似 reference book 的东西. 但是呢, 也不尽然, 具体情况就要具体对待啦. 囧

这里摘录5本技术类型的 ---
C in a Nutshell (In a Nutshell) 据称是可以和 C Reference Manual 相媲美的一本无所不包的终极指导手册. 针对C99标准, 主要是阐述C语言的细节和对 runtime library 的说明, 还涉及到了 gcc 和 gdb 以及 make.
C++ in a Nutshell
Linux in a Nutshell, 5th Edition 从使用者的角度出发讲述 linux, 不过也涉及到了不少高级主题.
Linux Kernel in a Nutshell 不是讲述内核开发, 而是从如何下载源代码开始, 一直讲述到如何配置编译等等. 相当相当的深入, 相当相当的详细.
XML in a Nutshell, 3rd Edition 似乎并非是 xml 的入门书籍, 不过搜索一下入门资料先看看应该就ok了.

恢宏宏的宏循环双链表结构

2009-02-23T23:40:00.023+08:00

linux 的内核源代码中, 有一个很重要的数据结构, 循环双链表. 在 $KERNEL_SOURCE_PATH/include/linux/list.h 中被完整实现.

按道理来讲, 循环双链表, 是一种很简单的数据结构. 不过这篇 post 的目的就在于说明, 良好的设计是多么重要.

其特点很鲜明, 就是将链表独立, 和数据分离开来.
好处是显而易见的, 构造链表更方便了, 而且更通用了. 不然, 也不会放到 linux 的内核源代码中, 作为最基本的数据结构嘛. 囧

任何想要被 linked 的数据, 只需要建立 struct 结构体, 然后在其中放入 struct list_head 就ok了.
也就是说, 数据中存放着链表. 是不是听着很奇怪? 一般来讲, 应该是链表中存放数据才对. 这一点也就是 linux 的此种实现方式的超级大优点了. 下面会具体分析之.

不过既然链表是存放在数据中的, 如何通过链表来访问数据呢? 也就是如何通过部分来访问整体呢? 使用 list_entry(pos, type, member) 就ok了.

下面来说说具体实现.
先就其使用方面, 对 list.h 进行一个结构剖析.

如果要查看内核源代码中的原始文件, 点击这里.
和我机器上的内核版本是一致的, 都是 2.6.27-9-generic.
这份原始代码是不能直接移植到其他项目中的, 因为其中包含了对多核心处理器的支持, gcc 编译器特有的命令 typeof(*pos) 等等, 所以, 只能在内核空间, 而非用户空间使用.

不过呢, 这份原始代码的可移植性很好, 很容易被移植到其他项目中, 简单的做些处理就ok了. 一份已经处理妥善的, 符合 ANSI-C 标准, 可以直接使用的代码点击这里下载.
如果无法下载, 点击这里查看.

ok, 剖析正文开始. 在文本编辑器上编辑好之后, 直接粘贴过来的. 囧
---------------------------------
list.h 接口剖析.

list.h 接口剖析, by jtuki:
---------------------------------
struct list_head;
最基本的链表结构体. 定义了前向指针 *prev, 后向指针 *next.

> 直接声明, 继而初始化一个 list_head 结构体.
LIST_HEAD(name);
效果等同于
do {
struct list_head name;
INIT_LIST_HEAD(&name);
} while(0);

> 链表初始化.
INIT_LIST_HEAD(ptr);
使用 #define 宏实现. 初始化一个 struct list_head 结构指针 ptr.

> 往链表中添加元素.
* @new: new entry to be added
* @head: list head to add it
static inline void list_add(struct list_head *new, struct list_head *head);
static inline void list_add_tail(struct list_head *new, struct list_head *head);
都利用了 __list_add(new, prev, next) 函数.

> 删除链表中某个 entry.
list_del(struct list_head *entry);
list_del_init(struct list_head *entry); /* 删除 entry 后立即将其初始化
       INIT_LIST_HEAD(entry); */

> 从某个链表中取出某个 entry, 然后移动到另外一个链表中.
* @list: the entry to move
* @head: the head that will precede our entry
static inline void list_move(struct list_head *list, struct list_head *head);
static inline void list_move_tail(struct list_head *list,
               struct list_head *head)

> 检测是否为空链表.
static inline int list_empty(struct list_head *head);

> 粘结两个链表.
* @list: the new list to add.
* @head: the place to add it in the first list.
static inline void list_splice(struct list_head *list, struct list_head *head);
static inline void list_splice_init(struct list_head *list,
                 struct list_head *head) /* 对变成了空链表的 list 做初始化,
                       INIT_LIST_HEAD(list); */

> 获得 struct list_head *ptr 的 ptr 所在的 struct 结构体指针.
struct type entry = list_entry(ptr, type, member);
/**
* list_entry - get the struct for this entry
* @ptr:    the &struct list_head pointer.
* @type:   the type of the struct this is embedded in.
* @member: the name of the list_struct within the struct.
*/
#define list_entry(ptr, type, member) \
 ((type *)((char *)(ptr)-(unsigned long)(&((type *)0)->member)))

> 对链表进行遍历.
/**
* list_for_each    -   iterate over a list
* @pos:    the &struct list_head to use as a loop counter.
* @head:   the head for your list.
*/
list_for_each(pos, head) {...}
list_for_each_prev(pos, head) {...}

/**
* list_for_each_safe   -   iterate over a list safe against removal of list entry
* @pos:    the &struct list_head to use as a loop counter.
* @n:      another &struct list_head to use as temporary storage
* @head:   the head for your list.
*/
也就是譬如 pos 所在的结构体是通过 malloc 分配的, 那么这个 list_for_each_safe 就是要保证 ---
将 pos 所在的结构体释放掉后, 依然能够通过 n 找到 pos->next.
list_for_each_safe(pos, n, head) {...}

> 直接对结构体, 而非链表, 进行遍历.
list_for_each_entry(pos, head, member) {...}
注意: 这个函数我在源代码中用 #ifdef GCC_COMPILER 掩盖掉了. 因为其使用了 GCC 特有的 typeof(*pos)
运算符. 如果需要, 可以用可移植的方式将其重新写出, 但是我觉得似乎没有必要, list_for_each 就足够了.
接口越多, 容易引发的问题越多.

好了, 接口就是这么多. 是不是很简单? 我估计答案是「不是」. 囧
第一眼望去, 确实显得有些复杂, 不过多看几遍就ok了. 如果多看几遍还是觉得复杂, 那么估计就是我的表达问题了.
---------------------------------
list.h 实现分析

源代码中有一个部分可能难以理解. 就是 list_entry(ptr, type, member) 宏定义. 我看到这部分代码后, 先是一愣 --- 这是啥实现方式? 继而是摇头 --- F***, 简直是太巧妙了. 囧
不过其实仔细想想, 也挺简单, 只是很巧妙罢了, 就是通过计算偏移量, (unsigned long) & ((type *)0)->member, 或者是更加稳妥一些的 (unsigned long) ((char *)&(((type *)0)->member) - (char *)((type *)0)), 和一系列的强制指针类型转换来完成之.

/**

 * list_entry - get the struct for this entry
 * @ptr:    the &struct list_head pointer.
 * @type:   the type of the struct this is embedded in.
 * @member: the name of the list_struct within the struct.
 */
#define list_entry(ptr, type, member) \

    ((type *)((char *)(ptr)-(unsigned long)(&((type *)0)->member)))

如果没法理解这段代码, 参考 C-FAQ 中的 Question 2.14, 以及这里的讲解, Linux Kernel Linked List Explained .

关于偏移量的问题, 在 ANSI-C 的 stddef.h 中有关于 offsetof(type, member) 的定义. 之所以要有针对结构体的 offsetof 定义, 是由于不同的编译器对于结构体的解释不同.
我这里写了一段代码, 来解释这一点 ---

#include <stdio.h>
#include <stdlib.h>

struct my_struct {
 unsigned int x;
 char y;
 struct my_struct *ptr;
};

int main()
{
 unsigned long offset_x, offset_y, offset_ptr;

 offset_x = (unsigned long)(& ((struct my_struct *)0)->x);
 offset_y = (unsigned long)(& ((struct my_struct *)0)->y);
 offset_ptr = (unsigned long)(& ((struct my_struct *)0)->ptr);
 printf("%lu, %lu, %lu\n", offset_x, offset_y, offset_ptr);

 offset_ptr = (unsigned long) (                             \
             (char *) & ((struct my_struct *)0)->ptr -   \
             (char *)((struct my_struct *)0));
 printf("%lu\n", offset_ptr);

 return 0;
}

运行一下, 就会发现在 gcc 平台下结果是:

0, 4, 8
8

而非 0 4 5, 其中的缘故就是因为 gcc 对结构体有所谓空洞的添加. 所以每个 char 类型也就分配了4个字节, 而非1个字节.
如果要强制1个字节怎么办?
使用结构体的位域技术就ok了, 不过这里就不阐述啦.

其次需要注意的是, list_for_each(pos, head) {...}, 以及list_for_each_safe(pos, n, head)的不同适用范围. 这一点很重要!

/**
 * list_for_each    -   iterate over a list
 * @pos:    the &struct list_head to use as a loop counter.
 * @head:   the head for your list.
 */

#define list_for_each(pos, head) \
    for (pos = (head)->next; pos != (head); \
            pos = pos->next)

/**
 * list_for_each_safe   -   iterate over a list safe against removal of list entry
 * @pos:    the &struct list_head to use as a loop counter.
 * @n:      another &struct list_head to use as temporary storage
 * @head:   the head for your list.

 */
#define list_for_each_safe(pos, n, head) \
    for (pos = (head)->next, n = pos->next; pos != (head); \
        pos = n, n = pos->next)

注释里阐述的很清楚了, 就不赘述了.

- EOF -

增强 blogspot 的编辑体验_@_linux

2009-02-20T14:43:00.039+08:00

在 blogspot 中写博客的编辑体验还是不赖的, 可以自定义css, 可以方便的切换到「Edit Html」, 可以使用各类快捷键 --- 这些, 对于咱们这种「自定义爱好者」真是一大乐事囧.
对于 linux 用户来说, 这种编辑体验可以进一步增强.

首先声明 ---
此文中所提到的一些貌似「奇淫巧计」的 tips 其实可以无障碍的应用在其他操作系统中, 也可以应用在除了编辑博客 post 之外的其他场合. 就看各位如何举一反三啦.
其实声明 ---
本文主要是供自己备份, 所以难免有不够清晰明白的地方, 谅解啦. 囧

Table of Contents:
> 自定义 css
> 使用 scim 的 special_table
> vim 插件和设置
> 如何输入源代码?
> 使用toc增强浏览体验

---------------------------------
自定义 css

这里将我修改的css部分备份在此, 注意使用良好编排的注释, 将自己添加的自定义css部分, 和原先的css默认部分, 区分开来.

/* begin --- added by jtuki */
pre{
#  border: 1pt dashed black;
#    color: #666666;
#    color: black;
#    padding: 1em 0;
background : #ABB3A8;
border: 1pt dashed #C0C0C0;
white-space: pre;
font-family: monospace;
font-size: 100%;
overflow: auto;
padding: 1em 1em;
}
.path {color:#652E1E; font-family:monospace;}
/* begin --- for the use of vim's plugin TOhtml*/
.Todo { color: #808080; background-color: #ffff00; }
.Identifier { color: #00ffff; }
.PreProc { color: #ff40ff; }
.Type { color: #00ff00; }
.Constant { color: #ff6060; }
.Statement { color: #ffff00; }
.lnr { color: #ffff00; }
.Comment { color: #8080ff; }
/* end --- for the use of vim's plugin TOhtml*/
/* begin --- for the keyboard shortcut */
.kbd {
    font-family: monospace;
    /* padding: 0px 1px 0px 1px; */
    padding: 0em 0.1em 0em 0.1em;
    border-width: 1px 2px 2px 1px;
    border-style: outset;
    border-color: #baa;
    background: #faf6f6;
    color: #000;
    /* border-style: solid; */
    /* border-color:  #edd #baa #baa #eed; */
}
/* end --- for the keyboard shortcut */
/* end --- added by jtuki */

注释里就阐释的很清晰了, 这里就不赘述了.
---------------------------------
使用 scim 的 special_table

不知道经常使用 scim 的朋友是否注意到了其 special_table? 进入 /usr/share/scim/pinyin 文件夹, 使用你最喜欢的文本编辑器编辑之.


#user-defined
love = 0x2665
email = jerome.rivest.long@gmail.com
name = jtuki
kh = 「」
i = -_-
j = 囧
y = 「译者注:」
blog = http://jtuki.blogspot.com/

site = http://sites.google.com/site/jtukipedia/

# 编辑文档时候很常用
stars = ***********************
fenge = ---------------------------------
s = <img src="http://otho.douban.com/pics/st.gif" vspace="0" alt="*"/>

pre = <pre></pre>
code = <code></code>

ctrl = <span class="kbd">Ctrl</span>+
alt = <span class="kbd">Alt</span>+
shift = <span class="kbd">Shift</span>+
kbd = <span class="kbd"></span>

path = <span class="path"></span>

br = <br />
jkh = &lt;&gt;
hh = ^_^

是不是感觉添加了快捷键输入方式后, 文本输入方便了许多?
使用自定义的模板进行输入, 而非总是重新造轮子, 个人认为是一种良好的习惯. 也是避免飞蚊症的良方. 囧
---------------------------------
vim 插件和设置

vim 很强大, 各种插件也是很丰富. 不过似乎和此篇 post 没太大关联囧. 这里之所以提到 vim 主要是做备份, 也是为了下方的「如何输入源代码」做引子.
这里只是推荐两款插件, taglist 和 supertab-continued.
插件下载后放置在 ~/.vim/plugin 路径下.

前者可以通过 :TlistToggle 激活, 后者可以由单击 Tab 激活.

由于 vim 比微软 Windows 默认的 notepad 强大太多太多, 所以自然需要自定义配置才好用, 这里将我的设置备份粘贴如下 ---
$ vim /usr/share/vim/vimrc

runtime! debian.vim
syntax on
" self-defined options and modes.
set number
set autoindent
set tabstop=4
let Tlist_Auto_Open = 1
let Tlist_Exit_OnlyWindow = 1
let Tlist_Use_Right_Window = 1
let html_use_css = 1
let html_number_lines = 0
colorscheme elflord

ps0: 刚才搜索一不小心碰到了这款插件, trinity.vim - Build the trinity of srcexpl, taglist, NERD_tree to be a good IDE : vim online, 似乎还不赖的样子, 今后有机会阅读超级源代码树的时候再尝试吧. 现在使用 taglist 似乎就足够了.
---------------------------------
如何输入源代码?

其实在 blogspot 中输入源代码特别简单, 尤其是利用 vim 中的 :TOhtml 命令. 上面的 vimrc 文件中, 也有相关的 let html_xxx = x 的内容. 使用挺简单的, 这里就不罗嗦了, 大家伙参考 manual 啦.
这个命令, 综合上方提到的 css 编辑中的格式定义, 就可以产生如下的效果 (随便选了一个很短的程序作为例子, 囧, 是用来检测处理器架构是大端还是小端的C代码) ---

 1 #ifndef ISBIGENDIAN_H
 2 #define ISBIGENDIAN_H
 3 
 4 typedef enum {FALSE, TRUE} BOOL;
 5 
 6 BOOL isBigEndian(){
 7     unsigned short x = 0x1234;
 8     return ((* (unsigned char *) &x) == 0x12)? TRUE : FALSE;
 9 }
10 
11 #endif

---------------------------------
使用toc增强浏览体验

对小型的分标题, 在说明域中增加 id="xxx" 的说明, 最好也在域中增加 style="font-weight:bold;" 的格式定义, 使其更加醒目清晰.
接下来就是利用如下格式添加进入 html 文本中便可 ---

<span style="font-weight:bold; font-size:large; font-family:monospace">Table of Contents</span>:
<a href="#xxx">The title of the chapter</a>

---------------------------------

app_@_linux

2009-02-15T12:59:00.050+08:00

持续更新, 将 linux 下可谓是杀手级别的 app 应用放在这里, 其一备忘, 其二推荐.

Table of Contents:

> 如何对 pdf 进行标注?
> 如何设置, 可以对音频视频的播放有最大限度的支持?
> 如何简单的编辑音频?
> 如何处理 chm 格式的文件?

---------------------------------
2009年2月15日

pdf 阅读 + 标注:

Wine + pdf-xchange-viewer

真不是我喜欢用 Wine, 如果 *nix 上有成熟的 pdf 标注工具, 我也不会用虚拟接口层了. 可惜事实恰好相反. Anyway, 不管白猫黑猫, 能抓住老鼠就是好猫, 何况 Wine 的确很强大.
两者的兼容性报告见这里 --- WineHQ - PDF- XChange PDF Viewer. 可以看到 pdf-xchange-viewer 的最新2.x版本同 Wine 的兼容性非常好.
注意: 如果出现兼容性不佳的状况, 请更新至 wine 官方站点上的最新版本.

--- 话外话: 关于 Wine 和 CrossOver, 以及 Cedega, 之间的区别和联系, 参考这个链接. 从中可以看出 Wine 对于 Cedega 的开发商 TransGaming 封闭源码的不爽之情囧. 俺稍微意译一下.

In the years since Cedega was originally created from Wine, development on Wine and Cedega have continued mostly independently. TransGaming currently gives back very little code to Wine. * 后来两者几乎是彼此独立开发. Cedega 不同于 CrossOver, 对 Wine 的代码发展贡献极低.

Cedega is not "Wine with more gaming support" - because Wine has had years of development since Cedega was made, and many games actually run better under Wine than under Cedega. Currently, Wine has more advanced Direct3D support than Cedega, but Cedega still has more advanced copy protection support due to TransGaming's licensing of (closed source) code from a handful of copy protection companies.
Cedega 并不是更加适合游戏的「Wine 衍生版本」, 有时候 Wine 对游戏的支持更好. 现在, Wine 在 Direct3D 方面比 Cedega 做的出色. 不过, Cedega 有更先进的防拷贝技术(此类技术是为了遏制正版游戏光碟的盗版传播) --- 这是因为其封闭的源代码特点, 可以使之借鉴和添加某些专业的防拷贝公司的代码.

Unlike CrossOver, most improvements to Wine don't get into Cedega due to the license differences between Cedega and Wine.
不同于 CrossOver, Wine 的很多改进并不会融合到 Cedega 当中去, 因为两者的 license 是有很大差别的.

可见公司运营策略很重要, Cedega 的包装要比 Wine 要好, 而且还有一个官方指定的游戏列表 pool, 一目了然. 所以不少人还是喜欢使用 Cedega 来模拟 Windows 平台下的大型游戏.
---------------------------------
2009年2月18日

音频视频播放:

mplayer-nogui mozilla-mplayer smplayer smpalyer-translations

也就是使用鼎鼎有名的 mplayer-nogui 作为系统音频视频处理的后端, 将 mozilla-mplayer 作为 firefox 处理各类流媒体资源的中间层插件, 将 smplayer 以及 smplayer-translations 作为视频播放的前端界面.

mplayer 具有异常强大的速度以及稳定性, 对音频播放而言, 最重要的命令如下 (摘自 man mplayer):

keyboard control
       <- and ->
            Seek backward/forward 10 seconds.
       up and down
            Seek forward/backward 1 minute.
       pgup and pgdown
            Seek forward/backward 10 minutes.
       [ and ]
            Decrease/increase current playback speed by 10%.
       { and }
            Halve/double current playback speed.
       backspace
            Reset playback speed to normal.
       <>
            Go backward/forward in the playlist.
       p / SPACE
            Pause (pressing again unpauses).
       q / ESC
            Stop playing and quit.
       + and -
            Adjust audio delay by +/- 0.1 seconds.
       9 and 0
            Decrease/increase volume.
       ( and )
            Adjust audio balance in favor of left/right channel.
       m
            Mute sound.

至于视频播放, 直接使用 smplayer 作为前端界面就ok了.
---------------------------------
2009年2月18日

音频编辑:

mp3splt Audacity

mp3splt 是用于分割 mp3 或者是 ogg 音频的小工具, 毋需重新编码, 直接将流媒体分割开. 毕竟流媒体的强悍之处就在于「流到哪就能播到哪」囧.
譬如下载的 audio-book 如果太大, 可以用这个工具分割. 有终端版本和图形界面版本(基于gtk). 不过用法大同小异, 设置分割的断点就ok.

对于 audacity, 我是彻底的外行, 几乎就没怎么用过 -_-. 喜欢玩音乐抑或是喜欢DIY录音的朋友可能更加清楚. 这里就不班门弄斧了.
同时, 大家伙还可以参考 Ubuntu Studio, 专门为影音制作图像编辑的发烧友定制的开源系统.
---------------------------------
2009年2月25日

如何处理 chm 文件?:
如果你喜爱 firefox 到了无以复加的地步, 那么可以尝试这款插件 CHM Reader.
不过呢, 俺个人还是推荐 xchm. 简单, 易用, 设置字体十足方便快捷. 而且速度有保证. So, 强烈推荐之.
更加偏好 pdf 格式? 一样有办法, 参考这两个链接看看如何将 chm 转换成 pdf 吧 ---
[SOLVED] convert .chm to .pdf file 下方的回复绝对经典, 体现了大众的普遍需求.
How to convert CHM to PDF with chm2pdf in Linux 事无巨细, 详细的 tutorial.
---------------------------------

情人节 - Feynman 给 Arline 的一封信

2009-02-14T19:12:00.018+08:00

Arline 是 Feynman 的第一任妻子, 是他高中时的 sweetheart. 这是他给她的一封信, 写于1946年, 10月17号, 后来由他的女儿公之于众.
Arline 因为肺结核病, 在1945年6月16号去了另一个世界. 身边坐着 Feynman, 还有七年前他送给她的一台数字钟.

那台数字钟很精巧, 但是质量不怎么样, 毕竟那是上个世纪三四十年代. 每隔一段时间, 准确的说是每个周末, Feynman 都会偷偷从曼哈顿工程的研究基地溜出来, 驾驶一辆他的室友(后来被发现是名间谍)的汽车前往 Arline 所在的医院探望她, 顺便修理一下那台数字钟.

D'Arline,

I adore you, sweetheart ... It is such a terribly long time since I last wrote to you — almost two years but I know you'll excuse me because you understand how I am, stubborn and realistic; and I thought there was no sense to writing. But now I know my darling wife that it is right to do what I have delayed in doing, and what I have done so much in the past. I want to tell you I love you.

I find it hard to understand in my mind what it means to love you after you are dead — but I still want to comfort and take care of you — and I want you to love me and care for me. I want to have problems to discuss with you — I want to do little projects with you. I never thought until just now that we can do that. What should we do. We started to learn to make clothes together — or learn Chinese — or getting a movie projector.

Can't I do something now? No. I am alone without you and you were the "idea-woman" and general instigator of all our wild adventures. When you were sick you worried because you could not give me something that you wanted to and thought I needed. You needn't have worried.

Just as I told you then there was no real need because I loved you in so many ways so much. And now it is clearly even more true — you can give me nothing now yet I love you so that you stand in my way of loving anyone else — but I want to stand there.

I'll bet that you are surprised that I don't even have a girlfriend after two years. But you can't help it, darling, nor can I — I don't understand it, for I have met many girls ... and I don't want to remain alone — but in two or three meetings they all seem ashes. You only are left to me. You are real.

My darling wife, I do adore you. I love my wife. My wife is dead,

Rich.

PS Please excuse my not mailing this — but I don't know your new address.

不知道这张照片中, 他们俩是否已经结婚.

这张照片应该是他们结婚当日所拍摄. 那时候, Arline 已经病得较重, Feynman 正要参与曼哈顿计划. Feynman 的母亲因为 Arline 患有肺结核病, 坚决的反对他们的婚礼. 而他, 因为母亲的冷酷, 一生对此都耿耿于怀.

他们立刻明白, 我不想整日沉埋在哀伤里. 很明显, 我对自己做了心理建设: 正视现实是那么重要 --- 我必须慢慢理清发生在阿琳身上的是怎么一回事 --- 以至于在好几个月之后才哭出来. 那时我在橡树林, 刚巧路过一家百货公司, 看到橱窗内的洋装, 我想阿琳一定会喜欢其中一件, 就怎么也按耐不住了. --- 摘自<别闹了, 费曼先生>

Feynman 先生不知道 Arline 的「新地址」, 想必现在肯定已经找到了吧. Happy Valentine's Day.

如何使用 vimperator 更好的折腾 firefox

2009-02-11T23:54:00.028+08:00

我并不是某一款编辑器的粉丝, 所以并不是由于 vim 多么好用多么强大, 而使用 vimperator 这款 vim-operation-style 扩展插件. 事情的起因是, 我想要手不离键盘, 直接进行 keyboard navigation, 就能够访问任何页面上的任何一个链接, 而不是用鼠标点来点去.

这里权且当作是备忘记载吧 ---

#1 估计这条发在 mozillazine 上的帖子, 应该是互联网上最早提出需要在 firefox 中使用 numbered links 浏览页面的帖子了(我是不是很适合做互联网考古学家?): Request / idea: keyboard navigation via numbered links • mozillaZine Forums

#2 发布这条 post 的人 --- Bill Bellon --- 是一名 Space Science and Engineering Center 的雇员. 通过和他邮件联系, 找到了一款完全能够满足 numbered links 需求的插件 hah (现在这款插件已经不能继续使用, 但是其分支 LoL 被很好的维护着, 有兴趣的朋友可以下载), 并不需要 vimperator 这么复杂的东西. -_- 可惜在得知这插件前, 我已经决定使用 vimperator 了. 因为我发现 vimp 确实是能够提高效率 --- 较为复杂的操作能够让人精神更加集中.

---------------------------------

关于 vimperator:

#1 官方站点: Vimperator – vimperator labs

#2 在 linux.com 上一篇很好的 tutorial 文章: Linux.com :: How to control Firefox using Vim keybindings, 版本可能老了些, 但是依然很有参考价值.

#3 需要最权威的参考, 安装插件后 :help 抑或是 F1, 查看官方帮助.

#4 如何使用 javascript 隔离来消除 vimp 中恼人的 beep 声 --- How to really disable the bell in Vimperator, 因为对于我们这种已经对 firefox 的快捷键了如指掌的人来说, 如果你按下 C^t 依然会打开一个新tab但是会发出一声嘟, 你肯定不爽. 此文就是你需要的.
简单点说, 就是在 ~/.vimperatorrc 中输入如下代码:
javascript liberator.beep = function() { return false; }

#5 vimp 对很多原先的快捷键, 譬如 C^c, C^v, C^x 都做了映射修改, 很不方便. 譬如粘贴需要 C^v C^v, 第一次是进入 pass-through 模式, 第二次才是粘贴. 参考 How do I use C^c, C^v for copy and paste? 调整之.

#6 yank 文本的使用方法 --- [Vimperator] how to yank text inside webpage.

#7 如何使用 firefox 的智能地址栏 --- Bug 19189 – Option to enable AwesomeBar on "o" and "t".. 这款插件的初始创造者 Martin 给出了答案, 在 ~/.vimperatorrc 中输入如下代码就ok了:
set wildoptions=auto
:set cpt=l

#8  delicious 美味书签的用户, 需要修改 bookmark sidebar 的快捷键, 譬如我设置成了 Ctrl+Shift+O, 重启 firefox 就ok了. 如果想要直接在 vimp 中搜索 delicious, 参考 vimperator用のdeliciousのBookmarkをインクリメンタルサーチできるプラグイン書いた！ver2 - cimada-ism.

#9 自定义编辑器. 在 Insert 模式下, C^i 就能够激活之. 默认的编辑器参数是 gvim -f, 你可以将其修改为 gedit 或者是其他你得心应手的编辑器.

ps.
我发现似乎在日本 vimp 很流行, 大量页面都是日文的. 是不是日本的朋友们使用 linux 和 vim 的有不少呢?
ps1.
vimperator 和 google 的产品兼容性貌似很差.. -_-
这里有众多的 vimp 插件, Vimperator Plugins in CodeRepos, 又是日语的.

- EOF -

情人节 *nix 1234567890

2009-02-10T16:08:00.019+08:00

真是一个令人兴奋的消息.
今年情人节, 也就是北京时间上午 07:31:30, *nix 系统的时间戳会成为 1234567890.
可惜是单身, 又没有表白对象. 不然今年的情人节一定是咱们这类喜爱 *nix 滴同学滴「黄道吉日」.
关于unix时间戳的概念, 参考 wikipedia. 简单点说就是 *nix 系统使用了一个数值, 而非 human readable format, 来保存当前系统的时间. 这个数值我们姑且叫做 time stamp 时间戳.

豆瓣活动页面在此.
用浏览器体验 javascript 倒计时效果更佳. 这个站点将任意时间戳转换成可读时间.
抑或是使用unix中最古老的C语言, 写就之 ---

#include <stdio.h>
#include <time.h>
#include <stdlib.h>

int main()
{
    time_t unique_tm_stamp = 1234567890;

    printf("前无古人后无来者的"
           "unix时间戳\n"

           "***********************\n"
           "1234567890\n"
           "***********************\n"
           "就将在这个时刻诞生\n"
           "北京时间 %s",\
           asctime(localtime(&unique_tm_stamp)));

    exit(EXIT_SUCCESS);
}

ps.
貌似显得有些无聊, 又没有 GF, 浪费这个时间写blog作甚... 囧

微软精巧型键盘 keycode 映射修改

2009-02-09T23:51:00.016+08:00

不知道为何, 刚才将万恶的 ati 显卡的 fglrx 驱动升级了, 结果俺「微软精巧型」键盘的映射居然全乱了. -_-
参考此文 Multimediakeys with .Xmodmap HOWTO 修改, 讲得应该是很清晰了.
这里将微软精巧型键盘的 Xmodmap 文件贴出来, 如果你恰好也是这款键盘, 恰好也碰到了映射错误的问题, 应该可以直接使用之, 毕竟相同键盘的 keycode 值都是内嵌一致的.

这里只有小箭头, 删除插入, 起始结束, 上页下页, Super_L Win 标志, 右 Ctrl, 小键盘回车键(小键盘 keypad 需要两个定义, 一个是按下数字锁定前的映射值, 一个是按下数字锁定后的映射值, 这里统一都是映射成 KP_Enter).
其他键值没有添加, 因为俺这里都能够正常识别. 囧

关于如何配置修改, 激活, 自启动激活, 直接参考上面的链接就ok, 这里就不再赘述了.
需要更多信息, 输入以下命令参考 manual 手册 man xmodmap.
查看标准键值的名称, 譬如 Up Down 之类的, 参考 /usr/include/X11/keysymdef.h 头文件中的核心键盘值部分和keypad小键盘部分.

$ vim ~/.Xmodmap
---------------------------------

keycode 113 = Left
keycode 114 = Right
keycode 111 = Up
keycode 116 = Down

keycode 112 = Prior
keycode 117 = Next
keycode 110 = Home
keycode 115 = End
keycode 118 = Insert
keycode 119 = Delete

keycode 104 = KP_Enter KP_Enter
keycode 105 = Control_R
keycode 133 = Super_L

透过八卦看人生

2009-02-08T15:39:00.024+08:00

每个人背后都有一个不大不小的故事. 这篇「简短」的八卦文章, 是今天八卦搜索两小时的战果之总结. 囧
尽管俺对 cpp 并不了解多少, 但是曾经买过一本C++高级编程, 原版名称 Professional C++. 本文的八卦就是关于此书的两位作者, 以及若干相关人士.

> Scott Kleper 是本书封面中站在左边, 身高稍矮的那个家伙. blog地址在这里. 简要的介绍可以在其blog中找到.

While I was finishing up my Masters, I started working full-time at Bluedog as employee number 5 and leader of the now-legendary SHAG group. After Bluedog, I joined Reactivity, which was a combination incubator and consulting company. I worked for a year on the project that became Raplix/CenterRun and later got bought out by Sun Microsystems. Then I rejoined Reactivity proper, which turned into an enterprise software/security company, and was (much) later bought by Cisco. I was the lead engineer on the UI for Reactivity’s web services security product. At some point in all of this, I co-authored Professional C++ along with my friend Nick Solter. In December 2004, I left Reactivity to join 3D Marketing Technologies (now called M-Factor). 3D makes software that helps companies plan marketing initiatives.

在斯坦福大学拿到了计算机科学的学士和硕士学位. 后来在多个公司担任过重要的开发职位. 从经历上可以看到, 跳槽较为频繁囧. 而且各个公司所涉及的领域也区别较大.
后来他离开了 M-Factor, 在斯坦福做了一段时间的教学工作, 继而开设了自己的公司, Context Optional.

I left M-Factor late in 2005 for a part-time teaching gig at Stanford and to start something on my own. SpotDJ was officially started in January of 2006. The company was founded by myself and Kevin Barenblat, and we were soon joined by Grant Goodale. We do social music stuff — you can read about it here.

可见主攻的领域是 Social Music. SpotDJ 就是其推出的一款社会化软件, 简单点说, 就是在 playlist 的音乐之间插入自己的intro, 好比是电台DJ在音乐播放的间隙间介绍一样.
更多的可以去 SpotDJ 站点上查看, 可惜的貌似已经不再有效, 点击 Create 后收到的只是如下提示 --- SpotDJ is no longer a supported product. We suggest checking out your local record store.

Klep同学是一个帅哥级别的人物, 可惜的是... 经过了这么多的岁月, 早已变得是... 真可谓是今非昔比. 大家伙自己看吧, 最左边那位双下巴如此突出的小胖就是 Klep, 中间是他老婆 Marni, 最右边是他昔日的大学同学. 估计是这位宅男长期不运动导致过于发福的结果. -_-
何以见得其宅男身份? 查看这篇post似乎就可窥见端倪.

> 再来看看右边那位, Nicholas Solter. 也是斯坦福大学计算机科学的学士和硕士.
目前是在 Sun 工作, blog在这里. 介绍可以在 OpenSolaris World Tour Speaker 页面中找到.

Nicholas Solter is the technical lead of the Solaris Cluster open-sourcing effort and the facilitator of the HA Clusters community on OpenSolaris. His Solaris Cluster development work over the past 6 1/2 years at Sun Microsystems has included designing and implementing support for Solaris features such as SMF and zones. He holds BS and MS degrees in computer science from Stanford University, and is the author of “Professional C++” (Wrox, 2005).

这两位在工作选择上的性格, 貌似较为迥异.
后者更加稳固, 在 Sun 已经工作了 6.5 年, 目前是 Solaris Cluster 的技术总监. 而且估计还会工作相当长的时间.
刚和另外两位作者一起合作写了本书, OpenSolaris Bible. 是第一本关于 OpenSolaris 的专著. 大家可以注意到, 这篇post的下方就有 Klep 同学的发言. Klep 还透露其在 Context Optional 公司里使用的就是 OpenSolaris 系统.

这本书的定位很广泛 ---

If you’re interested in OpenSolaris, whether you’re a novice or an experienced user or admin, this book should have something for you. The only prerequisite is some experience with UNIX or Linux; and at close to 1000 pages, we’re able to cover both the basics and many advanced topics. The detailed table of contents (note: PDF link) and index (also PDF link) on the book web site give an idea of the topics and scope of the book.

Solter 的妻子刚开始了自己的公司, 是一家帮助小孩子学习音乐, 或者更加准确的说, 对幼儿进行音乐启蒙教育的公司. 感觉这家公司真的是很有爱. 囧转换话题说一下, 这种公司在国内有没有市场? 肯定有市场, 而且估计还不小, 因为毕竟亲子活动是循序渐进的. 啥时候可以关注一下.

附上Professional C++的世界各地之版本的照片 ---

> 真正的八卦开始了..

以上, 都是正儿八经的介绍. 下方, 就是「延伸」内容了.

大家请猛烈点击这个链接查看初始八卦post. 作者的介绍摘要如下 ---

It’s a (terribly-blurry) photo of Adam Nash, me, Michael Schroepfer, and Scott Kleper in 1997 when we met Woz as interns at Apple. Nash is now Director of Products at LinkedIn, Schrep just (today) left his position as VP Engineering at Mozilla to join Facebook as Director of Engineering, and Klep is CTO at Context Optional, Inc. What’s especially interesting is that all three of them ended up at social networking companies. I guess it’s the next big thing, eh?

这是一群当年在 Apple 实习的同学, 与他们「教练」的合照. 而这里的八卦, 就是围绕这几位同学展开, 从左到右 ---

第一位 Nash 同学. 是 ebay 的一名产品经理. 在2005年刚过了自己的30岁生日. 这个链接里有大量生日 party 上的照片, 各位有兴趣可以瞅瞅. 前面的 Klep 同学超级发福照, 就是在这链接里无意看到的.

第二位 Eric 同学. 目前担任一名职业摄影师, 拍摄了大量水下图片. 堪称经典. Eric 似乎很喜欢黑色的背景色, 不仅仅blog背景色是黑色, 甚至画脑图也是如此.

在 Eric 的这个链接上, 可以看到其对 Nash 同学的介绍 --- Has had skits composed at HBS about his creative hand movements, can talk for hours on end, likes gorillas, and is recently married! Is supposed to take over the world, now that he's done with business school. 囧

第三位. 还需要说么? Apple 公司的两位创始人之一.

第四位. 大家伙能够认出来么? Mike Schroepfer. 看看这篇 Nash 同学写的博文吧, 下方还有 Eric 同学的留言. 前firefox技术总监, 现在加盟了facebook. 被 PC-world 于2007年评选为互联网上的50个重要人物中的40th.

第五位就是 Klep 同学了. 前面已经提到, 最近开发的 SpotDJ 这款社区音乐类软件, 就是主要运行在 facebook 上, 不过似乎已经停止开发.

---------------------------------

这几位同学的生涯轨迹, 可谓涵盖面很广 --- 有最终选择了商学院, 继而做产品经理的同学; 有涉足摄影行业, 喜爱潜水的业余「旅行家」; 有社会化软件行业的 professional, 做架构抑或做应用; 也有操作系统以及网络架构领域的 professional...

性格迥异的朋友们, 11年前曾经一起在 Apple 跟随 Wozniak 实习 (除了 Solter 外), 10年后, 经历了多少人生的选择, 多少跌宕起伏, 而且还会继续下去. 彼此都有了自己的家庭 (不过貌似 Eric 同学还是单身), 有了自己的孩子 (Solter 的孩子都已经5岁了). 让我这个事外之人都感慨不已.

祝他们的爱情和事业都一路好运.

ps1.

上面的照片中, Solter 的孩子在玩的, 是一款宠物驯养游戏 webkinz. 貌似他驯养的是一只白天鹅? 囧

这个站点的 introduction 在这里. 确实很适合小孩子玩. 不仅仅可以自己驯养宠物, 参与答题(区分有各个年龄段)获取宠物币, 还可以邀请朋友一起聊天(是直接选择词语, 进行组合, 貌似不允许自己输入, 主要是方便监管囧), 参与朋友之间的「竞赛」, 或者是挑战一些「任务」.

国外的此类 kids game 网站都做的非常好.

重视和小孩子父母的沟通, 譬如这里, boy 和 friend 这两个词汇都是可以在聊天中出现的, 但是 boy friend 是要被过滤的. 可见对内容监管的重视程度. 就算是在我天朝的蜘蛛网环境下, 这样的站点也绝对不可能被河蟹.

有明确的盈利方式一, 电子虚拟商城, 而且指明了18+用户才能网上支付, 如果是未成年人, 那么就要由父母来完成网上支付; 以及盈利方式二, 需要购买一个实体娃娃, 得到序列号来登录webkinz, 序列号有效期持续一年, 就好比是某些杀毒软件的年卡.

需要注意的是, 不管是实体娃娃, 还是虚拟商城的商品, 都挺贵.

那么, 究竟有没有父母愿意掏钱? 有多少父母愿意? 我没有具体搜索, 更没有严密的调查统计, 但是俺相信, 肯定是有的, 而且可能还有不少.

换做是我, 我就会. 为何? 当你仔细浏览这个站点, 就会发现其安全性和对于小孩子而言的体验都做得相当到位, 很令父母放心. 试着想想, 如果一个3岁或者5岁的孩子想要玩 Doom Quake CS, 你会让他或者她玩么? 估计 WOW 我都不会让他玩.. 起码得等到8岁(俺个人很反对孩子早熟化, 不过这趋势貌似也没法完全遏制囧. 还是要看情况, 但是, 不能让孩子过早接触 FPS, 或者是带有恐怖抑或是成年的游戏, 却是必然&必要的). 而 webkinz 上有N多的, 对小孩子而言可玩性不赖的, 甚至带有教育功用的游戏, 如果恰好你的小孩不少朋友都在webkinz上有帐号, 那么为何不花上数十美金, 让孩子玩一玩呢?

ps2. 八卦文章的确很难写, 写作的时间远远超过了八卦搜索的时间...

ps3. 突然想到其实对小孩子而言, guitar hero 吉他英雄这种游戏还是很不赖的, 或者是 PC 机器上酷似 guitar hero 的开源游戏 Frets on Fire (可以跨平台, 在Win linux Mac下运行).

ps4. 如果今后俺儿子或者丫头能够轻松搞定 Frets on Fire 的复杂关卡, 那么他们就比他们的老爸厉害多了. 瓦哈哈哈~ 囧

- EOF -

史上最清新「因特網之歷史」

2009-02-07T18:10:00.018+08:00

这是一段很强悍的视频 --- History of the Internet.
从超级大型机时代开始, 一直说到了当代的网络电话网络银行.
简要的讲述了当年北美和欧洲的若干互联网早期开发机构的历史; 现代互联网通信分组交换机制, package switch, 产生的背景; 稍微涉及了 OSI 架构和后来更加实用的 TCP/IP 协议; 还扯了一下 X.25, 倒腾了一把冷战历史...

这段视频称不上是关于「因特網之歷史」的最清晰的视频, 却必然是最清新的视频 --- 这段视频的背后, 就是某小团队的堪称庞大的计划, PICOL, PIctorial COmmunication Language, 图片化沟通语言. 而这段视频, 就是这计划中诞生的无数「具有明确象征意义的图标」的第一次试水.

PICOL is an project for providing free and open icons for electronic devices.
The aim is to find a common pictorial language for electronic communication.

这项计划的反响, 以及被接受程度, 都还有待观察. 特别是那些繁杂的规约, 几乎可以与 OSI 的复杂和面面俱到相「媲美」. 但是可以肯定的是, 必有一部分可以构成一套不错的 subset, 组成一些不错的事物, 譬如这项计划的博客的模板, 譬如某类技术书籍中的简单标识.
而且个人觉得在普通电子商品的说明书中, 如果不是追求出奇制胜, 这套图标可以简化很多东西. 对于某些追求与众不同的地方, 这类超级图标集合恐怕难以找到太多用武之地.

更多信息, 以及这套图标, 可以从这里获取: http://blog.picol.org/pre-release-picol-icons/
很多人在那里讨论pre-release的缺陷, 如果你有强烈兴趣, 也可以下载好好研究之.

这里举三个例子, 大家伙猜猜这三个图标代表啥意思? ---

ps.
标题之所以使用繁体「因特網之歷史」, 是因为这段放在 youtube 上的视频, 其字幕的中文翻译者是台湾人.
如果谁有兴趣, 可以联系视频的创作者将其翻译成简体中文. 譬如将「網路」转换成「网络」, 「伺服器」转换成「服务器」.
俺开始联系了一次, 那时候还没有中文翻译, 后来又主动联系了一次, 估计那时候已经有了繁体翻译. 再后来就是被告知, 已经有了中文版本的翻译. 可见对于好东西大家伙都是很热心的. 囧
现在貌似不好意思再告诉作者说啥繁体简体之类的了.

赫然发现 google 的所有离线服务原来都如此危险 o_o

2009-02-06T22:47:00.023+08:00

google 的离线服务非常好, 起码大多数时候都是如此.
不过今天在豆瓣的 google 小组中, 碰到一个问题, 我这里摘要一下 ---

　　1. 第一次同步时会自动替我选择同步的时间范围, 那之后同步下来的邮件, 如果超出时间范围的会自动删除以保证硬盘文件容量不变吗? 还是以后就不删了?
　　
　　2. 近期的邮件, 如果我在Online模式时删除了, 会同步从硬盘上的同步文件中删除吗?

　　因为看到C盘正在被无情蚕食中...

由于对于 gears 没有啥研究, 唯一的「接触」也就是第一次 gmail 离线同步失败后, 搜索离线数据的存放目录时, 有一次亲密接触. 所以决定亲自试验下, 毕竟咱折腾, 咱娱乐嘛. 囧何况咱们都是 google 的 fans, 自然希望能够有更多了解.

申请了一个新帐号, jtuki.0x2665@gmail.com, 至于0x2665究竟是啥玩意儿, 您就 google 去吧. 囧
gmail 会对每一个新用户发送一封欢迎邮件 ---

Messages that are easy to find, an inbox that organizes itself, great spam-fighting tools and built-in chat. Sound cool? Welcome to Gmail.

To get started, you may want to:
<XXX 此处省略摘要 XXX>
Thanks,

The Gmail Team

进入 lab 开启 offline 模式, 继而点击之. 等待大约1分钟后, 同步完成. 接下来的任务就是寻找数据究竟存放在哪里.

根据上面的亲密接触的信息, 层层 cd 后来到
~/.mozilla/firefox/q0pvp6rn.default/Google Gears for Firefox/mail.google.com/https_443

查看文件信息

ls -l |less
---------------------------------
total 208
drwx------ 2 jerome jerome   4096 2009-02-06 22:31 GoogleMail[24]#localserver
drwx------ 2 jerome jerome  12288 2009-02-06 22:31 GoogleMail_managed[22]#localserver
drwx------ 2 jerome jerome   4096 2009-02-06 22:29 GoogleMail_managed[23]#localserver
drwx------ 2 jerome jerome   4096 2009-02-02 13:33 icons#desktop
-rw------- 1 jerome jerome   6144 2009-02-06 22:31 jtuki.0x2665@gmail.com-GoogleMail-b#database
-rw------- 1 jerome jerome 157696 2009-02-06 22:31 jtuki.0x2665@gmail.com-GoogleMail#database
-rw------- 1 jerome jerome  13312 2009-02-06 22:31 jtuki.0x2665@gmail.com-GoogleMail-t#database
---------------------------------

可以发现其中几个很显眼的字眼, database, 而且一个文件, jtuki.0x2665@gmail.com-GoogleMail#databas 的体积比另外几个含有database字眼的文件要大不少, 莫非数据就是存放在这里?

为了先稍加验证, 重新开了一个terminal, 进入 ~/.mozilla/firefox/q0pvp6rn.default/Google Gears for Firefox/docs.google.com/https_443 , 也就是 google-docs 的数据存放基地, 查看文件信息

ls -l |less
---------------------------------
total 23144
drwx------ 2 jerome jerome     4096 2009-02-06 16:22 DocImg[14]#localserver
drwx------ 2 jerome jerome    12288 2009-02-05 12:03 Doclist_managed[11]#localserver
drwx------ 2 jerome jerome     4096 2009-02-05 12:03 Doclist_managed[12]#localserver
drwx------ 2 jerome jerome     4096 2009-02-05 12:03 Documents_managed[7]#localserver
drwx------ 2 jerome jerome     4096 2009-01-30 19:13 icons#desktop
-rw------- 1 jerome jerome   270336 2009-02-06 22:22 jerome.rivest.long@gmail.com-Doclist#database
-rw------- 1 jerome jerome 22886400 2009-02-06 22:40 jerome.rivest.long@gmail.com-Documents#database
-rw------- 1 jerome jerome     8192 2009-02-06 11:51 jerome.rivest.long@gmail.com-Logging#database
-rw------- 1 jerome jerome   449536 2009-02-06 10:38 jerome.rivest.long@gmail.com-Presentations#database
drwx------ 2 jerome jerome     4096 2009-02-05 12:03 Presentations_managed[8]#localserver
drwx------ 2 jerome jerome    12288 2009-01-30 19:23 PresImg[13]#localserver
---------------------------------

果然, 相同类型的 jerome.rivest.long@gmail.com-Documents#database 的体积已经非其他database文件所能比拟.
初步估计就是此文件.

不过这些也没啥. 关键是咱们的数据怎么保存的呢? 用文本编辑器打开 gmail 的那个瞅了瞅, 居然发现了明文信息, 顿时冷汗就出来了.. 明文! 没有任何加密..
莫非 gears 没有任何数据保密措施么?..

不妨测试一下:

---------------------------------
$ grep "Messages that are easy to find" ./*
Binary file ./jtuki.0x2665@gmail.com-GoogleMail#database matches
---------------------------------

-_- 真的很吃惊.

那么 docs 文档又是如何呢?
在一篇 doc 文档中挑选了一句测试:

---------------------------------
$ grep "The usual arithmetic conversions" ./*
Binary file ./jerome.rivest.long@gmail.com-Documents#database matches
---------------------------------

更加惊讶, 原来都是明文保存的, 只不过是加上了众多 tag 罢了.

再次回到 gmail offline 的话题, 如果在线删除了 gmail 中的邮件, 再次同步后, 本地会删除么? 就好比 IMAP 邮件存取协议一样, 支持本地和在线同步更新? 测试结果是, no.
换句话说, 在线删除了的文档, 本地依然被保存着, 而且还是明文形式.

So --- 如果不是家庭电脑, 如果 gears 的这个问题总是存在, 如果你身边有一个喜欢偷窥你信息, 而且懂得如何偷窥的人, 如果你的很多信息较为 private, 不希望被他人看到, 那么 --- 您还是关闭 gears 吧. 囧

ps. 当然, 对于大多数, 譬如俺, 就可以坦然的使用啦. 除非, 是在公用电脑上.

update: 2009年2月6日
刚才搜索了一把, 这里提供几个非常有价值的链接:
> http://markmail.org/message/x54ucaczxtfrmaz6 --- 信息爆料: gears 团队已经考虑到了这个信息加密的问题, 只是还没人开始做囧. 可以有多种办法实现手动加密, 譬如firefox插件, 又譬如 Tara Kelly 的回复(说不定今后很可能被直接整合进入gears).
> http://www.insideria.com/2009/01/google-gearsa-great-tool-to-en.html --- 摘要一段

Gears provides no security of data stored locally, so it is entirely up to the programmer to not store any sensitive data on a local store. Currently, offline data encryption/decryption is completely under the control of the local machine, and any user with access to that machine could conceivably access the data.

同时, 各位也可以看到, 使用gears的服务还真是不少. 囧还有不少好信息, 大家就去 google 搜索结果上翻吧.

- EOF -

doubanclaimeda46969f2e0a2a3

2009-02-06T22:46:00.001+08:00

豆瓣博客认领. again. -_-

外行看热闹

2009-01-29T15:01:00.007+08:00

当初 LHC 开始运行时的媒体盛况, 估计每个人都还记忆犹新.
谁知由于某些故障, 不得不暂停运行, 等到将近一年之后才可重新启动.

最近爆了几条重要新闻, 这里贴出链接, 咱们外行人可以看看热闹. 到时候情况如何, 就另当别论再说咯.
> 由于 LHC 计算过程中的重大错误, 其危险性增加了很多.
> 一种新的模型表示, 微型黑洞持续时间的期望值 ≫ 1 sec. 甚至有可能达到数分钟之巨. 当然, 这并不意味着一定会产生毁灭性的灾难 --- 这种概率不会太大, 但也没有 CERN 所述的那么小.

------------------------
每篇 blog 文章下方的评论总是很精彩, 而且很 informative.
譬如第一条消息下方的评论就表示, 论文中根本就没有提到大面积的「重大计算错误」, 只是小错误罢了, 而且危险性仍旧是微乎其微.

- EOF -

gedit nautilus 咔呲咔呲的硬盘

2009-01-21T13:46:00.025+08:00

每次大规模升级 Ubuntu 都不会让人很舒坦, 这次从 hardy 升级到 intrepid (俺承认这很火星, 人家 9.04 都已经出来了, 我才开始整 8.10 -_-), 结果也是一样.

不过, 差不多每次都可以顺利通过 dpkg-reconfigure 避免繁琐的兼容性配置.
只是这次升级后, 那个最喜欢为难 ati 显卡的 xserver-xorg 抽风了, 居然 dpkg-reconfigure 没法直接配置屏幕分辨率 (个人觉得这个修改做的非常不好), 只能配置一把 keyboard 和 mouse. 而且 X 完全没法打开, 出现的错误一坨一坨的. 最终还是纠结在黑白屏幕, 没有开启 framebuffer 的低分辨率 tty 中. -_-

情形窘迫啊. 幸而我们不仅仅可以升级, 还可以降级, 同样幸而 tty 中可以使用 lynx 文字浏览器 google 查找解决办法, 而且 aptitude 在 tty 下, 简直就和 synaptic 在 X 下一样方便. 在尝试还原 xorg.conf 文件无果后, 在强制删除了若干无关驱动, 以至于键盘鼠标变得没法识别后, 还是选择了最原始的降级. -_-

顺利降级 xserver-xorg 到老版本, 就一切 OK 了.

这个事例告诉我们, 对于 ati 的显卡, 能不升级 xserver-xorg 就尽量别升, 除非你对于 X 的配置特别熟悉, 或者你爱坐过山车, 升升降降, 降降升升.
---------------

升级后的惊喜 --- (我不是直接升级的, 只是修改了 source 之后, 挑选相应的程序包升级, 这估计也是每次升级完毕后总有或多或少的依赖问题的原因)

> nautilus 可以 tab 浏览了.
很久前就知道了 nautilus 的这个改进, 只是现在才升级尝试. 觉着貌似比较鸡肋, 快捷键远没有浏览器的 tab 那样方便.

> nautilus 原来是支持 scripts 和 extension 的.
其实这个不是升级之后才有的功能囧.
是在 help 文档中查找 tab 的说明时意外发现的, 真是相见恨晚. 最喜欢的就是 nautilus-open-terminal 和 nautilus-gksu.
sudo apt-get install nautilus-open-terminal nautilus-gksu 便可安装这两个扩展插件.

> gedit 的速度问题终于得到彻底改善了.
这是最大的惊喜.
例如 linux 内核的 tags 文本文件, 大约是 100M 的样子. 用 vim 打开几乎是瞬间, 而如果用以往的 gedit 版本打开, 那么往往是以在 terminal 中输入 pkill gedit 终结.
这次, gedit 一向被人诟病的速度问题终于被 kill 掉了. :)

资源占用情况还不错, 用 htop 查看进程的资源占用情况如下 --- 第1列和第2列分别是虚拟内存和物理内存占用, 在 gedit 打开 tag 文件之前已经关闭了全部的 gedit 插件.

从第一行跳转到最后一行速度还不赖, 只是需要的缓冲时间比 vim 要长, 但是过了缓冲时间后就相当迅速了.
下面是最后5行的截图.

> 硬盘终于不会咔呲咔呲了.
每当系统变得空闲, 读盘不太频繁时, 俺这硬盘就会咔呲咔呲的叫唤, 让人非常不爽. 不管是 Windows XP SP2/3 还是 Ubuntu, 都是一样.
这次升级了内核到 2.6.27-9-generic, 居然貌似没有这个情况了, 也是另外一个超级惊喜了.

--------------------------------
update 2009年1月23日

由于 gedit 的速度瓶颈得到突破, 这里就推荐若干 gedit 的插件, 也算是做一个记录.

> 对于官方直接附带于 gedit 中的插件, 推荐如下, 插件名称后方分别是推荐星级和简介 ----

Document Statistics

统计文档的字符数量和文字数量.

Snippets

用来添加常用的代码段, 非常强大的小工具. 如果你有整理自己的代码模板的习惯, snippets 绝对是你不可错过的选择.

Spell Checker

拼写检查.

External Tools

使用自定义快捷键, 来执行自定义外部脚本. 这是将 gedit 推向一个综合 ide 平台的重量级工具.

> 第三方开发插件有很多, 满足各种各样不同的需要.
但是插件的质量也是鱼龙混杂, 特别是对于完成相同功能的插件, 往往要对比好几次, 才能找出其中更优秀的那个. 这里稍微推荐两款 ----

Word Completion

对于当前 gedit 进程下的所有文档中的所有 word 都进行索引, 在你输入时即时显示候选词汇. 对 gedit 运行速度的影响几乎没有. 用 python 开发完成. 强烈推荐.

Symbol Browser

如果你使用 vim, 那么你肯定会使用 ctags 和 taglist , gedit 也可以实现根据 tag 索引来浏览代码, 而你所需要的就是安装这款插件.
如果你是非 Ubuntu 用户, 可能不得不自己编译, 那么需要参考这篇文章将代码和 gedit 原生代码混合在一起编译才行 (如果没法打开文章链接, 点击这里翻墙访问之).
如果你是 Ubuntu 用户, 那么就直接下载相应的二进制插件, 放到 ~/.gnome2/gedit/ 下, tar -xzf gedit-symbol-browser-plugin*.tar.gz 解压缩就可以了.

Enjoy yourself with the brand new gedit. :)

- EOF -

胡同学的 Dedicated to *

2009-01-18T16:59:00.011+08:00

此篇 blog 绝对属于八卦, 彻头彻尾的八卦 (今天下午歪打正着, 继而再接再厉, 一共半小时左右的成果). 而且我现在还有些担心是否会触犯某些人的隐私权. 如果回答是 YES, 请您立马提醒我, 保证立即删除之. -__-

按照时间顺序表述之 ---

0> 由于喜欢<谷歌-金山词霸>, 所以考虑是否有办法将 Google 的网络词典搬到 Stardict (linux中最流行, 也是最好用的一款字典软件) 中来.

1> 搜索到了一个链接. 原本是个没什么用的链接, 熟料下方的某个评论爆了一个猛料. 八卦神经立刻被触碰, 于是想要弄明白究竟是怎么回事. -_- (俺承认这样确实很八卦.. 太八卦了..)

2> 轻松找到了 Stardict 的原作者 (胡正同学) 的个人站点. 猛一看, 都可以知道确实有点教主色彩.. 我这里所说的教主, 不同于豆瓣团队中行事低调, 感情上略带「闷骚」(百分百褒义, absolutely -_-) 的 zsp 教主.
具体原因, 各位有兴趣的同学可以下载 <我的世界之源代码> 在第1页查看原委 --- 也就是出版社的名称.

3> 在胡同学的个人首页的「合作伙伴」中, 轻松找到了「hwj的blog」的链接名 (做了化名处理, 有八卦爱好的同学, 可根据我上面提供的多个链接, 寻找蛛丝马迹得到答案. 而且这个链接本身也就和其他链接不一样, 几乎一眼就可看出来, 想必胡同学也是很希望大家伙看到 -_-).

4> 如果你理解了上述「而且这个链接本身也就和其他链接不一样」, 那么想必你一定点击开了那个与众不同的链接. :) 我在这里废话一句, 有点神似咱们寝室某男生的 GF..

5> 此人究竟何方神圣? 和胡同学究竟是何关系? (我所感兴趣的, 也就是到达「是何关系」这个层面)
继续八卦, 前面提到的某个 pdf 材料 <我的世界之源代码> 确实给了我一个轻而易举八卦线索. -_-
各位有兴趣自己翻吧, 两个重要的页面是 219 和 69.

总之, 有点无语. 相比当年在 Spybot 的 license 文件中看到的 dedicated to the most wonderful girl on earth , 胡同学的这种对待感情的极为不成熟的行为, sigh, 不多评论了. -_-

ps.

尽管胡同学在感情问题上的处理太值得商榷, 但是 Stardict 还是一款很优秀的软件. :)

对于一开始的那个想法, 似乎没有办法完全照搬. 涉及到解析并且综合多个 query 结果的工作, 而且说实话, 我貌似还没弄清楚, 它究竟是从哪些站点搜罗信息. -_-
如果退而求其次, 可以将爱词霸的 firefox 搜索插件添加到 firefox 右上角的搜索引擎中, 也还是挺不错的. 相比那些固定XX数量词汇的词典, 这种 wiki 类型的, 甚至借力于搜索引擎的在线词典, 确实够海量词汇.

最后提供两个关于 homeboy 的好玩链接, 也就是这个家伙 (照片上居然还有红眼 -_-) 的这件衬衫.

- EOF -

未来一个月

2009-01-12T19:49:00.015+08:00

原本一个很平常的寒假, 逐渐被我的懒惰和拖沓变成了某个人生十字路口的最后一小段路 --- 另一段新的路途就要启程了. :)
考研结束. 也确实是结束了. 就和当初考完了 GRE 一样. 简直是如出一辙, 不管是经历还是结果.

还是随意先说一说考研吧 --- (按照考试时间从前往后排列)

1> 政治考试.

如果你和我一样, 就花了一天时间复习, 那么也还是有通过的希望的. 反正咱们对于政治的期望值都是, 60. (抑或是55? 貌似及格就是55.) 而且每年政治普遍得分的方差也不大, 不论是花了一个月每天狂背的同学, 还是就花了最后三天, 随意浏览了篡改后的辩证唯物主义和历史唯物主义的马哲, 快速翻阅了马经, 胡乱参考了毛概邓论的同学, 抑或是我这种花了一天就翻阅了马哲, 其他部分纯属瞎掰的有95%概率挂科的 loser.
总体上, 题目不难, 顺利通过应该问题不大.
对于50分的选择题, 务必保证正确率. 这也是挂科的同学最可能丢分的地方. (例如我, 选择题就丢掉了22分 -_-)
至于主观题, 到时候多看看题干中的材料, 然后分析分析就可以作答了. 不过至于得分高低, 就要看你的语言表达准确率, 专业词汇的使用, 还有字体是否不碍眼了. 千万别相信什么押题之类的东西. 一群依靠考研养活自己的所谓 expert 罢了. sigh...

2> 英语考试.

最他妈的变态. :(
文章不难. 如果你词汇量还成, 应该没什么问题. 不过如果词汇量太小, 那么还是推荐你赶紧找本英文原版, 边查辞典边阅读之. (俺说的原版不是指很多同学喜欢在地摊上购买的英文原版小说, 个人觉得看英文小说对咱们这种母语是中文的人来说太.. -_-) 个人觉得最好的办法就是看自己本专业的原版书, 或者是尽量多阅读各种文档(如果是文科专业, 就多看一些原版的普通本科经济学教材), 其次就是各种新闻类型的英文站点.
不过只是个人意见罢了, 每个人的思维习惯都不太一样, 还是要看自己的喜好.

那么为何变态? 选项设置. 简直是他妈的脑残选项. 原因如下 ---

--- 你把文章都看懂了, 一瞟选项, 发现居然似乎4个里面有3个貌似都说得通.
譬如就说阅读的第一篇的第五题. 我选择的是 D, 其实我觉得 D 和 A 都是说得通的, 最后感觉 relaxing mind 还有可能导致松弛, 所以就选择了好奇心 curiosity. 谁知道答案就是 A. :(

--- 这样的题目也就罢了, RP问题, 对出题者的思路把握不够. 可气是什么呢? 有的题目答案非常明显, 居然还是会错.
譬如还是第一篇, 第三题. 问你文章中出现的一个单词 rut 是什么意思. 我选择的是 A. 很明显, 本来 rut 就是<刻痕车辙>的意思, 更何况文章前面和后面还有原词(track)或者是近义词(road)的重现, 这里也很明显是一种 metaphor --- 将人的习惯比喻成大脑中的一道道难以抹去的车辙印迹.
他妈的答案居然选 C, characteristics, 特性特点. 我靠. 我真是怀疑出题的人有没有查字典.

这样的例子数不胜数, 譬如第四篇阅读, 强烈推荐大家看一看, 关于新英格兰的一坨清教徒. 文章看了一遍, 觉得没啥问题. 结果看了题, 立马傻眼了. 这哪里叫做选项, 简直叫做赌博, 还不如每人进考场前发一枚筛子. 管你他妈的能不能看得懂文章, 直接投掷筛子决定答案得了, 反正都一样.
5个里面错了三个, 36 38 39, 也恰好就是三个需要碰运气的题, 而且还是我经过层层分析仔细考量后确定的答案(F***). 答案在这里. 有兴趣大家按住 Ctrl 后猛锤鼠标左键打开链接, 围观之.

那么如何搞定考研英语考试?
首先要明确, 你要搞定的是他妈的「考研」英语, 不是英语. 哪怕你经历了 GRE 的洗礼, 考研英语一样有可能不理想.
扩大词汇, 好歹能够投掷筛子的时候发现那些绝对错误的答案. 至于剩下的, 直接做些往年的试题, 发现脑残背后隐藏的规律, 应该就 OK 了. (我这次最失败的地方就是一道题都没做, 直接就裸考去了, 和当年 GRE 的情况一样. 尽管那时候上了一回新东方, 专门给你讲笑话的 GRE 培训班, 也还是做了一些题. GRE 没考好的原因主要还是词汇量不够大)

3> 数学考试.

四门考试中最让我沮丧的一门.
题目不难, 都是基础题 (别问为什么是基础题, 依然会让我这么沮丧).
不要购买什么数学复习全书, 如果你基础还成, 看两个星期的书, 然后买一套往年的真题, 做一做就没事了.

微积分部分. 难度大概就是一般工科学生使用的<微积分>上下册中的总习题难度.
关键是考察解题的速度, 和对基本定理的理解.

线性代数部分. 简直没难度. 如果你使用的是清华大学出版社居余马的教材, 那么只需要看懂每一章的基础部分, 把整个框架理解清楚, 就基本上没事了. (顺便说下这教材. 相当不错. 当年大一的时候没有感觉到, 现在重新阅读的时候感觉到了. 写作上环环紧扣, 有的例题就是为了后面部分埋伏笔, 习题设置也是很用心. 如果有时间, 推荐看下这本教材的<应用问题>章节, 相当不错) 如果你使用的是同济大学的教材, 那么还是推荐换掉吧.

概率论部分. 如果说线性代数部分还是有些难度, 那么今年的概率论真的是没难度了. 我用的是浙江大学出版社的教材, <概率论与数理统计>.
这门最抽象的课程, 由于是作为统一数学考试, 所以没有考察工科学生普遍都需要掌握的随机过程部分. 不过这本教材中还是涉及到的.
也正是由于统一数学考试, 所以对于数理统计的部分应该以考察理解为主, 至于什么假设检验, 就没必要考察了.
Fortunately, 那些出题的数学教授们是很清楚这一点的. 相比那些英语出题人的脑残思维.. 唉..

4> 专业课考试.

这场考试最搞笑.
对于专业课程的考察, 各个学校因人而异, 如果报考咱们学校(武汉大学)的信号处理, 通信, 电路, 都是仅仅考察一门信号与系统课程. 我们使用的教材是郑君里的<信号与系统>.
发下的试卷袋比前三门都要小, 而且试卷袋上写着, 业务科. -_-

这门课我考试前的一个晚上才复习完. 一直看书看到了凌晨3点, 睡觉估计快要4点了(而且当天, 也就是为期两天的考研中的第一天, 只睡了大约5小时, 由于复习政治的缘故 -_- 现在想起来真是无地自容).
睡眠的不充足可以说是我数学失利的最大原因, 早晨起来后脑子一片浆糊, 计算分析思考记忆, 各种能力全方位下降, 甚至写字都一塌糊涂, 愣是感觉手上的笔和大脑一起统统罢工, 都不听指挥了.
幸而中午经过调整, 加上心情无比放松(考成这模样, 也无所谓了. 所以心态简直「好」的可怕 -_-), 下午的专业课考的还成. 不过也于事无补了.

--------
总结起来, 大概就是两段话 ---

不遗憾的 -- 身边坐着一个很文静的女生, 笑起来很漂亮(不笑起来其实也很漂亮 -_-), 声音也很好听. 和她一起坐在最后一排, 感觉考试过程整体上还是比较舒坦的. 不过她不是我们学校的(似乎这样会影响复试, 对于本校的学生, 可能更加容易通过复试), 而且似乎数学和专业课都没考好. 最后还是希望她能够考上.

有遗憾的 -- 没考好. 对自己问心有愧.
--------

开年后的2月末就要开始准备找工作了. :)
考研之后的一个月, 必定不能当作普通的寒假来度过了. 我也的确过了太多「寒假」了, 各种各样的「寒假」. sigh...
那些顽固的缺点, 务必要渐渐磨练掉.
就这样吧.

- EOF -

0x00000001

2009-01-12T19:28:00.003+08:00

博客第一篇, 命名为16进制的<1>.
如果哪天此博客文章的数目能够让这个8位的16进制数溢出, 那么肯定是奇迹了. 或者是 blogger 的服务器发生了超级故障.
Altablogs 不得不关闭, 可能是资金来源受到了金融危机的威胁. 这段日子, 小公司或许都不太好过.

重新翻出了 blogspot, 赫然发现原来后台操作已经改进了这么多. 欣然重新驻下.

update -- 2009年1月14日
google 新推出的 blog-converter 非常好的解决了不同博客系统间, 导出的 xml 文件格式不兼容的问题. (原本还准备自己研究一把的, 顺带学习一下正则表达式. 现在又可以「腾出精力」了. -_-)
http://code.google.com/p/google-blog-converters-appengine/
在 README.TXT 中可以找到 appspot 的在线转换地址.
目前仅仅是支持少数 xml 格式导出文件的博客系统, 期待后续更多的功能补充.

原先的博客在这里做了备份.

- EOF -

厨子读兵书 兵家看菜谱

New Blog

Tcl 多线程初步

使用SyntaxHighlighter高亮代码

Coming back

Blog be moved...

Updating Linux kernel to 2.6.30 & Lowing CPU Temperature

Green Dam become famous due to its STUPID

Green DAM is DAMN useless

What a fucking bad luck

Learning Qt or Gtk+, The Good-Practice of Framework

What happened on April 24th?

What is the User Convinence of OS?

Protocols and Platforms

μC/OS-II 研究系列 - 004

μC/OS-II 研究系列 - 003

μC/OS-II 研究系列 - 002

因言获罪

失望

The Google Music Product

μC/OS-II 研究系列 - 001

μC/OS-II 研究系列 - 000

eqo 中国推广之败北

Blackberry 漫谈

三款网络电话服务

分布式 - 并行运算 - 服务器 - 数据库

闭关闭关闭关

果核中的xxx --- 系列读本

恢宏宏的宏 循环双链表结构

增强 blogspot 的编辑体验_@_linux

app_@_linux

情人节 - Feynman 给 Arline 的一封信

如何使用 vimperator 更好的折腾 firefox

情人节 *nix 1234567890

微软精巧型键盘 keycode 映射修改

透过八卦看人生

史上最清新「因特網之歷史」

赫然发现 google 的所有离线服务原来都如此危险 o_o

doubanclaimeda46969f2e0a2a3

外行看热闹

gedit nautilus 咔呲咔呲的硬盘

胡同学的 Dedicated to *

未来一个月

0x00000001

厨子读兵书兵家看菜谱

恢宏宏的宏循环双链表结构