Shell's Home

debian社区争论摘抄

Mar 18, 2011 - 1 minute read - Comments

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

debian中文名的争议

Mar 15, 2011 - 2 minute read - Comments

最近在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

hack comix for windows use gbk as filename code

Mar 14, 2011 - 1 minute read - Comments

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社区规模估量

Mar 13, 2011 - 2 minute read - Comments

debian是一种重要的linux发行,基于其上有很多衍生,其中最知名的就是ubuntu。debian的包是通过ftp mirrors来进行发布的,因此一个国家的镜像数量,大概能够反映出这个国家debian社区的规模。也大概的,能够说明这个国家开源软件社区的发展。 debian的所有官方镜像有一个列表,具体在这里(http://www.debian.org/mirrors/list)。我利用wget下载了这个镜像,然后写了一个简单的脚本来处理这个文件。文件发布在这里(http://shell909090.org/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个镜像居于第四,这到让人很是意外,居然比日本还多。

关于日本地震,关于人性

Mar 12, 2011 - 1 minute read - Comments

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

个人文件管理的几个经验

Mar 10, 2011 - 1 minute read - Comments

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

Mar 7, 2011 - 1 minute read - Comments

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。其余都很顺利,就不废话了。

版权和道德的讨论

Mar 4, 2011 - 1 minute read - Comments

某个朋友在做一个文档共享网站,需要一些文档。我建议他去抓取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小时时,乃至当电信劫持我们的流量插入广告时,我们说,忍一时风平浪静。当有人站出来,为了他自己,也为了我们所有人而奋战时,我们在后面说两句好话,期待他的成功能让我们一同享福。当对方做出一定让步,承诺给我们一定好处时,我们就对为我们奋战的人置之不理,乃至落井下石。 我们没有软件业,因为盗版不但没有损害国际巨头的利益贴补国人,反而损害了国人的利益贴补国际巨头。金山,一个中国软件业的传奇,上市靠的是网游,而不是单机软件。国内无数的程序员做着外包,也许这还可以解释为人民币对美金汇率的差价。但是无数程序,是由中国程序员写出,却没有中文版。我们宁可花长途话费对老外点头哈腰,也不愿意给同胞改几行代码,因为人家付钱,我们破解。老外的软件仓库中,充斥着免费且强劲的软件,和收费且良好的服务。我们的软件仓库中,充斥着免费的流氓软件和收费的冷屁股。 也许我们无法从购买正版软件做起,或者承诺不上网看盗版书。但是至少,我们应当开始关心我们所说的那些东西,包括版权,包括什么是正确的事情,人和人之间如何制衡来得到正确的事情。也许这是徒劳的,也许一个人的改变无法改变什么,但是当每个人都前行一步时,世界将会不一样。

招人,招人!

Mar 3, 2011 - 1 minute read - Comments

最近帮一个朋友吼招人,发现上海要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标准的常识。涵盖调试,优化,运维等方面。 通常来说,比较全才的,经验丰富的主力程序员,我会推荐他们去一些小公司。所谓宁为鸡头不为凤尾,当你在大公司里面做到顶棚的时候,可以试试看在小公司里面主政一方。如果老板赏识,也许还有机会参与期权。这对已经不算缺钱的程序员来说比较有吸引力。而小公司通常没成本来雇用一些比较初级的程序员,又在主力程序员的人选上求助无门,因此往往对主程序员求才若渴。 而刚毕业的同学就不要去凑热闹了。小公司没那么多钱,每个人都要独挡一面。刚毕业的人通常没这个能力,更可怕的是通常不知道自己没这个能力。因此建议,除非是大学期间就参与过商业网站运作的,否则别去凑。中型公司是一个更好的选择。公司里有几个高手,你方便找人。工作方向相对窄,容易入手。而且工作稳定,没有随时随地的压力,利于学习发展。至于大型公司,通常不是大牛的人进去,接触的东西太有限,太定向,发展前景有限。而且大牛都集中起来了,你也很难抓到人。 至于牛人,我就不吼了。牛人都不是在人才市场上求职的。

如何建立自己的debian repository

Feb 28, 2011 - 1 minute read - Comments

首先,感谢zigo的大力支持,并且贡献出他的源码,我才得以完成本文。其次,技术文,该散的可以退散了。 很多时候,我们对某些东西比较有兴趣,所以会安装一下。debian系统下最熟悉的安装系统就是dpkg了。作为debian用户,我想用deb包来安装这些东西。这样会有以下的好处: 1.便于在多个系统上重复安装。如果是源码包编译,就必须每台系统安装好环境来configure/make install了。 2.便于拆除。如果是make install,能不能拆就看你的运气了。 3.系统可以管理依赖。包括自动安装缺失的依赖包,以及保持依赖包的固定等。 关于打包,请看debian新维护人员手册( http://www.debian.org/doc/maint-guide/index.zh-cn.html)。本文主要是说一下如何将这些包变成一个自己的仓库。 变成仓库,你将拥有以下好处。 1.不必自己去复制包,然后手工安装。 2.当仓库更新后,目标机器在update后可以发现。 3.你可以向仓库中加入自己定制编译的,更加新版本的软件。替换掉系统的同名软件,而不改变操作特性(除了没加key会碰到不安全提示)。 其实debian的主系统是一个超级大仓库,通过ftp和rsync同步提供服务。我们的包如果够重要,也会享受到这种待遇。然而debian官方仓库的要求比较严格,你必须在文件级别搞清楚每个文件的授权,并且核对这些授权是否符合dsfg协定。你的包必须足够重要,有可能的潜在用户。多数时候,我们自己写的产品/库还没有这种待遇,因此只有自己做一个仓库了。 zigo提供了他的打包代码,比我的功能全多了,大家可以参考这里(http://git.gplhost.com/gitweb/?p=mgmt-scripts.git;a=blob;f=scripts/scan_archive;h=db7647732b989b35ae7d8a48c80a48ecf67e4612;hb=0ff8fd7d0ba1991d552376f8beca0b46bfaa32e3)。我根据这个脚本,自己实现了一个,放在这里(http://shell909090.3322.org/debian/scan_deb.py)。下面,我简述一下用法和原理。 首先,你需要建立一个pool目录。在其中建立一些release目录。举例来说,wheezy是一种release,testing也是。但是目前testing是wheezy的别名,你用ln -s做链接指向就可以了。在release目录下,你需要建立category目录。例如main是一种category,contrib和non-free也是。 在指定一个deb仓库的时候,release和category是必须指定的,可以被看作是一个仓库地址的一部分。 建立完三级目录后,将你的包放在对应目录下。 全部文件放好后,在根目录下执行python scan_deb.py。如果你需要自动签名,将最后一行的False改为True。在此前请准备好私钥。如果缺少某种架构,请修改脚本architectures一行。 系统的基本原理是,在某个release, category, architecture下,对于pool/release/category目录执行dpkg-scanpackages操作,生成Packages文件到dists目录下,并且再生成一个压缩版本。 对所有目录执行过操作后,使用apt-ftparchive来生成一个Release文件,这个文件指名了有哪些Packages文件,以及他们的MD5各是多少。 客户端获得了Release,就可以知道某种release的特定几个category是否需要更新。更新到了Package,就知道有什么包,他们的meta信息是多少。最后对Release文件进行签名,就可以防止作假了。