作家们和百度的战争

    作家们和百度打起来了，真是让我情何以堪呐。
    照理说，作为一个码工，怎么也算是码字工的同行，应当对作家们表示一下支持。但是我又是个开源免费的爱好者。为防止有人搞不大明白啥叫开源免费，我简单解释一下。简单来说，就是拿着自己的东西在那里叫卖，来吧都来看吧，白给不要钱，还送设计图。作为正常中国人，也许很难理解这种脑残行为。不过事实上，这一切真的发生了，而且在全球范围内轰轰烈烈。
    不过这让我的立场就尴尬了。唔，怎么说呢？我们还是把这件事情拆开说吧。
1.百度有错么？
    我没仔细看，不过依据我的推测，作家在看到自己的作品出现在百度文库中之后，告知了百度，百度却没有积极的配合移除。实话说，这个比较符合我对百度的一贯认识。上次百度因为类似问题，还和盛大吵起来过。当时百度那位发言人的言论，让我颇为惊叹——这么好的人才怎么就没去中宣部或者外交部呢？
    系统里有他人作品并不是原罪，但是别人告诉你，别收录，你还不当回事情就是了。想不被收录进去还要交钱，你当自己是中国黄页么？
    另外做一个不负责任的猜测，说百度和此事无关，也未必完全无关。百度当年曾有要求其他公司购买自己排名，不买就把对方的关键词指到自己身上的记录。我怀着恶意的猜测，若是百度文库的产品经理发现自己产品没人用，找一堆枪手以普通用户身份上传也是有可能的。可惜事出有因，查无实据。本段落仅供一笑，切莫当真。
2.普通人的态度？
    我和女朋友说过这个事情，她的态度是，趁着百度没关，赶快上去看看。还看到一款百度和爱国者推出的电子书，等于免费看很多作品。于是感慨早知道不买kindle，买这个了。我坚决的劝下了她，这种擦边球是不稳定的，投资硬件实属风险，买下来谁知道哪天就白买了。verycd殷鉴在先，百度文库也难说的很——果然，没几天李彦宏出来说话，管不好就关。算不算数倒是另说，要是买了那个电子书，怕是又要担心能不能用了吧。
    有便宜不占是很正常的思路，不过在占便宜前，先考虑一下这句话：起初他们追杀共产主义者，我没有说话-因为我不是共产主义者；后来他们追杀工会成员，我没有说话-因为我不是工会成员；接着他们追杀犹太人，我没有说话-因为我不是犹太人；最后他们奔我而来，却再也没有人站出来为我说话了。（http://www.kaieconblog.net/2011/03/29/10343/）我觉得郭凯说的很好，你可能觉得百度很好，白看东西不花钱。这次你支持了百度，下次就有人搞软件下载中心，上面全是破解软件。再下次就有人搞不知道什么中心——
    中国已经够山寨了，别搞的全国皆山寨，OK？
    可能你说，我种地，我不靠脑子吃饭，搞不到我头上来。那也请你多想一步。搞死中国的作家，我们就只能看免费的社论。搞死了中国的程序员，我们就只能高价买别人的程序。你把中国做创造的都搞死了，你就等着老外涨价吧。山寨老外的？当WTO吃干饭的阿？WTO已经因为中国没有按约定开放出版市场提出抗议了(猛击这里：http://www.etu.net.cn/Article_Show.asp?ArticleID=579)，重复这么搞下去，还想不想出口了？
3.作家维权，结果如何？
    我觉得，这是另一方面。百度固然有错，但是我却不看好作家的维权行动。如我上文所说，中国人现在的习惯就是，窃书不算偷，读书人的事，能算偷么？对着这样的民众，我常有有力无处使的感觉。实话说，我是非常不看好维权的结果的。这种土壤中，即使一个百度倒下去，千百个白读站起来。
4.有什么建议？
    别搞纸质书了，那个注定是昨日黄花。一本纸质书，作家能拿多少？一本电子书能拿多少？假定读者不变，作家收入不变的情况下，电子书定价可以达到纸质书的一到两折，而且没有什么前期费用。作为用户而言，家里堆一堆纸海也是浪费且不低碳的生活。我实在搞不懂为什么要弄纸质书。盗版问题？电子书是比较容易盗版，纸质书就不会受到电子盗版的冲击么？要真不会也没有这次事情了。而且，在一本书一两折的低折扣下，读者反倒会比较多。一本深入浅出MFC，我八年前买的时候是90，现在恐怕要到150上下。一两折只有20-30，买也无关痛痒。读者增多，作家收入还会增加。
    不过现实的一个问题是，传统认为，花钱买一刀纸回去叫消费，天经地义。花钱买一本电子书就不好接受了，总想弄免费的。不过我得说——未来笼罩在迷雾中，一切都会变的，观念也是——
5.我为什么情何以堪？
    因为我比较赞同开源运动的精神，所以也对保护版权的问题提不起精神来。
    开源运动据说起于上世纪美国的嬉皮士文化，主要观点是，代码应当属于全人类，而不是被某个人圈起来贩卖牟利。开源运动开始之所以风行，是因为很多大学教授碰到了版权上的实际问题——版权条约禁止代码用于教学。最有名的例子是UNIX做了闭源限定后催生了minix，后者催生了linux。程序员必须阅读很多的源码，来增加自己的水平，而版权限制这点。
    到了后期，很多大公司也开始支持开源运动。因为这一运动对上游和下游都非常有利，它只损害以版权牟取暴利的人。作为上游厂商，雇用一个熟悉开源系统的硬件程序员，就可以直接开发这一系统的硬件驱动。而不用像微软模式一样，雇用通过微软认证，并且和微软签署不可泄漏协议的硬件专家——这些人的工资中有相当部分是交给微软的保护费。使用开源可以直接的降低成本。而作为下游，则更看中开源系统代码透明，不容易植入有害代码（这点上，微软一直盛传被植入了后门，但是始终无法有力辩驳就可以知道），而且很容易基于自己的需要定制修改。中游厂商则是通过服务收取有限费用，而不是暴利。
    实际上，版权从始至终，都是在保护创造作品的人的积极性。在软件业，开源运动找到了另一种方式来激励创作者的积极性，而不是一味的把东西保护起来。这让我们反思对影视产品的保护力度问题。软件业只享有20年的保护，而出版业，唱片业享有70年的保护。我们是否应当执行如此强力的版权保护政策呢？
    问题归于出版领域，这篇博文（猛击这里： http://weiwuhui.com/4190.html ）印证了我的想法。出版业的大头都在出版社这里，这才是使用版权赚取金钱的大头。

python源码解析读书笔记（四）——杂项

1.GIL的影响

    很多人讨论python性能的时候都提到一个概念，GIL。我在python源码中搜了一下，这个函数调用并不多，但是位置很要命。每个线程，生成的时候请求一下，退出的时候释放一下。在每次运行字节码前也会短暂的释放一下，让其他线程有获得运行的机会。说白了，除非程序显式的调用release_lock去释放资源，否则python是没有任何多线程能力的。这种机会并不很多，通常只发生在阻塞的时候。

    而python原子化的粒度也比较清晰，就是每个字节码内部一定是原子的，字节码和字节码之间是非原子的。当我们操作l.append的时候，不用担心线程竞争导致数据结构损坏。但是如果我们操作del l[len(l)]的时候，存在发生异常的概率。

2.对象缓存池

    python对小内存对象（碎片对象）提供了小内存对象缓存池。默认情况下，256字节以下的内存由小内存缓存池管理，以上的直接向系统申请，申请大小每8字节对齐。

    对象缓存池的分配和收集技术采用了自由资源链表，在2.5之后，当某个尺度的资源不再需要时，会整体释放。

3.python的GC机制

    python的GC机制是基于引用计数的，因此当引用计数归零，对象一定会被释放（如果是碎片对象，内存不一定直接释放，可能归对象缓存池）。

    python的辅助垃圾收集算法是三色标记法和分代垃圾收集模型（generation），由于要跟踪所有的容器对象，因此容器对象上有跟踪链表。

4.字符编码处理方案

    无论从何种来源，只要是字符串，并可能交给一个和当前代码并不紧密耦合的代码处理，就应当被转换为unicode。或者换一个更简洁的说法，应当使用unicode作为接口数据类型。

    str对象是很难猜测编码的，当离开了数据源代码后，再分析编码是个不靠谱的方案。

python源码解析读书笔记（三）——对象和函数

1.mro

    算法，自身先入栈，而后按声明顺序继承每个父类的mro，内部对象在最后。简单来说，深度优先，从左向右。

    当类对象创建时，会将父类所有函数全部复制过来（很明显，应当是符号复制）。

2.super规则

>>> class A(object):

...     def f(self): print 'A'

...

>>> class B(object):

...     def f(self): print 'B'

...

>>> class C(A):

...     def f(self): print 'C'

...

>>> class D(C, B):

...     def f(self): super(D, self).f()

...

>>> d = D()

>>> d.f()

C

>>> D.__base__

<class '__main__.C'>

>>> D.__bases__

(<class '__main__.C'>, <class '__main__.B'>)

>>> class A(object):

...     def f(self): print 'A'

...

>>> class B(object):

...     def g(self): print 'B'

...

>>> class C(A, B):

...     def f(self): super(C, self).g()

...

>>> c = C()

>>> c.f()

B

>>> C.__mro__

(<class '__main__.C'>, <class '__main__.A'>, <class '__main__.B'>, <type 'object'>)

super的算法是跟随mro次序，寻找非本类第一个符合名称的函数，调用之。

3.construct

instance = cls.__new__(cls, *args, **kargs)

cls.__init__(instance, *args, **kargs)

4.bound method

>>> class A(object):

...     def f(self): pass

...

>>> a = A()

>>> a.__class__.__dict__['f']

<function f at 0xb7595454>

>>> a.f

<bound method A.f of <__main__.A object at 0xb75a1e6c>>

>>> a.f.im_self

<__main__.A object at 0xb75a1e6c>

bound method是一个函数对象和一个实例对象的集合。

5.descriptor

>>> class A(object):

...     def __get__(self, obj, cls): return 'A.__get__ %s %s %s' % (self, obj, cls)

...

>>> class B(object):

...     v = A()

...

>>> b = B()

>>> b.v

"A.__get__ <__main__.A object at 0xb75a1cac> <__main__.B object at 0xb75a1cec> <class '__main__.B'>"

某个instance的属性查找顺序为，obj.__dict__，class属性（按照mro顺序）。如果有data descriptor则先于obj.__dict__。

于是，这解释了一个问题。我们定义函数的时候，定义的都是"类函数"，即函数是类的成员。为什么最终函数会变成实例的成员呢？为什么又在调用时会自动产生一个self呢？

实例在查找的时候，会先查找class属性中的descriptor。假定class有成员函数f，当使用obj.f时，首先命中这个函数对象，因为这个对象是一个descriptor。descriptor在取值时，会被调用__get__方法，这一方法有obj参数。于是函数对象的默认__get__返回了一个bound method，其中包含了self和函数对象自身。

这种行为在每次调用时都会发生，因此实例成员函数的性能比unbound method直接写对象要慢。

python源码解析读书笔记（二）——函数特性

1.函数的性质

>>> def outer(o1, o2):

...     def inner(i1 = 10, i2 = []):

...             return i1+o1+o2

...     return inner

...

>>> a1 = outer(50, 30)

>>> a2 = outer(50, 30)

>>> a1.func_closure

(<cell at 0xb75454f4: int object at 0x8455ddc>, <cell at 0xb7545524: int object at 0x8455cec>)

>>> a2.func_closure

(<cell at 0xb754541c: int object at 0x8455ddc>, <cell at 0xb75453a4: int object at 0x8455cec>)

两次生成的函数对象拥有不同的闭包空间。

>>> a1.func_defaults

(10, [])

>>> a2.func_defaults

(10, [])

>>> a1.func_defaults[1].append(10)

>>> a1.func_defaults

(10, [10])

>>> a2.func_defaults

(10, [])

也拥有不同的默认值空间。

>>> def default_test(d = []):

...     print d

...

>>> default_test.func_defaults

([],)

>>> default_test.func_defaults[0].append(10)

>>> default_test()

[10]

然而同一次生成的默认值空间是共享的，哪怕多次运行。

2.参数传递

>>> def f(a,b,c,d): return a,b,c,d

...

>>> f(1,2,3,4)

(1, 2, 3, 4)

>>> f(1,2,a=3,b=4)

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

TypeError: f() got multiple values for keyword argument 'a'

>>> f(1,2,c=3,d=4)

(1, 2, 3, 4)

参数分两种，位置参数和键值参数。具体如何传递是由调用时决定而非编译时。调用时参数必须先以位置参方式传递，再以键值参方式传递。一旦出现键值传递，再出现位置传递即出现编译时非法。调用时会先入栈所有参数，一个位置参占一个对象，一个键值参占两个对象（这是当然）。

解析的时候按照先位置后键值的方式赋值，先将所有位置参依次赋值给所有参数名。如果位置参有多，而没有扩展位置参来接收，则报错TypeError: %s expected at %s %d arguments, got %d。而后将所有键值参赋值给未赋值的参数，如果这个参数名已经赋值，则如上文，报错。如果键值参数有多，又没有扩展键值参来接受，也报错。

最后，如果有参数名尚未赋值，查看这些参数名是否有默认值。如果没有，报错。

另外，在字节码中访问本地（locals）命名空间的时候，是不通过命名空间查询的方式进行的。因为编译时可以明确一个名称是否在locals空间中，而不用理会代码段在名称空间中的位置结构。而一旦明确其在locals命名空间中，则可以直接堆栈访问位置，这样使得locals名称查询速度远高于普通名称空间。对于一个函数内频繁使用的符号，建议做一次赋值，将其引入locals命名空间。

3.调用堆栈

    python的调用堆栈是通过PyFrameObject来实现的，每一次调用，python会产生一个新的PyFrameObject加入到栈中。而每个PyFrameObject自带一个小数据区域，用于接收参数，处理局部变量。python字节码指令中的LOAD_FAST，STORE_FAST就是操作的这个区域。

4.层级闭包的实现

>>> def f1():

...     def f2(): return i

...     i = 10

...     return f2

...

>>> a = f1()

>>> a()

10

实现的还是不错的。通过计算当时名称-值的方法就无法获得i。

>>> def f1():

...     def f2():

...             return inet_aton

...     from socket import *

...     return f2

...

<stdin>:1: SyntaxWarning: import * only allowed at module level

  File "<stdin>", line 4

SyntaxError: import * is not allowed in function 'f1' because it is contains a nested function with free variables

这主要是因为闭包的实现是通过函数编译时名称层状传递。例子1在编译时，f2知道上层作用域中有一个名叫i的变量，于是f2的freevars属性就为i。而当f1操作i时，f2保持了一个对结果的引用。当f1返回f2函数对象时，自身的PyFrameObject消失了没错，但是f2中对结果的引用还保存在了func_closure中。当from socket import *的时候，当前locals空间名称会发生变化，从而导致动态引入的名称无法在f2中生效。

python源码解析读书笔记（一）——内置对象

1.类型的类型

    obj int(10).ob_type -> PyInt_Type

    PyInt_Type.ob_type -> PyType_Type

    PyInt_Type.tp_base -> PyBaseObject_Type

    PyBaseObject_Type.ob_type -> PyType_Type

    PyType_Type.ob_type -> PyType_Type

更精确的参考源码解析262页图。

2.小整数对象

    if (-NSMALLNEGINTS <= ival && ival < NSMALLPOSINTS) {

        v = small_ints[ival + NSMALLNEGINTS];

        Py_INCREF(v);

    }

3.大整数对象，空对象池，对象缓存

>>> a = 1000000

>>> b = 2000000

>>> id(a) == id(1000000)

False

>>> id(100000) == id(100000)

True

最后一个是因为python解析器在解析对象的时候，对前后生成的对象进行了缓存。经过测试，对文件也有效。

4.字符串对象复用和缓存

>>> c = 'qazwsxedcrfvt'

>>> c += 'gbyhnujmikolp'

>>> a = 'qazwsxedcrfvtgbyhnujmikolp'

>>> id(a) == id(c)

False

>>> a = 'abc'

>>> b = 'def'

>>> c = 'abc'

>>> id(a) == id(c)

True

>>> b = 'abcde'

>>> id(b[1]) == id(c[1])

True

缓存原理同上，对于长度为0, 1的小字符串，永久缓存。

5.free_list对象缓存的机制

每个类别有自己的free_list对象，用于缓存已经被销毁的对象。目前尚不清楚GC是否会定时释放这部分内存，但是python在对象引用到0时是不释放对象的，而且多数情况下表现为内存泄漏。而且多种对象的free_list不能互相通用，继承子类也不适用。

6.list对象的行为

list对象用一种vector等同的方法处理对象池。因此随机插入（尤其是头部插入）一个对象超长队列会引发大量的内存复制行为。

7.dict对象的索引方案

dict对象的索引方案使用的是哈希表，而且是开放地址法的哈希表。当装载率达到一定规模后，会新申请一块内存，将有效数据复制过去。最小的表空间为8个对象，当装载率超过2/3时，会扩大规模到当前active的4倍（超过50000个对象为2倍）。目前为止，在对象被删除后，其表空间并不释放。因此曾经增长的非常大的dict对象，可以定期复制以回收空间。

8.dict的用法注释

从序列中移除重复对象

    dict.fromkeys(seqn).keys()

计算序列中元素出现次数

    for e in seqn: d[e] = d.get(e,0) + 1

词典中移除大量元素

    d = dict([(k, v) for k, v in d.items() if k != xxx])

词典中访问可能不存在的元素（当不存在的风险高于5%时）

    o = d.get(k, default)

词典中访问可能不存在的元素（当不存在的风险低于5%时）

    try: o = d[k]

    except KeyError: o = default

豆瓣九点的认领功能

    以前写了blog，每天都跑去豆瓣同步一下。方法是新建一篇日记，然后贴链接。今天牛博恩（http://www.douban.com/people/dark-shines/）提醒我，"你在九点上订阅自己的博客，然后再认领就没必要更新博客的同时还在豆瓣日记上发一篇一样标题带链接的"。好吧，刚刚发现这么舒服的方案。我已经发贴，豆瓣来吧。
doubanclaim7834a5d025d455b1

不要问我你和妈掉进水里救哪个

    我和你妈掉进水里你先救哪个？这个问题恐怕全地球男人都知道正确答案——不要回答。
    先救老妈？只怕女朋友当场翻脸。但是先救女朋友？先不说老妈高兴不高兴，女朋友要知道你会如此对待父母，只怕也会质疑你会如何对待她的父母。所以这个问题就根本不能回答，或者说根本不要问。因为哪个回答都不是你想要的。
    中国古代伦理中，这个问题倒是不难回答。百善孝为先，除了皇帝的女儿，有哪个跋扈媳妇敢问这种大逆不道的问题？只怕先是一个多言的罪名被休妻回家，回家还会被众人指指点点戳脊梁骨。外国人如何回答我不清楚，我只问了thomas这个问题。当然，准确的说，是他老婆问的。但是他的回答很有意思，救年轻的。他老婆听了很高兴，然后thomas很二的加了个注解。如果你和孩子掉进水里，我就先救孩子......
    我不知道这是不是外国人的普遍观点，不过这也代表一种观点——最大幸福理论。最大幸福理论关注的是结果，当一个冲突发生的时候，最大幸福理论的意见者总是选择获利人数最多的方案。例如一个正常的铁轨上有五个孩子在玩，一个废弃的铁轨上有一个孩子。你可以扳动扳手来决定死哪边，扳不扳？最大幸福理论者认为，扳！当然，会有另一个相反的理论跳出来。这种理论关注原因，当一个冲突发生时，他们总选择惩罚行为不正确的人。还是以铁道上的孩子为例，他们的观点是，那个孩子是正确的，所以，不扳！
    应用在老妈和老婆掉到水里的问题上，最大幸福理论就很容易得到观点，保护剩余生命最长的人。当然，另一个理论就没法得出直观的结论，因为我们根本不知道老妈和老婆是怎么掉下去的。如果是老妈推老婆下去导致自己也下去了呢？关注行为的理论就能得到结论，救老婆。
    相较于外国的两大观点，分别关注过程和结果。中国的理论更关注"关系"，关系决定论占据了东方决策的主流。以双方的关系，子女和父母的关系，夫妻的关系，来决定每个人的行为。这就是所谓的"父父子子君君臣臣"。从传统观点来看，媳妇敢和婆婆争重要性，无疑是忤逆犯上了。其最简洁的回答就是，媳妇可以再找，老娘只有一个。这个理论推广开，就是婆婆折磨媳妇，多年媳妇熬成婆的传统。这个传统的对错暂且不论，中国传统伦理那一套已经被我们彻底打倒了，还踩上一只脚让其永世不得翻身。文革平反后，中国又开始了大规模的城市化进程。这个传统的儒家伦理体系现在是不受到什么重视了，只是在每个传统中国人的行事里面看到痕迹而已。
    那么现下中国人的实际答案呢？救老婆。有意思的是，这个观点的形成并不是理论体系的指导和理论体系对现实的适应，而是彻彻底底的市场运作。由于一胎制的推行和中国传统重男思想的痕迹，所以中国男女比例严重畸形，男性人数远远大于女性。上面那句回答的实际情况就变成了，老娘只有一个，媳妇一个不到。所以聪明点的中国人都知道，养女儿，不要养儿子，儿子是个赔钱货。在这种情况下，男士们虽然碍于传统中国思想，都不敢大声说出自己的选择。但是在有意无意中，都照着这个实际答案做了。
    所以由此产生的中国女性解放，不得不说带着畸形的痕迹。新中国的女性要求照着欧美靠拢，但是唯独不学人家的女性独立生活的能力。当然，中间要插一句的是，中国人也向来不注重培养年轻人的独立生活能力。一个美国学生发表这方面言论还被死亡威胁。(具体看这里： http://internet.solidot.org/article.pl?sid=11/03/21/037231&amp;from=rss )中国女性希望依靠丈夫，于是丈夫越有钱，有能力，就能吸引更多的女性。按照流行的话说就是，我宁可坐在宝马后面哭，也不要坐在自行车后面笑。然而中国女性在依靠了丈夫后，却不希望如传统一般受到夫家家庭的约束。当然，实际上夫家的约束还是会发生的，就形成了新一代的婆媳冲突。这和传统的恶婆婆折磨媳妇并不尽相同，因为婆婆通常不是折磨媳妇，而是关于儿子的具体问题上，双方不能达成一致。
    好吧，回到原题。如果你正在恋爱中，或者婚姻中。就别问你的伴侣，我和你妈掉到水里你先救谁。你得不到想要的答案，对方一定会顾左右而言它。更神奇的是，我认识的人中，问过这个问题的人基本都受到了这个问题的折磨。所以，你最好不要问，而是祈祷这种问题永远不要发生。

关于IT雇员的一点话

    IT是个很大的圈子，没人敢说什么都懂，也没人什么都懂。我们都有碰到不明白的时候，都得去查资料。一个人力资源方面的有趣的问题是，公司该不该为查资料的时间付钱呢？
    技术上说，IT人员查资料是一个自我学习的过程，公司既不从中受益，也就没有为此支付薪水的必要。然而我们都忽略了一件事情，就是你招聘的员工，究竟是一个新手呢？还是一名领域上的专家。如果是领域上的专家，我得说这个技术上的说法是成立的。因为你在招人的时候，就已经知道对方的身份。并且，可以合理的假定，对方基本不用去查找资料，或者学习一些新的东西。当然，实际执行的时候，偶尔还是会发生这样的事情，不过这就不重要了。
    然而多数公司没有这样的好运，好运这个词包括招聘的价格和高昂的招聘运作过程。天天投简历尚找不到工作的人也许无法理解，一个公司要招聘一个靠谱的员工到底有多困难。在IT的某个子领域，例如某种数据库大规模集群性能优化。能够谈的上足够专家，有一定经验，从而避免大部分的学习和资料查找的人，在中国的人力市场上大约也就是几千人。平摊到广袤的中华大地上，在上海的专家不足一千，不少还在大公司里。当一个公司真的需要一个能做事的人的时候，几乎没有可能找个专家过来，甚至在比较生僻的领域中连有一定经验的人都极为抢手。即便是比较通俗的java程序员，专家的招聘难度虽然不高，但是工作成本却不低。雇用一批专家来写程序是件很低效的事情。
    大多数公司会雇用一批合适的人，这批人通常是高校毕业，有工作经历。这些经历可能是学校中的，也可能在小公司工作了一年。无论如何，他们会使用工作中所需要的技术，却绝对不能称作熟练。他们没有足够的经验写出工业化的程序，而且会花费大量时间查阅资料，自我学习。也正是如此，公司支付的薪水也是非常低廉的。
    好，我们回到最初的问题上。我认为对于这些普通员工，公司实际上是以降低价格的方式，来让他们为学习买了单。如果再要求他们不能在工作时间查阅资料自我学习，无疑是苛求。相反，对于这些尚未成熟的程序员，最好增加公司培训，以补充高级程序员的缺口。当然，实际执行的时候必须考虑到培养成本和违约问题，考虑一些比较可控的培养方式。在中国常见的情况是，程序员培养好了，人也跑了。
    说到这里，想起一个台湾朋友和我说的。虽然我们（指台湾员工和大陆员工）的能力差不多，但是台湾人，新加坡人拿的就是比大陆人多。有些人就觉得是有歧视，其实不是的。老板要求的是一个稳定的人来做事，他和我说好了两年不能离开，我就准备工作两年。他们老板我也聊过，的却向我抱怨过大陆这里招到人，培训好了人就跑了的情况。正是因为我们每个人的小小聪明，造成我们的整体信用不佳。老板不敢用，也不敢培养大陆的员工，总觉得有一天会被他们放鸽子。这种情况下我们发展到领域高阶职位就越来越难。很多东西必须是坐在那个位置上才会学到那些东西，就是所谓的"居移体养移气"。对于员工来说，长期在一些低端职位做一辈子，也是学不到高阶位置所要的东西的。大陆员工不比别人笨，但是人家一出来就做到管理者位，我们则是坐在了工位上。于是在此后几十年的人生长跑中，差距就越拉越大。
    怎么办？我不是教人怎么办的，我只是说行业里面的一些现象。

approx无法升级问题的解决

    approx最近不知道怎么回事，无法升级。每次aptitude update都无任何升级提示。而直接指向mirrors是可以升级的。
    其实，去缓存目录下删除Release和Release.gpg就好了，通常是在/var/cache/approx下面的debian/testing/下面，testing是你的/etc/apt/source.list中指名的发行。

乘飞机的几个提示

    1.飞机的登机过程是，买机票。提前起飞小时一个半小时到机场。到值机柜台划位，托运行李，更换登机牌。过安检，到登机口等待登机。登机，并等待飞机起飞。下面的过程就比较不固定，大概是，天气原因飞机延误，航空管制飞机延误，不广播原因飞机延误。注意！民航规定，飞机延误四个小时以上的，不问理由，必须赔偿。当然，战争之类的不可抗力不算。天气算不算不可抗力，这是一个很有意思的问题。

    2.记得携带身份证，没有身份证是上不了飞机的，而且后果自负。

    3.机票通常越早订越有折扣，临起飞前一天往往已经没有折扣了。

    4.根据机场和航班的不同，通常要求你提前到一定的时间。以北京首都国际机场为例，国航的要求是提前一个半小时到机场。这并不是说你没有提前一个半小时就无法上飞机，只是说如果迟到后果自负。当然，这个时间越长，你越找不到航空公司的麻烦。所以不要相信这个时间，傻傻的去等着。在你熟悉机场的情况下，可以估算一下提前多久。飞机的值机柜台关闭大概是起飞前30分钟，后面就是等候柜台办理了。登机关闭大约在飞机起飞前10分钟，两者会根据你的登机口距离和飞机距离有所变化。只要你在合适的时间赶到，都可以顺利上飞机。当然，如果机场并不熟悉，还是早点到的好。不知你是否能够想象，有的时候机场外面出租车会排起长达一个多小时的长队，例如以前的虹桥机场在周一早上的时候。所以要稍微清楚一点到机场的方式和可能被延误的时间。通常越不稳定的交通方式，越早到机场以防万一。

    5.知不知道最好的座位在哪里？走道机窗各有所好，但是公认的最佳座位在紧急通道旁边一排。首先是，根据统计，这里的逃生概率最高，坐在这里等于具有额外的命。其次，由于为了逃生原因，所以座位和前面的距离比正常的宽一些，坐起来比较舒服。

    6.如果你迟到了，值机柜台关闭了。你自己估计赶的上飞机，可以向候补柜台申请。最好没有行李，因为重新开启行李通道比较麻烦，工作人员一懒，你就上去不了。当然，平时也是尽量少带托运的好，拿行李也很麻烦。

    7.在过安检的时候，记得不要带凶器，不要带液体，不要带火。有电脑的拿出电脑，尽快的把东西放在篮子里面过去。被安检人员发现违规是最麻烦的事情，你要么回去重新托运，要么当场丢掉。

    8.在紧急的情况下过安检，你可以向工作人员申请急客通道。有的机场让你从机组和头等舱通道过去，也是一样的。目的是减少你过安检的时间。当然，你最好不要用到这条。

    9.检票登机的时候不要着急，登机牌上的座位是固定的，你不高兴没人会抢。早早的排队登机只会增加你的排队时间。

    10.到座位后，把东西放上行李架就赶快坐下，后面的人还要过去。文明点，谦让点，下次也会有人让你过去。

    11.飞机起飞的时候有快速升高，这时候会产生压耳现象，尤其是当你感冒的时候。有些人可以自主调节欧式管，从而消除压耳现象(贝壳就可以)。有些人就不大会，从而发生耳鸣，听不到声音，耳痛什么的。别担心，喝点热水，嚼一下口香糖会好转的。

    12.很偶然的情况下，飞机内舱压会略略失常。有些人会发生头晕，头痛，耳鸣(和压耳完全是不同感觉)，疲劳等高原反应。在贝壳数百次飞行中，只发生过一次这样的现象。这时候没什么好办法，尽量睡着吧。高原反应药是来不及了，严重可以吸氧。

debian是什么

    debian是一种开源的操作系统，其内核理论上是可变的，主要有linux/freebsd/hurd三种。但是目前为止，主要被采用的都是linux内核，大部分都是基于i386或x86_64编译。

    debian系统使用一种被称为deb的打包格式，这种格式中声明了依赖性问题，但是没有解决。所谓依赖，是指一个包内不包含运行所需的所有组件。例如特定版本的lib，辅助配置程序等。将依赖分离有助于多个包共享一份被依赖程序，并且几个组件可以独立升级。windows中通常将依赖包加入安装包内部，但是这样往往不利于被依赖程序的升级。(windows的二进制兼容性做的并不很好)如果没有打入安装包，windows中通常表现为安装一个程序的过程中提示你需要安装某个东西，请去哪里下载。debian的依赖是依靠一套被称为apt的系统解决的。在这套系统中，你可以指定一个源(debian mirror)，或者多个源。apt系统会自动将上面所有软件的目录下载下来供你查阅安装。如果有依赖性问题会自动安装依赖的包。因此，配置好的apt系统相当于一个软件仓库，里面有很多程序。你可以选择其中的一部分，安装使用，而无须忧心安装过程。

    apt的更新分为三部分，一部分是这个源中有哪些包，这些包的元信息(meta info)。包括这些包的名字，版本，所依赖程序的版本等。当一个源获得了新的软件的时候，就会更新这个列表，或者叫目录。客户端更新目录后就可以发现，有哪些包需要更新或者下载。而另一部分则是这些包文件本身。最后一部分是以上内容的签名。在元信息上有包文件的校验，而元信息本身则被一个非对称密钥签名。这个签名由apt的管理者签署，从而保证只有受到管理者认可的包会被客户安装，其他恶意插入的包都会被警告。

    debian系统默认是没有图形界面的，也没有ssh操作界面，debian的基础系统甚至没有一个可启动的内核。基础系统中只包含了一个文件结构，和被简单配置能够自我管理的apt系统。最精简系统在基础系统之上，安装了内核和引导管理器，从而保证在某个系统上可自启动和自引导。debian的businesscard安装包包含了一个建立其他精简系统所需的所有工具的集合，而netinst安装包则增加了建立最小系统所需的镜像。两者的区别在于，businesscard必须联网以下载最小系统所需的所有安装包，而netinst可以从光盘上获得这些包。

    当然，这离一个完整的系统还差很远。作为服务系统，必须安装ssh以便于远程管理。作为桌面系统，需要安装X，WM，还有其他应用程序。甚至，作为网络系统，基础的网络配置组件都是默认不完整安装的。你必须设定网络，设定源，然后更新列表，而后安装合适的程序。这一切对于初学者非常不友好，所以debian还有一种gnome标准安装包，在光盘上放了建立一个标准系统所需的所有包。你可以在不联网的情况下，自动建立起一个标准的桌面。

    debian的特性是非常强的自我定制，虽然从根本上说，gentoo的定制方式才是极限。但是长期滚动编译对维护而言是一个非常大的挑战(debian的维护方式都会让很多公司感到不舒服)。debian可以很方便的直接定制一个特制化系统，而跳过编译过程。这对于自己需要一定程度定制的高级linux用户非常有吸引力。

社区的基础规则和原因

    1.社区中的常规事务由个人申请，申请到的人全权处理问题。
    2.在申请前，需要在社区公共平台呼叫请求。大致类似于"我要做某事了，有没有人在做或者能够提供帮助，请联系我"。
    3.如果有人对贡献者所做的工作有异议，可以请求修改或者复议。
    4.如果仍旧不满意，可以申请替换贡献者。经过全社区成员投票后就会变更贡献者。
    5.如果不能明确归属的事情，或事情本身就比较重要，则由全社区成员投票。
    6.如果具体操作者在不确定做法的时候，可以发起讨论和投票，获得社区意见。

    为什么社区通常具有以上工作模式？
    首先，社区的原则是自愿。通常社区是不会为个人的工作支付薪酬的。因此，谁愿意做什么事情，做到什么质量，完全是不可控制的。这也就是为什么社区事务是由个人申请的，因为并不能向社区中的具体人员指派工作。当一个问题比较严重的时候，也只能由资深社区人员呼吁有没有人志愿解决，而不能强行分派。这是社区为各个软件公司所诟病的特性之一。
    为什么申请前需要在公共平台呼叫请求？这样首先防止了工作冲突。尤其是上游发行一个新包的时候，如果没有呼叫请求(debian社区好像叫做ITP)，就会出现两个打包者重复工作的问题。其次，如果前任因为某些因素放弃了继续处理，也许他能给你一些额外的帮助。尤其是兼容性问题上的帮助，这样比较有助于保障一致性。
    为什么通常事务由申请到的人全权负责？因为一个事务会牵涉到非常多和复杂的细节问题。例如一个包的临时文件位置是使用/tmp还是/var/tmp，依赖库是使用gcc4.1还是gcc4.4。这些细节问题要一一搞定，社区没有那么多时间。如果志愿者是个熟练的人，往往问题的决策会采用比较通用的方案，社区会无条件接受志愿者的方案。当志愿者的方案比较糟糕，或者至少说有待推敲的时候。如果有人用的不爽，就会提出异议，或者更进一步提出解决方案。如果没人关心，那就让他去了。
    为什么对于仍旧不满意的问题，只能替换贡献者，而不能强迫贡献者接受方案呢？因为，上文阐述了，贡献者是出于自己的自愿，来帮助社区的。强迫他们接受某个他们所不习惯的想法首先并不尊重他们，招致他们的强烈反感。其次，这些方案可能扰乱他们的工作思路。所以从这个角度来说，当志愿者愿意接受你的方案时自然好说。而如果万一他不接受，要使得自己的想法实现只有让全社区基本同意，你，或者其他人接替这个志愿者的部分工作。
    为什么社区在决定性的问题上，采取贡献者民主投票的方式呢？因为，如前我们看到，社区的发展是每个贡献者提供自己的力量共同发展的。这样的社区一定会有不协调的情况。而让冲突升级，导致社区分裂，是不利于社区发展的。可以看到，社区是要讨好贡献者的。更多，更强力的贡献者，社区就能够有更好的发展。所以，采取民主投票的方式，是征求最多贡献者的同意，让他们支持社区，愿意继续为社区作出贡献。并且期待不同意的贡献者，能够理性的作出一定妥协，接受社区的大多数意见。
    当然，由于意见未能统一而倒置社区分裂的情况常有发生，尤其是社区同时拥有两位强势的领导的时候，并且他们的意见碰巧相左的时候。但是在大多数时候，贡献者会考量，自己是否值得为了某个意见放弃整个社区。考量的结果往往是接受社区的结论，但是保留自己意见。这种行为会保留社区中最多的人，并且可以期待剩下的人能够接受。这一原则，我们称为"尊重大多数贡献者"。而社区中，部分事物自主可决定的规则，只是因为社区假定你的行为会被大多数贡献者接受。
    我们可以看到，社区在发展中采取了很多自主判断假设和市场机制。社区需要假定你的行为是被大多数贡献者所能接受的。社区假定你能够分辨什么是"比较重要"的事情，从而需要征求多数意见。什么是你不需要劳动社区帮忙的事物。在正常的世界中，我们的假定通常都是成立的。debian社区大部分打出来的包并没有人提出异议。对于社区中文名定名或者下一开发版代号之类的问题，通常也是社区协商确定后再行处理的。因此，我们的社区通常工作良好。但是在某些特例下，例如有人无法理解什么问题是重要问题，哪怕大多数的人对这个问题的认识并没有困难。或者，更进一步说，有人捣乱。在这些特例下，社区往往会陷入一种比较混乱的状态。国外经常有所谓"民主效率低于专制"的结论，就是这个现象的集中爆发和体现。
 

debian社区争论摘抄

jobinson <jobinson99@gmail.com>

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

强烈反对这种所谓的尊重说

1、这是人身攻击，攻击他人人品，不是在认真讨论问题

2、我并没有违规。我的作为，是符合debian维基本身规则的，如果这样你还认为我违反规则，不尊重别人，那么，首先的问题就是你拉大旗扯虎皮，把你的个人观点强加在整个debian社区之上，这才是更大的不尊重社区。

也就是说，在目前维基规则未变的情况下，我并没违规，上面几个认为我不尊重人的人，其实才是真正的违规者。

3、请不要以贡献来论我的对错，这是道德绑架，虽然我对debian目前官方社区的贡献有限，但在其他地方的贡献，请不要在不清楚的情况下肆意抹杀，然后试图以玩道德绑架的方式让我闭嘴。

4、单纯讲翻译问题，debian社区确实太多文档老久了，以至于我都不知道debian中文翻译团队是否活着，这是谁的问题？如果按贡献论，是不是原有社区的人都该被论罪？这显然会激起众怒，如果楼上认为贡献论可行，那么接下来激怒社区的责任楼上要负全责。

5、如果debian是世界性的，那么debian就应该容纳得了中文、英文、德文、日本、西班牙文……，而不是只能使用英文。现在这种情况，连个中文名都起不了，还谈什么世界性，简直就是狭隘英文中心主义。

6、请不要回避问题，老左躲右闪的，以贡献啊、尊重啊、其他更需要啊之类的来搪塞对问题的真正讨论。要不干脆关闭这个讨论，要不就不要躲躲闪闪，认真对待。

还有，就是存在众多莫名其妙的所谓公认规则，结果一认真，才发现不过是个人意见，强加给这个社区的，这样的个人规则，请不要再秀出来，这才是真正对社区其他人的极大不尊重！

其实，我也不想纠结在这些名词上，但如果连这么个名词都容纳不下，我不觉得还能容纳下什么别的东西，我不知道英文社区是否也是如此。

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

Aron Xu <happyaron.xu@gmail.com>

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

2011/3/17 jobinson <jobinson99@gmail.com>

>

> 强烈反对这种所谓的尊重说

> 1、这是人身攻击，攻击他人人品，不是在认真讨论问题

也许有些人的话确实说的不怎么恰当，这是说话人的问题，呵呵。

> 2、我并没有违规。我的作为，是符合debian维基本身规则的，如果这样你还认为我违反规则，不尊重别人，那么，首先的问题就是你拉大旗扯虎皮，把你的个人观点强加在整个debian社区之上，这才是更大的不尊重社区。

> 也就是说，在目前维基规则未变的情况下，我并没违规，上面几个认为我不尊重人的人，其实才是真正的违规者。

你的操作没有违反权限（否则没权限你无法编辑），但是违反了在社区活动的一条基本准则：做自己的事不要给别人带来麻烦。现在你私自改了东西就给很多人带来了麻烦。

像项目名称这样重大的决定应该是团队的共同意志，如果你直接不经说明就私自改了，那么你忽略了其他人的意见，这的确是不尊重他人。社区中不是你有权限编辑的地方就可以随意编辑，赋予你权限是对你的信任，相信你能够和其他人好好地合作，共同把项目做好。如果说有了权限就觉得自己什么都可以做，那就辜负了社区对你的信任。

> 3、请不要以贡献来论我的对错，这是道德绑架，虽然我对debian目前官方社区的贡献有限，但在其他地方的贡献，请不要在不清楚的情况下肆意抹杀，然后试图以玩道德绑架的方式让我闭嘴。

何必把这个问题升级到对与错呢（大家都停止说这个对错，^_^）。我觉得只是你做事方法不对，现在不应该在这里讨论这个名字如何如何，而是尊重大家的意见暂时不使用它，并且通过主流媒体做出更正。

昨天我联系 cnbeta.com 等两三个站点删除了文章，LUPA等社区还发了一些更正。希望大家能到 cnbeta 等地方投稿更正这个事情。

> 4、单纯讲翻译问题，debian社区确实太多文档老久了，以至于我都不知道debian中文翻译团队是否活着，这是谁的问题？如果按贡献论，是不是原有社区的人都该被论罪？这显然会激起众怒，如果楼上认为贡献论可行，那么接下来激怒社区的责任楼上要负全责。

Debian 文档翻译在 Squeeze 周期里没有怎么更新 installation-guide，重译了

maint-guide。网页翻译匆匆地赶出来了一个 release-notes。

如果你要参与，非常欢迎，这个团队现在可以说基本只有个别人做零星贡献。自由软件社区里，每个人都是自由的，行为上第一条是不给别人捣乱，第二条是交接好工作。翻译上一直没人接手，如果谁愿意来可以到这里先询问一下情况——比如你现在问，这个团队是否活着。

> 5、如果debian是世界性的，那么debian就应该容纳得了中文、英文、德文、日本、西班牙文……，而不是只能使用英文。现在这种情况，连个中文名都起不了，还谈什么世界性，简直就是狭隘英文中心主义。

这种说法有些偏激，和中国中央电视台不能称为CC{T,A}V有一拼了（笑）。当然，Debian和中文名之间并非完全和CCTV那个情况相同。

Debian 不是不能有中文名，而是现在还没有让众人觉得确实最好的名称。过去常说的"大便"显然不雅，"蝶变"某种意义上讲是个不错的候选，但还是有很大反对的声音。

不管好与不好，想出来的都是"候选"，不能直接改 Wiki 强迫别人接受你的意志，哪怕你解释说只想做个实验。

这样的实验是不合适的，就好像说某国核电站出了问题，事后说我只想实验它出了问题能有多大影响，这显然不对。

> 6、请不要回避问题，老左躲右闪的，以贡献啊、尊重啊、其他更需要啊之类的来搪塞对问题的真正讨论。要不干脆关闭这个讨论，要不就不要躲躲闪闪，认真对待。

其实讨论能展开这么久，你回避了最关键的问题。现在是你做得不对，未经讨论滥用了社区赋予的权限，为啥还在说别人呢。

争论的话说多了，谁都可能说出赶劲的话，这时候大家坐下来喝杯茶冷静下，呵呵。

> 还有，就是存在众多莫名其妙的所谓公认规则，结果一认真，才发现不过是个人意见，强加给这个社区的，这样的个人规则，请不要再秀出来，这才是真正对社区其他人的极大不尊重！

>

这确实是公认的规则，难道赋予你的权利不是给你的信任吗？如果说，必须要精细地管着你的权限才舒服，那我在这里无话可说。可以随意编辑的分到一类，不可以随意编辑的再分到一类并锁定，我觉得那时候会有人大叫不公平。

> 其实，我也不想纠结在这些名词上，但如果连这么个名词都容纳不下，我不觉得还能容纳下什么别的东西，我不知道英文社区是否也是如此。

不想纠结就不说这些，赶快把给大家造成的麻烦处理掉。如果你想讨论社区的规则是怎样的，社区怎样才有包容性，再单独发主题，有兴趣的人会愿意和你讨论三百回合。:P

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

Tao Wang <dancefire@gmail.com>

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

说你不尊重社区，你还觉得有错了。还什么这论，那主义的，还论罪，我怎么恍惚觉得倒退了几十年，又看到了满眼红色的世界？

真是莫名其妙，看看jobinson都干了些啥：

http://www.udpwork.com/item/4522.html

http://www.freebsdchina.org/forum/topic_51353.html

http://www.freebsdchina.org/forum/topic_51346.html

http://zh.wikipedia.org/w/index.php?title=Debian&diff=15902934&oldid=15830869

http://zh.wikipedia.org/w/index.php?title=Linux&diff=15963993&oldid=15926795

http://zh.wikipedia.org/w/index.php?title=LISP&action=historysubmit&diff=15923316&oldid=15796262

http://wiki.freebsdchina.org/howto/i/installbsd?do=diff&rev2[0]=1297687950&rev2[1]=

https://wiki.archlinux.org/index.php?title=Beginners%27_Guide_%28%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87%29&action=historysubmit&diff=133867&oldid=133351

不止 Debian "受灾"，还有"共努"(GNU), "你牛叉"(Linux)，FreeBSD 也不能幸免，而且不限

OS，还有"历"(Lisp)，"易码器"(Emacs)，"囧境"(FreeBSD jail)等。

不怕浪费流量的，还可以看看他的blog，还有更多：http://jobinson99.blog.163.com/blog/static/2591478201111801642260/

基本上，所有这些中译名都没有成为社区共识，他就自己擅改了。导致各个社区不得不花力气来回卷他造成的破坏，浪费了更多给社区做贡献的时间。而且，他在各个社区都强行将回卷回去的内容，在改回来，完全不顾维护者的劝告，试图把自己的意志强加给社区的身上，引起了各个社区的抗议和争论，更是浪费了大家大量的时间和精力。

这绝对是对开源社区的不尊重，而且还是对开源社区的破坏，强迫大家把有限的精力放到这些事情上。

社区赋予你权力的时候，同时赋予你信任。信任你的修改是贡献，是不违背社区意志，是尊重社区的成果。你辜负了社区的信任，而且辜负了不止一个社区的信任。

开源社区是协作，不是独裁。没有人禁止你讨论，但将你自己的意志强加到社区身上，绝对违背了社区活动的基本准则。

开源社区是互相尊重，而不是我就是对的，你就是错的，忽略别人的劝告。那些浪费自己精力的各个开源社区的维护者把你的内容回卷的时候，很多都提出了劝告，告诉你不要这么做。你要是反对，可以发起讨论，形成共识，自然会形成结果。而不是把别人的劝告当耳旁风，又强行改回来。

开源社区是建设，而不是破坏。你做的事情，不是建设，而是破坏。

开源社区是贡献，而不是被迫。大家都是业余时间来做贡献，平时都有自己的事情。本来时间就不多，应该把有限的时间，投入到更多的贡献上来，而不是不得不花精力修复你的破坏，从而避免产生更大的影响。浪费别人的时间，可以等同于谋杀。

如果这还不叫不尊重社区，那就真是见鬼了。承认你的错误，向每个被你捣乱的社区道歉，主动修复你的破坏，积极参与社区社区建设弥补你给社区带来的浪费和损害，这是我认为一个还对开源社区有点尊重的人应该做的事情。

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

CHEN Xing <cxcxcxcx@gmail.com>

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

本地化并不只面向英文有困难的人。一个外来事物与本地文化相融合时，产生一些本地化的词汇等是完全正常的。而且即便是有一定的外文水平，多数人还是愿意用母语或母语的习惯交流。且不说使用拉丁字母的其它语言可能各自按其拼读习惯称呼Debian。随便上Debian主页上点一点，发现多数使用非拉丁字母的拼音文字的语言，如朝鲜语、阿拉伯语、波斯语、希伯来语、泰米尔语等还是按其发音做了音译，我想这也是为了人们更方便的拼读和交流吧。汉字不是拼音文字，所以中文翻译常要译出点意思，但不同人对这"意思"的理解不一样，就容易出分歧（于是我还是建议，"德边"啊"戴边"啊之类无意义但读音相近或与汉语拼音一致的翻译，至少能统一个称呼）。

另外，本地化与国际化并不互斥，少做本地化也并不意味着国际化就更容易。就拿Debian这个名字来说，看来真正读得准的人并不多；前面朋友也指出像Fedora这样的名字也有不少人读错，这或多或少反映出虽然还没有即便没有本地化，也未必就已经很好的国际化了。另一方面，即便有了中文名字，懂英文的人还是会知道其英文对应的是Debian的，这个应该不必担心。

但本地化要做还是要做好，做得不好不要发布，或者有些干脆不要做。比如中文的man pages，很好的一个项目，但可惜多数man

page的中文翻译相当不完整，丢失了很多信息，这个就非常不好（还不如翻译能翻译的，其它留着不动）。我现在如果装了带中文man的发行版，不得不先把相应的包删掉……另外有些应用的中文翻译出现大量莫名其妙的译法（一时忘了名字），也是不大合适的。回到这两天的"蝶变"，也算是一种例子吧。

不过想起一个问题，给Debian一个中文名字确实会给搜索资料带来一定麻烦，不知Google的同义词库更新及时不及时。但我感觉影响很可能也不会太大，有个中文名字大家估计还是口头交流用的多，书写技术文档时估计还是会习惯直接用Debian吧。

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

今天先摘抄，改天做社区总论。

debian中文名的争议

    最近在debian社区上爆发了关于debian中文名问题的争议，我大致摘录一下，具体可以看debian maillist archive。毕竟这里不是wiki，我就不求全了。
    起因是因为Jobinson在社区未达成一致的前提下，将wiki中debian的中文名称改为了"蝶变"。而后，wenheping告知了LIDaobing。后者是DD。LIDaobing将wiki还原，并且发起了社区讨论。他们之间的原文贴录如下：
----------------------------------------------------------------------------
(03:37:51 PM) Atlas Jobinson: 我想问你个问题，你是什么时候知道这维基被改的？通过什么途径知道的？
(03:38:01 PM) LI Daobing (李道兵): 很晚
(03:38:11 PM) LI Daobing (李道兵): 因为我没有 subscribe 那个页面
(03:38:22 PM) LI Daobing (李道兵): wenheping 告知的
(03:38:29 PM) Atlas Jobinson: 你可以看看我最早翻译于什么时候
(03:38:37 PM) LI Daobing (李道兵): 看到了
(03:38:40 PM) Atlas Jobinson: 2011-03-04
(03:38:42 PM) LI Daobing (李道兵): 10天前
(03:38:52 PM) Atlas Jobinson: 那说明什么问题？
(03:39:06 PM) LI Daobing (李道兵): 说明你在没有取得社区共识前
(03:39:09 PM) Atlas Jobinson: 还有，那个wenheping，是我在freebsd上得罪他了
(03:39:12 PM) LI Daobing (李道兵): 就修改了 wiki 页
(03:39:23 PM) Atlas Jobinson: 错，说明debian中文的参与者都不关心
(03:39:30 PM) LI Daobing (李道兵): 罗伯特议事法则
(03:39:34 PM) Atlas Jobinson: 连被人改了都不知道
(03:39:38 PM) LI Daobing (李道兵): 不要追究动机
(03:39:47 PM) LI Daobing (李道兵): 我们关心的是 ibus, fcitx, scim 的 bug
(03:39:50 PM) LI Daobing (李道兵): 不是这个
(03:40:04 PM) Atlas Jobinson: 是，我也更关心那些
(03:40:27 PM) Atlas Jobinson: 但实际上，这个修改已经过了十天，才有反应，都快两周了
(03:40:35 PM) Atlas Jobinson: 快成既定事实了都
(03:40:44 PM) LI Daobing (李道兵): Debian 的运作不需要 wiki
(03:40:45 PM) Atlas Jobinson: 那假设我在其他地方修改呢？
(03:41:05 PM) Atlas Jobinson: 那你还那么看重维基的修改？
(03:41:08 PM) LI Daobing (李道兵): Debian 的核心在于打包人员, DM, DD, ftp-master
(03:41:13 PM) Atlas Jobinson: 我知道
(03:41:15 PM) LI Daobing (李道兵): 那是错的
(03:41:17 PM) LI Daobing (李道兵): 我知道了
(03:41:23 PM) LI Daobing (李道兵): 我去纠正他
(03:41:28 PM) LI Daobing (李道兵): 仅仅如此而已
(03:42:02 PM) Atlas Jobinson: 如果两周是个争议期，恐怕这两天我都不会让你安心的，呵呵
(03:42:42 PM) LI Daobing (李道兵): 我真不知道你能跟谁合作
(03:42:53 PM) Atlas Jobinson: 我仅仅是表达意见
(03:43:21 PM) LI Daobing (李道兵): 你为一个社区做贡献是因为你认同这个社区的理念
(03:43:29 PM) Atlas Jobinson: 而且这手段是合理的，并没有在规则外。
(03:43:56 PM) Atlas Jobinson: 但谁能说他认同的观点就是该社区的观点呢？比如说debian不需要炒作？
(03:44:03 PM) Atlas Jobinson: 这是光晕效应
(03:44:14 PM) LI Daobing (李道兵): 如果你不认同这个社区的理念，个人建议还是创建自己的社区比较好
(03:44:30 PM) Atlas Jobinson: 可能你认同其他观点，但这个观点很可能是你个人观点强加给社区的
(03:44:33 PM) LI Daobing (李道兵): 比如在 维基百科
(03:44:55 PM) LI Daobing (李道兵): 如果这个观点有问题，你可以在 maillist 上讨论啊
(03:44:59 PM) LI Daobing (李道兵): 有何不可
(03:44:59 PM) Atlas Jobinson: 因为我没在debian社区中找到这一条
(03:45:14 PM) Atlas Jobinson: 也没人公开宣称这一条
(03:45:21 PM) LI Daobing (李道兵): 如果这个观点有问题，你可以在 maillist 上讨论啊
(03:45:55 PM) Atlas Jobinson: 那么，此条很可能就是你自己过于想当然的想法。
(03:46:08 PM) Atlas Jobinson: 观点是你的，是你应该发起这个 讨论，而不是我
(03:46:21 PM) LI Daobing (李道兵): 好的
(03:46:42 PM) LI Daobing (李道兵): 我直接把这些聊天记录发到 maillist 吧
(03:46:46 PM) Atlas Jobinson: 而你不也是没经过讨论就宣称：debian不需要炒作的么？你这不也首先违规在先了？
(03:46:49 PM) LI Daobing (李道兵): 你订阅了 maillist 么？
(03:46:59 PM) Atlas Jobinson: 我刚刚订了
(03:47:02 PM) LI Daobing (李道兵): OK
----------------------------------------------------------------------------
    Jobinson自己的说明是。
----------------------------------------------------------------------------
    自从我把debian维基上的debian改为"蝶变"之后，已经有多家媒体先后报道(cnbeta 51cto lupaworld oschina ylmf uusite等)，希望如果决定不采用此名字，也不要错过这次宣传机会。从谷歌搜索，大家可以查看到相关评价。
----------------------------------------------------------------------------
    个人观点。
    首先，这件事情最核心的问题不是一个"debian中文该叫什么名字"的问题。而是"谁有权决定debian中文叫什么"的问题。debian的中文命名权应当属于为debian做出贡献的人。在实际的操作上，就是"社区事务由DD投票决定"。在未达成共识前不应贸然行动，这是一个不言自明的共识。如果每个人，或者特例点说，每个DD都有权独立决定debian的社区事务，那社区绝对会天下大乱。我们可以试想到，一个包一会叫这个名字，一会叫那个名字的情况。
    如果今天，是DD集体投票决定debian的中文名字，哪怕我觉得不好听，也会尊重这个决定。因为这是一群为debian付出心血的人，由父母决定孩子的命名是天经地义再正常不过的事情。而其他人，只能给出建议，征询社区认同。在社区未认同的时候，直接修改wiki，并且试图造成既定事实。这和在父母没有为孩子命名的时候跑到派出所给别人孩子登记命名一样，是滑稽且恶意的行径。
    其次，debian在美国有48个镜像，德国有32个，法国有28个，台湾地区有13个镜像，中国大陆地区3个镜像。我不觉得没有一个繁体中文名阻碍了debian在台湾地区的应用，显见他们那里debian的发展远胜大陆地区。因此在debian没有出现德文法文繁体中文名之前，做点实际的事情。拿改名来吸引别人的眼球，实话说，和狗仔队降到了同一等级。
    社区的发展靠的是民众的兴趣，和足够的工业基础。有民众的兴趣才会有足够多的人才，和足够多的贡献者。而有了工业基础，才有我们能够使用的一切。包括网络，服务器，乃至高级用户的工资，都来自工业。在不发展这两者的情况下，通过改名吸引眼球，也许能火一把。然后呢？我们可能会多出不少感兴趣的人，却绝少能增加一个DD，也绝少会增加用户和服务器。然后我们再改名？debian的核心在于，自由，稳定。因此debian才有dsfg的限制，和漫长的stable周期。我不希望如此的系统沦落到和海绵宝宝（简称X宝）一样的地步。

hack comix for windows use gbk as filename code

    Comix is a python application to view comic. it use pygtk as GUI library, so technically, it can be used under windows. But unfortunately, it has code problem under windows. OK, 2 fix it, open src/filechooser.py:214.

            gbkpath = paths[0].decode('utf-8').encode('gbk')

            self._window.file_handler.open_file(gbkpath)

    done.

linux社区规模估量

    debian是一种重要的linux发行，基于其上有很多衍生，其中最知名的就是ubuntu。debian的包是通过ftp mirrors来进行发布的，因此一个国家的镜像数量，大概能够反映出这个国家debian社区的规模。也大概的，能够说明这个国家开源软件社区的发展。
    debian的所有官方镜像有一个列表，具体在这里（ http://www.debian.org/mirrors/list ）。我利用wget下载了这个镜像，然后写了一个简单的脚本来处理这个文件。文件发布在这里( http://shell909090.com/debmircnt.py )。以下是结果。
United States 48
Germany 32
France 28
Taiwan 13
Australia 12
Japan 11
Great Britain 11
Canada 11
Portugal 9
Italy 9
Russia 8
Sweden 8
Spain 8
Czech Republic 8
Brazil 8
Austria 7
Bulgaria 7
Poland 7
Turkey 7
Netherlands 7
Hungary 5
Greece 5
Ukraine 5
Belgium 5
Thailand 5
Croatia 4
Finland 4
Lithuania 4
South Africa 3
Romania 3
Switzerland 3
Denmark 3
China 3
Korea 3
Slovakia 3
Latvia 2
India 2
Mexico 2
New Zealand 2
Indonesia 2
Chile 2
Slovenia 2
Iceland 2
Belarus 2
Israel 2
Argentina 2
Ireland 2
Nicaragua 1
Colombia 1
Uzbekistan 1
Kazakhstan 1
Estonia 1
Luxembourg 1
Moldova 1
New Caledonia 1
Hong Kong 1
Bosnia and Herzegovina 1
Venezuela 1
El Salvador 1
Singapore 1
Algeria 1
Norway 1
French Polynesia 1
Costa Rica 1
Malta 1
Bangladesh 1
360
    这个列表有几个有趣的数据。首先是中国的排名，不算太差，三个镜像，在第30名上下，比香港的一个镜像好多了。不过考虑到香港的人口和中国的人口，让人有点笑不起来。其次是俄罗斯的排名，以8个镜像居于11位。这也不难理解，因为俄罗斯不使用英文，所以在俄罗斯流行的不是常见的英文发行版本。德国比法国多出四个镜像居于第二位，美国是debian的发源地，以48个镜像的惊人数量居于第一。世界全部镜像是360个，光是前三位的镜像数量就占了将近三分之一。台湾地区以13个镜像居于第四，这到让人很是意外，居然比日本还多。

    为了减少特殊性，我又选择了一种社区系统，gentoo。之所以选择社区系统，是因为这些系统更少用于商业用途，相对比较反映社区力量。对于gentoo，可以在这里下到镜像列表（ http://www.gentoo.org/main/en/mirrors2.xml ），我也写了一个脚本（ http://shell909090.com/gtomircnt.py ），结果如下。
USA 47
Germany 30
Netherlands 12
Ukraine 11
Canada 11
UK 10
Russia 10
Czech Republic 10
Austria 9
Portugal 9
Japan 9
Sweden 9
China 9
Poland 8
France 7
Brazil 7
Greece 6
Romania 6
Slovakia 6
South Korea 5
Bulgaria 4
Spain 4
Taiwan 4
Kazakhstan 3
Turkey 3
Finland 3
Ireland 3
Hungary 2
Switzerland 2
Denmark 2
Bosnia and Herzegovina 2
Iceland 2
Israel 2
Thailand 2
Argentina 2
Lithuania 2
Kuwait 2
Malaysia 1
Latvia 1
Hong Kong 1
Indonesia 1
Norway 1
280
    这次就好多了，中国以9个镜像居于10位左右（具体是13，但是同样是9个镜像的国家比较多）。但是注意，这个脚本并不区分镜像类别。就是说，对于同一个镜像的ftp，http和rsync，会被计算做三个。我认为这从某个方面能够反应镜像质量，所以并没有严格区分（当然，得承认，部分原因是因为我懒的写代码了）。美国依旧排名第一，德国居于第二，第三变成了荷兰。依然，头三名占据了世界三分之一左右的镜像。乌克兰和捷克的上榜让我颇为惊讶，这些东欧国家为何偏爱gentoo呢？法国只有7个镜像，看来在法国debian衍生系列比gentoo系列要流行的多。台湾四个镜像，香港一个镜像，都是比较正常的数据。

    对比两个发行的不同排名，会发现一些比较有意思的东西。例如美帝国主义势力的强大，德国紧随其后。台湾地区和法国偏好debian系统，东欧和中国偏好gentoo。对此，我个人觉得有两种可能。gentoo和debian相比，对授权的限制更加松散，对系统的管理要求更加高一些。因此东欧和中国对gentoo的偏好，可以解释为这两个地区偏好license限制更加多的软件，或者是这两个地区的管理水准更高？
    当然，不排除还有一种可能。就是gentoo社区规模比debian小很多，从而发生了涨落效应。gentoo的280个镜像很多被重复计算了，真实镜像大概就100多。比起debian实打实的360个二级镜像，还是太少了。因此，只要在一个国家中多加一个镜像，就很容易的排到很前面。从而引发随机涨落效应。

关于日本地震，关于人性

    说人性有点大了，其实这里没有什么该不该对日本幸灾乐祸，或者幸灾乐祸者就OOXX的道德讨论。只是说说我和我周围的人在几次大事中的反应。但是说到底，也没什么好的词，只能用人的本性来形容。
    我第一次有意识的观察人们对无预知的大型公共事件的反应，是在汶川地震发生的时候。当时我在一家报社内做项目，看到周围有几个人跑了一下，也没有在意。过一会，QQ新闻跳出来，说四川发生地震，目前情况不详。我稍微提了一下这个事情，周围的人没有震感，就随便他去了。但是当晚据说就有几个记者去了四川，剩下的人也可以看到神情兴奋。是的，兴奋，而不是悲痛。说不上是高兴，但是兴奋之情是难以掩藏的。
    第二次是智利地震，这次我在上海一家公司里面做事，一楼。新闻出来后，大家都是一脸笑嘻嘻的说，地球是不是进入震动模式了。然后地震伤亡数字出来了，大家看看，哦，死的真少，比汶川少多了。然后就散了。
    第三次是日本海地震，这次还是这家公司。大家先也是笑嘻嘻的说地球进入震动模式的笑话，然后听说震源在海上，就纷纷去查海啸的问题。结论是上海一点事都没有，于是也就这样了。日本地震，中国历来是不发动官方捐款的。最多就是几个国家部门的领导象征性捐款一下。
    也许有人该愤怒了，那是人命阿，你们怎么都笑嘻嘻的？实际上，这就是我想说的东西。人对于不关系到自己和自己熟悉的人的危害，不可能在第一时间有发自内心的焦急。对于在危害中死去的人，也不可能有发自内心的悲痛。除非他本人也深受其害。这是人之常情。如果你告诉我，印尼海啸，你在那里完全不认识什么人，甚至都不知道那个地方在哪里，就第一时间的发自内心的表示焦急和悲痛。我说，要么你是世界第一的圣人，要么你是世界第一的装逼犯。当然，曾深受其害者和各国领导人例外。
    遇到突发灾害，人的第一本能反应，无一例外，都是兴奋。其实从生物进化角度不难理解。如果人类在突发的灾害面前不能保持高度的兴奋，来应对各种情况。人类早就因为适应不良而被自然淘汰了。因此在听到地震的消息时，神情兴奋的东问西问是正常反应。不是幸灾乐祸，也不是杞人忧天，而是正常的人类反应。如果灾害不会危及自己，过一会就淡了。如果灾害可能危及自己，会优先考虑自己怎么避难。当兴奋过去后，才会考虑是否应当对受害人有所表示，如何表示的问题。

个人文件管理的几个经验

    1.明白你在面对什么问题。个人资料管理，永远是可靠性和价格的双重难题。廉价方案就不可靠，可靠方案就不廉价，因此弄明白你自己需要的是廉价还是可靠。作为如果你的选择是可靠性，就要假设明天电脑就坏了。任何设备在损坏之前都是不会打招呼的，因此现在立刻就行动。

    2.由上文引出的第一个建议，区分高可用资料和非高可用资料。通常而言，我们有很多资料，林林总总一大堆。但是其中有一些是丢失了虽然心疼但还可以接受，另一些则是无法接受，往往要搞到去数据恢复中心的地步。与其如此，不如提前区分高可用资料和非高可用资料，尤其注意区分“你的资料”和“你下载的资料”。通常一个人的核心资料应当小于100G（我假定你不会比我更变态），如果你有大量录像资料要备份不在此列，以下的高可用方案也对你不适用。

    3.文件的管理方法，区分大类，放弃小类。通常我们的文件管理都有随意性，每个人都有不同的文件放置习惯。建议对文件区分以大类，而放弃细节的文件夹分类。人类在区分大的类别上往往比较恒定，也比较节约时间，在细节分类上越向下越费时。通常我们对歌曲区分男歌手女歌手团体外文等非常容易，但是要细分某个歌手就比较困难了，要精细到某张专辑绝对会花费大量时间。然而人类在寻找东西时的难度，和总体规模大致成正比。为了减少一点复杂性而花费大量时间是一个非常不值得的事情。

    区分大类的另一个理由，则是大类的区分经常关系到高可用和非高可用，高安全和非高安全。贝壳的分类中，几个类别的资料全是要求高安全性的，另几个类别则全随便。

    4.文件的管理方法，文件名标识，运用搜索。文件管理的第二个建议，就是别用分类来查找文件，使用搜索。windows下肯定是everything，linux下可以用mlocate。通过将内容反映在文件名上，对文件进行管理。在需要用的时候搜索文件名，远比你整理所有文件来的省事。至于上面区分大类的建议，则是事关下面高可用数据的解决方案，所以还是要做的。

    5.磁盘的稳定性研究。磁盘能稳定使用多久？贝壳听到最倒霉的记录是7个月，最长纪录是10年。但是通常来说，6成的硬盘会在3-5年内损坏。因此一旦硬盘使用超过3年，就处于临界状态，坏了也不要觉得奇怪的。对于临界状态的硬盘，建议采用SMART监控软件，随时保持监控异常。对于硬盘上发生过循环冗余检查错误，复制死机，文件读取错的，尤其要重视。

    5.磁盘的分区方案。很多人拿到硬盘，就先分上三四个驱，好像不分区不专业似的。其实分区是上个世纪FAT文件格式留下的传统，作为NTFS而言完全不必分区，甚至分区是有害的。FAT在不分区的情况下最高只能使用4G硬盘，VFAT方案下windows也只能使用32G的硬盘。因此对于大硬盘都必须分区使用。NTFS最高能使用4T的硬盘，我想个人是用不到这么大的硬盘的，因此完全可以将所有磁盘都分为一个区。这样主要是空间互通，减少对一个磁盘区域的反复使用。同时，在一个磁盘空间不足时不用反复移动文件凑空间。但是对于C盘（系统盘）建议分区安装。这样便于不擦除数据的情况下重装系统。当然，这种情况仅限于windows，linux要重装系统是没必要擦除数据的。不过我仍旧建议/home和/分别安装，因为两者的读写乃至管理特性都相差很大。

    6.数据量控制在60%-80%之间。太少的数据会导致利用率过低，而太多的数据则导致存储快速碎片化。windows的磁盘碎片整理程序在空间小于15%的情况下是不工作的，ext3也有类似的问题（低空间下的高碎片化）。

    7.因为上文的原因，因此区分普通数据和可抛弃数据。有一些数据，我们总是不确定将来是否会有用，现在删除又太可惜。可以将这些数据集中起来加上标记，命名为可抛弃数据。硬盘空间低于60%的时候尽管留着。一旦空间波动超过80%，就开始丢弃可抛弃数据。

    8.个人不要用RAID0。因为使用条带技术，RAID0的时候，如果一个磁盘损坏，则整个卷都没救了。即使另一个磁盘完好无损，数据也是基本拿不回来的。对于两个磁盘的情况，建议你将两个空间分为两个盘，其中一个设定为临时文件存放和非高可用文件存放位置，挪挪空间还是能凑合管理的。同时，我也不建议个人使用LVM，LVM2，活动硬盘之类的高级磁盘管理技术。主要问题是磁盘一旦损坏，剩余盘拿到其他系统上几乎如废物一般，要拯救起来非常困难。

    9.RAID1必须打开数据非同步提示。这个原因如8所说，如果你没有打开数据的非同步提示，你根本察觉不到其中一块硬盘已经失效。这个时候往往会发生第二块硬盘级联失效（因为压力集中），这样的RAID1方案就退化成了一点好处都没有。

    10.高可用资料的方案——移动硬盘。你的高可用数据是我们真正要管理的目标，哪怕其他资料都损坏，必须保证核心资料的可恢复。通常由于核心数据并不很大，因此我建议用移动硬盘作为核心资料的承载方案，数据在移动硬盘和主硬盘间定时同步。对于频繁修改的文件，建议在两个电脑上进行同步，乃至使用版本管理系统管理和同步。移动硬盘的一大好处就是随身，因此往往和主电脑分离存放。即使你主电脑出现问题，例如被偷走，移动硬盘内的数据往往也没有问题。

    11.移动硬盘引入的问题，加密。一旦使用移动硬盘方案，就意味着任何人都可以接触到你的资料。这是一个非常难办的问题，所以你可能要加密数据。我建议不要使用EFS作为数据加密方案，因为EFS的密钥保存在当前用户帐户内，备份和管理比较复杂。我建议两种加密方式，一种是AxCrypt，一种是TrueCrypt，后者比前者更强更复杂一些。前者是针对某个具体文件进行加密的，后者会直接虚拟出一个磁盘来加密，因此更加复杂。然而一旦将数据加入后者的磁盘后，就真的一点痕迹都不留了。不过需要提醒的是，由于磁盘上的数据并不能真正的被擦除，因此一旦数据进入磁盘，在虚拟文件内所占的空间就固定了。即使删除文件也无法收回空间，这给管理带来了困难。

    11.高可用的一种备用方案，使用大型硬盘（1T以上）复制然后冷盘存放。这种方案的好处就是稳定性很高，四年前的大型硬盘已经超过500G，足够存放下你所有的数据。由于不加电，因此安全存放五年以上是没问题的。但是建议也不要太长，即使不加电，随着时间推移，硬盘还是会出问题的。当然，与之相应的就是成本高，管理不方便。你多花了一个硬盘的钱（虽然我觉得和保存数据相比还算廉价），但是又不是随时能使用这些文件。

    12.高可用的误区，刻录光盘。光盘是数据最大的敌人。我们计算硬盘的存放成本，2T大概700，1T400不到，大约是0.35-0.4元/G。DVD的存放成本大约是，一桶50张的卖70，大概0.32-0.35元/G，成本非常相近。光盘存放三到五年也会出现数据丢失的情况。又不能改写，又容易丢失，光盘可以说是一种非常不合算的数据存储方式。通常建议光盘只用来迁移数据，或者干脆别用光盘。

    以上建议的核心，其实就是保持主硬盘和移动硬盘上分别驻留一份高可用数据，并且保持同步。当其中一个硬盘损坏时，尽快更换。

debian under box

    This is linux tech blog, so...猫咪和六牙四皂小姐退散。 

    下面简介一下小型系统组装NAS和服务器的完整攻略。实话说这篇文章写的异常艰难，题目本来叫debian squeeze under EPIA。结果一晃过了一个春节，debian升级了，EPIA挂了。下面前一部分的文章是开始写的，后来发现M10000系列主板只要上sata to ide就会死机，部分IDE硬盘也会死机。所以...

    首先是物理硬件的组成办法。推荐购买VIA EPIA M10000，价格大约在150上下。附带了VIA C3 Eden，只要一条内存就可以工作，非常便宜。不过USB引导有些问题，所以后面用的是其他机器装的Linux，并且给折腾了个半死。贝壳还买了一个小机箱，能够放置3.5'硬盘，并且买了1T的硬盘来组装NAS。由于1T的硬盘只有Sata接口，因此还得买一块Sata to IDE，大概是30-40。全部的硬件就是这样，组装起来就可以工作。主板的右下角是主板控制跳线，从左（以CPU和电源所在边为上）到右顺序，引脚如下定义：上排2-3，power sw。上排4-5，reset sw。上排6-7，power led。

    首先借助一台大型机，使用USB开始debian系统的安装。另外补充说明一下USB安装debian一文中的一个情况，在boot.img.gz解压开的U盘内复制入netinst也是可以工作的，不一定是businesscard。按照这个估计，复制入完整ISO也是可以的。在分区的时候，贝壳选择了full disk with LVM。/boot分配了228M，最后用了17M。root用LVM中的ext3卷，分配了7G，用了不到1G。全部装好大约有2G吧，安全起见。swap用了2.5G，其实不用这么大，不过我懒得换了。剩下908M，因为1T有一定损耗，还有JS的1000进制算法。。。好吧，全部用ext3放到/home下放数据用。

    之所以没用btrfs的原因，一方面是这个是硬盘，不是ssd，也没有高等数据管理要求。另一方面也要求一定的稳定性，btrfs还没有fsck呢。

    系统安装并没有什么太大困难，对于熟悉linux系统安装的人，很快就可以完成安装。不过由于是在其他机器上安装，因此注意在迁移后需要修改/etc/udev，把网卡修改为eth0。

    下面就是大头了，系统使用grub2引导，但是在booting kernel这里直接挂掉，完全起不来。问过gary后，基本肯定要么是主板坏了，要么是内核坏了。后来我猛然想起，C3是个老CPU了，我用的内核是686内核。改为486内核？顺利引导。

    EPIA edin C3 just support i486 Instruction Set, so don't use linux-image-.*-686。

    系统启动后，发现速度并不很快。我用samba和windows共享文件，大约只有7M/s的读写速度，消耗了60%的CPU。我使用的是TP-504G+路由器，后面是一个100M的交换机。EPIA是VT6102，10/100M自适应网卡。主机是1G的网卡——不过没任何用。理论上，最高读写速度应该有12M/s的。实际上根据我的测试，瓶颈居然可能在windows上。我在windows复制文件的时候从box上读取数据，居然对复制没有影响的情况下达到了2M的速度。这样的速度远远低于硬盘30M/s的持续读写速率，所以硬盘效率不用顾虑太多，包括碎片问题。

    当我发现sata的问题后，使用iozone确认了问题在udma层面上。杯具的是，这问题无解。所以，退了主板换了一块新的。新主板上去后，性能有所升高。硬盘的吞吐到了97M/s，网络共享的读写速度大约是10M/s。其余都很顺利，就不废话了。

版权和道德的讨论

    某个朋友在做一个文档共享网站，需要一些文档。我建议他去抓取wikipedia的数据作为初始文档，他很惊讶的问我，那个可以么？

    谢天谢地，总算碰到一个有点常识的人。我告诉他，wiki使用的是CC协议。只要他将数据抓下来后，注明数据来自wikipedia，是完全符合版权协议的。按照他们最近的情况，要是你肯赞助一笔，并且承诺按照CC协议来，说不定wikipedia还会奉送打包好的资源。相反，他做的这个网站在别处出事的概率到更高一些。他反问我，出什么事情呢？

    那就很多了。例如，某个人上传了一个带版权的内容，并且因此获利了。在事发后，带着赚的钱失踪了。那么网站是否要承担责任呢？他说有协议，我问，你们的协议可以对抗第三方么？有人偷了东西，把东西卖给废品站，人消失了。废品站拿着协议大喊，我们签过协议，他承诺这东西不是偷来的，应当被认可么？协议其实什么都不能证明，连你没有盗用版权的故意也无法证明。要证明你没有盗用版权的故意，你必须有一定的核查行为，检查你的内容版权问题。但是这是几乎没法实现的，这也是所有web2.0网站所面临的公共难题。就是说，只要你允许用户上传内容，就几乎无法避免版权问题的指责。

    还有，如果别人再复制你的内容呢。他说打官司咯。我说真打官司就脑残了。如果对方在上海还好说，如果对方在北京，根据中国法律，这种官司归侵权事故的发生地管辖。就是说，你得去北京起诉。光是你去北京数次沟通的费用就比对方的侵权赔偿还大。而且中国的国情是发生这种事情的公司绝对不是一家，起诉到判决的时间往往也不止一年。你官司没打完呢，网站就先倒闭了。如果这种事真的官司能解决，腾讯早就赔到死了。

    同样，回来上网，看到刘慈欣很生气的说，有个人在百度贴吧里面说，自己已经看完了三体III，准备手打一份贡献给大家。要光这点也就算了，刘慈欣跑上去说话还很猖狂的骂人。我看到这里就不禁很无语，虽然看盗版书这种事情我也干，但是至少我知道这是错的。要是有个好点的渠道给作者点钱，我到不介意付费。但是，一，不要买纸质书，现在家里书山书海，没地方放您的一摞纸，二来也不环保。三就是一次购买，我需要这本书的各种载体都不再付费。不能我花钱买了一次epub，回头txt或者pdf就要我再付费，这可不干。问题是，怎么有人（而且不是一个）没感觉到，免费看书是错的呢？

    说到这点，我就想起个老外，上海的DD之一的zigo。上次他在debian打包讲座上说到，Ubuntu开Ubuntu Store，他觉得这个很恶心。LiDaoBing就问他为什么，是因为收费么？他说不是，因为Ubuntu用了很多Debian的包，但是又不承诺免费。LiDaoBing就很门清的和他说，这个完全符合版权协定啊。Debian有dsfg承诺，Ubuntu可没有。zigo就说，我知道，所以我说很恶心。当然，可能因为他也是Debian的打包者，也可能是因为Debian的维护者在版权问题上都比较敏感和激进。但是我接触的大多数老外对于一个内容是合法使用还是非法使用都是比较关注的，哪怕他们买盗版光盘，也至少要关心一下这个内容是真的盗版了，还是合法资源的集合。

    说到这里，我觉得，这种问题应当是每个中国人的问题。我们往往知道理论上什么是对的，但是却完全不屑于理论，还和别人争辩理论是没用的。道理上说，我们知道不应当看别人的版权内容。道理上说，我们知道，版权经常有问题的网站应当被抵制。乃至于道理上说，我们不应当用盗版windows，我们不应当砸别人的车，我们不应该收红包，我们都知道。但是在操作的时候，我们用盗版，不但堂而皇之，而且可以找出无数理由。支持国产啦，损害外国公司利益啦。我们砸别人的车，也有无数理由，抵制日货啦，支持国货啦。我们在做的时候，用的是我们自己的一套规则，或者说潜规则。所谓理论上的东西，只是拿来找说法的。自然，说法这东西是随便找的，再多也不怕。

    有人选择对这种现象抱怨，但是抱怨不解决任何问题。深谙此道者会从中获利，并且以胜利者的姿态对其他人说教，你们不了解社会。民众会抱怨，但是不是因为整个世界没有公平，正义，乃至美好的道德，而是因为他们在整个体系中没有分得一杯羹。

    我们每个人的小聪明，毁坏了我们的整个利益体系。我们没有IT业，因为我们每个人都对电信的不合理行为视若无睹。当电信提供低质量的服务时，当电信无法接入时并且要求你等待24小时时，乃至当电信劫持我们的流量插入广告时，我们说，忍一时风平浪静。当有人站出来，为了他自己，也为了我们所有人而奋战时，我们在后面说两句好话，期待他的成功能让我们一同享福。当对方做出一定让步，承诺给我们一定好处时，我们就对为我们奋战的人置之不理，乃至落井下石。

    我们没有软件业，因为盗版不但没有损害国际巨头的利益贴补国人，反而损害了国人的利益贴补国际巨头。金山，一个中国软件业的传奇，上市靠的是网游，而不是单机软件。国内无数的程序员做着外包，也许这还可以解释为人民币对美金汇率的差价。但是无数程序，是由中国程序员写出，却没有中文版。我们宁可花长途话费对老外点头哈腰，也不愿意给同胞改几行代码，因为人家付钱，我们破解。老外的软件仓库中，充斥着免费且强劲的软件，和收费且良好的服务。我们的软件仓库中，充斥着免费的流氓软件和收费的冷屁股。

    也许我们无法从购买正版软件做起，或者承诺不上网看盗版书。但是至少，我们应当开始关心我们所说的那些东西，包括版权，包括什么是正确的事情，人和人之间如何制衡来得到正确的事情。也许这是徒劳的，也许一个人的改变无法改变什么，但是当每个人都前行一步时，世界将会不一样。

招人，招人！

    最近帮一个朋友吼招人，发现上海要python程序员的公司真不少。保守估计，有五家以上需要各种python程序员。

    我们公司需要一个比较精通系统的python程序员，最好有C/C++能力。有一家朋友的公司是需要python进行测试开发的，说白了就是测试程序员。另两家求靠谱的python web主力程序员，需要熟悉系统，数据库建立和优化，完整的python程序架构和实现。这两家比较打架。最后一家需要python web工程师，能干活的那种。

    每个公司的要求和薪资都不大相同，排除掉爬虫，几乎涵盖了整个python领域的方方面面。当然待遇薪水也涵盖了从低到高的整个领域。今年有意思的同学不妨试试运气，说不定能找到你要的工作。

    另外就是每个大三快大四，即将毕业的同学。如果你今年开始学python，搞不好明年毕业就可以直接签掉。如果你能搞定整个网站，有数据库优化经验，并且真实的运营过一个网站。搞不好毕业薪水就上五位数。有没有兴趣混一下python社区，靠谱的学上一年？

    当然，这里说的，对程序员基本功都有一点要求。昨天还在餐厅洗盘子的，今天跑来学三个月python和django，明天跑过去求职。这一准失败没商量的。你起码应当知道常用系统调用，尤其是os.open和open的区别。应当知道django中如何实现多对多外键，并且将这个外键转化为一个带复选框的表格，再表单提交读出来。知道为什么IE打开网页一切正常，firefox和chrome却每次都让你保存网页而不是显示出来。知道网页在几个浏览器下乱码，而另外几个正常是为什么。知道django给你弹出一个错误，里面说了些什么。知道mysql慢的要死是为什么，还有怎么做。知道数据存入mysql再读出来就全是乱码是为什么。

    以上种种，是开发中最常见的一些问题，也是每个开发都会碰到的问题。他们涉及了系统底层调用和封装调用的常识，ORM和表单的常识，http协议的常识，html标准的常识。涵盖调试，优化，运维等方面。

    通常来说，比较全才的，经验丰富的主力程序员，我会推荐他们去一些小公司。所谓宁为鸡头不为凤尾，当你在大公司里面做到顶棚的时候，可以试试看在小公司里面主政一方。如果老板赏识，也许还有机会参与期权。这对已经不算缺钱的程序员来说比较有吸引力。而小公司通常没成本来雇用一些比较初级的程序员，又在主力程序员的人选上求助无门，因此往往对主程序员求才若渴。

    而刚毕业的同学就不要去凑热闹了。小公司没那么多钱，每个人都要独挡一面。刚毕业的人通常没这个能力，更可怕的是通常不知道自己没这个能力。因此建议，除非是大学期间就参与过商业网站运作的，否则别去凑。中型公司是一个更好的选择。公司里有几个高手，你方便找人。工作方向相对窄，容易入手。而且工作稳定，没有随时随地的压力，利于学习发展。至于大型公司，通常不是大牛的人进去，接触的东西太有限，太定向，发展前景有限。而且大牛都集中起来了，你也很难抓到人。

    至于牛人，我就不吼了。牛人都不是在人才市场上求职的。