2008年12月27日

lyman 的 2008 年度游戏总结

在 LP 的呵斥声中艰难完成的通关列表:

3 月 9 日,生化危机 4。

老游戏。当年很不适应,又不缺其它游戏,就搁下了。这次在新水木看别人讨论得眼馋,又翻出来。很爽。就为那小马哥手持王八盒子勇救铁皮碍事梨的换皮设计,通关两次也值得。这是一个挺独特的亚游戏类型——只要你肯花点时间适应。补充:这游戏我是用手柄通关的,感谢贝尔金。

3 月 15 日,雷顿与不可思议的小镇(DS)。

我对这类游戏爱不多。能通关大概是因为觉得删档可惜,留着又比较占地方。LV5 做的还是挺认真的吧。不过从我们公司给其做外包的情况来看,暴发户做事情也不怎么靠谱。

4 月 5 日,命令与征服 3:凯恩之怒。

光头早就死过无数次了,但是 EA 不能让他死。这类游戏还不如都做成 General 系列那样偏写实的好。

4 月 24 日,工人物语 6。

战斗简化版的要塞。很轻松,很杀时间的游戏。画面相当好。

5 月 13 日,Turok 2008。

中规中矩的 FPS,流程不长,乏善可陈。

5 月 24 日,bioshock。

好评无数的名作。像看三十年代旧美国风格的电影。挺好,但是感受并不强烈。应该是背景信息不足,难以产生共鸣的缘故。

7 月 12 日,Mass Effect。

年度通关的最佳 RPG,没有之一。已列入收藏名单——如果没有 DNA 应该已经收了,恨。听说 STEAM 上有卖了。好事。但是目前非欧美地区仍然 not available,不知道为什么在线销售数字产品也要搞区域限制。

10 月 31 日,Space Siege。

SEGA 出品,小品级,类 Diablo 的无脑点鼠标游戏。估计有多结局,我只打了一个。大鱼大肉之间的调味菜。

11 月 8 日,恶魔城:被夺走的刻印(DS)。

应该算是大陆的国民游戏了吧。虽然买正版的人很少,也无从买到中文的正版。御姐剧情通关,修炼堂未果并枪男进行中时掉档了。如果中古店看见了就收一套日版正版。电车上掏出个明显能看见 TF 卡槽的 DSL 还是挺让人羞愧的。

11 月 23 日,Dead Space。

第一感觉很重口味。但这是不可多得的佳作——只要你肯花点时间适应。列入收藏名单。再恨 DNA。等 STEAM 解除地域限制。

12 月 7 日,Need For Speed : Undercover。

都说卡。好在我的配置是令很多人发指的 4850 拖 1024x768。但即便如此还是遇到过几次因为跑的太快导致大楼在轰隆隆的硬盘声中一块一块贴出来的情况。不过个人仍然认为本作是自 Most Wanted 以来最好的一作——我喜欢明亮的竞速环境。

12 月 18 日,Prince of Persia。

流程因为难度太低而显得短了许多。但是另类的渲染风格和畅快的游戏体验我喜欢。悲剧童话的情节我也喜欢。正版无任何加密,赞。准备收藏。

补充列表(无特别说明均未通关):

无冬之夜2:叛逆者的面具

已收正版。但这一作的噬魂设计我不很适应,并因此长期搁置。应该会在某年某月某日焚香沐浴斋戒更衣之后一鼓作气完成之吧。

Witcher

再强调一次 Witcher 不是巫师而是狩魔猎人。这游戏的缺点就是扔了一段时间就很难捡起来继续——我就是如此,中元节长假回家操办婚事之后就再没捡起来。准备收正版。

Red Alert 3

老了,想象力不够了,面对高达海豚学生妹熊德鲁伊的乱战,我混乱地选择了退缩。

Far Cry 2 和 Brothers in Arms: Hell's Highway

一个 FPS,不管是因为系统太复杂还是其它什么而导致玩家不能很有快感地扣扳机的,都不是好 FPS。

刺客信条

无聊的流程还不如搞成 Indigo Prophecy 那样的 QTE 游戏从而让人专注于剧情。

万能先生的泡妞生活(DS)

忘了啥时候通关的了。不知道拿这个当攻略在日本把妹靠不靠谱。靠谱的话就是神作。

几何战争(DS)

这个类型我喜欢。不过也说不好如何才算通关,反正是玩到个人能力上限就搁置了。

另若干想都想不起来的游戏略。

总结:

游戏可能影响家庭和谐。

2008年12月25日

平安夜

平安夜在北京逗留。约朋友吃饭。找饭店。只想起来个饭统网。

先打 114 查号好了。

“喂,你好,能帮我查一下饭统网的电话么?”

“我们没有收录饭统网的电话,114 现在也提供饭店订餐服务,请问您……”

哦。我又土了。

2008年12月7日

parcellite 也不错

parcellite 是个剪切板管理程序,作用跟 glipper 差不多。如果你常常头疼在 x selection 和 clipboard 之间(科普在这里)粘贴东西,类似的工具还是必不可少的。

这类工具 gnome 下最常见的就是 glipper。之前我也一直在用。只是这东西总有一定概率在启动 gnome 的时候给我一个启动失败的提示——显然我不是一个人在瞎逗,ubuntu launchpad 上讨论了一大圈也没有个所以然。我也就一直这么将就着用。

直到 parcellite 在 0.9 里终于加入了对 x selection 的支持,功能上已经可以和 glipper 平起平坐了。虽然 archlinux 的 community/parcellite 跟进并不及时,但是我已经迫不及待的从 abs 里拎出这个包,自己编译了 0.9 用上了。几天试用下来,没发现什么问题。最重要的是,不用再时不时地手动启 glipper 了。

如果你也被 glipper 困扰,那么推荐你尝试一下 parcellite (>= 0.9)。以后的版本里应该能看到简体中文支持。记得感谢我 ;P

2008年12月5日

纪念我的第一台 DC

2008 年 4 月29 日,我把她从秋叶原的 Sofmap 赎了出来。前天,我又把它卖进了新宿 BicCamera 四层的 Sofmap。虽然是二手,但七个多月的时间里,过万次 shot,她的表现从没有令我失望。

她就是我生命中的第一台自己的 DC——Ricoh GX100。这里谨以一些拙作,纪念她的离去。

11 月 30 日。东京塔。






11 月 22 日。奥多摩湖。







11 月 8 日。高尾山。







11 月 1 日。多摩动物园。







10 月 11 日。小石川后乐园。







9 月 22 日。丹泽大山。






7 月 19 日。葛西临海公园。






6 月 13 日。家附近。






5 月 6 日。高尾山。






最后,她的身影。




ps. 欢迎点击以上图片访问/订阅我的个人相册。

2008年12月3日

[中英对照] evdev, xorg.conf, hal 和其他迷雾

(译注:原文载于 Peter Hutterer——X input 开发者——的博客,标题为“evdev, xorg.conf, hal and other FUD”。FUD 是 Fear, uncertainty and doubt 的缩写,即恐惧、不确定和怀疑,本文译为“迷雾”。)

Sparked by this thread, here's a list of X input facts in random order.
这条讨论线索的启发,这里列举一些 X input 的现状(不分先后顺序)。

  • The evdev driver is the preferred input driver. If you are not running Linux, then evdev is not available for you and you can keep using the mouse/kbd drivers.
  • 推荐使用 evdev 驱动。如果你用的不是 Linux,那么你也用不上 evdev,你可以继续使用 mouse/kbd 驱动。

  • If you are running Linux, you can keep using the mouse/kbd driver if you wish, but configuration adjustments need to be made. See below for details.
  • 如果你运行的是 Linux,如果愿意你也可以继续使用 mouse/kbd 驱动。但是配置需要调整一下,详见以下叙述。

  • By default, the X server will expect a device list at runtime from HAL. You can turn this behaviour off by using Option "AutoAddDevices" "off" in the ServerLayout, or by disabling HAL at configure time. HAL is not required to use X.
  • 默认情况下,X server 会在运行时尝试从 HAL 获得设备列表。你可以在 ServerLayout 部分使用 Option "AutoAddDevices" "off" 来禁止这种行为,或者直接从配置里拿掉 HAL。X 不依赖于 HAL。

  • If HAL is enabled, then the mouse/kbd drivers are disabled. Otherwise, you will get duplicate devices. If you want to use mouse/kbd, disable HAL.
  • 如果 HAL 被启用,那么 mouse/kbd 驱动会被禁用。否则将会有重复的设备。如果你想使用 mouse/kbd,禁用 HAL。

  • Devices only get added if they have the input.x11_driver option set (check lshal). For mice and keyboards, evdev is the default, drivers such as linuxwacom or synaptics provide their own fdi.
  • 设备只有在具备 input.x11_driver 选项属性(通过 lshal 查看)的时候才会被加载。对于鼠标和键盘,evdev 是默认的驱动。其他驱动诸如 linuxwacom 或 synaptics 提供自己的 fdi。

  • Any other options need to be added with the key "input.x11_options.foobar" and must be of type string.
  • 其他任何须同 input.x11_options.foobar 键值同时加载的选项必须是字符串类型。

  • Devices specified in the xorg.conf will not be available after unplugging and replugging them, but will become available again after a VT switch or a resume.
  • 在 xorg.conf 中指定的设备在拔出并重新插入之后会失效,但是会在 VT 切换或唤醒之后重新有效。

  • XKB options are specified by HAL, not by the server.
  • XKB options 由 HAL 指定,而不是 server。

  • The evdev driver will prevent you from adding the same event device twice. The synaptics driver does too. Evdev will not prevent you from adding /dev/input/mice and /dev/input/event1 at the same time.
  • evdev 驱动会阻止加载同一设备两次。synaptics 驱动也是如此。evdev 驱动不会阻止同时加载 /dev/input/mice 和 /dev/input/event1。

  • HAL will prevent you from adding the same UDI.
  • HAL 会阻止加载重复的 UDI。

  • AutoAddDevices specifies whether to add devices through HAL (default on).
  • AutoAddDeivces 指定是否通过 HAL 来加载设备(默认开启)。

  • AutoEnableDevices specifies whether to enable such devices immediately (default on).
  • AutoEnableDevices 指定是否立即启用加载设备(默认开启)。

  • AllowEmptyInput specifies if a mouse/kbd section if none is present is required (if AEI is on -> no mouse/kbd required, disables mouse/kbd if present in the xorg.conf). AllowEmptyInput defaults to (AutoAddDevices && AutoEnableDevices)
  • AllowEmptyInput 指定是否需要 mouse/kdb 配置部分(如果开启此选项,则不需要 mouse/kdb 配置,即使在 xorg.conf 中设置了也会被禁用)。如果 AutoAddDevices 和 AutoEnableDevices 开启,此选项默认也为开启。

  • Synaptics SHM or other options can be enabled in the FDI file with the key "input.x11_options.SHMConfig" (or likewise). Options have to be type string.
  • Synaptics SHM 或其他选项可以通过 FDI 文件中的 input.x11_options.SHMConfig(或其他看着差不多的)键来设置。类型必须为字符串。

  • Synaptics has improved a lot in regards to autoconfiguration and you probably won't need half of your options anymore.
  • Synaptics 的自动配置改进很大,你或许可以扔掉一半原来的配置选项。

  • For every default setting that annoys you there's at least one person that loves it. For every default setting that you find appropriate, there's at least one person hating it. Become an active contributor, then you get to decide on what the defaults are.
  • 默认设置永远无法取悦所有人,总会有人省心有人麻烦。做一个积极的贡献者,你就能参与决定默认设置。

  • Storing configuration in HAL's fdi file is not the best solution but the best we have right now.
  • 将配置放在 HAL 的 fdi 文件里面不是最好的解决办法,但是是我们目前能做的最好的。

  • The old system worked, because you only ever had one mouse and one keyboard in X. Now you can have multiple of each, independently configured. This is why we switched to HAL for hotplugging and autoconfiguring.
  • 旧系统仍然工作,因为你在 X 里面从来都只有一套键盘鼠标。现在你无论键或鼠都可以有多个,并且各自独立配置。这也是为什么我们转向用 HAL 来识别热插拔和自动配置。

  • Ranting and/or commenting on some blog won't get your issues fixed. Filing a bug may.
  • 在博客上(译注:对中文用户来说,论坛也是如此)抱怨或/并评论不会解决问题。提交 bug 或许可以(译注:lyman 认为,加入 xorg 的邮件列表参与讨论或许也可以)。

2008年11月23日

东京的圣诞节

虽然距离圣诞还有一个多月,但是东京新国立剧院已然开始搭那个年年都有的巨大圣诞树了,还专门立了个牌子——11 月 20 日点灯式。

反正这新国立剧院就在公司旁边,是每天下班坐电车的必经之路,这点灯式自然是不会错过了。



可能是点灯式的缘故吧,新国立剧院比平时热闹些。下班路过的人纷纷掏出手机留影。这几个学生妹不知是不是专程赶过来的——日本妹(很多 OL 熟女也一样)真的是很抗冻啊。



这颗圣诞树前前后后搭了足有一个星期。之前我还感叹怎么日本人搭着东西效率如此之低。没想到这东西还真有点名堂。树底下围着一票人的那个地方是个算星座运势的机器,运势不同,这树上的彩灯亮起来也不一样。

和国内一样,圣诞不是什么正经节日。但商家都铆足了力气造势,无非是想提升一下大家消费的欲望(估计这也是为什么要提前一个月就开始“点灯”)。真洋人的圣诞树,大抵从 12 月 25 号开始要栽个把礼拜。但是新国立剧场里的这棵,根据去年的经验,26 号就已经在拆了——日本人正经要过的,其实是元旦。

2008年11月19日

上帝也发飚

本科时,江爷爷的“too young, too simple, sometimes naive”颇为轰动,传为一时美谈。只有 L 同学看过之后,第一句话是“老江说的并没什么不对”,让我印象颇深——当时大家的注意力,显然都集中在江 core 比比划划的表演上面了。

这事用时髦点的话讲,叫“话糙理不糙”。

可惜媒体很少这样明白事理——尤其又是在自己被批评的时候——于是经常揪住“话糙”这一点大作文章。

比如最近麻生同学该在什么地方交际应酬的事情,就可以通过断句、拼凑、引申放大等一系列手段转进成这样一个“让人忧心”的段子——拍也不拍在点子上,批评厨子不说菜的事却揪住他会不会脑筋急转弯,找这些个边角料下手未免下作。

可是,辨一事易,辨三事难。虽然老祖宗留了很多成语来警醒咱们这些后辈——“曾参杀人”、“三人成虎”、“众口铄金,积毁销骨”——媒体要是一天到晚在你耳朵边吹的都是这种风,你也难免忘记了成语,蒙蔽了双眼,这背后的道理或许只有传说中的心理学能说得清。

唉,媒体怎么这么坏啊!可是等等,这天下熙熙攘攘,利来利往,媒体要总是热衷于某类事情,也必然是无利不起早的啊。

于是,从字里行间,我读到了血淋淋的四个字——眼球经济。媒体当然自诩客观公正,只是他们在遇到你潜意识里可能想要的东西的时候,从不吝惜篇幅笔墨而已。而这个循环里,又能责备谁呢?我仿佛听见老罗声嘶力竭的质问“人民有没有庸俗的权力!”——这就是本恶的人性啊。

等等,不是也有说人性本善的么?呃,我其实更认同告子、王阳明同学主张的人性无善恶。在今天这个话题里,善恶只存于您一念之差,而这一念之差,可能只是出于猎奇。

冷淡如康夫同学也终究没能按捺得住“我能客观认识自己。我不像你。”的时候,我觉得,即使是上帝,也早晚会发飚吧。

题外话:为了这个标题特意查了下字典,挺有意思,居然是“飚同飙”,但是看字给人的感觉可相差万里啊,一个风风火火,另一个么……

2008年11月6日

第二起跑线(三)——评论:Yes We Can

这次“富士康”事件的主角,看似是主板,实际上,是 BIOS。更准确一点说,应该是 BIOS 所保存的 ACPI 代码中的 DSDT 表部分。或许看了这个专题前两部分热闹,你仍然不清楚什么是 ACPI 标准,什么是 DSDT,以及它们为什么重要,那么这里我将尽我所能做点解释。

ACPI,全称 Advanced Configuration and Power Interface,是从 APM(Advanced Power Management)进化而来的一整套涉及电源管理的 BIOS 代码。现代绝大多数电脑硬件的常见功能如 CPU 频率自动调节、挂起/休眠、CPU 风扇的智能调速等等,无不仰仗 ACPI。

但是,并非所有的硬件都支持 ACPI(ACPI 1.0b 颁布与 1999 年),也并非所有的操作系统支持 ACPI,况且从 1999 年的 1.0b 到目前的 3.0b 到正在开发当中的 4.0,ACPI 自身也在不断发展完善之中。为了取得更好的兼容性以及用户体验(其实是对用户透明,你感觉不到它的存在才证明它的成功,这点 GFW 仍需努力),ACPI 想了这样一个办法(OS 指操作系统,后略):
硬件\OS传统 OS支持 ACPI 的 OS
传统硬件传统硬件配传统 OS,没什么问题如果 OS 缺乏对传统硬件接口的支持,ACPI 以硬件方式接管全部旧有功能
支持 ACPI 同时保留传统接口的硬件在传统 OS 下,就跟使用传统硬件一样启动时 OS 告知硬件从传统接口切换到 ACPI,之后即为完整的 ACPI 支持
仅支持 ACPI 的硬件电源管理功能失效完整的 ACPI 支持

注意表格当中字体加粗的部分,问题就出在这里。这也是 ACPI 中为什么要有 DSDT 的原因。

DSDT,全称 Differentiated System Description Table,启动时 OS 通知 ACPI 自己支持 ACPI,然后可以从这里获得系统相应的 ACPI 实现和配置的信息(ACPI 有很多版本,不是吗)。

我相信如果 OS 通知给 ACPI 的是自己支持的 ACPI 标准版本,那么事情将简单许多——事实是,OS 传递给 ACPI 的是一个标识自己的字符串。比如

Windows 2006
Windows 2001.1
Windows 2001 SP1
Windows 2001
Microsoft Windows
Microsoft WindowsME: Millennium Edition
Microsoft Windows NT

如果你反编译一下你的 DSDT(在 Linux 下,这么做真的很容易,这要感谢英特尔),你就能看到那个庞大的巨丑无比的 if-else 嵌套块——以上字符串就来自于我正在写这篇文章的富士通笔记本,不同的 BIOS 会包含更多不同的字符串,它们全加起来比 ACPI 版本的数量还要多。不用奇怪 ACPI 标准为什么会容忍 OS 相关性这么强的字符串,看一下起草 ACPI 标准的成员名单你就会明白:惠普、英特尔、微软、Phoenix(就这一家是做 BIOS 的)和东芝。

但更加不幸的是,很多硬件制造商根本没能力提供全功能的 DSDT 表,甚至 ACPI 成员厂商也不例外(稍后再述)。

于是,生存在非微软世界的 PC 开发人员和用户就一直在和恶劣的 BIOS 做着不懈的斗争。这次“富士康事件”,仅仅是自 Linux 2.6 内核不断成熟、可用性空前进步加上 Ubuntu 大力推广扩大了用户群之后的一次影响范围稍大的冲突而已。看看那么丰富的 DIY 修改版 DSDT 库(是的,Linux 支持用一个自己修改过的 DSDT 文件来代替内置在 BIOS 里的那个),你就能想象 Linuxer 们自己动手、丰衣足食的传统有多么悠久。今天的 Linux 内核更是宽容,它可以告诉 ACPI 自己是任何版本的 Windows 以求正常工作——除非 DSDT 给 Linux 还刻意准备了一份信息。而这次事件中,富士康恰恰就是这么做的,而且那份信息恰恰有问题。

或许你并不关心 Linux。但是我要提醒你的是,同样的手段可以用在不止 Linux 的身上。记得 HP 6520S 近半年难以安装 WindowsXP 的事件么?回忆一下 Halo 3 Vista Only,DirectX 10 Vista Only,我向来不惮以最坏的恶意揣测微软——你以为惠普这个不大不小的“疏漏”是微软赞助下的一次强推 Vista 的尝试?嗯,我还没这么说。

标准,本来是大家做事的准则。标准的制定当然不能缺少微软(否则这对微软也不公平不是)。但是我们都不希望看到标准被污染,也都清楚微软污染标准的能力(请回忆 OOXML 事件)。利用标准的控制权,微软可以合法的将竞争对手推到第二起跑线上。因此,我很赞赏 Ryan 的做法,也由衷敬佩美国公平交易委员会的威慑力(呃,写到这里总是自我迫害般的妄想如果这事发生在国内会如何如何)。我们应该好好学习 Ryan。因为只有给第二起跑线上的人们一个公平的机会,我们的切身利益才有保证——该出手时就出手,套用奥巴马的口号——“Yes We Can”。

2008年10月29日

第二起跑线(二)——中英对照:富士康的醒悟

上集回顾:
名为 Ryan 的 ubuntu 用户发现自己购买的富士康主板在 Linux 下工作不正常。投诉受阻之后通过一系列技术手段发现造成问题的根源竟然不是“不支持”而是“故意不支持”。又经过几番和富士康客服的交锋之后,他愤怒了。他和富士康不得不说的故事,传遍了互联网(英文世界),直至公平交易委员会的数据库里。

本文是 2008 年 8 月 2 日,富士康员工在 ubuntu 英文论坛上发帖的翻译。很高兴事情能有这样的大团圆结局,同时也赞一下富士康的反应速度——距离 Ryan 发表檄文的 7 月 24 日,仅仅 9 天。

原帖地址
---

Updates of resolution od Foxconn bug --- from Foxconn FAE Heart Zhang
关于富士康 bug 解决方案的进展——来自富士康的 FAE Heart Zhang
(译注:不清楚这个 FAE 是指 Field Application Engineer“现场应用工程师”还是 Failure Analysis Engineer“错误分析工程师”,笔者更倾向于后者,但保留原文)

Hello every enthusiasts on Linux,
各位 Linux 发烧友你们好,

My name is Heart Zhang from Foxconn China, these days I and another Foxconn guy in UK names Carl Brunning contacted Ryan Farmer with each other at all times by email and phone on the big issue happened on our Foxconn MB G33M-S.
我是富士康中国的 Heart Zhang。这些天来我和另一位富士康香港的同事 Carl Brunning 一直在通过电子邮件和电话就我们富士康 G33M-s 主板发生的问题和 Ryan Farmer 密切沟通。

Yesterday evening I sent one debug version BIOS about this issue to Ryan, ask him to help us verify again. This morning Ryan replied me his testing result. Almost bugs are fixed by this BIOS.
昨晚我将一个 debug 版本的 BIOS 发给了 Ryan,希望他能够帮忙测试一下。今天早晨,Ryan 回复了他的测试结果。几乎所有的问题都在这一版本得到了解决。

Here is Ryan's testing result about the development BIOS
这是 Ryan 对我们开发版 BIOS 的测试结果
----------------------
The development BIOS they sent fixes pretty much all the particularly bad behavior of the current release BIOS, in that:
他们发给我的开发版 BIOS 修正了所有现有发行版本 BIOS 中的问题:

Fans resume to proper speed after resume from suspend.
从挂起唤醒之后,风扇速度恢复正常。

PC successfully reboots after having suspended.
挂起之后,PC 能够正常重启。

PC restarts a lot faster.
PC 重启速度大大加快。

PC no longer seems to randomly crash.
PC 不再随机崩溃。

PC hibernates and wakes up from hibernation properly.
PC 休眠和唤醒都正常了。

No longer complains about error reinitializing the Serial ATA controller.
重新初始化 SATA 控制器也没问题了。

For the sake of curiosity, I tried booting a Ubuntu 7.10 (Gutsy Gibbon) CD, it booted up whereas it crashed before.
出于好奇,我试了试用 Ubuntu 7.10 (Gutsy Gibbon) 光盘启动,原来崩溃的地方也可以顺利启动了。

Issues remaining:
尚未解决的问题:

Aug 1 05:51:15 ryan-desktop kernel: [18.280909] ACPI Warning (tbutils-0217): Incorrect checksum in table [OEMB] - 96, should be 8F [20070126]

With the release version of the BIOS it said "70, should be 69"
在发行版本的 BIOS 中,日志说的是“"70, should be 69”。

Matthew Garrett says Linux doesn't even need OEMB and this is some vendor-proprietary Windows stuff. (Should be OK to ignore)
Matthew Garrett 说 Linux 根本不需要 OEMB 表,这是某种 Windows 才用的制造商信息(忽略掉应该没问题)。

Intel HD Audio device does not reinitialize from suspend. (Kernel 2.6.26 fixes this, it appears to be a Linux bug in kernels earlier than this, this kernel will be in Fedora 10 and Ubuntu 8.10)
Intel HD Audio 声卡从挂起唤醒后没有重新初始化。(Kernel 2.6.26 修正了这点,这看起来更像是 Linux 老板本 Kernel 的 bug,新 Kernel 将会被包含在 Fedora 10 和 Ubuntu 8.10 中)

"ACPI: Error Attaching Device Data" still appears in kernel log, four times. (This too seems to be a Linux bug since 2.6.26 fixes that)
“ACPI: Error Attaching Device Data”仍旧出现在内核日志里,四次。(这似乎也是 Linux 的 bug,2.6.26 已修正)

Overall, I believe:
综上,我相信:

The very worst of it was a bad BIOS.
罪魁祸首就是那个烂 BIOS。

Many of the annoyances were kernel bugs that are fixed in 2.6.26.
许多烦恼其实是内核的 bug,也已经在 2.6.26 得到修正。

All but the checksum error is fixed if you use the new BIOS and kernel 2.6.26, and the checksum error is not a serious issue anyway.
如果用新 BIOS 和 2.6.26 内核,除了校验和错误之外的所有问题都得到了修正,而且那个校验和错误本身也不是什么大不了的事情。
----------------------

So it likes that the BIOS works much better with Linux.
And Ryan told me in the email, he tested the BIOS even on Windows Vista/Server 2008, there also seems like no issue.
这样看来新 BIOS 在 Linux 下表现要好得多。
而且 Ryan 在 email 中告诉我,他甚至在 Windows Vista/Server 2008 上也试了下新 BIOS,没什么问题。

----------------------
I also gave this BIOS a very crude set of tests with an evaluation edition of Windows Vista/Server 2008 and it even appears to work better with a few things there.
我拿体验版的 Windows Vista/Server 2008 对这 BIOS 作了下粗略的测试,其表现在某些方面似乎还更好些。
----------------------

If someone is intereted in this debug BIOS, you also can download from our Foxconn FAE FTP.
如果对这个开发版 BIOS 感兴趣,你也可以从我们富士康 FAE 的 FTP 上下载。

http://wft.foxconn.com/wft/Login.aspx
Login: enduser
Pass: 123456

BIOS name: 772F1D43
You can unzip the file, just run flash.bat on DOS mode to flash BIOS.
Attention: after finishing the BIOS flashing, please goto BIOS setup to load optimized default before first time entering Linux.
你可以解压,并在 DOS 模式下运行 flash.bat 来更新 BIOS。
注意:在更新 BIOS 之后,请进入 BIOS 设置界面 load optimized default,再进入 Linux。

I hope you guys can get the good result that you really want.
But that is only a debug version BIOS which focus on this issue, later we will release Production BIOS for it ASAP.
Not only on this motherboard, but also on all the other motherboards which got the same issue.
Please make attention to our website for BIOS update,
希望大家都能得偿所愿。
但是,这只是针对此次问题的开发版 BIOS。我们将会尽快释放一个产品版本的 BIOS 出来。
不仅是这款主板,其他所有型号主板都又类似问题。
请随时关注我们网站上的 BIOS 更新。
http://www.foxconnchannel.com/product/Motherboards/

And here I want to say Thank you to all the linux enthusiasts. From this case, Ryan and all of you gave us a lesson. And also as our plan, we will take more time on Linux OS testing.
And I am sure Linux is becoming more popular and great OS.
For me, Carl Brunning and all the Foxconn FAE, technical support guys, we would like to receive any issues regarding to our products (motherboard and VGA card)whatever it is from Windows, Linux or any other operating system.
You can report to this link if you have any issue or comments,
在此我想感谢所有 Linux 发烧友们。这次事件,Ryan 和你们所有人给我们上了一课。我们计划今后会投入更多时间到针对 Linux 的测试上。
我相信 Linux 会成长为更受欢迎的伟大的操作系统。
对于我、Carl Brunning 和所有富士康 FAE以及技术支持人员,我们真诚希望能够听到任何关于我们产品的问题(主板和显卡),无论这些问题是来自 Windows、Linux 还是其他操作系统。
如果有任何问题或建议,你可以访问下面这个链接,
http://www.foxconnchannel.com/support/online.aspx

If possible, you can inform this message to any people as many as you can. Maybe they met the same issue before on our Foxconn motherboard.
如果可以,你能将此信息广为传播。或许他们在使用富士康主板时也遇到过同样的问题。

Thanks all of your guys' attention! Thank you very much!
感谢大家的关注!非常感谢!

--- Heart Zhang from Foxconn China
--- Heart Zhang 富士康中国

(译注:这篇帖子在 ubuntu 英文论坛上得到了 117 位用户的感谢)

2008年10月23日

第二起跑线(一)——中英对照:一个 ubuntu 用户的愤怒

本文讲述的是一块主板在富士康和 Linux 用户之间引发的恩怨。这段故事在简体中文世界流传并不广泛,故作此“第二起跑线”专题,跟大家讲述一些在鲜为人知的角落发生的鲜为人知的事实。

谨以此专题向那些站在第二起跑线上和微软竞争的选手们致敬!

英文水平有限,翻译不周之处万望赐教。

---
原帖地址
---

A possible bug in Foxconn boards BIOS affects Linux ACPI
富士康主板的疑似问题 BIOS 影响了 Linux ACPI 功能

Update: I just got off the phone with Foxconn, they called me from China (1 AM in Indiana, heh) and were asking if I would test an improved version of their BIOS based partially on the modifications I've made to mine, hopefully this all blows over, and regardless of who's fault it is or isn't, we can just go back to using our computers with full functionality.
进展:我刚刚接了富士康从中国打来的电话(印第安纳州当地时间凌晨 1 点,呵呵)。他们问我是否愿意测试一下改进版的 BIOS(部分根据我的修改而来)。希望这次事件就此平息,不管是与不是谁的责任,我们终于能够全功能地享受自己的电脑了。

Thanks to the community for helping me get the message to Foxconn.
感谢社区(译注:应该指的是英文 ubuntu 社区),帮我将信息传递给富士康。

Edit: Please tell Foxconn what you think of their behavior:
更新:请向富士康表达你对他们行为的感受:

http://www.foxconnchannel.com/support/online.aspx

You need to put in an email, and then it will bring up a form, choose Complain/Suggest.
需要输入 email 地址,然后你会收到一份表格,选投诉/建议。

FOXCONN PHONE NUMBERS and LOCATIONS OF US-Based facilities
富士康美国的电话和地址

http://maps.google.com/maps?q=foxconn

Edit: Welcome Digg, Reddit, and Slashdot.
更新:欢迎到 Digg,Reddit 和 Slashdot 上来讨论此事。

http://digg.com/linux_unix/Foxconn_d..._destroy_Linux
http://www.reddit.com/comments/6tcv8...their_bios_to/
http://linux.slashdot.org/article.pl.../07/25/1150218

Who is Foxconn and why must we get the message to them?
富士康是谁以及我们为什么要把这些信息告诉它?

I've heard a lot of people ask, "Who the hell is Foxconn", if you use a PC, there's a good chance you have one of their boards, even if it's branded as MSI or some other brand, if you use a Nintendo Wii, XBOX 360, or Playstation 3, Foxconn made that motherboard, this isn't some little dodgy hardware maker with no name that we can afford to be quiet about.
很多人问我“富士康是 TM 谁呀”,如果你有 PC,那么很有可能你的主板就是富士康产的,无论这块主板贴的是微星还是其他什么牌子。如果你有任天堂 Wii,有 XBOX 360 或者 Playstation 3,那么它们的主板也是富士康产的。这不是个我们可以忽略不计的虾米山寨厂。
------------
I have disassembled my BIOS to have a look around, and while I won't post all the results here, I'll tell you what I did find.
我反编译我的 BIOS 看了看,不全把结果贴在这,我也能告诉你我发现了什么。

They have several different tables, a group for Windws XP and Vista, a group for 2000, a group for NT, Me, 95, 98, etc. that just errors out, and one for LINUX.
他们有不同的(译注:DSDT)表,一套是给 Windows XP 和 Vista 准备的,一套给 2000,一套给 NT、Me、95、98 等,以及唯一有问题的一套,给 Linux 的。

The one for Linux points to a badly written table that does not correspond to the board's ACPI implementation, causing weird kernel errors, strange system freezing, no suspend or hibernate, and other problems, using my modifications below, I've gotten it down to just crashing on the next reboot after having suspended, the horrible thing about disassembling any program is that you have no commenting, so it's hard to tell which does what, but I'll be damned if I'm going to buy a copy of Vista just to get the crashing caused by Foxconn's BIOS to stop, I am not going to be terrorized.
这套给 Linux 的烂表不符合主板的 ACPI 实现,导致了诡异的内核错误,奇怪的系统死锁,无法挂起(suspend)或休眠(hibernate)和其他问题。通过下面的修改,我已经解决了挂起之后重启崩溃的问题。反编译任何程序的恐怖之处在于得不到任何注释,所以很难分辨哪段代码具体是什么作用。但是富士康的烂 BIOS 不能逼我去买套 Vista 来解决问题,这吓不倒我。
-----
How to fix:
如何修复:

(译注:此处代码颇多,故略去,需要技术细节的请参见原帖
-----
Edit: Complained to the Federal Trade Commission
更新:给公平交易委员会的投诉

http://www.ftc.gov

Foxconn
458 E. Lambert Road Fullerton
Fullerton, CA
92835

FOXCONN PHONE NUMBER: 714-871-9968

Company sold me a computer motherboard, model G33M-S, claiming that it was compliant with ACPI versions 1.0, 2.0, and 3.0.
富士康公司出售给我的型号为 G33M-S 的电脑主板,声称兼容 ACPI 1.0、2.0 和 3.0。

Linux and FreeBSD do not work with this motherboard due to it's ACPI configuration, using a disassembler program, I have found that it detects Linux specifically and points it to bad DSDT tables, thereby corrupting it's hardware support, changing this and setting the system to override the BIOS ACPI DSDT tables with a customized version that passes the Windows versions to Linux gives Linux ACPI support stated on the box, I am complaining because I feel this violates an anti-trust provision in the Microsoft settlement, I further believe that Microsoft is giving Foxconn incentives to cripple their motherboards if you try to boot to a non-Windows OS.
Linux 和 FreeBSD 因其 ACPI 配置而无法工作。通过使用反编译工具,我发现它会特别侦测 Linux,将其指向一套有问题的 DSDT 表,并因此使其硬件支持失效。如果稍加修改,设置系统使用修改后的版本,让 Linux 获得跟 Windows 同样的 BIOS ACPI DSDT 表,Linux 的 ACPI 支持问题全无。我认为这触犯了微软和解协议(译注:关于 Microsoft settlement,笔者认为指的是 2002 年微软公司与美国司法部和九个州就反垄断案达成的和解协议)中的反拖拉斯条款。我更有理由相信,为了让主板在非 Windows 平台上出现问题,微软对富士康进行了奖励。

We have received your complaint.
我们已经收到您的投诉。

Thank you for contacting the FTC. Your complaint has been entered into Consumer Sentinel, a secure online database available to thousands of civil and criminal law enforcement agencies worldwide. Your reference number is:
感谢致函公平交易委员会。您的投诉已经被录入 Consumer Sentinel,一套向全世界人民和执法机构公开的安全的在线数据库系统。您的投诉编号为:
19642372

Edit: Full correspondence with Foxconn
更新:和富士康的全部往来信件
(译注:后文中 Me、Ryan 都指原作者,Foxconn 指富士康,因多次出现,后文不再一一对译)

Me:

ACPI issues, cannot reboot after having used suspend
ACPI 问题,挂起(suspend)之后无法重启。

Jul 22 08:37:53 ryan-pc kernel: ACPI: FACS 7FFBE000, 0040
Jul 22 08:37:53 ryan-pc kernel: ACPI: FACS 7FFBE000, 0040
Jul 22 08:37:53 ryan-pc kernel: ACPI: FACS 7FFBE000, 0040
Jul 22 08:37:53 ryan-pc kernel: ACPI: FACS 7FFBE000, 0040
Jul 22 08:37:53 ryan-pc kernel: ACPI Warning (tbutils-0217): Incorrect checksum in table [OEMB] - 70, should be 69 [20070126]

I get these messages in my system log at boot, I also fail to reboot after having used suspend in a session, it hangs and plays a continued beep on the PC speaker.
启动时系统日志如上。一次冷启动(译注:此为笔者理解的 session)之中挂起之后也无法重启,机器死锁,扬声器长鸣。

Foxconn:

Dear Ryan:

Do you get the same beep codes if you were to remove all RAM out and then turn the system ON again?
请尝试拆掉所有内存条,开机之后是否扬声器依旧长鸣?

Me:

No, because then I wouldn't be able to boot into Linux, suspend to RAM, to get the ACPI failure, have syslogd pollute my /var/log/messages file with it, or read about it in my system log.
呃,挂起到内存(suspend to RAM)的话,拆掉内存条就无法启动到 Linux 了啊,syslogd 也没机会写 /var/log/messages,更不用说读到 ACPI 错误以及其他任何系统日志。

In particular, the number of quirks that the kernel has to use, and this invalid checksum are what has me nervous.
特别是内核挣扎的次数和这个无效的校验和让人感觉很诡异。

If you need me to attach the full contents of /var/log/messages, I can do so.
如果需要完整的 /var/log/messages,我可以奉上。

Foxconn:

Dear Ryan:

This board was never certified for Linux. It is only certified for Vista. See URL below. So please test under Vista. Does this issue also occured under Vista or Winxp?
本主板仅通过 Vista 认证而非 Linux 认证(链接如下)。所以请使用 Vista 进行测试。问题是否同样存在于 Vista 或者 WinXP?

http://www.foxconnchannel.com/produc...ification.aspx

Me:

Well, this is a replacement for a dead Intel board (a 945g that fully supported ACPI), Vista was never really up for consideration, and I'm not about to go buy a copy to find out.
好吧,买这板子是因为之前一块 Intel 板子(带完整 ACPI 支持的 945G)坏了,Vista 从来不在考虑之列,我也不准备买一套来试试。

The ACPI specs are there for a reason, and broken BIOS's like what is in this motherboard are the reason standard ACPI does not work, I've taken the liberty of filing the report in kernel.org, Red Hat, and Canonical's Ubuntu bug tracking systems, and posting the contents of my kernel error log on my blog, which is in the first several results if you Google search "Foxconn G33M" or "Foxconn G33M-s", "Foxconn Linux", etc, as well as prominently in other search formats, so hopefully this will save other people from a bad purchase, and hopefully kernel.org can work around your broken BIOS in 2.6.26, as I understand that kernel is more forgiving of poorly written BIOSes built for Windows.
符合 ACPI 规范是我购买此主板的原因,但是貌似 BIOS 有问题导致标准 ACPI 失效。恕我已向 kernel.org、Red Hat 和 Canonical 的 Ubuntu 报告了此问题,并将内核日志贴在了博客上,这些页面在用 Google 搜“Foxconn G33M”、“Foxconn G33M-s”、“Foxconn Linux”以及其他可能的关键字组合的时候都排在前几项。但愿这样能够提醒那些持币待购的人。也但愿 kernel.org 能够在 2.6.26 版内核避开你们的问题 BIOS。据我所知,对于仅对 Windows 写的烂 BIOS,内核还是很宽容的。

I've already gotten several dozen hits on those pages, so you guys are only hurting yourselves in the long run, by using bad BIOS ROMs, as people like me are quite vocal when dealing with a bad product.
这些页面已经吸引了一定点击量。所以,对于你们来说,长远来看,提供有问题的 BIOS 只是在伤害自己。因为像我这样的人面对烂产品的时候嘴从来不闲着。

Foxconn:

Dear Ryan,

Making idle treats is not going to solve anything.
空洞的威胁解决不了任何问题。

As already stated this model has not been certified under Linux nor supported.
如前所述,此型号主板既不支持,也未经过任何 Linux 认证。

As you are unhappy with the product- using a non-support operating system nor certified, please contact your reseller for a refund.
如果您对此产品不满意——哪怕在其上使用不支持的/未经认证的操作系统,请联系零售商进行退货。

Me:

Yeah, well, I allege that you guys thoroughly suck.
好吧。我承认,你们真是彻头彻尾的烂。

Learn how to write a BIOS before you go selling hardware with falsified specs.
好好学学怎么写 BIOS 吧,不要净卖一些假装符合规范的硬件。

Me:

I've been debugging your AMI BIOS, and the ACPI support on it is far from within compliance with the standards, I've dumped out the debugging data into Canonical's Launchpad bug tracking system so that we may be able to support some sort of a workaround for the bad ACPI tables in your BIOS, I would hope that you will be part of the solution instead of the problem, alienating customers and telling them to go buy a copy of Windows Vista is not service, your product claims to be ACPI compliant and is not, therefore you are falsely advertising it with features it isn't capable of.
我在调试你们的 AMI BIOS,其中 ACPI 支持部分距离遵守标准还远着呢。我已经将调试数据提交到 Canonical 的 Launchpad Bug跟踪系统,以便于人们能想办法避开你们 BIOS 里面那些有问题的 ACPI 表。我很希望你们能够参与到其中来,提供解决办法而不是问题本身。疏远客户,告诉他们去买套 Windows Vista 不是服务。你们的产品声称 ACPI 兼容但实际上不是,因此你们已经涉嫌虚假广告。

I would ask that you issue an update that doesn't make it dependent upon Windows Hardware Error Architecture, but that decision is up to you.
我希望您发布一个不依赖于 Windows 硬件错误体系(译注:WHEA,详见此处)的(译注:BIOS)更新版本出来。但是决定权在您手上。

Please find all relevant data here:
相关数据在此:

Bug #251338 in Ubuntu: “Bad ACPI support on Foxconn G33M/G33M-S motherboards with AMI BIOS”
https://bugs.launchpad.net/ubuntu/+s...ux/+bug/251338

I appreciate your consideration in this matter.
恳请三思。

-Ryan

Foxconn:

Dear Ryan,

You are incorrect in that the motherboard is not ACPI complaint. If it were not, then it would not have received Microsoft Certification for WHQL.
您认为这块主板不兼容 ACPI 是不对的。如果它不兼容 ACPI,那么它不会通过微软的 WHQL 认证。

Refer to:
参见:
http://winqual.microsoft.com/HCL/Pro...33M-S&oid=3179

As already stated, this model has not been certified under Linux nor supported.
如前所述,此型号主板既不支持,也未通过任何 Linux 认证。

It has been marketed as a Microsoft Certified Motherboard for their operating systems.
此主板是作为微软认证的主板销售的。

Me:

I've found separate DSDT tables that the BIOS hands to Linux specifically, changing it to point to the DSDT tables Vista gets fixes all Linux issues with this board.
我找到了你们 BIOS 里面特别指定给 Linux 的 DSDT 表。把这个表改成特别指定给 Vista 的就能解决之前 Linux 下的所有问题。

So while I accept that you've gotten some kind of Microsoft Certification (doesn't surprise me), that does not make your board ACPI capable, just that Windows is better at coping with glitches custom tailored to it, for this purpose.
所以,尽管我同意(也不诧异)你们取得了某种微软认证,但是这并不能说明你们的主板兼容 ACPI,而只是 Windows 更长于应对那些微软量身认证的诡异之处而已。

Foxconn:

Dear Ryan,

Stop sending us these!!!
不要再给我们发这样的信了!!!

Me:

Your BIOS is actually pretty shoddy, I've taken the liberty of posting everything that's wrong with the DSDT lookup tables and how to fix some of it so the community that has already purchased your filth can make do with it, also, it's now pretty much impossible to google Foxconn and Linux in the same sentence without getting hit by the truth, that your boards aren't good enough to handle it.
你们的 BIOS 确实非常次。恕我已将所有 DSDT 查询表的谬误以及一些补救办法公开,这样已经购买了你们产品的人才不至于束手无策。而且,现在同时搜 Foxconn 和 Linux 的话,不看到这些真相已经很难很难——你们的主板不够行。

Have a very nice day.
祝好。

Foxconn:

Dear Ryan,

Surely this is the way to ask for us to attempt to fix something that is not supported in the first place.
要求我们提供不支持的修正服务,这真是个好办法。

Me:

Would it be so difficult? I mean really? I suppose you've never heard of building a happy customer base vs. just angering everyone that deals with your products to the point they make sure others don't make the mistake of buying them.
有那么难么?真的那么难么?是构建一个满意的用户群?还是激怒让每个购买了你们产品的人,直至他们会努力告诉别人不要再犯同样错误的程度?我猜这个问题你从没考虑过。

You know, I have several computers, and they all support any OS I want to put there, as well they should, if you can't fix the damaged BIOS you put there intentionally, can you at least put a big thing on the site that says no LInux support so people won't make the mistake of buying your stuff?
要知道,我有好几台电脑。它们全都支持、且应该支持任何我想要的操作系统。如果你不能修复你刻意制造的问题 BIOS,你能否至少能在网站上写清楚“不支持 Linux”几个大字,这样人们就不会再因类似错误而买你们的东西?

Your DSDT table looks like it was written by a first year computer science student, it is scary, I will not just shut up and go away until I feel like I've been done right, this can end up on Digg, Slashdot, filed with the FTC that you are passing bad ACPI data on to Linux specifically.
你们的 DSDT 表看上去就像个一年级计算机本科生的作品。这太恐怖了。只要我认为我做的没错,我不会就这样安静的走开,这件事会出现在 Digg 上,Slashdot 上,以及公平交易委员会(FTC)的投诉里——你们在刻意给 Linux 传递有问题的 ACPI 数据。

I saw you targeting Linux with an intentionally broken ACPI table, you also have one for NT and ME, a separate one for newer NT variants like 2000, XP, Vista, and 2003/2008 Server, I'm sure that if you actually wrote to Intel ACPI specs instead of whatever quirks you can get away with for 8 versions of Windows and then go to the trouble of giving a botched table to Linux (How much *is* Microsoft paying you?) it would end up working a lot better, but I have this idea you don't want it to.
我知道,你们给 Linux 故意准备了一套有问题的 ACPI 表。你们同时另有一套给 NT 和 ME,一套给更新一点的 NT 家族,像 2000、XP、Vista 以及 2003/2008 Server。我敢肯定,如果你们真的按照 Intel ACPI 规范写代码,而不是什么乱七八糟手段都用上来迎合 8 个不同版本的 Windows 却丢给 Linux 一个烂表(微软了你多少钱?),结果会好很多很多。但是我感觉到你们不想这么做。

Last edited by TheAlmightyCthulhu; July 26th, 2008 at 12:55 PM.

(译注:这篇帖子在 ubuntu 英文论坛上得到了413 位用户的感谢,ubuntu 论坛的这个感谢系统挺有创意)

下集预告:中英对照:富士康的醒悟。

2008年10月21日

戴绿帽子要从娃娃抓起



上班路上偷拍,东京初台。

以下八卦来自互联网,切勿当真。

《元典章》规定:娼妓之家长和亲属男子裹着青头巾。由此,“青头巾”就与娼妓之男性亲属有了联系。由于青、绿二色比较接近,又同属贱色,人们习惯于说“绿头巾”。由于绿色与娼妓有关,后来,“绿头巾”专用来指妻子有不贞行为的男人,并演变成了“绿帽子”。

2008年10月6日

物美价廉

自由市场经济理论里,只有生产者和消费者两个角色。消费者的购买行为实际上等于是在用钞票对生产者进行投票,在一轮又一轮的票选中,生产者们重复着“优胜劣汰”的古老传说。

可是,“优胜劣汰”是消费者用钞票投选出来的。如果大量钞票都投的不那么优,结果就很难说是优胜劣汰,而很可能恰恰相反了。

消费者投票的依据,我觉得大概可以总结为“物美价廉”四字。现在的问题就在于,随着科学技术的日益发展,作为消费者越来越难以判断“物”是否“美”。比如,喝了这么多年牛奶,你可能根本不清楚什么是三聚氰胺。(多嘴一句,再比如,用了这么久电脑,你可能根本就不知道,你购买的主板可能早已被某公司收买而只能在 windows 下工作正常

而相比之下,判断“价”是否“廉”就简单很多了。于是怎么样?一个可能的结果就是既然东西看起来都差不多,那就比谁更便宜了。

如果某个行业存在一种方法能够既瞒住消费者的眼睛又偷工减料一本万利,那么这个行业就很有可能整个烂掉。比如乳制品。

当然,实际的市场情况远比自由市场经济理论复杂。实际控制商品质量的可能并不是初始生产者(比如奶农),而是聚集了大量资本的加工/销售商(比如三鹿);消费者难以鉴别物美,从而将鉴别任务委托给公众部门(比如质检机构);在生产消费这个圈子之外,可能还有一个监督机构(比如司法系统)。但是,无论是生产者、销售商、消费者、公众部门还是司法系统,都有各自不尽相同的利益。利字当头,凡事皆有可能。

那作为群体最为庞大的消费者,我们该怎么办?我认为,最根本的办法是不要让别人有机会蒙住我们的眼睛——即我们需要继续进化。进化当然不是说要我们的身体去适应有毒的奶粉,人类进化从来也不是靠身体的百毒不侵;而是要我们继续开发我们的大脑,提高识别“物”是否“美”的能力。

设计再精良的制度也不如自己的头脑更可靠。

或许有人觉得继续往人类小小的脑袋里塞这些越来越多的东西有些残忍。但是生命本当如此。即使人类已经贵为进化链顶端,不需要再如非洲草原上的野牛一样靠狂奔不息来赢得生存,但我们依旧无法摆脱继续进化的命运——与人斗其乐无穷。

2008年9月29日

从来不曾想起,永远不会忘记

记得在初中写作文时曾因为写了这样的句子
…仿佛那样遥远,又那样切近…

而被语文老师批评。时至今日,我依然没能看出这样的句子有何不妥,只是以为这样的句子可能有点矫情。

后来再次看到类似的句子,就是标题这句。是在艺术人生采访童子荣的那期节目里,童老师的粉丝们在演播室现场拉起的巨大横幅上。

直到前两天,突然想起两句歌词
竹子开花咯喂
咪咪躺在妈妈的怀里

竟然夜不成寐。于是上网,感谢 youtube,居然能够找到如此珍贵的视频




程琳这个名字好熟悉啊!于是一发不可收拾,一路追索下来,竟翻出了侯先生的名字。这才发现,包括这首“熊猫咪咪”在内许多我耳熟能详的歌曲,竟然都出自侯先生之手。

比如曾经红极一时却突然销声匿迹的“龙的传人”。




还有这首被无数人翻唱过的“酒干倘卖无”。标题这句话,应该最早就是出于此处。




人如其歌,侯先生是性情中人。我至今仍认为侯先生是当年广场上几个头头里面说话靠谱的一个。

“很多人说,广场上有两千人被打死,或者几百人被打死;在广场上有坦克碾轧学生撤退的人群,等等。”

“我必须强调,这些事情,我没有看见。那么我不知道别人是在哪里看见的,我是六点半还在广场上,我一点都没看见。”

“我一直在想,我们是不是需要用谎言去打击那些说谎的敌人,难倒事实还不够有力吗?那么如果我们真正使用了谎言去打击说谎的敌人,那只不过是满足了我们一时的泄恨,发泄的需要而已。这个事情是个很危险的事情,因为也许你的谎言会先被揭穿,那么之后的话,你再也没有力量去打击你的敌人了。”


程琳说,侯先生应该被授予华语音乐的终身成就奖。对于我来说,即使没有人颁这个奖,他也是无冕之王,无情可矫——“从来不曾想起,永远不会忘记”。

2008年9月24日

自食其果

近日读 Gerald M. Weinberg 的《咨询的奥秘》,看到这段“福特基本反馈公式(Ford's fundamental feedback formula)”比较有趣,摘抄至此。


据传说,有一次亨利·福特就怎样阻止河流被工业化工厂污染的问题而被国会召见。福特对所有国会所考虑的复杂的立法不屑一顾,他提出了一条简单的法律,可以“一劳永逸地结束河流污染”,国会没有通过这项法律,但是它的两个部分却值得记住:

1,人们可以为任意目的从任意水域取任意多的水。
2,人们必须将相同数量的水返还到他们取水地点的上游。

换句话来说,人们可以对水资源做任意想做的事,但前提是他们自己必须伴随着随之产生的后果生活。


换成地道的中文表达,就是必须保证自食其果。

这其实还是个公平原则的不同表达。正如权利义务必须公平,风险收益必须公平,行为与后果也必须公平。如果用这样的基本思想来建立质量监督体系,大概就会避免很多问题——质检总局的领导们,大抵是不喝三鹿奶粉的。

2008年9月20日

东京都议会的广告

这是一张偶然在电车上看见的广告。

大意是通知一下本年度的东京都议会(大概相当于省级人大吧)第三次例会的日程,以及各种获得本次会议更多内容的渠道(直播的电视频道、网址及问讯电话)。

回忆我在国内亲身经历的民主生活,虽然从小就被告知是国家的主人,但是快三十年了,只在本科就读的时候行使过一次当家做主的权利——在三个不认识的人当中选两个。依稀记得那年某外系同学希望当选区人大代表而四处活动,结果是 bbs 上发的帖被删,据传本人也被学校警告。至于后来我们选上去人主张什么,又干了什么,鬼知道。

2008年9月13日

何患无辞

你说你的,我说我的,很热闹。

当事人方面

三鹿:不法奶农向鲜牛奶中掺入三聚氰胺

网友妙评(出处不详):

三鹿:奶农干的
奶农:奶牛干的
奶牛:草干的
草:艹……


政府方面

卫生部:三鹿集团应该承担很大的责任

质检总局

质检总局副局长 蒲长城

  刚才这位朋友说到,在质检总局的网站上看到了有关消费者的投诉。我们了解到的情况是,今年6月份确实有一个食用了三鹿奶粉的消费者投诉,说食用三鹿奶粉造成了对身体健康的影响。我们负责在网站上答复消费者提问的,及时给了回复,希望他详细提供相关的信息,以便我们进一步详查。遗憾的是,后来我们再没有得到较为详细的信息,也没有再得到回复。


这个 6 月份的投诉就是在说这个吧(注:提问正文文末的“留言已隐藏”字样为快照保留之原文,以白色隐蔽……本引述予以保留):

问:
6月初,在湖南省儿童医院,6个月婴儿得肾结石!8个月得肾结石!10个月又是肾结石?天哪!!!共有5名婴儿同样的病,更巧是同样一直食用一种奶粉。
实属罕见病例,医生表示可能是奶粉问题导致结石,可能是钙和磷的成分。
问题1,医院有首例病例就应该调查原因,对症下药?
2,6月8日投诉该奶粉公司,6月12日才有有关负责人去医院看望,这就是大公司的效率?
3,有投诉工商部门,是不是应该引起高度重视,彻查此事?肾结石—可能导致肾衰竭,根本就没有救的。
4,6月25日该奶粉公司还没有给出结论,一直拖下去,受害的就只有消费者,可怜的就是婴儿。
6月大小孩父亲 瞿先生 13786359388
婴儿每天哭,医疗费用昂贵家庭负担重
三鹿奶粉 有婴儿结石作为证据
急急急:
1,调查奶粉问题,作为消费者,作为妈妈,希望奶粉赶紧下柜,并对造成伤害的亲属公开道歉赔偿。
2,通过媒体告知,一直服用三鹿奶粉的婴儿去医院检查。
3,国家有关部门应该制定标准,在钙和磷的含量上
请尽快查清奶粉是否有问题,为避免更多婴儿得此病留言已隐藏

答:
请你提供问题奶粉的详细信息,以便我们调查处理。


猜测:高大全们都很忙,手机号还不够详细。

总评:有钱大家赚,黑锅我不背。

2008年9月12日

两个链接

原帖已 404,立此存照(google 的快照,请自行爬墙)。

20080724-6021-28494+aqsiq.gov.cn


20080630-1622-25262+spscjgs.aqsiq.gov.cn


总理说:是人民在养你们,你们自己看着办。

2008年9月10日

giplet 更新到 0.1.3

giplet 作用很简单,在 gnome-panel 上显示当前 ip。对我来说,其主要意义在于,当桌面因某种原因死锁(比如说,连键盘都失去响应)了之后,想尝试通过其他机器 ssh 过来杀掉捣乱进程时,不至于因为不知道动态分配的 ip 而束手无策。

然而一直到 0.1.2 之前,giplet 都只能设定一个 interface,要么有线,要么无线,像我这种有线无线经常混用情况,就有点麻烦——频繁更改 interface 吧,不是办法,而且时常会忘记;放两个 giplet 吧,panel 又太挤。

昨天突然心血来潮,翻来了 giplet 的源码看了看。要实现从多个 interface 获得 ip 很简单,几分钟就搞定了(赞 python,上手难度几乎为零),做了个 patch 给 Erik(作者)。

今天收到 Erik 回信,他现在没时间管这摊(也难怪,0.1.2 发布都已经是 2006 年的事了),于是我被加入到了 giplet 的项目中,打上我的和 yanik 同学早在 4 月份就提交的 patch,0.1.3 就这样诞生了。

这个版本的 giplet 主要更新有三:

1, 修正 about 窗口 close 按钮无效。
2, 增加拷贝 ip 到剪切板。
3, 支持设置多个 interface(空格分隔),giplet 将显示第一个可用的 ip。

看起来用 python 写 UI 很爽,有空应该多关注一下。

2008年9月1日

弱民无民主

零、引

niobe 的好文“民主是什么”,应该是 2006 年之前的老文了,我今日才偶得拜读,实在相见恨晚。

1933 年的德国和 1936 年的美国,为何会作出截然不同的选择?难道仅仅是因为德国人“轻易相信了希特勒的承诺”,而“美国人可不是这么考虑问题的”么?

一、博弈

我们都知道弱国无外交。大家能坐下来谈,靠的是实力(请回忆联合国五大常任原子弹)。民主也一样。大家坐下来投票、选举,靠的也是实力(这个实力是什么,稍后再说)。所以,所谓民主其实是在势均力敌的情况下产生的一种博弈模式。如果这种势均力敌的形势被打破,那么博弈的规则也很可能会被改变,民主制度就会被削弱、甚至可能彻底失去其制约能力。

二、实力

既然大家都是文明人,那么对于参与民主博弈的人来说,实力基本上等于智慧。

那智慧又是什么呢?假设大家的智商都没有问题,那么智慧程度的高低则大抵取决于信息的对称程度——即如果你不笨,却做了蠢事,则多半是着了信息不对称的道(大部分情况下,就是被人骗了)。

这里举一个不太恰当的例子:你在民主活动中的判断,好比是在做算术题——例如 3 * 7 = 21——你的判断正确与否就在于能否得出正确的结果 21。那么,想要得到 21,就要求你至少知晓两类信息,一是乘运算法则,二是参与计算的数字。这就是判断信息是否对称两个要素,即规则信息和数据信息,二者缺一不可。

三、分布

回到民主的讨论上来。前面说过,民主博弈的前提是参与者实力的势均力敌,而实力又约等于智慧,那么,用统计学的方法来描述“势均力敌”,就可以概括为(不懂方差为何物的同学请自行补课)

民主制度能否正常运行,要看参与者智慧的分布情况。这个分布的期望值或许鲜有意义,但是方差绝不能太大。


1933 年的德国,出了希特勒这么个人精,智慧分布的方差陡然增大,民主制度轰然崩溃。

1936 年的美国,罗斯福、大法官、提起诉讼的公民、推波助澜的律师,个个都是人精,虽然智慧分布的期望值很高,大家也斗得其乐无穷,但方差却不大,民主制度故无大碍。

四、对策

对于一般民众来说,管他是民主博弈还是其他什么博弈,实力不济的总是吃亏更大的一方。所以当务之急还是提高实力。

如何提高实力(智慧)呢?智商或许是很难改变的,那么根据第二节的分析,剩下的就要看信息对称与否了。这里简称玩信息不对称的参与者为骗子,防止信息不对称给自己造成的劣势,换句话就是要增强识别骗术的能力。

高级一点的骗子玩规则信息不对称。譬如轮子功,受其影响的人直接洗脑,导致你再给他什么数据他也得不出正确的结果,危害力极强,是谓邪教。对付规则信息不对称基本要靠教育。一般来说,受教育程度越高,这种骗术的门槛就越高。所以在教育启蒙早的发达国家,已经鲜有规则不对称的事例发生。顺便提一句,跟政治相关的规则,历史本身就是很好的教科书(当然,如果所谓的学史只是死背了一些时间地点人物事件就算了)。

更多的骗子则玩数据信息不对称(包括政府、媒体、政党都很喜欢玩这手)。即使在通信技术如此发达的今天,以偏盖全,断章取义,小题大作,指鹿为马,甚至干脆封锁消息,也都不少见。对付数据信息不对称,没有太好的办法。除了仰仗技术更加进步(可能很缓慢),还是得靠自身的力量提高获取、甄别数据信息的能力。顺便提一句,获取数据信息的能力和甄别数据信息的能力同样重要,放假数据瞒天过海也是骗子们常见的技俩之一。

五、如果

看,民主博弈对参与者的智慧要求可不低啊!如果形势并不允许而硬推民主制度,或者哪怕已经推行了民主制度而形势有所变化,民主选举多半会蜕变成大众选秀,直至闹剧。

远的不说,就看台湾近些年的“大选”,实在是让人很有这样的感觉——大陆一直留着台湾不收,就是在把它当作民主制度的试验田。

2008 年的美国大选(阮先生的博客可能要翻墙参观,请自备云梯),也让人对今天美国人民的智慧分布多少有点起疑。

六、结论

以今天大陆人民的智慧分布,你觉得民主出来会是什么结果?——我总觉得,在这片连规则信息不对称都能被玩的如火如荼的神奇土地上,我们离民主博弈真的还有点远。

可是“今天我们中的有些人还太嫩以至于还不能推行民主制”这样的话我这闲人可以说,有些人则不太能。于是这些人想出了“社会主义阶段的主要矛盾是人民日益增长的物质文化需求与落后的社会生产之间的矛盾”这么个晦涩的说法。我的解读是,管他三七二十一,大家需要提高博弈实力才是真的。这个基本判断我认为靠谱。

所以,如果你真的向往如西方极乐般的民主制度,眼下来看,除了脱离这片土地,最应该做的是脚踏实地想办法改善国人的智慧分布而不是去故吹什么——即使你鹤立鸡群的认为自己已经具备了行使那“神圣的一票”的资格,你也需要时刻注意控制自己欲望和野心,帮助、监督“那些人”履行他们晦涩的承诺,为了让国人变得和你一样智慧而不懈奋斗。

2008年8月28日

湿度 80% 的日子

自打从东北回来,屋里的湿度计已经连续几天指示在 80% 这个位置了。虽然东京的气温和东北老家相仿,都是 25 度上下,但感觉却截然不同。在这样的湿度里工作生活,基本上不用担心静电对电子设备造成的潜在威胁,这对喜欢硬件的朋友来说是件好事,但我还是更喜欢神清气爽的东北秋天。

顺便延伸一下,看了点关于气温、湿度、风速和体感温度的资料,目前好像还缺乏统一的计算标准,就不贴链接了。

2008年8月25日

sun-pinyin && novel-pinyin @ aur

花了点时间,给 sun-pinyin 和 novel-pinyin 做了 PKGBUILD,放到了 aur 里。前者是在 linuxsir 上狱卒兄的成果基础上改出来的(linuxsir 网线被拔中——谁干的大家都知道),后者在 alex epico 极为迅速的补丁之后在我的环境里也已经没什么问题了。包的名字分别是 scim-sunpinyinscim-novelpinyin,用 yaourt 安装起来很方便。

需要提醒的是:

一、sun-pinyin 所需要的两个比较大的数据文件(一个 23M+,一个 6M+),opensolaris 官方下载点似乎不支持断点续传,国内的用户下起来可能会比较吃力。

二、novel-pinyin 目前使用的图标和 scim-pinyin(智能拼音)一样,不过输入法名称改成了“新智能拼音”,切换输入法的时候留意一下就好。

2008年8月8日

sun-pinyin 简单试用

只论输入法的话,linux 确实没法和 windows 比。后者优秀的拼音输入法实在是太多了。相比之下,linux 的选择就少很多,而且也不够“现代化”

只是 suzhe 在 google 的工作似乎和输入法并没有太多关系,历史就这样凝固了好长一段时间。后来出了个 scim-python,然后同作者又开始打 scim 的主意,自行开发了个 ibus,让 linux 输入法这个小圈子又热闹了起来。

然而今天要说的不是 scim-python,也不是 ibus,而是 sun-pinyin。根据官方说法,这可是一个很“现代化”的拼音输入法哦。

SunPinyin (developed by Sun Asian G11N Center, shipped since Solaris 10, and opensource'd on OS.o), which is a SLM (Statistical Language Model) based IME.


简单试用下来,效果还可以。选项不很多,但是比古老的 scim-pinyin 还是有进步的。比如我一直用来评价拼音输入法的两个用例(很片面,嘿嘿)——en 能否打出“嗯”字,zhen 能否打出“帧”字,sun-pinyin 就一对一错,比 scim-pinyin 颗粒无收要好一些。但后者估计为整句输入设计的缘故,候选字数很少,像我这样习惯了短语输入的不太适应。而且不够稳定,时常会出现拼音字母和汉字都被输入的情况。

另外还有一个不那么引人注目的“现代化”拼音输入法:novel-pinyin。尝试编译了一下,搞得 scim 崩溃了。可能离实用还有点距离吧。不过如果真的和 sun-pinyin 合为一体,还是很令人期待的

archlinux 用户如果想尝试 sun-pinyin 的话,可以参考这里。我正在联系那帖的楼主,商量下是不是把他的成果直接放到 aur 上去。

修订(2008-08-25):已经扔到 aur 里面了,包名叫 scim-sunpinyin。

2008年8月2日

给 pcmanx 找个合适的英文字体

pcmanx 可以分别指定中文字体和英文字体,很贴心。但是实际用起来总有些小问题。比如,如果中文字体使用文泉驿正黑的话,英文字体选起来就有些麻烦。常见的 Bitstream Vera Sans Mono / Dejavu Sans Mono 的 W 显示不全,其他常见的等宽英文字体跟正黑配在一起基线位置有点怪怪的等等。

这里推荐一套能够在 pcmanx 下,跟文泉驿正黑珠联璧合的一套字体——“sazanami gothic”。从名字上看出点蹊跷了吧,没错,这其实是一套日文字体。其英文部分是等宽的,基线安排的和文泉驿正黑也差不多,在 pcmanx 里面效果很好。archlinux 下的包名是 ttf-sazanami。ubuntu 的话是 ttf-sazanami-gothic。

其他都是废话,直接上图。

2008年7月31日

两首老歌

流行音乐方面,我向来都很迟钝,所以就总是在老歌里徘徊。最近又回味了两首老歌,一首苏芮的《一样的月光》,一首郑智化的《中产阶级》。

蘇芮-一樣的月光

作詞:吳念真/羅大佑 作曲:李壽全 編曲:陳志遠

什麼時候兒時玩伴都離我遠去
什麼時候身旁的人已不再熟悉
人潮的擁擠 拉開了我們的距離
沈寂的大地 在靜靜的夜晚默默的哭泣

什麼時候哇鳴蟬聲都成了記憶
什麼時候家鄉變得如此的擁擠
高樓大廈 到處聳立
七彩霓虹 把夜空染得如此的俗氣

誰能告訴我 誰能告訴我
是我們改變了世界
還是世界改變了我和你

誰能告訴我 誰能告訴我
是我們改變了世界
還是世界改變了我和你

一樣的月光 一樣的照著新店溪
一樣的冬天 一樣的下著冰冷的雨
一樣的塵埃 一樣的在風中堆積
一樣的笑容 一樣的淚水
一樣的日子 一樣的我和你
一樣的笑容 一樣的淚水
一樣的日子 一樣的我和你


中产阶级

词/曲:郑智化

我的包袱很重
我的肩膀很痛
我扛着面子流浪在人群之中

我的眼光很高
我的力量很小
我在没有人看见的时候偷偷跌倒

我的床铺很大
我却从没睡好
我害怕过了一夜就被世界遗忘

我的欲望很多
我的薪水很少
我在台北的马路上迷失了我的脚

没有人在乎我这些烦恼
每个人只在乎他的荷包
我常常喝着可乐我吃着汉堡
只是心中的空虚饥渴无法填饱

是不是就这样平凡到老
我的日子一直是不坏不好
是不是学会了放弃思考
这样的我才能够活得很好
头壳坏掉才能够活得很好

这两首歌,小的时候喜欢旋律,长大了喜欢歌词。

2008年7月29日

或许韩国人并不那么笨

前阵子韩国人抵制美国牛肉,夸张到了近乎疯狂的地步。很难理解,一面是本国牛肉价格狂高,已经上架的美国牛肉供不应求;一面是大批民众围攻政府要求停止进口牛肉——感觉既分裂又自虐。

直到最近读到郎咸平的“产业链阴谋——一场没有硝烟的战争”,才有所醒悟。

韩国总统李明博要进口美国牛肉,读者知道不知道韩国民众为什么这么激动要冲击韩国政府呢?!读者以为韩国人只是好斗吗?我告诉各位读者,韩国人比我们聪明的多得多,他们从亚洲金融危机学来太多经验那就是韩国一旦成功了进口美国牛肉以后,美国牛肉特别的便宜,他将席卷全韩国牛肉户,把全韩国养牛户淘汰,到最后,韩国牛肉价格将被国际金融炒家掌控!所以我个人认为,韩国老百姓反对政府进口牛肉是有原因,因为只有自己生产,才不会被别人所控制,就这么简单!


文中“金融超限战”的概念,感觉和《货币战争》所要表达的中心思想类似(没正经读过《货币战争》,不敢肯定),大概就是说国际金融巨头所操纵的世界范围内的金融垄断,可以操纵几乎任意商品的价格。

而“二元经济”说,和陶显芳先生的观点(为什么大学毕业生工作难找一)本质上是一致的,说的是国内营商环境的恶化,导致资源大量变成热钱(股市、楼市),进而变成泡沫,进而引发通货膨胀。

以上两个观点,我没有把握说是正确的,因为手里没有可信数据(国家统计局的数据你信么?媒体专家们提出的数据你又信么?),所以只能以亲身经历相验,以自己有限的智力判断,感觉是对的。如果这些理论是对的,那么韩国一般民众所表现出来的,就远不是分裂和自虐,而是一种智慧了。

突然间想起老马的那句“资本来到人间,从头到脚,每个毛孔都流着鲜血和肮脏的东西”。突然间也有点明白了为何无论日本本土的产品——从农产品到电子设备——如何质次价高(或者说是质平价高吧,或许日本的农民真的已经尽力了),日本人都会近乎偏执地优先选择国产。我们所处的这个时代,或许离文明而和谐的供求关系决定价格的自由市场经济还很远。

2008年7月18日

eclipse 的 svn 支持怎么这么差

毕业之前一直用的是 windows 平台,那时候除了写 delphi,拿 eclipse 写 java 也是很爽的事情。工作以来一直是 c++,主要平台是 linux,离开 eclipse 一晃就是两年多。两年的时间可以改变很多东西,delphi 已经物是人非,令人唏嘘不已了。

最近有机会重拾 java,才发现 linux 平台上 eclipse 对 svn 支持的是如此之差。有人或许会说,subclipse 不是很好用吗,装个插件就可以了啊——一开始我也是这么想的。

subclipse 的主页上,最新的版本是 1.4.x。这个版本的 subclipse 取消了 SVNKit 接口,只剩下了 JavaHL。而后者在 linux 平台上通常都是一个默认无效的选项,要使其生效需要手动安装 JavaHL 库(参见 subclipse 的官方 FAQ)。

然而,获得这个库并非很简单的事情。debian 系的可以直接加第三方源,RPM 系的可以拿搜到的 RPM 包碰碰运气,其他发行版的估计就得自行编译了。还好 FAQ 那页接下来就是一系列的编译、安装步骤,看起来真是够麻烦。

无意间搜到了 subversive,号称是 eclipse 官方的 svn 支持插件。尝试了一下,堪称痛苦。网站提供的 update url 装倒是能装上,装上了却不能用。仔细扫一眼,原来还以来其他插件:

Important: In order to start work with the Subversive you should install SVN Connectors distributed from external location. Such scheme of distribution caused by licensing requirements.


这个“其他插件”的页面或许就是 subversive 进入 eclipse 前的老东家吧,其 svn connector 被可耻的标成了“optional”,晕。尝试装这个 optional 的 svn connector,提示又缺依赖插件若干……

这里给出一个能够快速解决问题的变通办法:安装 subclipse 1.2.x。即,将 subclipse 官网提供的 update url 改成 http://subclipse.tigris.org/update_1.2.x,装上之后 Window->Preferences->Team->SVN 里面把 SVN Interface 选成 SVNKit 即可。

附一、试了一下 netbeans 6.1,感觉很好。个人感觉完全已经可以取代 eclipse 了。
附二、回头试一下 jdee on emacs 如何。

2008年7月2日

笔记本硬盘到底能 unload 多少次?

之前写的文章(警惕 laptop-mode-tools 的 HD_IDLE_TIMEOUT 参数archlinux 下的 load/unload 问题还是那个硬盘 load/unload 的 bug ),都是基于“硬盘的设计 unload 次数有限,对此不加控制会影响硬盘寿命”这样一个前提。但对于这个前提自身是否靠得住没作过多关注。这次就拿着硬盘的 spec 来说一说这个事情。

我的本用的硬盘是 FUJITSU MHY2120BH,这里是其详细的规格说明书(PDF)。

1.10 节关于 Load/Unload Function 原文如下

The product supports a minimum of 600,000 Load/Unload cycles.
Unload is a normal head unloading operation and the commands listed below are
executed.

也就是说,这块硬盘的设计 Unload 次数不小于 60 万次。这是一个相当大的数字了。

1.11 节关于 Advanced Powermanagement (APM) 提及

SC = C0h - FEh : Mode-0 Active Idle → Low Power Idle
SC = 80h - BFh : Mode-1 Active Idle → Low Power Idle (Default)
SC = 01h - 7Fh : Mode-2 Active Idle → Low Power Idle → Standby

这个应该就是和 hdparm -B 所设置的值了。与 hdparm 的 manpage 略为不同的是,这块硬盘的 apm 有三个值段,默认是 128(这个和旧文的测试结果是相同的),也就是 Mode 1。

注意这段,只要进入了 Low Power Idle 状态,硬盘就会进行 unload 动作。

Active Idle: The head is in a position of extreme inner in disk medium. (VCM Lock)
Low Power Idle: The head is unloaded from disk. The spindle motor rotates.
Standby: The spindle motor stops.

这里应该注意一下两个容易混淆的概念,unload 和 spin-down。前者指磁头归位,后者指马达停转。

那么,Mode 1 下硬盘的具体行为是怎样的呢?还在这一节,看 Table 1.7(画表截图都够费力,这里就只贴文字了)

Mode-0: Mode shifts from Active condition to Active Idle in 0.2-1.2, and to Low Power Idle in 15 minutes.
Mode-1: Mode shifts from Active condition to Active Idle in 0.1-0.2 seconds and to Low Power Idle in 10.0-27.5 seconds.
Mode-2: Mode shifts from Active condition to Active Idle in 0.1-0.2 seconds and to Low Power Idle in 10.0-27.5 seconds. After 10.0-40.0 seconds in Low Power Idle, the mode shifts to standby.

也就是说,默认设置下(即使不用 linux),当硬盘在空闲了 10~27.5 秒之后就会进入 Low Power Idle 模式,也就是 unload 一次。

通常,我们应该认为出厂的默认设置应该是安全的。究竟有多安全呢?来算一下,按 18.75 秒 unload 一次(10~27.5 的平均值,其实这也是相当相当坏的情况了),60 万次的设计寿命可以支撑 11,250,000 秒,即 3125小时,即 130 天。这个数字看起来不那么乐观。但是能得到这么坏的结果,前提是你足够有耐心,每天 24 小时不间断地每 18.75 秒就激活一次硬盘,而且你的运气足够坏,硬盘恰巧在 18.75 秒之内就进行了 unload 操作而且恰巧 unload 60 万次就寿终正寝了。如果按每 1 分钟激活硬盘一次,每天 12 小时计算,结果会变成 833 天。而实际使用的场合,两次激活硬盘之间的间隔可能会很大。

出厂默认既然如此,还有什么可担心的呢。就算我这个人非常胆小,这块硬盘的 Mode 0 也足够用了(15 分钟 unload)一次,只是此时需要手动指定一下 hdparm -B 192。

当然,以上只是以我自己这块硬盘为准作出的结论,还不放心的朋友可以自己搜一下自己硬盘的型号、对应的 specification,自己给自己找个定心丸吃。

2008年6月27日

东京印象——电车

先上一张东京的电车全路线图。



有心的同学可以仔细找找,我日常通勤就是京王线,从つつじヶ丘(直译应该是杜鹃花之丘,因为确实有很多杜鹃花,但是中文名却被定成了踯躅丘,不知何意)到初台。

对比一下北京 2008 地铁线路图,北京的轨道交通还是很有潜力可挖的 :)



再来一张京王线的电车路线图。



和北京地铁不同的是,东京电车有快慢车之分,而且分门别类决不亚于国内长途铁路运输(请回忆普快、特快、贼快直至动车组),例如上面给出的京王线电车,便有各停(每站都停,这就是北京地铁了)、快速/通勤快速(通勤快速在上下班高峰时段若干站不停,其他和快速相同)、急行、准特急、特急之分。想要有效率地在东京城里移动,必须能够看懂上面的指示图乃至牢记时刻表若干。看出来了么?从つつじヶ丘到初台,能够搭乘到通勤快速或者急行是最省时间的。

对于不熟悉的路线,出行之前做做功课很有必要。好在东京在这方面做的还不错,yahoo 还有其他很多网站都能满足要求。东京的电车执行严格的列车时刻表,除非有人卧轨或严重恶劣天气,一般都不会延误。

和北京地铁不同,东京电车并不是轨道供电,而是架在空中的(估计是日本雨水多,铺在地上容易短路吧)。曾经跟同学聊天开玩笑,想要摧毁东京的交通,用美军那种碳纤维炸弹扔几个过来就立竿见影。而北京,或许一次强对流天气就够了。

2008年6月26日

订阅 spaces.live.com 的 rss

登录 live.com,所有的 spaces (包括我自己的)都无法自动发现 rss 订阅(firefox 3)。退出登录,如果幸运(比如允许匿名查看的 spaces)的话,可以自动发现 rss 订阅。否则会温馨提示“您需要具有权限才能查看此共享空间”。

机灵点的通过 Google 或其他途径可以知道在 spaces 地址后面直接加“/feed.rss”即可。驽钝点的(比如我)则有可能挨个提示朋友“你的 blog 为啥不开 rss 订阅”。

勤快点的(比如我)就在首页明显位置加个 rss 订阅链接,不管浏览器能否自动发现,这个链接总是不难找到(起码比新浪博客的位置好得多)。

2008年6月24日

东京印象——出租车

最近有同学问我,晚上参加居酒会错过了末班电车为啥要睡在公司而不打车回家。看来虽然我一直在强调东京的主要交通方式是城市铁路(电车),但是一直以来都没有从反面说明为什么日本人不怎么打车。

这里描述一下东京出租车的计费方式,各位和自己本地的出租车资费对比一下,大概就心知肚明了。

1、起步价 710 日元(合人民币 45 元左右),里程 2 公里。折合成购买力的话大概和国内一顿吉野家的价钱相同。
2、超过 2 公里,每 288 米加价 90 日元。折合每公里 312.5 日元(人民币约 20 元)。
3、时速低于 10 公里/时的情况下,每 1 分 45 秒(105秒)加价 90 日元(人民币 20 元)。
4、深夜时段(22:00 ~ 5:00),费用上调 20%。
5、计费超过 9000 日元(人民币 573 元左右)的话,可以打 9 折。

以上资费信息来自日本交通株式会社,其他各出租车公司的资费或许有略微不同,但不会有明显差异。

从我在东京的住处到公司,地图直线距离 12 公里左右,这样算的话车费在 4600 日元左右(人民币 293 元)。当然还要考虑到,出租车不可能在地图上走直线,而且还要加上一路上等红绿灯的时间 / 105 * 90 日元——东京的红绿灯比北京之多不少——估计最终的花费会在 6000 日元(人民币 382 元)左右。这要是在北京打车的话大概不会超过 38 块人民币。想想自己在东京的收入远没有在北京的 10 倍那么多,而且在北京的时候打车也挺奢侈,所以该忍的时候也就忍了。

还找到一篇两年前中国青年报上的旧文,大家也可以参考。

2008年6月18日

双喜临门

firefox 3 正式发布。
wine 1.0 正式发布。

对我来说,后者更令人瞩目一些,毕竟 0.9.xx 了那么多年。虽然 wine 的世界里,中文的声音似乎永远都没人听得到。

Firefox 3.0 是个好东西,但是我并不很认同什么冲击吉尼斯下载记录的营销手段。据称 Mozilla 的官网还一度不堪重负。我还是老老实实等 archlinux 源里更新好了。

2008年6月17日

复杂到令人发指的东京车站

之前的文章提到过,东京的主要公共交通都是靠四通八达的城市铁路(在日本多数被称为电车,也有少数全程地下运行的被称为地铁)。而多条城市铁路交汇的大型车站,结构必然十分复杂。前两天找到了这幅图,可以给大家一个更直观的认识(点击可以看大图)。



相比之下,西直门实在是小巫见大巫(哦,或者说西直门并不复杂,只是设计的比较脑残)。

只是不知道这样的结构抗震性怎么样,以及如何在这样复杂的结构里迅速逃生。

2008年6月2日

thunderbird + google reader,放弃其它 rss 客户端

linux 上常用的 rss 客户端,一个是 liferea,一个是 akregator,分别对应 gnome 和 kde。两个我都用了挺长时间。转到 archlinux 之后就一直是 liferea,因为受不了 kde 粗放的打包方式,为了一个 akregator 要装那么多不相干的东西进来。

结果最近 liferea 就出了点不大不小的问题:正在密集 update feed 的时候崩溃了。结果我的 unread 搜索文件夹里面就出现了 10 篇幽灵文章,他们并不存在,但是时时显示在那里,如果尝试将这些幽灵文章标记为已读,则 liferea 必然崩溃。(这个问题非常规办法能够解决,最后多亏了 liferea-devel 列表上某开发人员给的我一堆 sql 命令)。

终于下定决心“再也不能这样活”。archlinux 能够从源里方便安装的 GUI rss 客户端除了 liferea、akregator 就只有 rssowl。装上试了试,居然一 update feed 就死锁在那里。还剩下一个选择就是 Thunderbird。只是 Thunderbird 对 rss 的支持并不是那么令人满意(参见此旧文)。

稍微动了动脑子(生活在这个时代,最难有机会做的事情恐怕就是动脑子了),决定试一下 google reader。如果 Thunderbird 搞不定某些 rss,那么可以让 google reader 来完成这个任务,如果运气足够好,Thunderbird 和 google reader 之间没有什么问题的话,那么问题就迎刃而解了,而且有 google reader 做网络中间层,对于跨平台共享数据也是很有意义的。

事实证明我运气很好。
1、从 liferea 导出所有订阅的 atom 文件。
2、从 google reader 导入上述 atom 文件。
3、在 google reader 上将必要标签设置为“公共”。
4、在 Thunderbird 里面订阅上述标签,完毕。

想了想这样的解决办法的优缺点:
优点:
1、摆脱特定的 rss 客户端。
2、利用网络存储,跨平台,利于多点访问数据。

缺点:
1、无法提供原来 liferea 的监视评论的功能(如果有新评论 liferea 会将文章题目置为灰色粗体)。
2、从 google reader 订阅的标签必须设置为“公共”。

2008年5月28日

archlinux 下复原 firefox 和 thunderbird 的图标

mozilla 对于 firefox/thunderbird 等等一系列旗下产品的商标策略导致了绝大多数发行版里面都去掉了官方的 logo/brand。只是去掉之后又不能没有,而勉强凑合上来的基本都很难看。比如 archlinux 使用的 big echo(替换 firefox)、mail/news client(替换 thunderbird),实在是难看的可以。

好在有很多办法能把原来的 logo 换回来。其实也不难,怎么换出去的怎么换回来就是。ubuntu 论坛上就贴过类似的脚本。可惜 ubuntu 下面命名都是 mozilla-firefox,mozilla-thunderbird 等等,脚本没有通用性。

archlinux 上已经有了一段脚本,但是只恢复 firefox。于是照猫画虎写了一段用于恢复 thunderbird 的,喜欢的朋友尽管拿去用好了。

2008年5月27日

寻回街机厅里的感动——推荐 GGPO

GGPO 何方神圣?简单的说,这就是一个街机模拟器。但是,在前有 NeoRageX、WinKawaks、Nebulas 等逐鹿中原,后有 MAME 一统江湖的模拟器界中能够脱颖而出,GGPO 绝非浪得虚名。

如果说老牌模拟器让你终于能够无限投币而圆了儿时梦想的话,那么 GGPO 则通过网络,将你重新带回了那个充满喧嚣、热闹非凡的街机厅(如果你恰巧是个好学生,没怎么参与过早期开发智力运动,那么可以回忆一下曾经几个大男生在不足 10 平米的宿舍里汗流浃背地挤在一个键盘上切磋 KOF 的日子)。没错!有了 GGPO,你将不再是一个人在战斗!

GGPO 的网络对站功能做得相当精彩。KOF 98 虽然还是 experimental 性质的支持,但是对战起来感觉和本地几乎没有区别。更妙的是,即使不参加对战,也可以以观察者的身份随意加入正在进行的对战之中。当年我囊中羞涩,虽然也是街机厅的常客,但看得多玩得少。没想到网络时代仍旧能够不出力看大戏,GGPO 设计的还真够体贴。

GGPO 使用起来也很简单。先从官网下载最新版本,安装。如果你的机器上没有 .Net Framework 的话到这里找大门叔叔要。

既然是网络对战,那就意味着运行 GGPO 是要登录的。运行 GGPO 之后只要点 Create Account 按部就班即可。


和其他所有模拟器一样,GGPO 是不提供任何 Rom。下一步就是拷贝 Rom 文件到 GGPO 的指定目录了。没有意外的话,应该是这里
C:\Program Files\GGPO Client\roms


以目前 GGPO 上最为火爆的 KOF 98 为例,需要 kof98.zipneogeo.zip 两个文件。

登录进入 GGPO 之后,在 Game Room 选择游戏,右键点击右侧的在线玩家可以选择观战或者挑战。如果有人挑战你的话,会有这样的提示。这里是真正的街机厅,这里有大把不停大叫 98 的饥渴各地玩家,也偶有义正辞严声明台湾永远是中国领土不可分割的一部分的爱国小将。不要以为不会有人挑战你,只想观战的同学记得在左下角把状态设置为 AFK(贴心提示:AFK = Away From Keyboard )。


开战之后会有真正的模拟器窗口(FB Alpha)弹出。Game -> Map game inputs 改键盘设置。游戏中按 T 键聊天(注意左下角)。


目前 GGPO 支持的游戏只有以下几个

Dungeons and Dragons - Shadow Over Mystara
King of Fighter 98
Marvel vs Capcom
Street Fighter Alpha 2
Street Fighter Alpha 3
Vampire Savior

绝不可谓多。而且服务器也经常出些问题(估计还是硬件资源不够吧,民间自发的项目大都有这样的问题),但是,对于一个刚刚 Alpha Test 的项目来说,她已经足够令人惊喜(目前在册的游戏居然同时有 CPS2 和 Neo 的 Rom,真是令人充满期待)。我们有理由展望 GGPO 很好很强大的明天。

最后上一张世界玩家的对战连线图。世界街机的中心在亚洲(不排除截图时欧美同仁都在睡觉的影响)。

2008年5月22日

linux 下搞定蓝牙耳机

其实今天在 linux 下面搞定蓝牙耳机并不是很难的事情。只不过因为这个问题在历史上曾经比较棘手,网上充斥了大量相对陈旧的、复杂的安装指南,导致人们一直感觉这样时尚的东西,可能 linux 支持起来很复杂。而实际上可能并不是这样。

linux 上的蓝牙部分,是 bluez 的项目来实现的。因此,只要紧盯 bluez 的官方网站,就可以获得最新、最权威的指导。比如搞定蓝牙耳机,基本上就只要参考官方 wiki 的这篇文章就可以搞定。如果更偷懒一些,这篇 blog 里的脚本也是 “拆箱即用”,方便的很。

相比之下,archlinux wiki 上的文章就相对陈旧。这里不得不佩服 gentoo,文档方面真是一流,从过去到现在,虽然写在一起有点杂乱,但是信息量很足。

最后奉上一点拙作,这是和之前那篇 blog 功能一样的一段脚本,不过不依赖 python,只要有 bash 就行(blogspot 的引用段落会打乱排版,如果自己加了 <pre> 标签,又有可能造成某些长行看不见,所以暂时就贴成这样了,还请见谅)。

#!/bin/bash

if [ $1 ]; then
ACTION=$1
else
ACTION="off"
fi

MAC="00:11:22:33:44:55" # your bluetooth device's mac

if [ "$ACTION" == "music" ]; then

echo Connect bluetooth headset in stereo mode

# active service
TMP=`dbus-send --system --print-reply --dest=org.bluez /org/bluez org.bluez.Manager.ActivateService string:audio`
DEST=`expr match "$TMP" '.*\(\".*\"\)'`
DEST=${DEST#\"}
DEST=${DEST%\"}

# create device
TMP=`dbus-send --system --type=method_call --print-reply --dest=$DEST /org/bluez/audio org.bluez.audio.Manager.CreateDevice string:$MAC`
DEV_PATH=`expr match "$TMP" '.*\(\".*\"\)'`
DEV_PATH=${DEV_PATH#\"}
DEV_PATH=${DEV_PATH%\"}

# connect
dbus-send --system --type=method_call --print-reply --dest=$DEST $DEV_PATH org.bluez.audio.Sink.Connect

# for gstreamer
gconftool-2 --type string --set /system/gstreamer/0.10/default/musicaudiosink "alsasink device=bluetooth"

echo done.

elif [ "$ACTION" == "voice" ]; then

echo Connect bluetooth headset in voice mode

# active service
TMP=`dbus-send --system --print-reply --dest=org.bluez /org/bluez org.bluez.Manager.ActivateService string:audio`
DEST=`expr match "$TMP" '.*\(\".*\"\)'`
DEST=${DEST#\"}
DEST=${DEST%\"}

# create device
TMP=`dbus-send --system --type=method_call --print-reply --dest=$DEST /org/bluez/audio org.bluez.audio.Manager.CreateHeadset string:$MAC`
DEV_PATH=`expr match "$TMP" '.*\(\".*\"\)'`
DEV_PATH=${DEV_PATH#\"}
DEV_PATH=${DEV_PATH%\"}

# connect
dbus-send --system --type=method_call --print-reply --dest=$DEST $DEV_PATH org.bluez.audio.Headset.Connect

# play
dbus-send --system --type=method_call --print-reply --dest=$DEST $DEV_PATH org.bluez.audio.Headset.Play

echo done.

elif [ "$ACTION" == "off" ]; then

echo Turn bluetooth headset off
gconftool-2 --type string --set /system/gstreamer/0.10/default/musicaudiosink "autoaudiosink"

else

echo Usage: $0 music/voice/off
echo default action is off

fi


p.s. 作为脚本来讲,python 真的很方便,用 bash 写起来要费力的多。那个去掉引号的部分,折腾了我两个小时。

最后,我的蓝牙耳机上的 mic 还没搞定(也就是说,上述 voice 部分不保证有效),如有高人路过恳请赐教,谢谢!

2008年5月1日

沟通问题

关于人与人之间的沟通问题,最近想的比较多。于是总是想起这一些老话。

“子非鱼,安知鱼之乐?”出自《庄子》。当然,这话不是庄子说的,而是惠子问庄子的话。庄子的回答是“子非我,安知我不知鱼之乐?”沟通之难,不要说人与鱼,即使是人与人,说同种语言的人与人,说同种语言且年龄相仿的人与人之间,很多时候都是难以逾越的鸿沟。庄子是个聪明人,知道跨越鸿沟之难,于是又划了一道鸿沟作为回答,讨巧却不那么厚道。俗语“家家有本难念的经”,“等你 xxx(可替换长大了、成家了、当爹了等等)才会知道”等等,莫不是同意的表达。

相比之下,孔老先生就厚道一些,儒家是入世的学问,自然提出了具体的做法。“子曰:‘不在其位,不谋其政’。”出自《论语·泰伯》。表达的就是沟通之难,不如噤声。不在其位,难以形成对称的信息。信息不对称,讨论就难有基础。鸡同鸭讲,对牛弹琴,倒算安全,倘若大家都年轻气盛,一言不合,拍案而起,立时就成了不和谐因素。老子讲“不尚贤,使民不争”,就是针砭此弊。所谓“贤”,俨然就是论坛里的某些“牛人”,深于资历(姑且),精于逻辑(一定),巧言如簧(通常),煽风点火(有意),挖了一个又一个大大的水坑。

说到了老子,他的办法也是让大家不尚不争。仔细想想,这其实很难。祸从口出,水民没有相当的素质,绝难看严自己的嘴。老子其实是以提升水民素质作为出发点的。但很奇怪的是,老子的话通常都被理解成相反的意思。比如“是以圣人之治,虚其心,实其腹,弱其志,强其骨。常使民无知无欲。使夫智者不敢为也。”这句常被人用来指摘老子提倡愚民,而“虚其心,实其腹,弱其志,强其骨”这四点,稍历风雨的人都知道还真不是一般战士所能企及。老子写了“大直若屈,大巧若拙,大辨若讷”,又写了“大音希声,大象无形”,就差很直白的写一句“大智若愚”,于是就被愚民指摘愚民了千年。一部千字《道德经》,白纸黑字且长流于误读,何况其它。所以上世纪 80 年代末,“理解万岁”风行一时(此语出处未作详考,可以参考这里)。确实,如果有办法促进理解而减少不和谐因素,实在是值得喊万岁的事。

孔、老提倡的做法,古今中外,一直适用。比如“搁置争议,共同开发”,比如“shut up and move on xxx (可以替换 f**king、coding、working 等等)”,都是换了个说法而已。只是今天的人们似乎都比古人要笨。古人之间,只要提醒不争就行了。今天的人们,还得进一步说明,闭嘴之后,该干嘛干嘛去。

2008年4月28日

警惕 laptop-mode-tools 的 HD_IDLE_TIMEOUT 参数

之前讨论影响硬盘寿命的 load/unload 的问题(见旧文一旧文二),都是集中于对 haprm -B 参数的调整。而这次要提醒大家注意的,是 hdparm -S 参数。

这里是 man hdparm 的 -S 部分的说明。

Set the standby (spindown) timeout for the drive. This value is used by the drive to deter‐mine how long to wait (with no disk activity) before turning off the spindle motor to save power. Under such circumstances, the drive may take as long as 30 seconds to respond to a subsequent disk access, though most drives are much quicker. The encoding of the timeout value is somewhat peculiar. A value of zero means "timeouts are disabled": the device will not automatically enter standby mode. Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21 minutes plus 15 seconds. Note that some older drives may have very different interpretations of these values.


看了之后冷汗直冒,实在是一个杀伤力很强的参数。如果有幸使用了 laptop-mode-tools,那么可以看一下 /etc/laptop-mode/laptop-mode.conf 里面,关于 -S 参数定义的部分。

#
# Should laptop mode tools control the hard drive idle timeout settings?
#
CONTROL_HD_IDLE_TIMEOUT=1

#
# Idle timeout values. (hdparm -S)
# Default is 2 hours on AC (NOLM_HD_IDLE_TIMEOUT_SECONDS=7200) and 20 seconds
# for battery and for AC with laptop mode on.
#
LM_AC_HD_IDLE_TIMEOUT_SECONDS=20
LM_BATT_HD_IDLE_TIMEOUT_SECONDS=20
NOLM_HD_IDLE_TIMEOUT_SECONDS=7200


我的 archlinux 上,laptop-mode-tools 使用的默认值仅仅是 20 秒!赶紧检查了一下 Load Cycle Count 的值(可能需要 root 权限,请自行 sudo),

$ smartctl -a /dev/sda | grep 193
193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 18556

如此高的数值,1 月份买的新机器,华丽地中招了 :(

预防办法很简单,将上述各 IDLE 值相应调大即可。不知道为什么 laptop-mode-tools 的默认设置会如此“有进取心的”(这里还真没想到用什么词比较贴切,英文可以用 aggressive)。或许对于这个问题,laptop-mode 的开发方并没有给予太多关注。

Spinning down too many times may kill hard drives

Desktop hard drives are usually rated for only 40,000-50,000 spinups, and one spinup every 10 minutes will kill your 40,000-spinup HD in 277 days. So this is NOT recommended for server use, unless you increase the spinup interval dramatically, to say once every hour or two. Laptop hard drives are usually rated for around 300,000 spinups, so those will last about 2083 days or 6 years if you have them powered on 24-7.

2008年4月25日

又犯了低级错误——这次是 vector

下午大部分时间都在调一段 c++ 代码。某线程共享 vector,用于存放对象的指针。创建对象之前先要检查一下是否已经存在符合某条件的对象,有则取消创建。对象创建时指针进入 vector,对象销毁时指针从 vector 中删除。

逻辑虽然简单,但是因为需要线程安全,所以加锁解锁也是步步小心。

但是跑起来之后还是出了问题。有时候明明 vector 应该已经空了,检查函数竟然返回存在的结果,导致某该被创建的对象创建失败。

根据日志输出,进行这个对象的创建前检查正巧位于某线程将某对象刚刚从 vector 中删除的时候,而检查出已存在的结果恰好是那个刚刚被删掉的指针,于是本能的怀疑是线程同步出了问题。

集中精神,走查代码(注意力都在加解锁上,这个过程耗时比较长)。一无所获。无奈,在日志输出中将每次 vector 操作时 vector 的状态进行了详细输出 。

令人瞠目的一幕出现了,vector 的 size 居然就从没有减少过!

赶紧检查 destructor,是这样写的:

...
LockMutex(...)
remove(foo_vector.begin(), foo_vector.end(), this);
UnlockMutex(...)
...


如果你也看不出不对,那么恭喜,你的 c++ 水平和我一样不济。不用多解释,看文档,好好补习一下 remove 到底是怎么用的。这个地方用 remove 其实并不合适。

将上述代码改成如下形式,问题解决。

...
LockMutex(...)
vector::iterator it=find(foo_vector.begin(), foo_vector.end(), this);
if (it != foo_vector.end())
foo_vector.erase(it);
UnlockMutex(...)
...


感受:
1、此例跟多线程一点关系也没有。“程序员的第一直觉几乎总是错的”说的就是这个。
2、“用非母语交谈,思维易受干扰”,用不熟悉的语言编程,也是一样。
3、不折不扣的 printf debug 流。
4、c++ 还是半吊子。

2008年4月14日

intel 集成显卡笔记本的背光控制

我这个新笔记本(Fujitsu MG75X/V)从打买回来装 linux,就没发现过怎么调节背光,无论是 Ubuntu 还是 ArchLinux。

不过一直以来我倒也不以为意。像我这种每天要盯着屏幕超过 8 个小时的人,通常屏幕亮度都比较低,而且不需要频繁的调节。屏幕亮度在某次设置 bios 时候调好了之后,就一直没有动过。

说来惭愧,要不是看到这篇帖子,估计我就会这么一直放任下去。

调节背光亮度,说来简单,就是一行命令的事。

xrandr --output LVDS --set BACKLIGHT [value]


至于这个 [value] 取多少合适,可以用以下命令来查一下。

xrandr --prop


关于背光的控制方式,可以 man intel 来仔细查看(之前也看到过关于背光调节的部分,但是因为当时没有找到可操作的办法——以为是折腾 xorg.conf 呢,没想到是 xrandr——所以一直没有引起注意)。在我的本上只有 legacy 模式起作用。在 legacy 模式下,value 的范围是 0~255。我常用的亮度值是 49。

既然有了调节背光的手段,一时兴起想把 Fn+F6/F7 两个背光调节键的问题也一并解决。照 ArchLinux Wiki 上的这篇文章简单试了一下,Fn+F6/F7 连 scancode 都打印不出来,“the key is not seen in any way by our os, we whould give up”。想来也是个很麻烦的事情,暂且搁置吧。2.6.25 内核眼看着也该发布了(已经 rc9 了,不远矣不远矣),或许新内核能直接带来些许惊喜也说不定。

2008年4月12日

异乡的云

4 月 11 日夜,云来势汹汹,遮天蔽月,席卷半穹。大图见我相册