21:41 看图说话:杂事四则 » 刘润

一、毕业十年

一晃就是十年,想想觉得可怕。5月2日,南京大学数学系94级/98届的老同学们相聚南京,参观老校区,寻找15年自己前种的树,回想我们在什么地方打水,在哪里排一个多小时的队为了打一个电话,感慨颇多。十年来:

1、 除了由于生活条件改善而导致的质量沉积,大家基本未变,呵呵,只是更加成熟;
2、 见到的同学中,好像只有吴艳军一人创业,其他人都和我一样,给吴艳军一族打工;
3、 南京、北京、上海、美国的同学最多,但是聚的很少;
4、 有至今未婚的(黄金王老五了啊!),也有孩子最大的7岁,连朱彤都有女儿了;
5、 内部解决率很高,两对,七分之二,我太后知后觉了,才知道;
6、 不少同学五子登科(女子、孩子、房子、车子、票子),羡煞旁人;
7、 20年后会怎样?大家都会在做什么?那时候我们会老了吗?

二、最具突破奖

捐献时间”获得鲁豫的“万众义心”公益“最具突破奖”。我们的核心成员俞丽辉(又高又帅)代表领奖。

最近和一个公墓基金谈合作的时候,被问到:捐献时间和央视合作,改名“慈善1+1”,是不错,但是淡化了一个很好的品牌你不觉得可惜吗?答:捐献时间是“我”的,还是你的,或者是他的,不重要。重要的是,这个模式需要什么样的资源、合作伙伴、组织结构才能发挥它的最大容量。如果说捐献时间“最具突破”性,那么我觉得突破的是很多草根公益组织的“家族企业”心态,才能突破性发展,帮助最多的人。

第一财经的《谁来一起午餐》邀请“多背一公斤”和“捐献时间”台上PK,被我婉拒了。

三、老古董

偶然翻出来上次在台北拍的一张很有意思照片,一本“准演执照”,老古董。准演执照里批示删了三个镜头:

1、床上接吻镜头一段;
2、海边接吻镜头一段;
3、“你先做三年预备党员~~~再做正式党员~~~”对白一段

看来,也就是这些年,“风化”这点事儿,才有重大的突破,两岸都一样。

四、表妹结婚

Angela终于嫁了,哈哈哈哈哈,感谢LQ~~~

21:21 Apache的泛域名解析目录映射实现:mod_vhost_alias - Apache HTTP Server » del.icio.us/chedong
A more even spread of files can be achieved by hashing from the end of the name, for example: VirtualDocumentRoot /usr/local/apache/vhosts/%3+/%2.-1/%2.-2/%2.-3/%2
微软宣布放弃收购雅虎的计划品味雅虎 » Che, Dong's shared items in Google Reader

  美国当地时间5月3日晚间8点05分,微软公司宣布已撤回收购雅虎公司的提议,至此,历史3个多月的微软收购雅虎案告一段落。

  微软放弃收购雅虎的原因是因为双方在收购价格上无法达成一致。当地时间1月31日6时40分,微软宣布以溢价62%,即每股31美元,总价值446亿美元收购雅虎,但收购计划遭到雅虎的拒绝。微软 CEO 史蒂夫·鲍尔默曾在上周六给雅虎的信中表示,希望能以475亿美元,即每股33美金的价格收购雅虎。但雅虎方面坚持收购价格至少要达到530亿美元,即每股37美元。

  史蒂夫·鲍尔默就放弃收购雅虎致杨致远一封信(详文附后),对雅虎为反击微软的恶意收购而作的一系列动作,如将在线广告外包给 Google 表示了深切的忧虑。认为这将会破坏雅虎自身的战略和长期的生存能力。,并仍然认为:就算在今天,我们的报价是能让你的股东就他们手上的股票获得完整和公平价值的唯一选择。拒绝我们的提案会使得你和你的股东损失相当可观的价值。

  雅虎针对微软放弃收购事件,也作了简短的回应,坚持了自己的一贯看法。

  附:史蒂夫·鲍尔默就放弃收购雅虎致杨致远的信(译文来自 cnBeta.com)

尊敬的Jerry:

  在三月多的谈判之后,我们对就微软及雅虎可能的合并的谈判结束了。

  我首先要表示我个人对你,你的管理团队,和雅虎董事会就考虑我们收购提议的感谢。我更要特别感谢你在该计划上所投入的时间。我觉得我们本周进行的讨论是非常有用的,让我弄清可能达到和达不到的目标。

  我对雅虎拒绝收购提案感到失望。我在1月31日第一次向你提出了收购的计划因为我认为两家公司的联合会使我们的股东受益,并且向消费者,出版商和广告商一个更佳的选择。我们认为62%的溢价合理的反应了这一点。

  在这一周的讨论中,我们表示愿意将出价提高到每股$33,再次表示我们对这会让双方受惠的交易的信心。该增加为为你的股东提供另外50亿的价值,和 以前的出价相比,在1月31日股价的基础上,该出价给出了高达70%的溢价。但你认为这还不足够,希望微软付出另外50亿,或者每股$4的出价。

  另外,在这一周的讨论之后,我认为由微软直接向你的股东进行收购是不理智的。因为这会导致委托书竞争和交换收购。我们和你的会谈让我们认为,你会努力阻止该”恶意收购”的发生。

  我们对你为了阻止”恶意收购”而和Google于在线广告上的合作计划感到忧虑。在我们看来,这种计划会使得我们收购雅虎的可能性消失:

  第一,鼓励广告商使用Google而不是雅虎的在线广告”Panama”会破坏雅虎自身的战略和长期的生存能力。这将会减低雅虎在线广告未来收入增长的可靠性。

  其次,这会损害雅虎吸引工作于在线广告的优秀工程师的能力。他们所产生的价值是收购案中我们关心的重要利益。

  第三,这也会使得Google有能力对自身和Yahoo上的关键词搜索进行定价,并且对Yahoo上的广告商提价。除了可能的法律问题之外,我们认为在商业上来说,这种举动是极不聪明的,除非此人希望退出该行业,并且支持google的发展。

  另外,这也会阻止雅虎和其他不提供Google关键词广告的搜索服务提供商的合作。

  因此,你对应对”委托书竞争”或”交换收购”的计划使得我们最终决定放弃该该计划。我们在此正式宣布放弃微软收购雅虎的计划。

  在微软自身优秀的工程师和与其他商业伙伴战略性交易的帮助下,我们会让微软继续创新和发展壮大。

  我仍然认为就算在今天,我们的报价是能让你的股东就他们手上的股票获得完整和公平价值的唯一选择。拒绝我们的提案会使得你和你的股东损失相当可观的价值。

  但很明显,这次交易不可能成功。

  再次感谢你抽出时间和我们会谈。

史蒂夫·A·鲍尔默

  信件英文全文


文章评论


Copyright © 2007 www.Yseeker.com E-Mail:ma.qingxi@yahoo.com (121.9.226.14)

Apache的KeepAlive设置与优化老黄纸条箱 » Che, Dong's shared items in Google Reader

前些日子一个朋友系统上出了点小问题,给他说了些优化的策略,回过头来,他听说关掉Apache的KeepAlive可以提高性能,特别要我帮他说说。我就在这里记下个纸条,以后备用。

先来说说Apache的KeepAlive的设置。

KeepAlive在Apache Core中的设置说明:
Keep-Alive扩展自HTTP/1.0和HTTP/1.1的持久链接特性。提供了长效的HTTP会话,用以在同一个TCP连接中进行多次请求。在某些情况下,这样的方式会对包含大量图片的HTML文档造成的延时起到50%的加速作用。在Apache1.2版本以后,您可以设置 KeepAlive On 以启用持久链接。
对于HTTP/1.0的客户端来说,仅当客户端指定使用的时候才会使用持久链接连接。此外,仅当能够预先知道传输的内容长度时,才会与HTTP/1.0的客户端建立持久链接连接。这意味着那些长度不定的内容,诸如CGI输出、SSI页面、以及服务器端生成的目录列表等内容一般来说将无法使用与HTTP/1.0客户端建立的持久链接连接。而对于HTTP/1.1的客户端来说,如果没有进行特殊指定,持久将是默认的连接方式。如果客户端进行了请求,将使用分块编码以解决在持久链接里发送未知长度内容的问题。

另一个相关的是KeepAliveTimeout在Apache Core中的设置说明:
Apache在关闭持久连接前等待下一个请求的秒数。一旦收到一个请求,超时值将会被设置为Timeout指令指定的秒数。
对于高负荷服务器来说,KeepAliveTimeout值较大会导致一些性能方面的问题:超时值越大,与空闲客户端保持连接的进程就越多。

后最后还有一个相关的是MaxKeepAliveRequests在Core中的说明:
MaxKeepAliveRequests指令限制了当启用KeepAlive时,每个连接允许的请求数量。如果将此值设为"0",将不限制请求的数目。我们建议最好将此值设为一个比较大的值,以确保最优的服务器性能。

通过Apache的设置说明,我们已经能明白KeepAlive的原理。在对于一个包含许多图片的网页来说, 客户端会在瞬间发出多个HTTP请求,此时多次建立TCP连接会大大降低响应速度。 此时通过持续连接,可以允许用户在一个TCP连接中发出多个HTTP请求, 减少TCP连接建立次数,提高响应速度。我们可以通过access_log统计出连续HTTP请求出现的次数、间隔时间、访问量, 以确定 MaxKeepAliveRequests 和 KeepAliveTimeout 的值。 KeepAliveTimeout 太小发挥不了持续连接的作用;太大了,持续连接迟迟不断, 浪费TCP连接数不说,更糟糕的是系统中的 httpd 进程数目会因此不断增加, 使得系统负载升高,甚至会导致服务器失去响应。

但是当你的服务器只是在处理动态网页请求时,由于用户很少会瞬间请求多个动态网页 (一般都是打开页面之后阅读好半天才点下一页), 此时打开KeepAlive无异于浪费TCP连接数。

哪么什么决定着我们是不是要开启KeepAlive的因素就很简单的确定出来了,就是说在用户一个页面请求中是否会向服务器发出多个HTTP的请求。

对于我的哪个朋友,他们的服务器中有着动态应用,有着所有的图片,我看了一下,估算他们的首页中发出的请求类型为以下几种:text/html、text/css、application/octet-stream、text/javascript、image/gif、image/jpeg。一个首页发出了181次请求(我看了所有的请求,注意所有的请求都是同一个域名)。这里可能由应用程序生成的只有text/html和application/octet-stream,这种请求中text/html只有一次,而application/octet-stream也只有4次。哪么关闭KeepAlive对他们有帮助吗?我的回复是没有帮助,而且会让服务器的服务质量更差!

如果是这样的情况,怎么办呢?我的建议如下:
1.如果我们每一个页面中只有一个请求是动态生成的,而180个(里面可能有4个不是,不过不重要了)都是静态的,哪么应该将静态与动态分开到两个服务器上(一台机器都可以)。将动态应用的KeepLive关闭,将静态服务器的KeepLive打开。
2.前端前部署四层交换或七层交换或缓存服务器,这样会让系统的扩展做起来,同时也可以让服务器的KeepLive打开时有更好的效果。
3.应该考虑优化下他们的apache了,听说一个进程有高达xxM的内存占用,比较恐怖,在10M以内比较正常的说,不过这是一个option了。

时间越节省越无法拥有?GTD Life » Che, Dong's shared items in Google Reader

2322408071_80664e5cd6

网友LijuanKate在交流圈里抛出了这样一个问题:

在《多少算够》这本书里看到的:

经济学家E.F.舒马赫提出的一个经济学定律“一个社会真正可用的闲暇的数量通常是与这个社会用以节省劳动力的机器数量成反比。”

人们越重视时间-因而越绞尽脑汁去节省它-人们就越不可能放松和享有它。

这确实引起了我深入的思考:

很快,老朋友C/J分享了他对这个话题的看法:

这是价值观与人性本身的问题,而非时间管理的存在意义问题。

- 时间管理本身是可以帮人放松和享受时间的,
  但贪欲决定着人决不会甘心将通过时间管理的而节省下来的时间完全用于"闲暇",
  每个人都会觉得有两倍的收入,会带来两倍的快乐,每一个人。

- 当社会生产力水平不发达的时候,人们也并非在享受闲暇,与其说闲暇不如说是无事可做,
  种子已经播下,杂草已经除尽,土壤的水份很充足,这个时候只有静静地等待作物生长。
  在看似闲暇的同时却抱有对未来不确定前景的隐忧,因为生产力水平低下,所以更容易受到风险的影响,同时因为社会水平低下,选择与保障也相对更少。其实古代人的心理压力比现代人更高。

- 时间管理只是一个工作,它只是帮你管理你的时间,但它管理你的期望与价值观,
  就像理财工具无法从根本上缓解你的金钱的焦虑与渴求一样。

其实时间本身并没有因为我们使用或者没有使用时间管理方法而增加或减少,时间对每个人都是公平的,我们所追求的,只是“时间自由

收藏、分享这篇文章!


© DavidZou for GTD Life, 2008. | Permalink

您可以第一个回复,来这里添加您的看法吧


关注时间管理、GTD的朋友共同成长的地方:

GTD在线交流

GTD、时间管理精彩文字尽在DiggTime:


挖掘GTD、时间管理精彩文字 什么是DiggTime?

请阅读相关文章

05:51 黑洞被逐出星系 » 格致 - 理解世界,享受科学

两个黑洞合并引起的引力波迸发,把新形成的黑洞推出星系核心。这种只在理论上预言过的大事件,被马普地外所的研究人员首次观察到了。

黑洞合并时会以光束发射强大的引力波,因为有方向性,形成的黑洞自己会因后坐力脱离原本在星系核心的位置。如果速度足够大,它甚至有可能脱离星系母体。

此发现同时暗示:有的星系的核心可能没有黑洞;缺失的黑洞在星系间漂流。

这些流浪者像星际海盗⋯⋯

Superkick: Black hole expelled from its parent galaxy
Komossa, S., Zhou, H., Lu, H. A recoiling supermassive black hole in the quasar SDSSJ092712.65+294344.0? Astrophysical Journal Letters, Vol. 678, L81, 2008 (May 10, 2008) 预印本


^==Back Home: www.chedong.com

^==Back Digest Home: www.chedong.com/digest/

<== 2008-05-03
  五月 2008  
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
==> 2008-05-05