Thursday, January 28, 2010
www.sun.com: 301 Moved Permanently
$ curl -v www.sun.com
* About to connect() to www.sun.com port 80 (#0)
* Trying 72.5.124.61... connected
* Connected to www.sun.com (72.5.124.61) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.4.5 zlib/1.2.3 libidn/1.9 libssh2/1.2
> Host: www.sun.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently< Server: Sun-Java-System-Web-Server/7.0< Date: Fri, 29 Jan 2010 05:38:56 GMT< P3p: policyref="http://www.sun.com/p3p/Sun_P3P_Policy.xml", CP="CAO DSP COR CUR ADMa DEVa TAIa PSAa PSDa CONi TELi OUR SAMi PUBi IND PHY ONL PUR COM NAV INT DEM CNT STA POL PRE GOV"< Location: http://www.oracle.com< Content-length: 0< Connection: Keep-Alive< Age: 0<* Connection #0 to host www.sun.com left intact* Closing connection #0
Tuesday, January 12, 2010
南洋随笔录之一: 纪念碑
http://www.sccci.org.sg/index.cfm?GPID=1189
位于市政厅(CityHall)与繁荣的现代商业城SuntecCity之间,是一片小型的广场,喷泉假山之间,中央便是这座庄严肃穆的纪念碑,碑文纪录相对简单,谨以此纪念日军占领期间死亡的新加坡人民;石碑正中呈四柱型,分别有中,英,马来,印度(Tamil)四种文字碑文,代表共同生活在这里的三个主要种族和使用的四种语言.暮色中石碑直指擎天,苍劲雄浑.与周围翠柏交相辉映.
其时1942年2月15日，日本攻陷新加坡，随后3年半至45年8月无条件投降，不完全统计有5万名新加坡华人遭杀害。日本占领时期死难人民纪念碑于1967年2月15日落成。此后，新加坡每年都要在纪念碑旁举行悼念活动。这里没有人民英雄纪念碑,本来没有英雄,战争所带来的,唯有苦难.
未知南京是否也有类似碑文,有机会当亲往拜访.
Friday, January 08, 2010
Samsung Developer Night
Samsung Developer Night, tonight, was really more like a social event, while some people there may be real developers, I've chatted with some of them, really exciting technology;
The first session is about SAMSUNG's own app store, while with this business model, I can say nothing about it, apple iphone has done it successfully, that does not mean every one can copy this model, SAMSUNG as a role of independent mobile phone producer, who can predict its success, I have a lot of doubt, but inappropriate in event like this, especially sponsorred by samsung, i have enjoyed good drinks and a fairly good dinner here, so let's just skip this;
Our real focus is on the samsung's new smartphone os project, Bada system, as illustrated in speaker's slides, Bada has its own kernel (maybe linux or other real-time kernel?), and its own graphical interface(maybe recently sponsored project, enlightenment, or e17 ?), after the topics speach, I asked questions with samsung staff, got positive replies, so it's true; I recall the Linux-based mobile/netbook project, there are already Linux Mortorola, Android by Google, Moblin by Intel, Mameo by Nokia, and alread cancelled OpenMoko project, hope there will be more and more linux based mobile os, everyone has the potential development power can hold such a system, samsung is just one of them, almost all pre-existing samsung smartphone are win based, some other symbian, some other Android, it just want more control on source os level software, but unfortunately it's still controlled by others, so it's the intention of Bad;
Documents showed that first real Bada would be coming in Mobile World Congress 2010, Bacelona, who cares?
Some friend just heard this named it's bad a thing, pronounces badly, but in fact, accroding to its official explaination, Bada means ocean in Korean, which we know little about, right? So it's just a name, let's keep interests on what can be done through Bada;
http://www.e27.sg/2010/01/04/samsung-developer-night/
http://www.linux-magazine.com/Online/News/Samsung-Sponsors-Enlightenment-Development-New-Light-for-E17/
http://www.bada.com/developer/day/
The first session is about SAMSUNG's own app store, while with this business model, I can say nothing about it, apple iphone has done it successfully, that does not mean every one can copy this model, SAMSUNG as a role of independent mobile phone producer, who can predict its success, I have a lot of doubt, but inappropriate in event like this, especially sponsorred by samsung, i have enjoyed good drinks and a fairly good dinner here, so let's just skip this;
Our real focus is on the samsung's new smartphone os project, Bada system, as illustrated in speaker's slides, Bada has its own kernel (maybe linux or other real-time kernel?), and its own graphical interface(maybe recently sponsored project, enlightenment, or e17 ?), after the topics speach, I asked questions with samsung staff, got positive replies, so it's true; I recall the Linux-based mobile/netbook project, there are already Linux Mortorola, Android by Google, Moblin by Intel, Mameo by Nokia, and alread cancelled OpenMoko project, hope there will be more and more linux based mobile os, everyone has the potential development power can hold such a system, samsung is just one of them, almost all pre-existing samsung smartphone are win based, some other symbian, some other Android, it just want more control on source os level software, but unfortunately it's still controlled by others, so it's the intention of Bad;
Documents showed that first real Bada would be coming in Mobile World Congress 2010, Bacelona, who cares?
Some friend just heard this named it's bad a thing, pronounces badly, but in fact, accroding to its official explaination, Bada means ocean in Korean, which we know little about, right? So it's just a name, let's keep interests on what can be done through Bada;
http://www.e27.sg/2010/01/04/samsung-developer-night/
http://www.linux-magazine.com/Online/News/Samsung-Sponsors-Enlightenment-Development-New-Light-for-E17/
http://www.bada.com/developer/day/
Wednesday, January 06, 2010
阅读内核：二叉搜索算法中一个常见的被很多人忽略的BUG
对于已排序对象的查找，二叉搜索算法是一个常见的优化算法，时间复杂度是 O(log(n)),
在 Linux 内核中关于符号表的运算中有对它的一个引用；在阅读这个文件的 git 历史中，
有一个变更看起来很让人费解：
$ PAGER= git show -p --stat 2fc9c4e18
commit 2fc9c4e18f94431e7eb77d97edb2a995b46fba55
Author: Vegard Nossum <vegard.nossum@gmail.com>
AuthorDate: Fri Jul 25 01:45:34 2008 -0700
Commit: Linus Torvalds <torvalds@linux-foundation.org>
CommitDate: Fri Jul 25 10:53:27 2008 -0700
kallsyms: fix potential overflow in binary search
This will probably never trigger... but it won't hurt to be careful.
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Joshua Bloch <jjb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
kernel/kallsyms.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 6fc0040..38fc10a 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -176,7 +176,7 @@ static unsigned long get_symbol_pos(unsigned long addr,
high = kallsyms_num_syms;
while (high - low > 1) {
- mid = (low + high) / 2;
+ mid = low + (high - low) / 2;
if (kallsyms_addresses[mid] <= addr)
low = mid;
else
这个 patch 中其实只有一行修改，就是对 get_symbol_pos 函数计算 mid 值的一次小小的修改，
可是，怎么看都不明白： 修改前后的两个算式 "(low + high) / 2" 与 "low + (high - low) / 2" 不是一样的么？
其作者给出 http://googleresearch.blogspot.com 上的一个链接，只有真正看过了才知道：
对于数学表达上看起来一样的式子在工程实践中有很大不同：
1) 数学是完美的符号表达；
2) 工程是要考虑计算机的实现构造：
当 (low+ligh) 超出了 signed int 的最大值 (2(^31) -1) 时，会变为负数，再接下来的下标引用中便会下溢出；
解决方法是修改为 "low + (high - low) / 2" 之类，或者先作无符号整数的强制转换：
6: mid = ((unsigned int)low + (unsigned int)high)) >> 1;
在 Java 中有一个 >>> 是针对无符号数的运算符，可以写得更简便：
二叉搜索的实现，如其所料，大部分人写的实现都有这个整数溢出问题。
--
Cheng Renquan (程任全), from Singapore
对于已排序对象的查找，二叉搜索算法是一个常见的优化算法，时间复杂度是 O(log(n)),
在 Linux 内核中关于符号表的运算中有对它的一个引用；在阅读这个文件的 git 历史中，
有一个变更看起来很让人费解：
$ PAGER= git show -p --stat 2fc9c4e18
commit 2fc9c4e18f94431e7eb77d97edb2a995b46fba55
Author: Vegard Nossum <vegard.nossum@gmail.com>
AuthorDate: Fri Jul 25 01:45:34 2008 -0700
Commit: Linus Torvalds <torvalds@linux-foundation.org>
CommitDate: Fri Jul 25 10:53:27 2008 -0700
kallsyms: fix potential overflow in binary search
This will probably never trigger... but it won't hurt to be careful.
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Joshua Bloch <jjb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
kernel/kallsyms.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 6fc0040..38fc10a 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -176,7 +176,7 @@ static unsigned long get_symbol_pos(unsigned long addr,
high = kallsyms_num_syms;
while (high - low > 1) {
- mid = (low + high) / 2;
+ mid = low + (high - low) / 2;
if (kallsyms_addresses[mid] <= addr)
low = mid;
else
这个 patch 中其实只有一行修改，就是对 get_symbol_pos 函数计算 mid 值的一次小小的修改，
可是，怎么看都不明白： 修改前后的两个算式 "(low + high) / 2" 与 "low + (high - low) / 2" 不是一样的么？
其作者给出 http://googleresearch.blogspot.com 上的一个链接，只有真正看过了才知道：
对于数学表达上看起来一样的式子在工程实践中有很大不同：
1) 数学是完美的符号表达；
2) 工程是要考虑计算机的实现构造：
当 (low+ligh) 超出了 signed int 的最大值 (2(^31) -1) 时，会变为负数，再接下来的下标引用中便会下溢出；
解决方法是修改为 "low + (high - low) / 2" 之类，或者先作无符号整数的强制转换：
6: mid = ((unsigned int)low + (unsigned int)high)) >> 1;
在 Java 中有一个 >>> 是针对无符号数的运算符，可以写得更简便：
6: int mid = (low + high) >>> 1;推荐阅读 作者给出的 blogspot 原文，其中提到作者自己的一个小故事: CMU 教授在1堂课上让每个人写出
二叉搜索的实现，如其所料，大部分人写的实现都有这个整数溢出问题。
--
Cheng Renquan (程任全), from Singapore
Wednesday, December 23, 2009
compare the evolution of hard irq implementation, you will find that hard irq numbers has shifted from 0x20~0x2f to 0x30~0x3f, but why someone need this change?
http://lxr.linux.no/#linux+v2.6.26/include/asm-x86/mach-default/irq_vectors.h
http://lxr.linux.no/#linux+v2.6.32/arch/x86/include/asm/irq_vectors.h
from oldlinux such as v0.11, as analyzed version as Doctor Zhao Jiong did, an old version just use it for the hardware limit, in the old 8259 interrupt controller days, the hardware 8259 is cascaded by 2 chips, and its real capability is only to handle 8 hard interrupt, by cascading style of implementation, there's another number is occupied by cascade, so there's only 7+8 = 15 interrupt numbers, every PC operating systems just re-program the 8259 IC, except for the intact PC standard, its 0x8~0xf for the first, and 0x78~0x7f for the second cascaded one, that can work well under 8086 Intel real mode, the DOS operating system keep it unchanged, and use int 0x21 as the system call service, then Linux re-program it as in the protected programming mode, for CPU internal usage, it reserved 0x0~0x1f 32 interrupt numbers; for the sake of x86 instruction encoding style, "int 0x80" is encoded as "0xcd 0x80", the interrupt number is just occupying one byte, so the CPU hardware limit is 256 int numbers, minus 32 reserved for CPU internal usage, it's 224 left, also as stated in the v2.6.26 irq_vectors.h comments said; Linux just use 0x80 as the system call interface, and shift/re-program 8259 to 0x20~0x27 and 0x28~0x2f; so the other range 0x30~0x7f, and 0x81~0xff are all unused; SMP architect is still strange, it generates special interrupts btween 0xee~0xff (238 ... 255); according to some recent secret unleashed, microsoft windows utilized 0x2e as the interrupt number, so the Linux int numbers changes just kept an reserved space for the unified kernel project; maybe it should be merged into mainstream someday;
http://www.oldlinux.org/
http://lxr.linux.no/#linux+v2.6.26/include/asm-x86/mach-default/irq_vectors.h
http://lxr.linux.no/#linux+v2.6.32/arch/x86/include/asm/irq_vectors.h
from oldlinux such as v0.11, as analyzed version as Doctor Zhao Jiong did, an old version just use it for the hardware limit, in the old 8259 interrupt controller days, the hardware 8259 is cascaded by 2 chips, and its real capability is only to handle 8 hard interrupt, by cascading style of implementation, there's another number is occupied by cascade, so there's only 7+8 = 15 interrupt numbers, every PC operating systems just re-program the 8259 IC, except for the intact PC standard, its 0x8~0xf for the first, and 0x78~0x7f for the second cascaded one, that can work well under 8086 Intel real mode, the DOS operating system keep it unchanged, and use int 0x21 as the system call service, then Linux re-program it as in the protected programming mode, for CPU internal usage, it reserved 0x0~0x1f 32 interrupt numbers; for the sake of x86 instruction encoding style, "int 0x80" is encoded as "0xcd 0x80", the interrupt number is just occupying one byte, so the CPU hardware limit is 256 int numbers, minus 32 reserved for CPU internal usage, it's 224 left, also as stated in the v2.6.26 irq_vectors.h comments said; Linux just use 0x80 as the system call interface, and shift/re-program 8259 to 0x20~0x27 and 0x28~0x2f; so the other range 0x30~0x7f, and 0x81~0xff are all unused; SMP architect is still strange, it generates special interrupts btween 0xee~0xff (238 ... 255); according to some recent secret unleashed, microsoft windows utilized 0x2e as the interrupt number, so the Linux int numbers changes just kept an reserved space for the unified kernel project; maybe it should be merged into mainstream someday;
15 * 16 * Vectors 0 ... 31 : system traps and exceptions - hardcoded events 17 * Vectors 32 ... 127 : device interrupts 18 * Vector 128 : legacy int80 syscall interface 19 * Vectors 129 ... 237 : device interrupts 20 * Vectors 238 ... 255 : special interrupts 21 *
http://www.oldlinux.org/
Tuesday, November 17, 2009
发现故事于近期 LinuxWeeklyNews 之 Quotes of the week (语录) 环节：
http://lwn.net/Articles/359270/
The fact is, maintainership does _not_ mean ownership. It means that
you should be _responsible_ for the code, and you get credit for it,
but if problems happen you do NOT "own" it. Not at all.
If you don't understand that, you shouldn't be a maintainer.
-- Linus Torvalds
事实是，维护不是意味着你拥有这部分代码；而是你要对它负责任，你从中获得荣誉和别人的称赞；而当问题发生时，你并不承担错误；完全不是；
可以进一步这封邮件的全文：
http://lwn.net/Articles/360156/
这封出自 Linus 的邮件第一句话就是 "You're full of sh*t." (你就是一坨屎) ...
如果你再有时间和兴趣，还可以进一步阅读讨论线索之全文，以了解整个事件之来龙去脉：
http://thread.gmane.org/gmane.linux.kernel/908831/focus=41872
邮件线索原始标题： "请考虑重置 commit 7d930bc" (即反转 commit 7d930bc 的所有修改)
1) Dmitry Torokhov 报告 2.6.32-rc5 中 cfg80211 (也就是 wireless 部分) 出现 Kernel Oops, 经过一番艰苦 git bisect 之后，发现引起问题的原因在于 commit 7d930bc, 重置这号 commit 之后可以解决；可见这确实是一个邪恶的 commit, 而且 git show 显示它引入于 2.6.32-rc5 之后；
2) David Miller (net-2.6 总管) 说在我的 net-2.6.git 树已修正了，稍晚会推送给 Linus;
3) 这时 Marcel Holtmann 忽然说了句 这个事件是这样解决了，但类似事件我们是不是可以改进下工作流，更多考虑下 最直接那个 MAINTAINER 的看法？ (Wireless 的 cfg80211 和 nl80211 接口部分维护人是 Johannes Berg) 让他能有个说句话的机会，而不是直接跳过去了？
4) Johannes Berg 说话了，"唉，类似问题困扰已久" 指的是工作流上，当问题发生时，人们都直接找 Linus 或其它几位顶级 MAINTAINER 要求重置了那个出问题的 commit, 甚至也不通知一下 那个 commit 的原始作者和我们这些底层的 MAINTAINER, 导致我们反而后知后觉，后面 merging 过程中麻烦多多；所以能不能先发给我们，以标题类似于 "发现问题于 某 commit, 我们看怎么解决？"
5) Dmitry Torokhov: 我不明白问题出在哪里，我都已经抄送给 wireless 邮件列表了，我觉得在 -rc5 之后我们要迅速地解决问题
6) Johannes Berg: 我不反对要迅速解决问题，你当然可以直接发给Linus要求直接revert，我只是说能不能先发给MAINTAINER(也就是我了)，我们有了更好的办法再汇报给Linus不晚哪，因为有时候 仅仅一个 revert 是不够的，因为原来那个 commit 肯定也是解决了某事情，如果我们直接 revert 可能会导致更糟糕的事情；这种工作流显得更为友好；而不是只被列在Cc里面，好像MAINTAINER的意见只是第二位的；
7) Dmitry Torokhov: 是说 To: 和Cc: 差别待遇吗？好了好了，下次我把你们全列在 To: 里面好吧
8) Marcel Holtmann: 近期我也发现有这种趋势：人们就不管三七二十一，上来就要示 revert, 然后才考虑解决真正的解决问题；
9) Linus 发火了： "你就是一坨屎" BUG 终究是BUG 就要被 revert 掉；那些在 merge window (rc2) 之后还引入 BUG 的人们应该被钉在耻辱柱上；一个 commit 引入的问题比它修正的要多，你说我们是不是就该要 revert 它？
10) Andrew Morton: subsystem maintainers 通常都很不靠谱
11) David Miller: To Andrew: 这很 平常 (common), 但不是普遍的 (universal)
12) Andrew Morton: David, 顺便把这几个 patch 从 -mm 树给接过去？
13) David Miller: 没问题，已应用至 net-2.6 树；其中有个 isdn-eicon-return-on-error.patch 又在用自动格式化工具玩大便 (holy crap someone run that driver through some auto-formatting tool!)
14) Linus Torvalds: 坦率地说，我还是对这个bug是非常的不满意：1) 它是 -rc5 之后引入的 2) 它被多人 bisect 出来，这浪费了多少人的时间？ 3) 此 commit 的原始作者(Johannes Berg) 在被告知了 具体哪一个 commit 导致的问题却还想从报告者那里等待更多的信息(你都已经被通知这号commit有问题了，你就不能自己搞定吗？)；
15) Marcel Holtmann: 当然是需要修正，但盲目地 revert 可能导致其它副作用； And to be honest, Johannes Berg 在解决 wireless 问题上还是很积极的；
16) Linus Torvalds: 每个人都知道出一问题要修正它；但真正的问题是"我们要最快地修正它" revert 就是最快的办法 我等不及 subsystem maintainer 来修正它；(To Marcel)你别光说讨好的漂亮话了；你错了，你应该感谢 Dmitry ，请求原谅浪费了他的时间；
17) Marcel Holtmann: 其实四天前我的邮箱就有了 Johannes 发过来的 解决办法的 patch 了，你的意思是要我当时就 越过 MAINTAINER (Johannes and David Miller) 直接把它发送给你？
18) Linus Torvalds: 你要我们的用户再多等一天还是再多等五天？ 在 -rc5 之后出现的问题我们要在最快的时间把它修正，即使不是最优的结果，但我们的测试用户有多少时间给我们浪费的？ 我们要做的就是 "Deal with it", And yes, 有时候 "Dealing with it" 就意味着必要时绕过维护者。 最差的情况下 我们有这样一个严格的管道在必要时 让用户不必在 MAINTAINER 路上等待太多时间
19) Marcel Holtmann: 我也同意。但是公平说，这个 bug 并不是影响着所有人 ...
20) Linus Torvalds: 不是的，你又错了。我是被动卷入这个线索的，其实看一眼那个 commit 就知道那个 memcpy 就有 NULL pointer dereference 问题。有人撞上了这个 problem 这就够了
21) Ingo Molnar 插入： 列举 Johannes 前两天的一封回复邮件，以说明其(Johannes)回复是 无用的， 不负责任的 (Unhelpful, defensive, in denial.) 你的 "hey, nothing happened, we fixed it after all" 表示你对此的无知，此类可避免的事故在将来还会重演
22) Marcel Holtmann: 谁这么说话了？那不是我说的好不好？
23) Ingo Molnar: 没在说你。是说上面写那个邮件的那个人，上面已 quote (就是 Johannes 写的) 部分
24) ... 有时候BUG比较复杂，1天还搞不定；这就证明了你是不够 responsive; 接着讨论要做到什么样才能叫做 responsive, 多少时间响应？ ...
25) Linus Torvalds: 拜托，两天看起来是不多，但我们的 merge window 关闭已有5个星期了，我们马上就要发布 (2.6.32) 了
Linus 对 Kernel 还是相当严格，顺便也提到 Mailing list 这个 "Immediate but asynchronous" 交流方式的优点，
顺便 David Miller 提到有人还在玩 auto-formatting tool 提交补丁，这种在刚开始入门时尚可，入门久了，再玩就没什么意思了，还会引起人家反感，请看这里的二楼评论；
http://roclinux.cn/?p=1440
BTW, 近期发现 有人 做的 KernelPodcast 不错，以语音的方式为大家播报最近 Kernel 进展和人物事件， 可以同时 作为内核 学习 和 英语 学习材料：只是希望可以持久下去， 这样的工作除了 LWN 可以作为全职以外，一般人恐怕很难持续下去：
http://www.kernelpodcast.org/feed/
http://lwn.net/Articles/359270/
The fact is, maintainership does _not_ mean ownership. It means that
you should be _responsible_ for the code, and you get credit for it,
but if problems happen you do NOT "own" it. Not at all.
If you don't understand that, you shouldn't be a maintainer.
-- Linus Torvalds
事实是，维护不是意味着你拥有这部分代码；而是你要对它负责任，你从中获得荣誉和别人的称赞；而当问题发生时，你并不承担错误；完全不是；
可以进一步这封邮件的全文：
http://lwn.net/Articles/360156/
这封出自 Linus 的邮件第一句话就是 "You're full of sh*t." (你就是一坨屎) ...
如果你再有时间和兴趣，还可以进一步阅读讨论线索之全文，以了解整个事件之来龙去脉：
http://thread.gmane.org/gmane.linux.kernel/908831/focus=41872
邮件线索原始标题： "请考虑重置 commit 7d930bc" (即反转 commit 7d930bc 的所有修改)
1) Dmitry Torokhov 报告 2.6.32-rc5 中 cfg80211 (也就是 wireless 部分) 出现 Kernel Oops, 经过一番艰苦 git bisect 之后，发现引起问题的原因在于 commit 7d930bc, 重置这号 commit 之后可以解决；可见这确实是一个邪恶的 commit, 而且 git show 显示它引入于 2.6.32-rc5 之后；
2) David Miller (net-2.6 总管) 说在我的 net-2.6.git 树已修正了，稍晚会推送给 Linus;
3) 这时 Marcel Holtmann 忽然说了句 这个事件是这样解决了，但类似事件我们是不是可以改进下工作流，更多考虑下 最直接那个 MAINTAINER 的看法？ (Wireless 的 cfg80211 和 nl80211 接口部分维护人是 Johannes Berg) 让他能有个说句话的机会，而不是直接跳过去了？
4) Johannes Berg 说话了，"唉，类似问题困扰已久" 指的是工作流上，当问题发生时，人们都直接找 Linus 或其它几位顶级 MAINTAINER 要求重置了那个出问题的 commit, 甚至也不通知一下 那个 commit 的原始作者和我们这些底层的 MAINTAINER, 导致我们反而后知后觉，后面 merging 过程中麻烦多多；所以能不能先发给我们，以标题类似于 "发现问题于 某 commit, 我们看怎么解决？"
5) Dmitry Torokhov: 我不明白问题出在哪里，我都已经抄送给 wireless 邮件列表了，我觉得在 -rc5 之后我们要迅速地解决问题
6) Johannes Berg: 我不反对要迅速解决问题，你当然可以直接发给Linus要求直接revert，我只是说能不能先发给MAINTAINER(也就是我了)，我们有了更好的办法再汇报给Linus不晚哪，因为有时候 仅仅一个 revert 是不够的，因为原来那个 commit 肯定也是解决了某事情，如果我们直接 revert 可能会导致更糟糕的事情；这种工作流显得更为友好；而不是只被列在Cc里面，好像MAINTAINER的意见只是第二位的；
7) Dmitry Torokhov: 是说 To: 和Cc: 差别待遇吗？好了好了，下次我把你们全列在 To: 里面好吧
8) Marcel Holtmann: 近期我也发现有这种趋势：人们就不管三七二十一，上来就要示 revert, 然后才考虑解决真正的解决问题；
9) Linus 发火了： "你就是一坨屎" BUG 终究是BUG 就要被 revert 掉；那些在 merge window (rc2) 之后还引入 BUG 的人们应该被钉在耻辱柱上；一个 commit 引入的问题比它修正的要多，你说我们是不是就该要 revert 它？
10) Andrew Morton: subsystem maintainers 通常都很不靠谱
11) David Miller: To Andrew: 这很 平常 (common), 但不是普遍的 (universal)
12) Andrew Morton: David, 顺便把这几个 patch 从 -mm 树给接过去？
13) David Miller: 没问题，已应用至 net-2.6 树；其中有个 isdn-eicon-return-on-error.patch 又在用自动格式化工具玩大便 (holy crap someone run that driver through some auto-formatting tool!)
14) Linus Torvalds: 坦率地说，我还是对这个bug是非常的不满意：1) 它是 -rc5 之后引入的 2) 它被多人 bisect 出来，这浪费了多少人的时间？ 3) 此 commit 的原始作者(Johannes Berg) 在被告知了 具体哪一个 commit 导致的问题却还想从报告者那里等待更多的信息(你都已经被通知这号commit有问题了，你就不能自己搞定吗？)；
15) Marcel Holtmann: 当然是需要修正，但盲目地 revert 可能导致其它副作用； And to be honest, Johannes Berg 在解决 wireless 问题上还是很积极的；
16) Linus Torvalds: 每个人都知道出一问题要修正它；但真正的问题是"我们要最快地修正它" revert 就是最快的办法 我等不及 subsystem maintainer 来修正它；(To Marcel)你别光说讨好的漂亮话了；你错了，你应该感谢 Dmitry ，请求原谅浪费了他的时间；
17) Marcel Holtmann: 其实四天前我的邮箱就有了 Johannes 发过来的 解决办法的 patch 了，你的意思是要我当时就 越过 MAINTAINER (Johannes and David Miller) 直接把它发送给你？
18) Linus Torvalds: 你要我们的用户再多等一天还是再多等五天？ 在 -rc5 之后出现的问题我们要在最快的时间把它修正，即使不是最优的结果，但我们的测试用户有多少时间给我们浪费的？ 我们要做的就是 "Deal with it", And yes, 有时候 "Dealing with it" 就意味着必要时绕过维护者。 最差的情况下 我们有这样一个严格的管道在必要时 让用户不必在 MAINTAINER 路上等待太多时间
19) Marcel Holtmann: 我也同意。但是公平说，这个 bug 并不是影响着所有人 ...
20) Linus Torvalds: 不是的，你又错了。我是被动卷入这个线索的，其实看一眼那个 commit 就知道那个 memcpy 就有 NULL pointer dereference 问题。有人撞上了这个 problem 这就够了
21) Ingo Molnar 插入： 列举 Johannes 前两天的一封回复邮件，以说明其(Johannes)回复是 无用的， 不负责任的 (Unhelpful, defensive, in denial.) 你的 "hey, nothing happened, we fixed it after all" 表示你对此的无知，此类可避免的事故在将来还会重演
22) Marcel Holtmann: 谁这么说话了？那不是我说的好不好？
23) Ingo Molnar: 没在说你。是说上面写那个邮件的那个人，上面已 quote (就是 Johannes 写的) 部分
24) ... 有时候BUG比较复杂，1天还搞不定；这就证明了你是不够 responsive; 接着讨论要做到什么样才能叫做 responsive, 多少时间响应？ ...
25) Linus Torvalds: 拜托，两天看起来是不多，但我们的 merge window 关闭已有5个星期了，我们马上就要发布 (2.6.32) 了
Linus 对 Kernel 还是相当严格，顺便也提到 Mailing list 这个 "Immediate but asynchronous" 交流方式的优点，
顺便 David Miller 提到有人还在玩 auto-formatting tool 提交补丁，这种在刚开始入门时尚可，入门久了，再玩就没什么意思了，还会引起人家反感，请看这里的二楼评论；
http://roclinux.cn/?p=1440
BTW, 近期发现 有人 做的 KernelPodcast 不错，以语音的方式为大家播报最近 Kernel 进展和人物事件， 可以同时 作为内核 学习 和 英语 学习材料：只是希望可以持久下去， 这样的工作除了 LWN 可以作为全职以外，一般人恐怕很难持续下去：
http://www.kernelpodcast.org/feed/
Friday, November 13, 2009
Open source participation in Asia be encouraged
This week, I've attended two open source related events here in
Singapore, they are Professors' Open Source Summer Experience
asia-pacific sponsored by Redhat, and Singapore Ruby Brigade (SRB),
that gathering location near Boat Quay is also wego's working offices;
Singapore, they are Professors' Open Source Summer Experience
asia-pacific sponsored by Redhat, and Singapore Ruby Brigade (SRB),
that gathering location near Boat Quay is also wego's working offices;
http://teachingopensource.org/index.php/POSSE_APAC
http://singaporerubybrigade.pbworks.com/
The SRB was apparently more technical-centric and a good event for
hackers and real developers like me; some speaker talked about the
ruby rails cucumber, its new Behavior Driven Development (BDD), and
everyday git working flow, someone still think subversion is better,
but have a consensus that CVS is horrible, and outdated. After that
event, we all also had another meal of refreshments and walked
alongside the bank of Singapore river, talking more about ruby and
open source, their application status in Singapore and in the whole
south-east Asia; and, there were some students from linuxnus.org,
certainly linux is also another topic of discussion. Comparing to
China, open source and linux adoption here is also very limited, the
open source guys circle here is also small, one of them told me, "I
almost know every linux people here;" so you can imagine how large it
is. We supposed kinds of scenarios for firms' linux adoption, but
maybe the significant factor here is decision-maker's thoughts, who
knew them? From the long queue outside the M$'s shop for its new
production arrival last month, in my opinion they were just wasting
money; and from this perspective we know that open source here in sg,
in southeast-asia, the whole asia, still has a long way to go. Or we
can express the future in our optimistic way: "Open source here is
very promising, and has more tremendous potential".
But what a pity, my digital camera is broken several months ago when
still in China, I didn't take any photos for these wonderful events.
Besides when in the Riverside Point, the photographer staff of redhat
had taken many photo for all teachers form all corners of Asia, maybe
we can watch them several days later. And another camera for myself is
also critical, I shouldn't miss any important following days, but
separate camera with 1200M better or just a smart phone (5M+ pixels)?
who knows, still in consideration.
Maybe in the end, you need more introductions about these two kind of companies,
You don't know redhat? That's unplausible;
You don't know wego? Maybe, it's a travel search engine, enjoy your
good experience with it (wego.com).
Thursday, November 05, 2009
Sunday, November 01, 2009
Wednesday, May 13, 2009
* 2009 La Casa della Musica, Parma, Italy - Website, A/V Streams & Slides
LAC (Linux Audio Conference) is held annually and this year it was in Italy in April, and from its papers and slides, it can be observed that frugal may be the next right direction.
Sunday, May 10, 2009
之前写过一篇 Blog
在这里，能找到这个系列又多了一个
这个代号隐藏于 每一内核发布的 Makefile 文件中，第5行是
其中 Vindictive Armadillo (怀恨的犰狳) 就是了。
倒推过来是
在这里，能找到这个系列又多了一个
- Karmic Koala (命运的树袋熊) 9.10 Released in October 2009
这个代号隐藏于 每一内核发布的 Makefile 文件中，第5行是
git show v2.6.30-rc5:Makefile |head -n5
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 30
EXTRAVERSION = -rc5
NAME = Vindictive Armadillo其中 Vindictive Armadillo (怀恨的犰狳) 就是了。
倒推过来是
- v2.6.30 Vindictive Armadillo (怀恨的犰狳) (Not Released Yet)
- v2.6.29 Temporary Tasmanian Devil (临时的 Tasmanian 恶魔)
- v2.6.28 Erotic Pickled Herring ()
- v2.6.27 Rotary Wombat ()
- v2.6.26 Rotary Wombat
- v2.6.25 Funky Weasel is Jiggy wit it
- v2.6.24 Arr Matey! A Hairy Bilge Rat!
- v2.6.23 Arr Matey! A Hairy Bilge Rat!
- v2.6.22 Holy Dancing Manatees, Batman!
- v2.6.21 Nocturnal Monster Puppy
- v2.6.20 Homicidal Dwarf Hamster
- v2.6.19 Avast! A bilge rat!
- v2.6.18 Avast! A bilge rat!
- v2.6.17 Crazed Snow-Weasel
- v2.6.16 Sliding Snow Leopard
- v2.6.15 Sliding Snow Leopard
- v2.6.14 Affluent Albatross
- v2.6.13 Woozy Numbat
- v2.6.12 Woozy Numbat
- v2.6.11 Woozy Numbat
Thursday, May 07, 2009
A simple way with curl to post code snippet to ubuntu paste:
$ curl -v -d 'poster=chengrq&syntax=python' --data-urlencode 'content@/home/gektop/bin/diff-filter' http://paste.ubuntu.com
* About to connect() to paste.ubuntu.com port 80 (#0)
* Trying 91.189.90.174... connected
* Connected to paste.ubuntu.com (91.189.90.174) port 80 (#0)
> POST / HTTP/1.1
> User-Agent: curl/7.18.2 (x86_64-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8j zlib/1.2.3
> Host: paste.ubuntu.com
> Accept: */*
> Content-Length: 3002
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 302 Found
< Date: Fri, 08 May 2009 01:29:08 GMT
< Server: Apache/2.2.8 (Ubuntu) mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.8 OpenSSL/0.9.8g mod_perl/2.0.3 Perl/v5.8.8
< Location: /166435/
< Content-Length: 0
< Content-Type: text/html; charset=utf-8
<
* Connection #0 to host paste.ubuntu.com left intact
* Closing connection #0
I need a diff (or patch) manipulation utility, but unfortunately I have not found one, then I wrote one, of course, it's in Python.
#!/usr/bin/python
import sys, os
# Usage: diff-filter [-v] path1 path2 ...
# <INPUT >OUTPUT
if len(sys.argv) <= 1:
print "Usage: %s [-v] path1 path2 ... <INPUT" % \
os.path.basename(sys.argv[0])
sys.exit(1)
# some global variables
inChunk = True
strip = 1
matched = False
buffer = ''
invert = False
# to invert the filter
if sys.argv[1] == '-v':
invert = True
del sys.argv[1]
# the main filter
while True:
line = sys.stdin.readline()
if not line:
break
if line.startswith("--- ") or \
line.startswith("diff") or \
line.startswith("Binary") or \
line.startswith("Index"):
matched = False
inChunk = False
if line.startswith("diff") or \
line.startswith("Binary") or \
line.startswith("Index"):
buffer += line
continue
else:
path = line.split()[1]
slash = path.find('/')
path = path[slash+1:]
for arg in sys.argv[1:]:
if path.startswith(arg):
matched = True
break
else:
matched = False
if invert:
matched = not matched
if not matched:
buffer = ''
if inChunk:
print line,
if matched:
if buffer:
print buffer,
buffer = ''
print line,
It also can be reached by the ubuntu paste service:
http://paste.ubuntu.com/166435/
Application field: if you have a big diff generated by "diff -R", and want to split it according to some seperate path or components, you can use this. Happy hacking!
Subscribe to:
Posts (Atom)