入侵暗时间的元思维

2009/12/20 | 23:49 | 分类:学习随感 | 标签: | 725次阅读

  刘未鹏同志来京工作半年以来,blog 的更新频率有所降低。那次与他交流,他给我的理由是“输入和输出的关系”,毕竟刚刚来到一个比校园复杂得多的工作环境,需要有一定的时间适应这一状态的转变,而这多多少少会影响他的读书计划。不过,更新频率的降低丝毫不影响博文的质量。他今天的这篇《暗时间》又一次激起了我的反思。
  我是大四下学期(2008 年 2 月)开始在现在的实验室工作的。那学期有一个有明确的目标——本科毕业设计,因此在实验室的时间大都花在了毕设课题及其相关的工程任务上。回顾那一阶段的技术笔记,几乎都是围绕着“shell”这个中心。现在对自己当时精心构建的一些 tricks 还记忆犹新。接下来的一年,我进入了研究生一年级的集中教学阶段,小部分时间花在教学楼里用来保证一个良好 GPA,而更多的时间仍在实验室完成组里安排的工程任务。任务的驱动也使我始终保持着对具体项目、技术和实现的思考状态。当然,也有一定的时间花在了琢磨自己折腾出来的那些体现小聪明的东西上。然而真正使我体会到“状态切换”的,是从今年 9 月升入研二以后。全职的实验室工作看上去比研一那种既要应付考试,又要做好工程的状态要专一,但全身心融入科研环境之后,需要个人处理的事情反而更多了。这其中最主要的一点便是需要更多的独立思考。因为自己经过一年多的训练,已经基本了解了实验室的项目情况和工作风格,那种“任务式”的工作逐渐减少,而自主权在慢慢扩大。在完成工程任务之外,老师和师兄只会在大框架上予以指导,而明确的研究方向和具体的实施细节则没有人会告诉你——毕竟我们在向着科研人员的目标迈进。在这种环境下,如果思维畅通、灵感涌现那自然是好事;但有时的思维受阻往往让人偏离对问题本身的思考,转而进入一种“元思维”,即“自己应当思考什么”甚至“自己是否应当思考‘自己应当思考什么’”。对于生活状态相对单一的中科院研究所的学生来说,这种元思维占用的不只是暗时间,很有可能已经是坐在电脑前的“明时间”了。这比浪费暗时间更令人担忧——一方面可能会想:有时间瞎琢磨这些务虚的东西,还不如多读几篇论文、多做几个实验呢;另一方面又会担心:不能把自己变成漫无目的的数据处理机,要想想怎样更加有效地利用时间、服务于自己的发展道路。
  因此,意识到暗时间的宝贵并不难,但用什么样的思维来填充暗时间则是一个因人而异的抉择。我比较相信“机会只偏爱有准备的头脑”,但问题也常常出现在这个“准备”上。对“准备”有不同的诠释,可以得出截然不同的结论。我赞同《把时间当作朋友》开篇对所谓“聪明学生基于投资——收效的时间决策”的批判,相比切切实实的努力,那种功利导向的元思维是无意义的状态切换。但什么才是有意义的元思维?是笑来老师的心智控制观或刘未鹏的元学习理论吗?可能皆有之。但我们需要的,也许是更适合自己实际心智水平的、在务实的事务之间决策的元思维。
  话是这么说,但这种元思维仍然是一个抽象的、空虚的概念。考虑自己每天对暗时间的应用,似乎与思考这一问题的过程本身有“分形”似的相像——在大的状态转移中嵌套着小的状态切换;在低频的思维起伏中包含着高频的意识波动——就差计算一个自相似因子了。意识到这个问题很重要,因为这意味着一种低效。元思维也是一种有输入才有输出的过程,而它的输入应当是其它务实的思维过程及其对应的实践活动。想大脑之所想,及自身之所及,调整元思维在暗时间中所占的比例,或许才是适合自己的一种时间利用方式。

Beijing Open Party,与周奕老师的一面之交

2009/12/13 | 14:57 | 分类:学科活动 | 标签: | 929次阅读

  参加了多次 Beijing Open Party,熟悉的面孔也越来越多。昨天的活动我去得比较晚,到场后发现又一次牛人云集。IT 民工圈、出版界的活跃人士不用多说,还有见识了传说中神侃的 o6z,听其大谈人类社会。这次西乔也贡献了话题,内容不错,可惜听上去没有她的 tweets 那样活灵活现。
  说说最惭愧的一件事:以前与周筠老师在 Gtalk 上聊天时,她就提到过她的弟弟周奕;昨天见到周奕老师并与之短聊之后,我也没有意识到这个周奕就是我中学时就从《大众软件》之类的杂志上有所耳闻的、中国共享软件界先驱人物之一的周奕。这一信息是今天在 twitter 上发现并确认的。其实,周筠老师的 blog 上已经多次提到过她弟弟的传奇,可惜我在浏览别人 blog 的时候,往往只对技术内容有深刻的印象,而人情世故什么的则一带而过,这方面以后一定要警觉一点。周奕老师向我询问了计算所胡伟武研究员和体系结构实验室方面的一些工作,而我却没有抓住机会向牛人请教一二。要知道,我也是周奕老师的成名作品《理德轻松排版》的早期用户(可惜是盗版),作为 Abandonware 收藏者,我手头还有一份能启动但无法正常使用的轻松排版 2.00 的拷贝呢(见截图)。
Beijing Open Party,与周奕老师的一面之交
  历史归历史,人还是要生活在实现中的。周奕老师抓住了共享软件的时代机遇并为之孜孜不怠,而我们要想在信息产业的变革时期有所作为,有必要具备周奕老师那样敏锐的眼光和实干的精神。

Btrfs 测试结果简述

2009/12/09 | 22:32 | 分类:Linux与开源 | 标签: | 1,299次阅读

  Btrfs 凭借着其优良的可伸缩性和诸多有用的特性,有望成为 Linux 下一代文件系统。目前它已被纳入主流内核支持,接受用户的实验性(Experimental)使用。
  今年 2 月 hutuworm 给出了一篇《Ext4 ReiserFS Btrfs 等七种文件系统性能比拼》,他是在 2.6.29-rc3 内核上使用 IOZone 3.318 做的测试。Btrfs 官方 Wiki 也给出了一些第三方测试数据,基于的是 4、5 月份的版本。官方 Wiki 同时指出他们在不断解决这些测试中所发现的问题和瓶颈。这几天我也对 Btrfs 进行了一些测试,并针对某些新特性进行了研究。我的测试基于 2.6.32 内核,使用的工具是 IOZone 3.327,对比对象为 ext3 和 ext4,机器配置为 2 * 4Cores Xeon 2.0G / 8G Memory。从测试结果看,性能方面,Btrfs 在 CPU Cache 区和 Buffer Cahce 区较好,在 Disk I/O 区不如 ext3/ext4(所谓三个区的划分参考 IOZone 文档);可靠性方面,Btrfs 仍有待加强。下面简述我的几条观察(详细数据省略)。

Btrfs 测试结果简述
./iozone -Rab output.xls -g 16G

Btrfs 测试结果简述
./iozone -Rab output.xls -s 16G -r 2M

Btrfs 测试结果简述
tar cf *.tar *; tar jcf *.tar.bz2 *

  性能方面:
  1.CPU Cache 区和 Buffer Cahce 区的 read 吞吐率,Btrfs、ext3、ext4 相差不大。
  2.CPU Cache 区和 Buffer Cahce 区的 write 吞吐率,明显地 Btrfs 优于 ext4 优于 ext3(tar 测试检验了这个结果)。
  3.Disk I/O 区的 read 吞吐率 ext3 占优,write 吞吐率 ext4 占优,而 Btrfs 两方面均劣于 ext3、ext4(与 hutuworm 的结论类似)。
  4.三个文件系统对于小于 CPU Cache 区的小文件,都有“文件或记录过小时读写性能变差”的问题。其负面影响程度 BtrFS 大于 ext4 大于 ext3。
  而可靠性方面,常规的读写校验并没有出现问题,但在测试 Copy on write(COW)特性时,先后遇到两个错误:
  1.最初使用 2.6.31-15 内核测试,出现了克隆文件与原始文件计算 MD5 有可能不一致的问题。开发人员回复说这个 bug 已经在 2.6.32-rc 以后的内核中修复。升级内核后此问题得以解决。
  2.目前使用 2.6.32 内核测试,发现同时读写原始文件和克隆文件,有可能致使 syslogd 出错、文件系统没有响应。现在我还没有得到可靠的答复,但相关回复者基本怀疑是竞态问题。
  有关 Btrfs 其它的高级特性我还没有详细测试。正在使用或打算使用 Btrfs 的朋友,也欢迎与我交流。

在 Dell PowerEdge 1950 上安装 Linux 2.6.32-rc8 内核的问题与解决

2009/12/03 | 19:26 | 分类:Linux与开源 | 标签: | 2,230次阅读

  出于实验和使用 Linux 内核某些新特性的需要,我要在 Dell PowerEdge 1950 服务器上安装最新的内核,而且必须是 2.6.32-rc 以后的版本。由于服务器硬件的特殊性,这一过程费了一番周折,最终在 @Sisyphusliu 师兄的帮助下搞定,记录如下。
  服务器上已安装的操作系统是 CentOS 5.3,软件栈的需求使之不能用别的发行版替代。保守的 RHEL/CentOS 5 系列的软件源上最新的内核是 2.6.18-164,因此只能从 Linux Kernel 官方获得我们所需的内核,自行编译安装。
  在 Kernel.org 下载当前最新的 2.6.32-rc8 内核,将原有内核的 config 文件复制过来,重新 make menuconfig,加入我们需要测试的新特性,然后编译、安装,这一过程顺利。但在系统重启之后,initrd 中的 init 脚本却报出“mount: could not find filesystem '/dev/root'”的错误。看来新内核没有成功挂载本地根文件系统,所以我们仍改用旧内核启动,开始排查原因。
  PowerEdge 1950 服务器安装了 RAID 卡,即使只使用一块硬盘,它也会走 RAID 的 Virtual Drive。因此 RAID 卡成了最大的嫌疑。检查新内核配置,与 RAID 相关的选项都已经选中,编译出来的 modules 目录中也存在诸如 raid456.ko 之类的模块,那么是什么地方有所缺失呢?对比旧内核与新内核的 initrd 中的 init 脚本,发现 raid456.ko 之类并没有在启动时加载;新旧内核不同的地方在于:旧内核加载了 dm-raid45.ko 模块,而新内核则没有。对比两个内核的配置文件,发现 dm-raid45 相关的内容只在旧内核中出现,新内核没有相应的选项,也没有对应的源代码。
  于是我们需要核查 dm-raid45 的身份。google 发现 dm- 系列模块不是 Linux Kernel 官方组件,而是 RedHat 开发的 Device-mapper 模块,是以 patch 方式添加到内核中的。CentOS 5 软件源提供的修改版内核中,已经附带了包含 dm-raid45 在内的 3000 多个 patch,这些在我们下载的标准内核中当然没有。在 dm-raid45 的作者 Heinz Mauelshagen(傻根?)的主页上,提供了 dm-raid45 patch 下载,但均针对的是较旧版本的内核,打在新内核上编译屡屡出错。进一步的 google 使我们惊喜地发现,Mauelshagen 一周之前在 Kernel Patchworkβ 上发布了针对 2.6.32-rc8 的 dm-raid45 patch——尽管他这个 patch 的主要目的是提供一个 xor 算法,但这个版本恰好能为我们实验所使用。下载并运行这个 patch 之后,内核编译通过并生成了 dm-raid45.ko 模块,init 脚本中也自动增加了相应的 insmod 语句。
  然而重新启动系统后,除了多了几句 insmod 的输出,mount 语句照样出错。难道我们找错了原因?这次不猜了,直接深入 initrd 内部分析吧。我们将 initrd 解包,在 /bin 目录中放一个静态编译的 busybox,并在 init 脚本的 mkrootdev 语句(这一语句创建了 /dev/root 节点)之前插入 busybox sh 命令。将这个 initrd 重新打包后重启系统,即可对 initrd 阶段的执行进行调试。调试时,我们发现 initrd 的 /sys/devices 目录下已经出现了一系列 PCI 设备,用 find 查找,其中有一个正是包含了 sda、sda1 等磁盘和分区的节点。看来硬盘是正常工作的。而在 /dev/ 目录下,却没有出现 /dev/sda、/dev/sda1 等设备节点。看来是 mkrootdev 之前的 mkblkdevs 语句没有生效。我们进入 nash,再次执行 mkblkdevs,发现仍然没有效果。于是试图采用 mknod 命令手工建立设备节点。mknod 所需的主、从设备号可以在类似于“/sys/devices/pci0000:00/.../block/sda/sda1/dev”的文件中找到,其语法也可以参考 init 脚本中的其它几条 mknod 语句。在 nash 中手工 mknod 之后,运行 mkrootdev、mount 仍然没能将本地根文件系统挂载。但改用 busybox 中的 mount,挂载则是成功的,可以访问磁盘文件。
  于是我们推测,可能是 CentOS 5 中较旧版本的 mkinitrd 及其包含的 nash 与新版本的内核出现了不兼容。因为使用新版内核的 Fedora 中的 mkinitrd 和 nash 早已进化到了 6.0.X 版,而 CentOS 5 中的还是 5.1.19.6 版。CentOS 5 的软件源上并没有更新版本的 mkinitrd,在分析了 mkinitrd 包的依赖关系之后,我们认为 6.0.X 有太多的、较为关键的依赖项(而 5.1.19.6 版的 nash 是静态编译的单个文件)。贸然使用 Fedora 源更新 mkinitrd 有可能造成较大范围的影响,不利于我们软件栈的稳定移植。我们需要的只是 initrd 中的 nash,因此可以从更容易的途径获得。我们从一台安装了 Fedora 10 的机器中复制出 initrd,将 nash 6.0.71 及其依赖的库覆盖到 CentOS 5 的 initrd 中。使用这个 initrd 启动,调试 mkblkdevs、mkrootdev 和 mount 顺利通过,最终 Linux 成功启动,文件系统访问正常。
  不过仔细观察启动时输出的信息,我们还是发现了两个小问题。一是 init 脚本中 stabilized 语句报错:“Could not detect stabilization, waiting 10 seconds”,经查这是 Fedora 10 上 mkinitrd 的一个 bug,在 switchroot 之后并不影响根文件系统的使用,可以忽略。再者是在执行 /etc/rc.d 下的脚本时,udevd-event 报错:“udevd-event[XXXX]: wait_for_sysfs: waiting for '/sys/devices/pci0000:00/.../ioerr_cnt' failed”。估计这也是旧版工具与新版内核不兼容的问题,udevd 主要用于监听设备的热插拨等事件,在我们的实验环境中一般不会涉及。毕竟这只是一个使用 rc 版内核的实验环境,这个问题暂不予理睬。我们最终需要测试的程序在新版内核上运行通过,效果良好。

更新于 2009-12-06:
  在我们刚刚取得基本成功的时刻,恰逢 Linux 2.6.32 正式版内核发布,要不在正式版内核上也实验一下吧。既然上面是因为升级 nash 而最终成功的,那么 dm-raid45 有可能不是核心问题所在。因此在编译正式版内核时,我们没有加入 dm-raid45,而只替换了 nash 版本。结果一次就启动成功!看来这个问题真是 nash 引起的。至于 dm-raid45,这个机器使用的是硬件 RAID 卡,对操作系统透明,一般不需要内核支持;而 dm-raid45 是软 RAID 模块(感谢网友指正),对我们的系统来说安装不安装无所谓。

更新于 2009-12-07:
  今天 google 到了另一种解决方案:编译内核前,在 .config 中设置“CONFIG_SYSFS_DEPRECATED_V2=y”即可。经我们实验,果然如此。究其原因,google 到的答案[1][2]大约是说旧版的 mkinitrd 及其 nash 在内核没有 CONFIG_SYSFS_DEPRECATED_V2 参数时默认使用旧版 sysfs 路径格式,从而在新内核下无法正确访问 /sys 内的硬盘信息节点。

Abandonware 趣图赏析

2009/11/26 | 00:52 | 分类:IT杂谈 | 标签: | 3,418次阅读

  Abandonware孤儿软件)是一个冷门但有趣的领域。在当前技术日新月异、产品推陈出新的大背景下,适时地回顾一下历史,也许能对现在的工作有一些启发意义。下面展示几张我对一些经典 abandonware 的截图,分享其中的好玩之处,体会软件内外的斗转星移。

  1.用过 UCDOS 6.0 以上版本的朋友都应该记得它当年强调的“特显”、“直接写屏”等功能。据称这样可以做到与显卡无关,提高兼容性,但带来的问题就是在 Windows 9X 下常常会花屏。抛开这个不说,如果两个类似的汉字系统同时写屏是什么效果呢?我们分别启动 GB2312 版的 UCDOS 与 BIG5 版的倚天中文系统,再启动一个 CCED 之类的全屏幕中文程序进行测试。随着键盘、鼠标操作对屏幕的刷新,两个汉字系统抢着写屏,使得屏幕上正确的文字与乱码共存,有超越 CCED 的“密写”功能之势。顺便说一下,我本科时有幸上了 UCDOS 智能拼音作者谭毓安老师的课,拜到了十年前就闻名的牛人。
Abandonware 趣图赏析

  2.Windows 95 中文版的蓝屏(BSOD)是 Windows 系列产品中文蓝屏的绝唱。从 Windows 98 以后,中文版 Windows 的蓝屏都改成英文的了,不再做汉化,这是为什么呢?因为 Windows 95 在实际使用中如果出现了某些严重的错误,会使得中文字库也无法加载,这时中文全变成了没有参考价值的乱码。看来在设计这种“最后的机制”时,一定要做到最小依赖,要给用户提供有效信息,而不要让自身成为系统的拖累。
Abandonware 趣图赏析

  3.Windows 95 中不规范的世界地图。在 Windows 95 的早期 Release 中,“区域设置”的世界地图上的国界标示导致了有领土争端的外国政府抗议(《Windows 编程启示录》中提到过),因此后来的 Release 取消了地图上的国家(时区)颜色标示。但一个新 bug 随之而来:新版地图上竟然没有阿拉伯半岛。我们使用 PE 资源编辑器打开“区域设置”所在的 intl.cpl 文件,其中有一幅标示了颜色的世界地图,包含阿拉伯半岛的。intl.cpl 读取这个资源,将其按海陆两色显示。不知是什么算法出错,导致阿拉伯半岛消失(其实覆盖对比,还有东欧部分地区和台湾岛也不见了)。不知这事当年有没有在中东闹起来,软件中的政治问题举足轻重呵。
Abandonware 趣图赏析

  4.江民的 KV 系列杀毒软件历史久远,在上世纪九十年代中前期,KV200、KV300、KV300+ 系列在 DOS 防毒、杀毒工具中独占鳌头,可谓微机必备。不过在互联网没有普及的时代,病毒库的升级成为一个问题。记得当年一种途径是去软件专卖店拷贝(小城市不可行),一种途径是用 Modem 拨号、超级终端登录到官方 BBS 上下载(长途话费呀),而最廉价的方式则是从《电脑报》、《软件报》上摘抄最新的病毒特征码,手工敲 debug 命令将其汇编到自己的 KV 病毒库中。设想现在哪个软件的升级若要用户编写并编译一堆代码,一定会被揍的。技术的发展使所谓“电脑高手”的门槛越来越低,这应该让人是高兴呢,还是悲哀呢?
Abandonware 趣图赏析

  5.同样令人感慨“沧海桑田”的,还有 CCED 3.3 的帮助文档。当年北京市电话号码还是 7 位,传呼机是流行的通信工具。四环路没有贯通,现在的太平洋电脑城附近当年还是“百货”,图上那几个单位如今尤在?
Abandonware 趣图赏析

  6.续上。从金山最失败的产品——盘古组件中提取的“信息服务”小工具,看看当年最长五位数的电话区号、最长三位数的火车车次。如今电话区号变短了,火车车次却变长了;电话费相对收入降低了,火车票价却不减反增。虽说铁路已经提速好多次了,可又有几次真正惠及了我西北的家乡呢?
Abandonware 趣图赏析

  7.我们再来看看超级兔子。这个软件见证了中国个体软件营销模式的变迁——从简单的免费软件,到知名的共享软件,然后遭殃泡沫经济、转战国外市场,如今 Web 2.0 时代又回归免费,改为以服务为中心的营利模式。我是这个软件在共享时代的正版注册用户,作者蔡旋给还专门向注册用户们透露了软件中的一个彩蛋:查看作者小时候的照片。呵呵,不知道蔡旋自己还记得这件事不?
Abandonware 趣图赏析

  8.不知不觉中,我们谈论的内容已经超出了 Abandonware 的范畴。有些产品并非已无版权,只不过开发者对旧版本不再提供支持而已。这并不影响我们怀旧的兴致。最后一幅图仍然是一个彩蛋,而且估计在那几年学过点计算机的中国人都见过这个彩蛋——Office 2000 附带的隶书、幼园等字体中的“胡万进印”。有多少人还记得暗藏在 Windows 95、98 或 Office 97、2000、XP 中那些好玩的小动画和小游戏呢?软件开发者期待一个展示个性的空间,然而公司对软件质量的苛求又在扼杀这种小聪明。节日礼花和赛车游戏在如今的 Windows 与 Office 中不复存在,不过有趣的是 Google 产品中的彩蛋却始终没有减少,这又是一个什么样的信号呢?
Abandonware 趣图赏析

页面存档: 上页 1 2 3 4 5 6 7 8 ...47 48 49 下页