top 命令补充 ( VIRT  RES  SHR)

Tasks: 182 total,   1 running, 181 sleeping,   0 stopped,   0 zombie
Cpu(s):  6.9%us,  0.9%sy,  0.0%ni, 91.7%id,  0.2%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   4145324k total,  3980684k used,   164640k free,   171700k buffers
Swap:  4192924k total,     1120k used,  4191804k free,  3561216k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                              
3047 web       15   0 55652  11m 6260 S    4  0.3   0:00.36 /data1/apache/bin/httpd -DSSL        
3036 web       15   0 55648  11m 6472 S    4  0.3   0:00.66 /data1/apache/bin/httpd -DSSL        
3052 web       15   0 55656  11m 6316 S    4  0.3   0:00.64 /data1/apache/bin/httpd -DSSL        
3055 web       15   0 55624  11m 6520 S    2  0.3   0:00.57 /data1/apache/bin/httpd -DSSL    

其中：
VIRT： 虚拟内存的大小，单位为kb，该进程自己认为自己使用了的内存的大小， 对应ps命令里面的VSZ
SHR :  共享的内存的大小，单位为kb，该进程可以与其它进程共用的资源占用的内存大小
RES ： 该进程当前占用的物理内存的大小， 对应ps命令里面的RSS

三者之间的关系：
VIRT = RES + SWAP
该进程占用的私有的物理内存大小为： RES – SHR

中国的权贵不把房地产搞崩盘誓不罢休

牛刀 中国房地产独立评论家

网上流传房地产蹦盘时间表，预言明年中国房地产崩盘，与我的预测基本一致，只不过我给了一个基本前提，只要房价涨过了今年，那么就要暴跌十年。这个时间表没有前提，肯定的预测就是明年崩盘。

不过也有专家提出：要用调控通胀的 机制来调控房价，首先要建立统一的房价指标体系，建立城市的普通住房价格指数。同时，设立不超过居民年收入增长率的房价容忍指标，一旦超过这一指标，相关 部门就要马上启动调控机制，例如调整房地产贷款利率、增加土地供应、提高购房首付。这一容忍指标也要设立下限，房价大跌同样不利于房地产市场的健康。这位 专家说，最理想的状态是通过这一体系，让中国房价在四五年内实现“软着陆”。

天真的专家，怎么可能？中国的权贵势力如此强势，不把中国房地产搞崩盘誓不罢休，因为他们只有通过房地产，实现最大限度的掠夺中国老百姓的财富后，一走了之，留下一地鸡毛，让中国老百姓来收拾。这是中国房价不能不崩的本质原因。想用五年的时间软着陆，只能是大白天的梦话。

可怜的中国老百姓，直到现在还有人去接高房价的最后一棒。他们是被搞怕了。2008年，正在房地产出现调整时，他们好容易看见房价下降的希望，结果 政府上下动员哄抬房价，举国之力，把房价撑到天上。这就是全球看见的，中国房地产的炒买炒卖举世无双，中国房地产泡沫破灭的后果要比日本严重得多。现在还 有谁会相信，房地产会软着陆？

首先我们要明白，房价和通胀是两回事。房价是资产泡沫，泡沫破灭影响的权贵阶层及其食利群体，他们只不过是资产缩水而已；而通货膨胀掠夺的是全体老 百姓。这样政策取向很明显，保护房价泡沫，衍生通货膨胀。目的，将老百姓的储蓄洗劫一空，去填补那永远不可能的填补的泡沫。这也是我们看见的明明通货膨胀 已经非常严重，CPI指数只有2.7%的根本原因。

因此，遏制通胀应该用遏制通胀的办法，化解房价泡沫要用化解房价泡沫的办法，这不可能纳入一个体系。现在，化解泡沫和遏制通胀已经都是火烧眉睫的 事，但是，仍然应该区别对待。用一些不痛不痒的产业政策、财税政策去给房地产这个巨型泡沫挠挠痒，有什么用？现在是要动用货币政策的时候，采用金融工具， 增加物业税，双管齐下，还有一线生机。

重庆正在单打独斗，准备在辖地推出房地产特别消费税，这实属无奈之举。推出这个税收，对重庆一地当然会产生很大的影响，但是，没有货币政策来保证币值的稳定，也是不会发生实质性的变局，因为，中国各大省区都处在一个货币政策之下，只要人民币不停止贬值，房价泡沫就不可能得到有效化解。

五年也好八年也罢，都不可能实现软着陆。中国的房地产已经命悬一线，要想泡沫不破，只有把利率提高起来，只有把物业税开征起来。等到明年，就是想开征物业税也来不及了。

至于通货膨胀，现在已经非常严重，但是是不是已经转成恶性通胀，没有数据可以说明。CPI这个数据不能作为测度通货膨胀的工具，而且，CPI已经人 为的被操纵，目的是阻碍遏制通货膨胀的努力，麻木市场的神经，受到百姓的嘲笑。目前，市场上已让出现操纵价格的现象，现在的菜市场，韭菜卖到9元钱一斤， 而猪肉才卖到7.5元一斤，这种反常的现象，不是人为操纵又是什么？

阻止化解房价泡沫的全部努力，那就是掩护国际楼市炒家拉高出货，从目前情况来看，即使拉高也出不了多少货，等下去还是泡沫破灭，中国房地产彻底崩盘，金融拨备率超过161%的中国商业银行，同样面临冲击。

Linux集群负载均衡

集群原理
linux集群系统包括集群节点和集群管理器两部分。集群节点有时简称为节点、服务器或 服务器节点，是提供处理资源的系统，它进行集群的实际工作。一般来讲，它必须进行配置才能成为集群的一部分，也必须运行集群的应用软件。应用软件可以是专 用于集群的软件，也可以是设计用于分布式系统的标准软件。linux集群管理器则是将节点捆绑在一起，以构成单一系统外观的逻辑结构，它用于将任务分解到 所有的节点。

集群因多种不同的原因而有着不同的类型，建立linux集群的最直接原因是共享CPU资源，在多个机器之间平衡负载，获得更多的系统可靠性，或在主机失败时提供后备系统（切换）。

通过对相关软件的分析，实现集群负载的功能是通过流量管理实现的，具体有以下几种实现方法：直接路由(Direct Forwarding)、网络地址转换（NAT）和隧道技术（Tunneling）。

直接路由（Direct Forwarding）是当参与集群的计算机和作为控制管理的计算机在同一个网段时可以使用此法。控制管理的计算机接收到请求包时，直接送到参与集群的节点。它的优点是返回给客户的流量不经过控制主机，速度快、开销少。

可能大家比较熟悉网络地址转换（NAT）这种方法。地址转换器有能被外界访问到的合法IP地址，它修改来自专有网络的流出包的地址，外界看起来包是来自地 址转换器本身。当外界包送到转换器时，它能判断出应该将包送到内部网的哪个节点。它的优点是节省IP地址，能对内部进行伪装；缺点是效率低，因为返回给请 求方的流量要经过转换器。

隧道技术（Tunneling）这种方式是linux集群的节点不在同一个网段时采用的转发机制，是将IP包封装在其它网络流量中。从安全角度考虑，应该使用隧道技术中的VPN，也可使用租用专线。

在计算机技术中，集群负载平衡是目前一个热门技术，也是一个高端应用。Internet/Intranet中使用集群负载平衡方案十分广泛，尤其是大中型网站都难离这种技术。直接路由、网络地址转换、隧道技术会根据应用需要而被采用。 

男女之间的10种“边缘”关系

男女关系越来越多元化的今天，颠覆传统的主力——大学校园里，更多种的异性关系出现了。这些无法定义的情感，以前叫“暧昧”，但随着人们对蓝颜知己的态度越来越宽容，今天这些擦边球故事里的哥哥妹妹们更喜欢管它叫“边缘”。

边缘关系之一：哥哥妹妹(姐姐弟弟)

边缘指数：****

招牌口号：“某某是我哥，我们是亲人。”“她是我老乡，比我小三届呢，小妹妹……”

潜在危机：“弟弟妹妹”对“哥哥姐姐”的感情，往往更为沉重和复杂，很容易陷入其中难以自拔，一旦“哥哥姐姐”开始恋爱，“弟弟妹妹”难免会成为绊脚石

边缘关系之二：死党

边缘指数：****

招牌口号：“我和她谁跟谁啊，完全是亲哥们！”“我早就认他做我姐姐啦。”

潜在危机：每天无拘无束玩在一处的亲密朋友，一旦有突发事件使其意识到对方是异性的事实，关系难免不出现化学反应

边缘关系之三：红颜蓝颜

边缘指数：*****

招牌口号：“女生的心和身体是可以分开的，我们之间，就一个纯字。”“男女生之间没有纯洁的友谊？那只怪你没找到红颜知己。”

潜在危机：和死党比起来，以感情互动为基础的红颜蓝颜又多了一层边缘的成分。即使是最清白的蓝颜知己，也会引起恋人的警惕；其次，毕竟是一男一女，一旦“酒逢知己千杯少”，难免突破最后一道防线，这“知己”关系就难再继续。

边缘关系之四：粉丝

边缘指数：**

招牌口号：“人家就是我偶像！我愿意帮他/她。我只是欣赏他/她的才华…”

潜在危机：不平衡的关系不容易顺利转型。通常这种带有奉献与仰慕性质的边缘感情会随着时间而淡化；不过也不排除出现意外的情况

边缘关系之五：异性合住

边缘指数：***

招牌口号：“一个人住负担太重，而且我怕黑，有个男生也好照应。”“她的重要意义体现在每个月除了方便面不知道还能吃啥的时候。”

潜在危机：房子本身就已经十分边缘，单身男女共住一房？即使并非一室，也太接近。小心咯，不要被别有用心的人利用，伤了感情还搅乱了生活
边缘关系之六：网络情人

边缘指数：*****

招牌口号：“我们在比特的世界里相爱，离开网络，这份爱就无法生存。”
潜在危机：因为彼此爱的，

边缘关系之七：青梅竹马

边缘指数：*****

潜在危机：最接近亲情的关系，反而危险，每当谈恋爱不顺的时候，难免会回归的港湾，除了家还有哪儿？这种边缘已经无需口号做掩饰。

边缘关系之八：损友

边缘指数：**

招牌口号：“我们以踩得对方心服口服为最终目的！小样的看谁牛……”

潜在危机：有竞争就有刺激的快感(此快感非彼快感，不许想歪)，嬉笑怒骂间培养出来的默契不容小觑，谁说俩人不会某天突然就损出感觉了呢

边缘关系之九：兼职司机/保镖

边缘指数：****

招牌口号：“反正他有车，正好顺路送我而已。”

潜在危机：这种关系可是衍生绯闻的源头哦！也许你只是搭了谁谁的顺风车而已，但别人怎么知道，车的终点是哪里呢？

边缘关系之十：约会拍档

边缘指数：****

招牌口号：“一个人玩有什么好玩，我不过是给自己找了个玩伴而已。”

潜在危机：如果这种关系稳定而确定、建立在共同的兴趣爱好上，可以称之为志同道合。但如果只是一方寂寞了需要消遣，而另一个属于纯粹的“n陪”，那就有说不清道不明的嫌疑了

PHP 获取POST数据的另一种方法

在研究网易登录的时候，发现网易的登录的POST数据为如下形式：

callCount=1
scriptSessionId=${scriptSessionId}187
c0-scriptName=UserBeanNew
c0-methodName=checkPassportVN
c0-id=0
c0-param0=string:ssologin
c0-param1=string:cf8956a6cf1cbbebe85ddde5156afee8
c0-param2=boolean:false
c0-param3=string:0
c0-param4=boolean:false
c0-param5=boolean:false
c0-param6=boolean:false
batchId=662190

因为如果是表单提交的数据的话，POST数据一般是xx=XX&yy=YY&.. 的形式，这样正好方便解到数组里面；但是网易的POST明显不是这种格式，还在想是怎么发起的这个http请求，后来才意识到使用ajax的方式时，POST数据完全可以使外部组织的。至于服务器端怎么解释就是另外一回事儿了。

网易的服务器端是java写的，至于java怎么获取这部分数据就不管了，如果是PHP，怎么获取这种格式的数据呢？一般来讲，使用PHP获取POST数据都是从POST数组中获取的，但是，这种格式显然不能按照xx=XX&yy=YY&.. 格式来解释成数组了，那么PHP又怎么获取这部分数据呢，至少PHP一定有办法获取这部分数据，只是我目前还不知道而已（或者是忘记了）；
后来百度一下，发现可以通过 php://input 来获取。

女人最需要的是什么

女人最需要的是什么？其实很多人都在找寻这个结果，不光男人不知道，有的时候女人也不知道自己想要的究竟是什么，女人有的时候很复杂，有的时候女人也可以是非常简单的。男人们总认为女人很难理解。其实是男人没有真正的理解女人。

    女人最需要的是什么？

    女人最需要：男人的理解、关怀、赞美、体贴和爱护。

    女人最需要：挺拔的身材、漂亮的脸蛋、秀丽的长发。

    女人最需要：内在的气质、幽雅的谈吐、温柔的品性。

    女人最需要：稳定的工作、幸福的家庭、自己的空间。

    女人最需要：同性的羡慕、异性的关注、晚辈的崇拜。

    1、礼物不在贵重，而在于真诚

    从女人的观点来看，最好的礼物是那些较平实的，而不是那些浮华夸张的。 有个丈夫专门收集情人卡，随时送给太太，每当她心情不好时，他就把一张卡放在她可能发现的地方，这使太太非常开心。

    2、不少女人真的怕自己不够漂亮

    女人需要明确的赞美：“我喜欢那个发型”，或者“你穿红衣服很好看”。这种赞美的话能给女人鼓励，使她注重打扮，使爱情不断得到滋润。

    3、女人也重视工作

    女人希望她们的丈夫或男友重视她们的工作，像他们重视自己的工作一样。每次太太谈论她自己的工作时，丈夫应竖着耳朵细听。不用说，由于在这方面沟通好了，他们之间的感情会越来越深厚。

    4、女人需要男人耐心倾听她说话

    男人心目中的交谈是研究问题、辩论是非，找出解决办法的途径。为了达到这个目的，他也许会一再打断女人的话，要她“明白”他的意思。然而，女人宁愿男人友善地倾听，而不愿他们老是发表意见，她们会说个不停，直到觉得心里恢复舒畅为止。

    5、女人不像男人那样容易堕入爱河

    女人择偶时，通常较重视各种实际的因素。女人也许亟需爱情，但她们内心仍有位品评专家在问：这个男人可靠吗？因此，男人除了要注意头发、衣服和礼貌等外，还要具有仁慈大方和忠实可靠的品德。

    6、女人希望跟丈夫成为朋友

    女人希望和她偕老的男人视为地位同等的人，尊重她的长处，容忍她的缺点，而且希望她也这样对待他。

    简单地说，她需要的是朋友、工作、了解她的伴侣。

好友或关注在社区产品中的设计

根据这个文章的分析，我觉得新浪作为一个综合性的门户网站，我们的目前的好友关系系统是一个以弱链接为主强链接为辅的关系系统。
 
————————————————————-
 
 

众所周知，“关系”的设计是社区产品中相当重要的一个环节，在设计关系的时候需要考虑到关系的成本，信息与关系的走向、关系的后续衍生产品和辅助功能等，不同类型的社区有着不同量级的关系设计，如果最初的架子没有搭建好，就会给后期的运营带来很大的麻烦。在此，将之前产品设计中领悟到的一些关于关系设计的问题总结整理，供大家参考。

1、谁与谁发生关系？

在社区产品，或者包含社区产品的大网站中，关系一般可以分为两个大的类型，：

(1)、用户与用户之间的关系

(2)、用户与内容之间的关系(包含用户产生的内容和网站本身产生的内容)。

以下我们先探讨关于用户与用户关系的设计问题

2、用户与用户之间的关系该如何设计，适用哪种类型的网站

要搞明白哪种关系适合哪种网站，首先要区分的是强链接与弱链接。

强链接：需要从强链接获取认同、纯关注、同情、炫耀、依靠等情感沟通，强链接类似家人、现实生活中的朋友、同学等，尽管可能你与对方不是处于同一个知识圈中，但依然可以找到很多个共同的公共话题和情感的交流。而且这种关系属于天然继承（亲人）或者环境造成（同学，同事）。

弱链接：需要从若链接获取知识、资讯、帮助、交流等，弱链接多产生在同一知识领域、共同的职业、同一爱好者群体、朋友的朋友（基于同一领域的）等。通过这些关系，可能对我们的工作、学习、爱好产生影响，在相互交互的过程中，双方换取资讯、知识、及对于某件事物的认识。

那么究竟哪些网站属于典型的强链接，哪些又属于弱链接呢？

SNS类网站，类似Facebook、Kaixin001.com  等基于实名注册和现实社交关系的基本上属于强链接关系。
豆瓣、last.fm等基于同一爱好或者文化基础的属于典型的弱链接模式，当然弱链接可能会转换为强链接。

在我们搞清楚强弱链接后，我们还需要知道的是，强弱链接的成本和信息披露的不同。

3、不同社区或网站适合什么类型的关系？

我们都知道，Facebook所采取的关系是好友，也就是需要对方同意后，方可以加为好友，加为好友后所获取的内容为对方的个人资料和个人状态的内容（照片、随笔、评论、日志、关系等）  。
而twitter采用的是关注，只需要主动关注即可成为关系，产生关系后，所得到的信息仅为对方的140字内容和少量个人介绍。

这两种关系的获取成本是截然不同的，
需要对方同意并加为好友的，首选需要得到主人的主观审核，并且获取了相对较多的内容，
而单纯关注性质的获取的成本就相对低廉的多，当然，得到的综合信息也会少很多（仅来自单一的产品形态）。

OK，由此可见：

若获取的内容为综合的，基于现实关系的(强链接)的，对关系双方资料有保护倾向的，需要采用好友的关系，也就是需要双方认证的。

若获取的内容为单一的，基于虚拟关系(弱链接)的，对关系双方不需要刻意保护的，需要采用关注的关系，也就是无需认证，最低成本获取关系的模式。

（弱链接在某些社区网站还用以标注收藏的作用）

那么获取关系后，信息的披露是如何的呢？

4、在获取关系后，信息该如何披露呢？

获取关系后的信息披露大致要考虑两点，

(1)、信息披露的主要内容

信息披露的内容其实主要是指双方在获取关系后，基于好友和关注究竟应该为用户推送什么内容呢(动态)。其实，在最上面的强弱链接的区别我们已经看出所需要披露的内容。

基于强链接的内容，我们更在意的是关系的交互，也就是对方做了什么，想了什么、更新了什么、那么对方是否更换头像、是否写了新的日志、是否拍了新的照片等，都会成为主要的信息推送内容。
而弱链接实际上我们更关注的不是对方，而是对方基于网站所产生的内容，也就是对方对于某个事物的表态、文章、照片、评价等。（类似豆瓣的推荐、我说、Mtime的随笔、分享，一句话影评，参加的活动等）

(2)、用户对信息的承载力，如何避免信息过载。

信息过载问题常常为我们所困扰，尤其是基于关系进行信息披露的，那么要解决或者尝试解决信息过载问题，首先要搞清楚的是用户对信息的承载能力问题，不同类型的关系和不同的用户，对于信息的承载力是不同的。

大致来说，关系越强，信息的承载力越强，关系越弱，信息的承载力就会越差劲。由此，我们可说，在强关系的动态中，我们可以更多的披露轻量级的动作，对于信息的流量不必控制太严格，当然，要严格注意个人隐私问题。
在弱关系的动态中，我们更需要注意的是信息的相关度和产生信息的量级问题（例如：产生内容的成本约大，可能信息的价值越高）

(3)、提醒在关系中的应用

提醒是社区类网站或网站社区功能中的主要组成部分，也是用户较低成本获取关系内容的方式。例如：站内信、特殊事件提醒、请求的提醒、回复内容的提醒、系统提醒都属于这种类型。

在提醒的设计方面，我们应更注重动作前移，也就是在提醒中的信息披露足以用户做出判断，并有相应的动作能够迅速完成对于信息的回应，这一体验将更有利于提高网站的黏性，增强关系。

以上是关于不同类型的社区或网站的社区功能中用户与用户之间的关系设计的一点小总结。

javascript 片段

http://www.google.cn/music/js/music_js-941234969.js

其中的一段，判断变量类型，居然也能这么复杂：

typeOf = function(a) {
    var c = typeof a;
    if (c == "object") if (a) {
        if (a instanceof Array || !(a instanceof Object) && Object.prototype.toString.call(a) == "[object Array]" || typeof a.length == "number" && typeof a.splice != "undefined" && typeof a.propertyIsEnumerable != "undefined" && !a.propertyIsEnumerable("splice")) return "array";
        if (! (a instanceof Object) && (Object.prototype.toString.call(a) == "[object Function]" || typeof a.call != "undefined" && typeof a.propertyIsEnumerable != "undefined" && !a.propertyIsEnumerable("call"))) return "function"
    } else return "null";
    else if (c == "function" && typeof a.call == "undefined") return "object";
    return c
};