Shell's Home

twip在LiteSpeed上碰到403问题的解法

Apr 2, 2011 - 1 minute read - Comments

这是一个老bug了,具体问题看这里(http://code.google.com/p/twip/issues/detail?id=80 )。 当你使用o模式,到twitter上同意后跳回来,就会撞上403。 不管他,当时你的url应当是http://xxx.com/path/getapi.php?api=http://xxx.com/path/o/username/token。xxx.com是你的域名,path是路径,username是用户名,token是一个随机的数字。 用http://xxx.com/path/o/username/token,直接上去。

作家们和百度的战争

Apr 1, 2011 - 1 minute read - Comments

作家们和百度打起来了,真是让我情何以堪呐。 照理说,作为一个码工,怎么也算是码字工的同行,应当对作家们表示一下支持。但是我又是个开源免费的爱好者。为防止有人搞不大明白啥叫开源免费,我简单解释一下。简单来说,就是拿着自己的东西在那里叫卖,来吧都来看吧,白给不要钱,还送设计图。作为正常中国人,也许很难理解这种脑残行为。不过事实上,这一切真的发生了,而且在全球范围内轰轰烈烈。 不过这让我的立场就尴尬了。唔,怎么说呢?我们还是把这件事情拆开说吧。 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源码解析读书笔记(四)——杂项

Mar 31, 2011 - 1 minute read - Comments

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源码解析读书笔记(三)——对象和函数

Mar 30, 2011 - 1 minute read - Comments

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):

python源码解析读书笔记(二)——函数特性

Mar 29, 2011 - 2 minute read - Comments

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 = \[\]): ...

python源码解析读书笔记(一)——内置对象

Mar 27, 2011 - 1 minute read - Comments

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 =

豆瓣九点的认领功能

Mar 25, 2011 - 1 minute read - Comments

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

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

Mar 25, 2011 - 1 minute read - Comments

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

关于IT雇员的一点话

Mar 24, 2011 - 1 minute read - Comments

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

approx无法升级问题的解决

Mar 23, 2011 - 1 minute read - Comments

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