Shell's Home

回京感想

Feb 8, 2009 - 1 minute read - Comments

昨天临时接到通知,贝壳周五(二月六日)要去北京出差。具体情况不多说了,不过——贝壳要回老家了。可一年半没回去了阿—— 早上5点半从杭州的宿舍出来,赶7点半的飞机。打车走了快一个小时,杭州的机场确实也够远的。师傅紧赶慢赶总算给我提前40分钟赶到了机场,离停止办理手续只有10分钟。这点住北京就很有优势,出门10分钟就到机场。6点半起床,赶8点的飞机绰绰有余。飞机很顺利,事情很顺利,贝壳就不多废话了。唯一的插曲就是贝壳的linux不支持投影仪,搞了半天总算在老板的机器上成功演示。 别的不多说了,就说说北京的风景吧。多了一堆莫名其妙的建筑,其中多数是政府机关的办公楼。贝壳原来认得的地方全都不认得了,鼓楼,宣武门,东直门,也就长安街还保持了一点原来的风景——当然,不算那个巨蛋的话。东直门改的面目全非,斜街那里完全看不到了,建了一个什么汽车中心。西单图书大厦已经快7年没去了,门口那堆书的摆设还在,但是被围起来不能坐了。西单文化广场被修的光怪陆离,完全看不出原来的样子。灵镜胡同没去,不过想必也不复旧观。 贝壳干完事情,被放到了丽都。本来准备和几个高中同学聚聚,可无奈前天才刚刚接到通知。刘江陵同学和佟国美同学非常义气的回了消息,不过很遗憾的,都没赶上机会。李鸿国比较忙,就不说了。老猫直到贝壳快闪了才有反应,够迟钝的。贝壳最后无奈的决定,不去顺义了,直接去机场,第二天可是8点的飞机。丽都旁边贝壳只认得915,那是去顺义的。所以贝壳弄了部车去机场,走的是附路。 机场附路,算算可是有年头没走了。自从在牛栏山上学以后,京顺路通了,附路修路。贝壳就主要坐915去北京,很少走附路了。现在的附路路面都翻修过,比原来顺了很多。运河上的桥还是那个老样子,不过有一段因为要修轻轨,因此被重修了。到了机场,贝壳碰到了一件非常囧的事情,贝壳被锁在家门外了。算算都26的人了,居然还会碰到这种问题。家门口等家长回家,又不是小学生。不过无奈的,贝壳就碰到了这种事情。老妈去上海探亲,老爹上班。大老远的从上海来北京出一次差,居然被锁在了自己家门口。无奈,贝壳出门转一圈吧。 从家里出来,贝壳绕着机场走了一圈。发现机场多了很多小店,建筑也被翻修过了。想必是为了迎奥吧,机场这里是最敏感的地方。唯一没变的就是机场高速的收费站和贝壳的破窝。呆在小时候常爬的假山旁边,不出意外的发现当初奋斗(真的是奋斗,贝壳小时候很胖)很久才能爬上去的山顶差不多就是一伸手的距离。公园的松树还在,前面的大广场却没人跳舞了。工人文化俱乐部(原来唯一的作用就是放电影,我们过去常常在这里看)被改成了XX货真价实的俱乐部,上了金色的招牌,不过恐怕就和工人无关了。最大的变化是贝壳的小学,机场二小,永远的消失了,变成了94中机场分校。估计是机场这里去94中的太多了,干脆弄个分校过来,省得费力。家后面的一排树全推了,改成了通向三号航站楼的大道。 坐在家门口的公园旁边,贝壳感觉五味沉杂。这么多年在外面,始终觉得自己是个过客。没想到到了自己家,才发现家已经不再是从前的样子,自己还是过客。上次出差,呆了两个月。这次出差,呆24小时。贝壳始终来来去去,来了又走走了又来,到底哪里才能停下呢?

MSN Space可以通过邮件创建

Jan 30, 2009 - 1 minute read - Comments

听说MSN Space Blog可以通过邮件创建,今天测试一下。 如果大家正确的看到了这段内容和前面的缩进,可以试试通过邮件编写blog。对于经常出差离线写东西的人很有效哦。

牛年快乐

Jan 26, 2009 - 1 minute read - Comments

过年了过年了 祝大家牛年快乐,万事如意 贝壳敬上

24点计算原理和程序

Jan 20, 2009 - 1 minute read - Comments

最近开心上狂算24点,于是贝壳搞了一个24点计算程序,并且说明原理。 我们将24点问题一般化,变成一个搜索问题。假定从一个初始表开始,里面有一些原子。我们定义一个操作,结合。每次操作任意从中选择出两个(或者以上)原子,使用算符连接,成为一个新的原子。那么,一般来说,24点就是计算所有可能的路径,从初始表开始,持续进行结合,直到只剩下一个原子,并且对这个原子求值得24。 有人可能在算符优先级上想不开,其实不用考虑这个问题,每次求值的时候,按照求值顺序优先就可以。你想到的另外一种优先级可能,会在穷举的时候被列举出来算掉,不用担心遗漏。 同时,算子必须是两目以上算子,因为单目算子可以持续作用于同一个对象,因此原子表中的原子个数并不严格单调减少,造成无法肯定路径收敛于有限步骤上。并且,如果允许单目算子,那么我只需要求导和阶乘就可以对任何数字求24点。 ((a')!+(b')!+(c')!+(d')!)!=24 因此,单目算符是没有意义的。 另外,注意算符分可交换和非可交换的。例如:a+b=b+a,但是a-b!=b-a。如果不注意这点,倒是不会漏算,但是会造成搜索空间增大,并且有重复结果。 以下是24点计算程序,python版本的。有兴趣的朋友可以用scheme重写,相信会更简洁有效。回头会用django封装一下,做成网页给大家玩玩。 #!/usr/bin/python import sys symbol_list = [ ("%s+%s", True), ("%s-%s", False), ("%s*%s", True), ("%s/%s", False), ("%s**%s", False), ] def diff_seq(length): for i in range(0, length): for j in range(i + 1, length): yield (i, j) def get_less_state(input_state): for i, j in diff_seq(len(input_state)): temp = input_state[:] del temp[j] del temp[i] for s in symbol_list: rslt = s[0] % (input_state[i], input_state[j]) rslt = "(%s)" %

论同时的双系统--准虚拟对双系统的进一步扩充

Jan 12, 2009 - 1 minute read - Comments

熟悉贝壳的人都知道,贝壳是个linux爱用者,不过因为工作关系,经常要使用windows。贝壳在自己的笔记本上使用了linux/windows混合双系统,并通过共用磁盘的方式共享数据,解决这个问题。但是长期的使用表明,这种解决方案存在几个巨大的瑕疵。首先是系统切换时间常,因此长期在一个系统中工作,而很少触及另外一个系统。其次是稳定性差,windows下一旦崩溃,进入linux后就需要检测数据盘,80G的数据慢慢扫描,感觉晕到死。那么是否有一种方案,能够同时使用两个工作级系统(注意,不是实验级,贝壳成功的在windows下的vmware里跑了一个oracle,这个可以说是实验级的典范。然而工作级系统的要求和实验级完全不同)。 从系统发展史的角度来说,我们可以预见,将来的系统将是脱离硬件的。首要的原因就是和硬件不相匹配的各个层级的计算能力需求。现在系统发展有两个极端,一个是虚拟机,试图将一个硬件整体分离,运行多个系统。另一个是高性能集群,试图将多个硬件合并,运行一个系统。从根本上说,这是因为高性价比的硬件集中在了一个性能区间,而实际的性能需求却是完全分离的,因此我们才会出现如此两类完全背离的需求。而现在有大量宝贵的人力浪费在了系统和硬件结合,系统稳定性问题上,这无疑是对将来发展的一个巨大瓶颈。虽然无法预知将来的技术发展会以何种方式解决这个问题,然而可以预见的是,解决硬件和性能的背离将是人类计算机发展史上一个重要的里程碑,解决这个问题的人必定会在计算机历史上留下重重的一笔。 同时,更进一步,贝壳揣测,将来的解决方案将是系统硬件调度/驱动和系统软件管理分离。一个软系统拥有一个用户表和一个硬件表,硬件表上写他可能有10个键盘,两个显示器,或者一堆其他设备。系统借助某个可信方案,管理了一系列虚拟抽象设备和真实设备形成的映射。作为系统层以上的软件,我们只要关心如何操作这个虚拟设备即可。而实际上,我们可以通过管理参数和对应关系实现各种需要。例如我们可以将多个机器的硬件管理核心加入一个系统,形成集群。或者我们可以在一个机器的硬件管理核心上加入多个系统,形成虚拟机。这个基本是分布系统的观点。如此一来,系统层软件就无法得知也无需得知自己是在到底运行在什么环境下。只是这个系统设计方案对高性能要求的子系统(主要是显卡)相当不利。 从揣测回到现实,为了实现一个工作级系统(幸好,还不是工业级),我们需要为系统制定一些评判标准,以判别各个方案的优劣。我们首先能想到的评判标准就是速度,一个慢吞吞的系统解决方案是没有任何实用价值的。当然,这个速度是有差异的,可能是linux快一些,windows慢一些,或者相反。我们假定实际的需要是windows快一些,因为linux可以通过定制进行加速。 我们的第二个评判标准就是稳定性,经常会崩溃的系统不比慢吞吞的系统好到哪里去,甚至会更加让人讨厌。虽然工作级系统并没有工业级那样高的要求,然而高负荷稳定,宕机平均频率低于3天/次还是要保证的。而后我们还希望两个系统可以做到数据互通,即两个系统间的数据尽可能的共享,至少要做到文件和邮件的共享。最后,我们希望解决方案简单易用,便于实施和维护。 而后,我们列出了一个原始方案,和以下几个改进解决方案,并给出优劣评价,谨供大家参考借鉴。同时我们在其中还补充了一些无法实际解决问题的虚拟化解决方案,并且说明无法使用的原因,供适合的人自行选用。 原始方案,windows+linux+数据分区。此种方案是最中规中矩的,性能最高的方案。具有对硬件最好的支持,最容易的维护。如果需要运行游戏(尤其是魔兽,WOW),这也是唯一可行的工作级方案。稳定性评价属于尚可,主要由于ntfs在linux的稳定性并不好,ext3在windows需要使用非官方驱动,和某些(就是avast)驱动不兼容。数据互通比较方便,通过数据分区可以轻松的共享文件和邮件。 windows虚拟方案,vmware+虚拟分区。这种方案是改进方案中唯一可以跑游戏的,因为虚拟机随时可以关上。性能上满足windows快 linux慢的要求,虚拟系统显示性能良好,也可以通过文件共享部分的解决数据共享问题(文件共享方便,邮件共享困难)。稳定性很好,基本没有什么不稳定的问题出现,操作和维护都不困难。然而之所以一开始这种方案就被排除在外,主要是因为这种方案无法让linux驱动实体硬件,无法通过机器启动。这样也许对一些跑起来玩玩的人或者是内核工程师/测试员比较有用,然而如果要在linux里面进行大量工作,编译程序,运行服务,这种方案就力有未逮。因此这个方案可以说是一个实验级方案,而非工作级。 windows虚拟方案,vmware+实体硬盘。速度一般,windows快linux慢,基本和上面一个方案一样,唯一的区别就是linux也可以被实际驱动。然而这也成了整个方案的最大败笔,因为linux的驱动灵活性不如windows,因此无法经受这种系统切换的动作。举例来说,真实的机器上,硬盘是sata的,作为sda识别和使用。而虚拟机上则是IDE的,被识别成了hda。于是启动环境一变,就需要修改大量配置来调和这个问题。又例如,在真实机器上,X使用fglrx驱动,而虚拟机下面要用mesa。如果我在/etc/xorg.conf中不指定驱动,那么真实机器的驱动也会变成 mesa,导致性能下降。如果指定驱动,又会导致虚拟机内X无法运行。诸如此类的问题林林总总,需要大量细节修正,因此维护复杂,稳定性差,不建议正式使用。在贝壳机器上更严重的,出现了虚拟机内和虚拟机外争抢数据分区的状况,这种情况下数据分区实质是被当做盘阵用了。使用非专用的磁盘作为底层共享存储,并在上面运行ext3系统,这是及其危险和愚蠢的。 linux虚拟方案,xen。速度超快,但是上来就在贝壳的机器上暴出几个问题,因而没有继续测试。首先是安装xen后x无法启动,出现fglrx驱动无法加载的状况。其次是xen要求使用虚拟盘启动,可贝壳经常需要跑到windows下面打游戏。因此在简单测试后被剔除出局。感觉这种方案的最大问题在于配置管理太过复杂,debian下面已经很轻松了,只需要安装对应内核,使用工具建立虚拟机,但是依旧感觉麻烦到一塌糊涂。相信这种方案在专业级服务器领域应当有不俗表现。 linux虚拟方案,openvz。这种方案压根就不适合贝壳的状况,因为这个虚拟方案要求宿主和客户必须是同一CPU同一系统(不要求同一linux发行)。主要用于希望将一个主机切分成多个独立的同构主机,以达到分离管理的目的(例如业务服务器和数据库服务器分离)。需要做大型网络管理/虚拟主机业务的人可能会对这个虚拟方案感兴趣。 linux虚拟方案,vmware。速度一般,linux快windows慢,视频效果不错。vmware毕竟是商业公司,视频驱动挺齐全的。但是内核驱动的编译麻烦到死,首先是要求编译器版本和主内核编译器版本一致,于是贝壳去搞了个gcc-4.1,然后连接了上去。下面又是内核头定义出现版本差异,搞到现在还没有搞定。谁能搞的定的给个参考,最好是debian上的解决方案。 linux虚拟方案,kvm。这个是贝壳目前使用的方案,基本比较理想。速度很快,和xen基本差不多,显示速度不如vmware(理论上说装好显卡驱动应该会好点,不过贝壳找不到CLDC5446的XP驱动,那是Win32和Win95时代的显卡)。linux快windows慢,但是还在可忍受范围内。稳定性很好,只要测试通过,运行中到目前为止没有死机(当然很多参数是加了之后开机即死机)。数据可以通过samba互通,邮件也同样可以互通。然而使用samba无疑复杂很多,而且性能并不太好。只是从稳定性上说,让linux自己去驱动ext3总比半吊子的windows驱动更好,同时也不会出现争抢的问题。易用性上还算可以,无论是内核编译还是系统使用都不太难,最大的麻烦就是网络配置。根据贝壳的测试,在真实机器上superpi运行100W 位需要45秒,虚拟机内需要54-60秒,尤其在换用kvm-72.2后反而更慢了(54下降到60,折合真实机器83.3%下降到75%)。 总体来说,贝壳更倾向于使用全开源的准-全虚拟解决方案kvm,主要因为他简便易行,对系统影响小,不改变现有系统。同时性能高,稳定性好。主要需要解决显卡效率问题。如果以上问题无法彻底解决,贝壳打算换用linux下的vmware,想办法搞定他的内核模块。

新年快乐

Jan 1, 2009 - 1 minute read - Comments

废话不多说了,新年快乐。 TMD想找个人说新年快乐也找不到,全出去Happy了,真该考虑找个女朋友了。 另外,专门在Linux里开个虚拟的Windows来写这个东西——鄙视一下微软的产品对Firefox 4 Linux的支持。另外,真TMD的复杂,真浪费。

emacs简介

Dec 17, 2008 - 1 minute read - Comments

emacs一定是我梦想中的编辑器,设计者一定是个超级的混蛋。 emacs是一种多平台的编辑器,具有非常古老的历史,和vi一起并称为黑客常用两大编辑器(在贝壳学习linux后,就“顺带”学习了vi——因为根本没有其他选择)。作为编辑器来说,他只接受文本编辑,但是却具有收发邮件,编译软件,调试程序,甚至煮咖啡等各种诡异的非正经功能。很多人疯狂的热爱他,认为他是人工智能的结晶,化妆成编辑器的操作系统。但也有人疯狂的咒骂他,认为这东西纯粹就是折磨人用的。贝壳这次的blog,就是侃侃emacs到底是什么。 说emacs是人工智能平台,其实这个说法并没有错。emacs的运作机理和我们通常的编辑器都有不同。通常来说,一个编辑器可能有多个windows啦,frame啦什么的,但是最终作用于一个文本。你可以添加,删除,修改,或者标记一段文本,进行剪切,复制,粘贴等动作。设计比较完善的还有回退和重做。让我们专注于其中一个任务,例如,删除,看看我们的编辑器是如何工作的。 以notepad++为例吧,在选中一段文字删除的时候,你可以用键,同样,如果没有选中文字,这个键作用于当前光标后面的一个文字。(在此我们不讨论和前后删除的关系)这很简单,一个内容,按删除,就没了。但是你是否注意了这个过程本身,为什么按下是删除,为什么不是按下键或者键? 按照程序员的思维来说,编辑器的基础是一个文本内容和一个光标(或者说一个position),我们通过修改数据结构变更这两者以达到某种目的,这个过程被称为操作。例如,作为删除操作,我们移除(remove)了文本内容的position处的字符。而后,我们将这个操作(也可以称为函数)绑定到键上。于是,我们在按下键的时候,触发了删除函数,导致内容被删除。这个是能够删除文本的核心过程。从正常人思维的角度来说,一般我们都会将这个功能绑定到上面,而不会是或者,或者其他更疯狂的键。同样的机理,我们按下,文件存盘,是因为存盘的功能被绑定到了这个键上。好的编辑器一般带有键绑定修改功能,notepad++就可以自行修改热键。而emacs则更进一步。 emacs允许你自行编写扩充函数,并且将这些新的函数绑定到键上,这样就赋予了编辑器无限的可能性。例如,你可以写一个过程,每次触发就在当前光标处插入当前时间对应的纽约时间。或者你可以写一个过程,自动根据一个预定义的数据表格补充你输入人名的头衔。可以想象,当你需要重复单一工作时,这种扩充能力是非常重要的。你可以免除记忆一堆领导的详细头衔,免除重复输入,免除繁重的劳动,只要你编写一次扩展程序,并且绑定到某个键上。然而现在编辑器的趋势是,我们使用编辑器从事各种不同的工作。有的时候,我们用编辑器记事,有的时候用来写程序,有的时候用来看源码。因此我们对编辑器的个性化能力和强大都没有要求,反之对编辑器的标准化要求很高。说的更通俗点,我们不需要自行扩充一个插件来省事,但是我们一定要用来复制,用来粘帖。因为我们(指普通用户,而非以电脑为生的专业用户或者是变态的geek)不会程序,或者不喜欢为了某个目地花费时间来编写程序,毕竟现在不是70年代,当时接触电脑的都是智力最高的一帮变态。现在接触电脑的都只是普通用户而已,我们不需要强大的扩充,但是我希望我用一个编辑器的时候,这些基本功能在另外一个编辑器上不会产生区别。从这点来说,emacs差劲透了。 emacs的键绑定是根据上世纪70年代unix下(那时候linus都没出生,何况linux)的键盘来的,因此emacs假定你有一个Meta键。这个键在今天的电脑上已经找不到了,我们用Atl来替代。但是同志们,Atl是系统键,这么替代是有副作用的。例如自动补齐的函数热键是M-Tab,但是请试试在windows下按Atl+Tab。亲爱的,你会跳到另外一个程序上。那是windows切换程序的热键。还有我们经常用来复制,来退回。可是在当时的linux下,代表终止程序运行,代表挂起程序到后台。emacs当然要避免这两个热键,于是——你自己试试在emacs下按这两个热键的结果吧。 从热键约定的角度说,emacs是当之无愧的最差编辑器。不过这个很难怪罪emacs,毕竟他出生的年代不用说windows,连dos都没有出生,cp/m还只是个样品。要怪只能怪windows的设计人员在考虑热键的时候根本没有考虑emacs的现有标准,自己瞎设计一通(尤其是最常用的,虽然从人机工程角度这个是最合适的键)。 emacs更强大的特性是,可以根据当前文件的特征鉴定文件类型,并且采用正确的模式。例如,我可以在python模式下编写python程序,在C++模式下编写C++程序。对于用户来说,这两种模式看不出区别,然而他们本身有着非常多的细节不同。例如,在C++模式下,/**/是注释,而python下,#才是注释。灵活的模式允许你使用同样的方法操作不同类型的文件,并且还具有各种扩充。对于C++,他可以编译,对于python,他可以校验。并且有一些比较常用的超级扩充,例如etags。这个程序可以用来生成一些文件,帮助你找到一个符号的位置。利用这个扩充,你可以快速的寻找符号位置,自动完成,等等。这些近几年才在VSIDE和eclipse里面出现的特性,早在数十年前就出现在了emacs里面。 如果你有程序基础,并且长期从事相似的工作,例如写程序,写文档,并且有很多重复的工作,希望解放自己的劳动力,那么推荐你使用emacs。如果你是个找酷的新新人类,希望找一个很少人用的编辑器,具有真正酷的特性,被很多人称赞,那么建议你用emacs。除此外的人,请珍爱生命,远离emacs——这东西太容易上瘾了。~~~~~~~~~~~~

U盘启动

Dec 15, 2008 - 1 minute read - Comments

hihi 大家看过血色星期一没有?那里面有个家伙用随身的U盘当系统带来带去,很酷哎。 贝壳也有个U盘系统盘,做过使用/分区隐藏/Linux启动/密码访问控制,但是基本用不上,首先一个原因就是――太慢。 KST的2GU盘读写速度是5/1.5,貌似用来启动个30多M的系统也够了,可是加上各种检测,时间就远远比硬盘长,而且长很多。所以贝壳正在寻思,什么时候弄个高速(起码要10M)U盘来当系统。分个2G给linux,足够他跑X了,连带编译器什么都可以加上去。 不过在这之前,首先要搞定系统启动问题。混蛋的grub在U盘启动的时候不稳定,一会把U盘当hd0,一会把硬盘当hd0。可以想象,系统启动的时候每次都要手工确认,这种东西鬼才高兴用。而且U盘系统有的时候开关机不稳定,半路死机ext3就损坏,又要拿debian来扫。ext3损坏本来没什么,可是hd识别又出现变化――变的像死机一样。TMD这种鬼环境,加上600M的空间,会用才有鬼了。 先解决这个问题,然后弄个8GU盘来装酷,就这么决定了。 另外,血色星期一的设定弄的很不错,系统是linux(估计是定制的),里面用的是python(就是听说用这个语言才去看的)。不过入侵的时候时间和动作都搞笑了点。真正的入侵往往耗时数天甚至数周,而hack高手也不是拿一堆脚本去淹死服务器的家伙。能够从别人认为完美的地方看出破绽才算入门,而能够从逻辑层面升华到理论的才算是大师。

杭州,火车,咖啡厅

Dec 12, 2008 - 1 minute read - Comments

贝壳,黄昏,杭州,城站火车站旁,上岛咖啡,红烧牛肉饭,充电,无线上网,博客,大家,好玩吗?

竞价排名和不作恶

Nov 23, 2008 - 1 minute read - Comments

前两个月贝壳才刚说到百度的竞价排名,果然,这回又出问题了,而且还出的很好笑。 央视曝光了百度竞价排名中的一些问题,主要是有很多医疗信息,百度并没有核实来源。此后,百度总裁李彦宏声称,法律没有要求百度对付费信息负责。从法律角度说,这是对的,我们今天说的主题也不是他,而是这个(http://www.cnbeta.com/articles/69964.htm)。 本来曝光百度,怎么转眼变成google了? 看来百度不应该叫搜索引擎公司,而应该叫公关公司。前两个月讲三鹿问题,他是公关。央视曝光医疗问题,他是公关。现在出这个,还在公关。不过你可以公你的关,不代表股东会买你的帐。详细情况大家可以看这里(http://realtime.zaobao.com /2008/11/081120_21.shtml)。 估计我这篇blog的百度排名应该会很低吧—— 下面贝壳废话一下,讲解一下竞价排名的问题,google的价值观和策略。 竞价排名在前两年是一个非常好的模式,通过竞价本身,我们就可以发现很多有价值的信息。例如,我们在搜索IBM的时候,肯花钱的蓝色巨人总比不肯花钱的国际大嘴(International Big Mouth)来的有价值吧。然而问题在于,由于搜索引擎价值的外在性很大,又没有监管,搞不好就要出问题。而且往往不是竞价排名供应商出问题,而是上游下游出,他们没法管。首先我们说外在性的问题,所谓外在性,是指由不应当承担后果的人承担后果的一种状况。好比我在XX地开了一个工厂,生产在欧洲要花很多环保费的东西,破坏了当地的环境。我获得了收入,但是后果由当地人来承担。不论出现的原因,由于外在性的存在,会破坏社会公平,因此很多国家都有补偿外在性的措施。例如排污税,针对富人的高所得税等。竞价排名的外在性在于,有人花钱买排名,并不总是发现价值的过程,也可能是减少价值的过程。而减少价值的损失并不总由百度承担,而是由百度的用户承担。更麻烦的是,这个过程是不可监管的。 我们举例详述整个过程。假定有人在百度竞价买了“流产”(这也是百度最贵的排名)这个关键词,那么,什么人会最乐意去购买呢?我们分析一下流产的潜在市场。正规医院的流产总要通过手续,未成年需要父母签字。很多有钱的小孩宁可多花钱也不希望父母知道,因此他们会选择一些非正规的医院。于是,这些市场一般都是非正规的医院把持的,因为正规医院的收费公开固定,流程有一定监管,肯定没法和这些非正规医院去竞标这个关键词。那么非正规医院中,我们可以想象,应当是付出最高价格的人能够获得这个关键词。如果你按照百度的去,那么你去的地方一定是市场上拥有最高的成本收益比的地方——因为只有这样他才能标到百度的关键词。问题是,什么样的医院会拥有最高的成本收益比?如果是监管医院,这个答案一般是私人贵族医院——如果中国有的话。如果是非监管,那肯定有问题。因为他不能贵族化,收入上不去,又要保证成本收益比,只有降低成本咯。而且医疗系统里面,降低成本普通人根本看不出来。不普通的人——不普通还需要自己找非监管医院么?同样,一些用户不希望被监管的医疗问题中,这个关键词应当也是非常贵的。例如生育,肾亏,等等。这个过程也是不可监管的,百度自己难道还逐个核查竞价排名的真实性?他又如何有权力做这个事情呢? 一家不在监管下的医疗机构,这个问题够严重了吧?但是百度有做什么非法的事情么?没有。从法律角度讲,任何人有权付费将某个信息在百度的排名变更。例如,我可以付费将布什是条狗的网页调整到最高——如果我对布什不爽的话。这个不触犯任何法律,除非你调整有悖法律的关键字。你不能说布什是条狗不是事实,因而不允许我调整排名。那么,百度调整这些有问题的医疗机构的网页,并不能说他触犯了任何一条的法律——从法理上讲是这样的。 通常来说,如果是普通机构,市场会自行调整。如果一个公司提供的信息是违背市场本意的,那么这个公司本身就会被市场淘汰。如果你天天提供广告给我们,我们应当一脚把你踢开。问题是,百度获得了足够的互联网资源,百度搜索是个太重要的东西了。因此他可以屏蔽对自己不利的消息。于是,即使百度有问题,大家也不会知道,直到上面的这幕出现。百度被另外一个媒体的老大——央视——点名,他屏蔽不掉了——总不能屏蔽央视吧?当然,他还是屏蔽了部分消息,并且留下了相当的尾巴。 google的核心哲学观点之一就是“不作恶”。简单来说,就是不因为外力——包括广告,赞助,等等——人工改变排名。google的排名一般有两种变更方法,一种是被发现作弊或者犯规,另一种是更改算法。用google的话来说,即使我们认为某个关键字结果是错误的,修正错误的方法不是我们调整这个页面的pagerank,而是使用更公正的算法,保证每个人在同一个起跑线上。这个和美国法律的精髓如出一辙。即使我认为这个判例是错的,我也不会行政干预这个判决。而是通过议会修正法案来修正法律,保证一个更公正的法律。 至于google的广告,不要误会,google也是卖广告的。google的广告都统一显示在页面的右边,和左边的搜索结果严格分离。大家可以很容易的识别出google的广告。如果你们对广告内容有兴趣,可以点击广告——这是google广告的本意。如果你们对广告内容没兴趣,不强迫你们。这个是“不作恶”的本意。