社区的基础规则和原因

    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标准的常识。涵盖调试，优化，运维等方面。

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

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

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