1,649
社区成员
发帖
与我相关
我的任务
分享2011聆听心灵 -==- 前奏，关于技术的态度
是啊，总结很多，今年总结写的很多很多。目前还在Beta版本
感谢看过的兄弟姐妹， 今天看了看了一篇文章觉得超级不错
是linux创始人说的，不是， 陈浩翻译的很准确，我拿过来
2011年4月12日，Linux 2.6.39-rc3发布了，Linus Torvalds写了一个发布邮件，其中包含了一个长长的为这个版本做过贡献的人员名单，
这个名单中有很多看上去应该是中国人的名字，我挺为他们感到骄傲的
不过，没过一会，发现了一个bug，经过大家的调查（2.6.38版没有发现这个问题），很快，找到了原因，是因为一个内存地址的问题，
一个叫Yinghai Lu的人（看其名字应该是中国人，其邮件是@kernel.org）找到了原因—— radeon card使用了一个不正确的内存地址[0xa0000000 - 0xc000000]。
Joerg Roedel跟贴说，这个地址超出了4GB的内存，然后他和Alex Deucher聊了一会，觉得不应该是这个问题，因为这个地址应该是GPU的，而不是系统内存的。
好像，Yinghai Lu没有理会他们说的不应该是这个问题，给出了个fix：
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 86d1ad4..3b6a9d5 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
* so don't use 512M below as gart iommu, leave the space for kernel
* code for safe
*/
- addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
+ addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
if (addr == MEMBLOCK_ERROR || addr + aper_size > 0xffffffff) {
printk(KERN_ERR
"Cannot allocate aperture memory hole (%lx,%uK)\n",
看到这个fix，Linus Torvalds不高兴了，他回贴问道：
为什么全都是Magic Numbers？
为什么0×80000000就那么特殊？
为什么我们这样改就行？
还说了这样一句话——
This kind of “I broke things, so now I will jiggle things randomly until they unbreak” is not acceptable.
这种“我把事搞砸了，就随意地调整直到事情又工作”的方式是不可接受的。
还说，这里即没有说明为什么我们fix在了正确的地方（也没有解释那些Magic Number是什么），也没有回滚那个有问题的patch。还说——
Don’t just make random changes. There really are only two acceptable models of development: “think and analyze” or “years and years of
testing on thousands of machines”. Those two really do work.
不要乱改。那里只有两个可行的开发模式：“思考和分析” 或是 “数年数年地不断地在几千台机器上测试”。这两个方式才是真正可行的。
当然，Yinghai Lu对其做了解释，说我们的确调查过了，老的代码用的内存地址是0×80000000，新的则是用0xa0000000，而0xa0000000不工作。
这又引发了 Linus Torvalds 的不满的回贴。
Linus说——
Yinghai, we have had this discussion before, and dammit, you need to understand the difference between “understanding the problem” and
“put in random values until it works on one machine”.
Yinghai，我们以前谈过这个事，该死的，你真的需要明白“理解一个错误”和“设一个随意的值直到其正常工作”的区别。
There was absolutely _zero_ analysis done. You do not actually understand WHY the numbers matter.
You just look at two random numbers, and one works, the other does not. That’s not “analyzing”. That’s just “random number games”.
这里就根本没有分析。你没有直正的明白为什么这些数字能行。你只看了两个随机的数，一个能行，另一个不行。这不是“分析”，这叫“随机数游戏”。
If you cannot see and understand the difference between an actual analytical solution where you _understand_ what the code is doing and why,
and “random numbers that happen to work on one machine”, I don’t know what to tell you.
一个解决方案真正经过分析了那段代码干什么的为什么的，另一个是“随机数字可以让其在一台机器上运转”，如果你不能看到和理解他们之间的不同，
那我不知道要和你说什么了。
然后，Linus Torvalds进行了谆谆教导——（相当的受用啊）
Let me repeat my point one more time.
让我再一次重复一下我的观点
You have TWO choices. Not more, not less:
你有两个选择，不多也不少：
- choice #1: go back to the old allocation model. It’s tested. It doesn’t regress. Admittedly we may not know exactly _why_ it works,
and it might not work on all machines, but it doesn’t cause regressions (ie the machines it doesn’t work on it _never_ worked on).
- 选择一：回滚到老的分配模式。那是测试过的。它过了回归测试。诚然，我们也许不知道为什么那样能行，并且，即使是那样也不一定能在所有的机器上工作，
但是其没有让回归测试有问题（这个代码永不可能在不能运行的系统上运行）
And this doesn’t mean “old value for that _one_ machine”. It means “old value for _every_ machine”.
So it means we revert the whole bottom-down thing entirely.
Not just “change one random number so that the totally different allocation pattern happens to give the same result on one particular machine”.
这并不代表“老的值只能在一台机器上工作”。这代表“老的值可以工作在每一台机器上”。所以，我们需要回滚整个代码改动。
而不只是“为了一个特别的机器去修改一个和以前完全不一样的随机数”。
- Choice #2: understand exactly _what_ goes wrong, and fix it analytically (ie by _understanding_ the problem, and being able to solve it exactly,
and in a way you can argue about without having to resort to “magic happens”).
- 选择二：真正搞清楚为什么会错，并且有分析地修改他（理解问题才能真正解决之，并且，只有没有“魔法发生”的时候你才可以来争论）
Now, the whole analytic approach (aka “computer sciency” approach), where you can actually think
about the problem without having any pesky “reality” impact the
solution is obviously the one we tend to prefer. Sadly, it’s seldom the one we can use in reality when it comes to things like resource allocation,
since we end up starting off with often buggy approximations of what the actual hardware is all about (ie broken firmware tables).
现在，整个分析方法（亦称作“计算机科学”的方法）应该是你可以在没有在外界干扰下真正思考这个问题而得到的解决方案，这很明显是我们推崇的。
只有在极罕见地情况下我们可以在有外界干扰下分析这种资源分配的事，因为我们只有了解倒底是什么样的硬件，我们才能最终远离bug（如：错误的固件表）
So I’d love to know exactly why one random number works, and why another one doesn’t. But as long as we do _not_ know the “Why” of it,
we will have to revert.
所以，我希望你能知道为什么一个随机数能行，而另一个不行。只要我们不知道，那么我们就不得和回滚整个改动。
It really is that simple. It’s _always_ that simple.
这真的是很简单，而且这一直是那么简单。
So the numbers shouldn’t be “magic”, they should have real explanations. And in the absense of real explanation,
the model that works is “this is what we’ve always done”. Including, very much, the whole allocation order.
Not just one random number on one random machine.
所以，那些数不应该是“magic”的，他们应该有真正的说明。在有真正的说明的情况下，我们的开发模式才会工作。其包括了整个分配顺序。
不只是那个在任意机器上的随机数。
Linus
后面的事不用说了。我没有想到Linux 内核组会有像Yinghai这样工作的方式，毕竟这是一个黑客级的开发团队。我个人对这个乱写代码的人执零容忍的态度，
不管你干过什么，不管你哪里毕业的，不管你简历怎么样，不求甚解随意写代码的人我无法接受。我不知道Yinghai Lu会怎么样想，
他/她会像我在“程序员那些悲催的事儿”中谈我经历那样知耻而后勇吗？能得到Linus的教导真是一件很不错的事。
虽然，Linus教导的这些东西，都应该是程序员最最最基本的技能。fix bug一定要fix在root cause上啊，了解一个问题，
不但要知其然，还要知其所以然啊，这都是老生长谈了。
各位朋友，我真心希望你能从这个小插曲中明白点什么。
从本贴的回复中可以看到有朋友说如果时间紧，没有办法只能在不求甚解的地去fix bug，因为老板催。我认为这是老板的“急功近利”的问题。
我想和大家说一下，你得想清楚你属于下面那种人：
你的老板给你压力，让你不得不乱fix，
你认同只要时间紧bug是可以乱fix的。
如果你属于1），那我觉得还情由可原，这是管理问题。但这不能成为你对乱fix bug的理由。一般这种问题怎么解决：首先，给一个hot fix去救火，
然后，有时间去调查root cause，最后经过分析和测试，给出一个final 的 offical fix。这就是应急的做法，根本不存在什么可以乱fix bug的做法。
如果你属于2），那么我只能“过激”地说你没有成为程序员的资质！
另外，快速地fix bug，并不等于，不求甚解的fix bug。大家不要把这两件事等同。
广州--零()
客户会宽容你嘛？
这个问题反问的好，我可以用2年的经验告诉你会，国内的绝对会，
国内的客户，不怕出问题，出问题给解决就行，但是国外的不行，
你出问题了会带来bug，带来额外的成本，所以关于这点我还是想说，国人
其实本身就不愿意自律，
就像出现紧急bug一样，我愿意给你时间出一个hotfix来救火，
但是我们要清晰root cause是一样的。 尽管我是0.容忍度。但是现状决定了。感叹一下
//说一个亲身的例子吧，
过去我负责Nasdaq的时候，我每天睡觉只有4小时，因为我害怕出问题，真实的原因是睡不着
在运行了48小时后，我松了一口气。我也知道出问题的代价。以至于我现在还保持着读代码的习惯
只要我看见有错误，我也会修正,
快速的修复bug，不是随意的修复bug
感谢看过的兄弟姐妹， 今天看了看了一篇文章觉得超级不错
是linux创始人说的，不是， 陈浩翻译的很准确，我拿过来
2011年4月12日，Linux 2.6.39-rc3发布了，Linus Torvalds写了一个发布邮件，其中包含了一个长长的为这个版本做过贡献的人员名单，
这个名单中有很多看上去应该是中国人的名字，我挺为他们感到骄傲的
不过，没过一会，发现了一个bug，经过大家的调查（2.6.38版没有发现这个问题），很快，找到了原因，是因为一个内存地址的问题，
一个叫Yinghai Lu的人（看其名字应该是中国人，其邮件是@kernel.org）找到了原因—— radeon card使用了一个不正确的内存地址[0xa0000000 - 0xc000000]。
Joerg Roedel跟贴说，这个地址超出了4GB的内存，然后他和Alex Deucher聊了一会，觉得不应该是这个问题，因为这个地址应该是GPU的，而不是系统内存的。
好像，Yinghai Lu没有理会他们说的不应该是这个问题，给出了个fix：
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 86d1ad4..3b6a9d5 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
* so don't use 512M below as gart iommu, leave the space for kernel
* code for safe
*/
- addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
+ addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
if (addr == MEMBLOCK_ERROR || addr + aper_size > 0xffffffff) {
printk(KERN_ERR
"Cannot allocate aperture memory hole (%lx,%uK)\n",
看到这个fix，Linus Torvalds不高兴了，他回贴问道：
为什么全都是Magic Numbers？
为什么0×80000000就那么特殊？
为什么我们这样改就行？
还说了这样一句话——
This kind of “I broke things, so now I will jiggle things randomly until they unbreak” is not acceptable.
这种“我把事搞砸了，就随意地调整直到事情又工作”的方式是不可接受的。
还说，这里即没有说明为什么我们fix在了正确的地方（也没有解释那些Magic Number是什么），也没有回滚那个有问题的patch。还说——
Don’t just make random changes. There really are only two acceptable models of development: “think and analyze” or “years and years of
testing on thousands of machines”. Those two really do work.
不要乱改。那里只有两个可行的开发模式：“思考和分析” 或是 “数年数年地不断地在几千台机器上测试”。这两个方式才是真正可行的。
当然，Yinghai Lu对其做了解释，说我们的确调查过了，老的代码用的内存地址是0×80000000，新的则是用0xa0000000，而0xa0000000不工作。
这又引发了 Linus Torvalds 的不满的回贴。
Linus说——
Yinghai, we have had this discussion before, and dammit, you need to understand the difference between “understanding the problem” and
“put in random values until it works on one machine”.
Yinghai，我们以前谈过这个事，该死的，你真的需要明白“理解一个错误”和“设一个随意的值直到其正常工作”的区别。
There was absolutely _zero_ analysis done. You do not actually understand WHY the numbers matter.
You just look at two random numbers, and one works, the other does not. That’s not “analyzing”. That’s just “random number games”.
这里就根本没有分析。你没有直正的明白为什么这些数字能行。你只看了两个随机的数，一个能行，另一个不行。这不是“分析”，这叫“随机数游戏”。
If you cannot see and understand the difference between an actual analytical solution where you _understand_ what the code is doing and why,
and “random numbers that happen to work on one machine”, I don’t know what to tell you.
一个解决方案真正经过分析了那段代码干什么的为什么的，另一个是“随机数字可以让其在一台机器上运转”，如果你不能看到和理解他们之间的不同，
那我不知道要和你说什么了。
然后，Linus Torvalds进行了谆谆教导——（相当的受用啊）
Let me repeat my point one more time.
让我再一次重复一下我的观点
You have TWO choices. Not more, not less:
你有两个选择，不多也不少：
- choice #1: go back to the old allocation model. It’s tested. It doesn’t regress. Admittedly we may not know exactly _why_ it works,
and it might not work on all machines, but it doesn’t cause regressions (ie the machines it doesn’t work on it _never_ worked on).
- 选择一：回滚到老的分配模式。那是测试过的。它过了回归测试。诚然，我们也许不知道为什么那样能行，并且，即使是那样也不一定能在所有的机器上工作，
但是其没有让回归测试有问题（这个代码永不可能在不能运行的系统上运行）
And this doesn’t mean “old value for that _one_ machine”. It means “old value for _every_ machine”.
So it means we revert the whole bottom-down thing entirely.
Not just “change one random number so that the totally different allocation pattern happens to give the same result on one particular machine”.
这并不代表“老的值只能在一台机器上工作”。这代表“老的值可以工作在每一台机器上”。所以，我们需要回滚整个代码改动。
而不只是“为了一个特别的机器去修改一个和以前完全不一样的随机数”。
- Choice #2: understand exactly _what_ goes wrong, and fix it analytically (ie by _understanding_ the problem, and being able to solve it exactly,
and in a way you can argue about without having to resort to “magic happens”).
- 选择二：真正搞清楚为什么会错，并且有分析地修改他（理解问题才能真正解决之，并且，只有没有“魔法发生”的时候你才可以来争论）
Now, the whole analytic approach (aka “computer sciency” approach), where you can actually think
about the problem without having any pesky “reality” impact the
solution is obviously the one we tend to prefer. Sadly, it’s seldom the one we can use in reality when it comes to things like resource allocation,
since we end up starting off with often buggy approximations of what the actual hardware is all about (ie broken firmware tables).
现在，整个分析方法（亦称作“计算机科学”的方法）应该是你可以在没有在外界干扰下真正思考这个问题而得到的解决方案，这很明显是我们推崇的。
只有在极罕见地情况下我们可以在有外界干扰下分析这种资源分配的事，因为我们只有了解倒底是什么样的硬件，我们才能最终远离bug（如：错误的固件表）
So I’d love to know exactly why one random number works, and why another one doesn’t. But as long as we do _not_ know the “Why” of it,
we will have to revert.
所以，我希望你能知道为什么一个随机数能行，而另一个不行。只要我们不知道，那么我们就不得和回滚整个改动。
It really is that simple. It’s _always_ that simple.
这真的是很简单，而且这一直是那么简单。
So the numbers shouldn’t be “magic”, they should have real explanations. And in the absense of real explanation,
the model that works is “this is what we’ve always done”. Including, very much, the whole allocation order.
Not just one random number on one random machine.
所以，那些数不应该是“magic”的，他们应该有真正的说明。在有真正的说明的情况下，我们的开发模式才会工作。其包括了整个分配顺序。
不只是那个在任意机器上的随机数。
Linus
后面的事不用说了。我没有想到Linux 内核组会有像Yinghai这样工作的方式，毕竟这是一个黑客级的开发团队。我个人对这个乱写代码的人执零容忍的态度，
不管你干过什么，不管你哪里毕业的，不管你简历怎么样，不求甚解随意写代码的人我无法接受。我不知道Yinghai Lu会怎么样想，
他/她会像我在“程序员那些悲催的事儿”中谈我经历那样知耻而后勇吗？能得到Linus的教导真是一件很不错的事。
虽然，Linus教导的这些东西，都应该是程序员最最最基本的技能。fix bug一定要fix在root cause上啊，了解一个问题，
不但要知其然，还要知其所以然啊，这都是老生长谈了。
各位朋友，我真心希望你能从这个小插曲中明白点什么。
从本贴的回复中可以看到有朋友说如果时间紧，没有办法只能在不求甚解的地去fix bug，因为老板催。我认为这是老板的“急功近利”的问题。
我想和大家说一下，你得想清楚你属于下面那种人：
你的老板给你压力，让你不得不乱fix，
你认同只要时间紧bug是可以乱fix的。
如果你属于1），那我觉得还情由可原，这是管理问题。但这不能成为你对乱fix bug的理由。一般这种问题怎么解决：首先，给一个hot fix去救火，
然后，有时间去调查root cause，最后经过分析和测试，给出一个final 的 offical fix。这就是应急的做法，根本不存在什么可以乱fix bug的做法。
如果你属于2），那么我只能“过激”地说你没有成为程序员的资质！
另外，快速地fix bug，并不等于，不求甚解的fix bug。大家不要把这两件事等同。
广州--零()
客户会宽容你嘛？
这个问题反问的好，我可以用2年的经验告诉你会，国内的绝对会，
国内的客户，不怕出问题，出问题给解决就行，但是国外的不行，
你出问题了会带来bug，带来额外的成本，所以关于这点我还是想说，国人
其实本身就不愿意自律，
就像出现紧急bug一样，我愿意给你时间出一个hotfix来救火，
但是我们要清晰root cause是一样的。 尽管我是0.容忍度。但是现状决定了。感叹一下
//说一个亲身的例子吧，
过去我负责Nasdaq的时候，我每天睡觉只有4小时，因为我害怕出问题，真实的原因是睡不着
在运行了48小时后，我松了一口气。我也知道出问题的代价。以至于我现在还保持着读代码的习惯
只要我看见有错误，我也会修正,
快速的修复bug，不是随意的修复bug
...全文
请发表友善的回复…
发表回复
UnknowName 2012-07-11
- 打赏
- 举报
受教了，学习中...
Brain0805 2011-12-24
- 打赏
- 举报
大家都用心做事就是了，都用一个能对的起自己，对得起别人的态度做事，就行了。
gangyewei 2011-12-23
- 打赏
- 举报
写代码的人对自己的作品不够尊重，也恶心到了与其合作的人。
说的好
说的好
康斯坦汀 2011-12-23
- 打赏
- 举报
想起你来了，谢谢你的夸奖。
yj2335479 2011-12-23
- 打赏
- 举报
我是菜鸟我怕谁
junyingxiu 2011-12-23
- 打赏
- 举报
稍微有点晕
fishion 2011-12-23
- 打赏
- 举报
。。这样的人也见过了，习惯了
renqHIT 2011-12-23
- 打赏
- 举报
受教了，谢谢楼主
bluesky12312388 2011-12-23
- 打赏
- 举报
think and analyze
金金2019 2011-12-23
- 打赏
- 举报
顶
一边吃饭 一边顶
今天 必须顶帖子
一边吃饭 一边顶
今天 必须顶帖子
血饮 2011-12-22
- 打赏
- 举报
有点深奥！
金金2019 2011-12-22
- 打赏
- 举报
[Quote=引用 35 楼 r3000 的回复:]
看了这个帖子，不说文中那位Yinghai Lu是不是国人或者是海外华人又或者来自台湾。
他确实很像我们国内的程序员，聪明智慧可以说是全球一流的，但守纪律、善于与别人合作方面
确是最差的。不乏技术高手，但缺少领军人物。能写高难度代码，但不会写简单代码（会写
难的其实不是高手，会写简单的代码解决问题才是高手）。
[/Quote]
不是台湾人， 因为繁体 有区别
看了这个帖子，不说文中那位Yinghai Lu是不是国人或者是海外华人又或者来自台湾。
他确实很像我们国内的程序员，聪明智慧可以说是全球一流的，但守纪律、善于与别人合作方面
确是最差的。不乏技术高手，但缺少领军人物。能写高难度代码，但不会写简单代码（会写
难的其实不是高手，会写简单的代码解决问题才是高手）。
[/Quote]
不是台湾人， 因为繁体 有区别
金金2019 2011-12-22
- 打赏
- 举报
TO R3000
3000 听懂了我的心声， 很欣赏R3000的态度和为人
我不知道你还记得 曾经你发我一个activeX 书籍
当时我给你 3k分， csdn说我们到分
我现在还记得你， 谢谢 你呵呵
3000 听懂了我的心声， 很欣赏R3000的态度和为人
我不知道你还记得 曾经你发我一个activeX 书籍
当时我给你 3k分， csdn说我们到分
我现在还记得你， 谢谢 你呵呵
乡客2023 2011-12-22
- 打赏
- 举报
一个愿给钱，一个愿接钱！我是菜鸟我怕谁
dfasri 2011-12-22
- 打赏
- 举报
中国软件为何就质量那么差?
原因在于:
Linus 的说法很正确, 只是在中国老板面前走不通.
软件就像一个建筑, 应该先建地基, 再建房间.
中国老板很不情愿的说:" 这些房间又不是给人住的, 又不会发生命案, 地基又不能用, 要地基干嘛, 赶快给我建房间, 然后叠在一起就行了, 时间就是金钱, 我可不愿意花钱来弄个没实际作用的地基! 房间出问题, 补就是了, 房间要通道, 直接破墙就是了, 赶快给我做出来! ."
Yinghai Lu是一个杯具, 被中国潜移默化成功的一个杯具, 但还好, 被染黑得不深, 我想大概会是版本因为发布出来了, 没得收回来, 要收场最好就是采用这种方式, 事后再查明真相.
但对于Linus的严格管理上, 不允许出现这种情况. 对于中国的理解, 这或者叫变通. 对于外国的理解, 这叫雕虫小技难成大器, 容忍了这次, 必然导致日后会有更多更多次, 这样会导致整个团队的价值观发生变化, 所以一定要一出苗头就扼杀.
原因在于:
Linus 的说法很正确, 只是在中国老板面前走不通.
软件就像一个建筑, 应该先建地基, 再建房间.
中国老板很不情愿的说:" 这些房间又不是给人住的, 又不会发生命案, 地基又不能用, 要地基干嘛, 赶快给我建房间, 然后叠在一起就行了, 时间就是金钱, 我可不愿意花钱来弄个没实际作用的地基! 房间出问题, 补就是了, 房间要通道, 直接破墙就是了, 赶快给我做出来! ."
Yinghai Lu是一个杯具, 被中国潜移默化成功的一个杯具, 但还好, 被染黑得不深, 我想大概会是版本因为发布出来了, 没得收回来, 要收场最好就是采用这种方式, 事后再查明真相.
但对于Linus的严格管理上, 不允许出现这种情况. 对于中国的理解, 这或者叫变通. 对于外国的理解, 这叫雕虫小技难成大器, 容忍了这次, 必然导致日后会有更多更多次, 这样会导致整个团队的价值观发生变化, 所以一定要一出苗头就扼杀.
康斯坦汀 2011-12-22
- 打赏
- 举报
看了这个帖子，不说文中那位Yinghai Lu是不是国人或者是海外华人又或者来自台湾。
他确实很像我们国内的程序员，聪明智慧可以说是全球一流的，但守纪律、善于与别人合作方面
确是最差的。不乏技术高手，但缺少领军人物。能写高难度代码，但不会写简单代码（会写
难的其实不是高手，会写简单的代码解决问题才是高手）。
他确实很像我们国内的程序员，聪明智慧可以说是全球一流的，但守纪律、善于与别人合作方面
确是最差的。不乏技术高手，但缺少领军人物。能写高难度代码，但不会写简单代码（会写
难的其实不是高手，会写简单的代码解决问题才是高手）。
mollyjh 2011-12-22
- 打赏
- 举报
什么样的大环境造就了什么样的人才。
金金2019 2011-12-21
- 打赏
- 举报
[Quote=引用 17 楼 alfacuton 的回复:]
有点 晕
不过 有些还是蛮在理..
LZ多愁善感型的.
[/Quote]
我自己都没发现
霍霍
谢谢
有点 晕
不过 有些还是蛮在理..
LZ多愁善感型的.
[/Quote]
我自己都没发现
霍霍
谢谢
zhiheyang 2011-12-21
- 打赏
- 举报
顶一个，现实中能不能真正实现是环境的问题，自己的态度就是自己的事了
kemee 2011-12-21
- 打赏
- 举报
不过首先觉得各种开源组里的中国人能越来越多是个好事
加载更多回复（27）
