zhiwei's shared items in Google Reader

Android应用程序需不需要手动退出？

2011-09-01T12:06:06Z

不止一次，也不止一个人问过这个问题。我都回答了：不需要。但是，还是要记录下来。

我们不妨从了解这个系统对于应用程序管理的一些内部机制开始说明原因。

对于Android系统而言，包含”进程”和”服务”。”进程”有正在运行的，也有刚刚离开在后台缓存的。”服务”是一个无界面、长时间运行的应用功能，并且不会轻易被终止。

我们知道，在Android中可以快速通过主页键（home）或者使用返回键（←）逐步离开应用程序。
主页键：

在当前运行的应用程序的任意界面，按下主页键会快速回到手机主屏幕。同时这个应用程序的进程将在后台被暂停并建立缓存，再次启动应用程序时可以方便地返回刚才的界面。（现场被保留）

当然，在你按下主页键回到手机主屏幕时，因设计需要，也有可能会在后台运行一个甚至多个进程和服务，以保证这个应用程序在后台是”活的”。（比如音乐正在播放时）

尽管我们知道了后台会产生各种各样的”进程”与”服务”，但你并不用担心它们会把你的手机拖累。当运行新的应用程序发现内存可能不够用时，系统会自动在后台释放部分缓存在后台的进程，以保障可运行新的应用程序。这是一个智能的、良性的供给体系。

返回键：

Android系统使用返回键来进行屏幕后退，以及关闭对话框/菜单/屏幕键盘。

对于传统的本地客户端应用程序，每个屏幕可以理解为一个活动（Activity）。通过返回键可以快速回退到当前应用程序的上一个活动，也可以离开当前应用程序打开的新的应用程序的某个活动。

所有的活动呈堆栈结构（一种串行形式的数据结构），正在运行的活动处在最顶端。当你按下返回键，会清除当前活动并恢复上一个活动。如下面的【图1】示例：

【图1】（来源：http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html ）

如果你连续按返回键，活动一个个被抽离，就像剥洋葱一样。

在Android的应用程序里，可以通过”意图（Intent）”功能，在当前应用程序（任务）的某个活动来启动另一个应用程序（任务）的某个活动。

比如下面的【图2】的示例，在”有道词典”主界面单击超链接”意见反馈”打开浏览器访问目标网页：

【图2】

在目标网页界面，你可以使用返回键快速返回刚才的”有道词典”主界面。

而接下来这个例子，体验则是非常糟糕的：

【图3】

请看【图3】，在目标网页想要返回上一个任务需要历经几番周折。一遍又一遍地回退浏览器的浏览历史，甚至还要回到浏览器的起始页，然后弹出一个对话框询问是否要退出。天哪！我快要疯掉了。

Android官方对于多个任务间的活动堆栈处理机制，可以看下面的【图4】来解释：

【图4】（来源：http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html ）

从图中我们可以看到，一开始在后台的”任务B”的”活动Y”经由”任务A”的”活动2″的一个按钮抽调到了前台，而随着”任务B”的活动一个个被剥离，最终整个”任务B”被结束了，并且使用返回键又回到了”任务A”的”活动2″。

当然，应用程序可以决定被调用时在哪一个活动就要结束。比如【图4】的”任务B”被”任务A”的”活动 2″抽调到前台后，可以决定在”活动 Y”这里就为终点，而不需让用户经过”活动 Y”的上一层”活动 X”。否则，就会出现像【图3】那样的麻烦，用户被不情愿地经过与当前任务无关的其它活动。

返回键实现了调用新任务之后快速返回的便利，而不是只能迂回地回到应用程序列表并找到上一个使用的应用程序再次启动。

当所有活动从堆栈中清除，任务结束。也就是说，在应用程序的主界面按下返回键，应用程序就已经退出了。

除非，这个应用程序设计了后台运行的进程和服务。比如”新浪微博”，即使你在应用程序主界面按下返回键退出了，在”程序管理”>”正在运行”界面上仍然可以看到正在运行的进程和服务。（需通过菜单键切换至”显示当前运行的服务”视图）

正如上面提到的，后台服务是一个无界面、长时间运行的应用功能，并且不会轻易被终止。即便你使用第三方的”任务管理器”来结束进程和服务，也有可能会自动重启进程和服务。（其实可以在”服务”界面找到它并且手动停止服务，只不过没有这个必要性，交给系统自动处理即可。）

至此，我们已经知道Android应用程序为什么不需要手动退出了。因为聪明的系统已经帮助用户做了许多事情，包括退出应用程序以及恢复可用内存。

受限于Android官方对设计规范的态度，Android并没有像iOS那样明文告诉设计者不需要这个不需要那个。Android应用程序的设计模式也因此而”百花齐放”，很难形成较为统一的体验。比如本文提到的需不需要手动退出Android应用程序的话题，如果在iOS中看到屏幕上有退出应用程序的按钮，是一件搞笑的事情。

无论如何，Android也好iOS也罢，用户本来就不需要关注”进程”或”内存管理”、”任务管理”这些东西。用完，离开界面即可，就这么简单！把用户不需要关注的问题抛给用户，无异于”不想让小孩玩火，但是又给他一个打火机。”

设计师们，该做些什么了。改变吧！

看到这里，也许你会问：既然Android应用程序在后台被挂起暂停了，但是为何开多了应用程序手机还是会变慢呢？

一方面：新运行的应用程序如果需要较大的内存，自然会比较慢。另外，如果手机本身的内存过小且CPU不给力，系统自然会因较频繁地自动结束进程释放缓存而导致手机在某些时候运行比较慢的感觉。

也正因为这样，我们知道了为什么”任务管理器”会如此流行，甚至成了”装机必备”。人们用它来快速提前释放缓存以保证运行新应用程序时有足够的内存。当然，随着CPU频率越来越高，内存越来越大的发展趋势，手动清除缓存已经慢慢变得不再需要。

另一方面：临时启动的后台服务可能会导致手机变慢。有些应用程序在后台监听到指定的事件会自动启动，比如操作系统本身的”Google服务”，又比如连接USB并且在PC上启动”豌豆荚手机精灵”，手机上的”豌豆荚守护精灵”会自动启动。为了避免这种情况，只能建议你有选择性的安装应用程序了。聪明的软件需要先进的硬件来支持。

也许你又会问：既然在应用程序主界面用返回键可以直接退出应用程序，可是为什么某Android应用程序（尤其是国内的）要弹出退出确认对话框呢？

往往他们会说是为了防止用户误操作，但完全是多余的考虑，因为有足够的恢复保障。背后真正的原因其实是产品人不希望自己的应用程序太容易被用户”退出”，为此给用户增加一道障碍墙。担心误操作，在我看来都是借口。

瞧瞧我们眼前的PC软件吧！单击窗口右上角的 X 图标后，也有不少软件在干同样的事情呢。

毫不客气地说，这是典型的把责任推卸给用户的做法。似乎在警告用户：”真的要退出了？确定的话我就不管你了！”

我们应该尽可能少使用对话框，提供必要的容错支持。允许用户犯错，并给予恢复的机会。比如你可以允许用户在按下返回键离开应用程序后还能再次返回现场。这在很多优秀的第三方应用程序上均有体现，比如Twitter、米聊……

当然，沉浸式的应用程序除外。比如影片正在播放或者游戏正在进行的画面，应当尽可能地不要让用户犯错被退出。沉浸式的应用程序应当提供沉浸式的体验保障，因为游戏或影片进行到一半被退出往往是无法返回现场的。

最后，补充说明：本文所说的”退出”是指退出应用程序，而不是指退出帐户的登录状态。如果你的应用程序是需要用户使用帐号密码登录的，那么提供”退出登录”（或叫”注销”）的功能，是有必要的。

支付宝为苹果与Linux用户提供无控件支付方案

2011-08-15T06:07:23Z

裸奔与虚拟机时代过去了，现在苹果与Linux用户也能安全又便捷地使用支付宝。即日起，已有安全产品（宝令、数字证书、手机动态口令任一）的用户可在无控件的情况下实现安全的支付，解决了上述用户长期面临的支付困境。

制图：不能透露

出于用户帐户安全的考虑，支付宝建议用户安装“安全控件”与“数字证书控件”，前者确保用户在登录支付宝时加强安全通信，可以有效防止木马截取键盘记录；后者为需要高等级安全的用户而准备，通过验证数字证书确保登录者与帐号所有人一致，可以有效实现“即便帐号被盗，资金也不会受损”的安全目的。

此前，由于缺少相应的控件，多数苹果与Linux系统用户徘徊在“不能付”、“裸奔”与“开虚拟机”之间，安全与便捷难以两全。自15日之后，包括iPhone、iPad、Mac OS在内的绝大多数苹果用户无需“安全控件”与“数字证书控件”，仅凭“安全产品”就可支付。而使用数字证书的Linux用户也不必再等待“数字证书控件”，在已有“安全控件”与“安全产品”的配合下安全性与便捷得到足够保证。

当用户选择“宝令”、“数字证书”以及“手机动态口令”以上任意一种“安全产品”时，每次支付都会提醒输入手机口令或宝令动态口令，安全性更高。

预计这一改进将数百万用户享受到更便利的网络生活。尤其是越来越多的用户使用iPhone、iPad等移动设备访问网络时，无控件支付方案将进一步促进电子商务及移动互联网产业的发展。

这是支付宝为方便用户使用所做的持续改进之一，今后将在确保安全的前提下为更多的移动设备提供便捷的支付方案。尽请期待。

具体说明：

——

让一个端口同时做两件事：http/https和ssh

2011-08-18T11:47:31Z

Shared by zhiwei
这个不能算真正的一个端口服务两个或多个程序。

相信很多人都在YY：能不能让80端口分析连接协议，如果是http协议就让服务器交给http服务程序（如Apache、Nginx等）处理，如果是ssh协议就交给ssh服务程序（如OpenSSH Server）处理呢？

答案显然是有的。

首先，配置http服务程序监听8080端口或者让https服务监听8443端口，配置ssh服务程序监听22端口。具体不再赘述，如果这都不懂就不用往下看了，因为肯定会搞不定的。

然后，安装一个叫haproxy的强大工具。步骤如下。

下载源代码：

wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.16.tar.gz

查看当前内核版本：

uname -r

然后进入目录编译安装：

cd haproxy-1.4.16

make TARGET=linux26 PREFIX=/usr/local/blog.creke.net/haproxy

make install PREFIX=/usr/local/blog.creke.net/haproxy

其中，第二行的“TARGET”参数要和内核版本一致。第二、三行的“PREFIX”是安装位置。

最后，配置haproxy。

如果要监听80端口，检测到http协议就转发给8080端口使用HTTP，否则转发给22端口使用ssh。配置如下：

#By http://blog.creke.net/

global
    maxconn 5120
    chroot /usr/local/blog.creke.net/haproxy
    daemon
    quiet
    nbproc 2
    pidfile /usr/local/blog.creke.net/haproxy/haproxy.pid

defaults
    timeout connect 5s
    timeout client 50s
    timeout server 20s

listen http
    bind :80
    timeout client 1h
    tcp-request inspect-delay 2s
    acl is_http req_proto_http
    tcp-request content accept if is_http
    server server-http :8080
    use_backend ssh if !is_http

backend ssh
    mode tcp
    timeout server 1h
    server server-ssh :22

如果还有监听443端口，检测到https协议就转发到8443端口使用HTTPS，否则转发给22端口使用ssh。则配置如下：

global
    maxconn 5120
    chroot /usr/local/blog.creke.net/haproxy
    daemon
    quiet
    nbproc 2
    pidfile /usr/local/blog.creke.net/haproxy/haproxy.pid

defaults
    timeout connect 5s
    timeout client 50s
    timeout server 20s

listen https
    bind :443
    timeout client 1h
    tcp-request inspect-delay 2s
    acl is_ssl req_ssl_ver 2:3.1
    tcp-request content accept if is_ssl
    server server-https :8443
    use_backend ssh if !is_ssl

backend ssh
    mode tcp
    timeout server 1h
    server server-ssh :22

把内容保存为“/usr/local/blog.creke.net/haproxy/etc/haproxy.conf”，执行命令：

/usr/local/blog.creke.net/haproxy/sbin/haproxy -f /usr/local/blog.creke.net/haproxy/etc/haproxy.conf

即可运行。

好了，大家应该可以举一反三，起码也可以依葫芦画瓢吧。

参考文章：

https://dgl.cx/2010/01/haproxy-ssh-and-ssl-on-same-port

http://haproxy.1wt.eu/download/1.4/doc/configuration.txt

数字签名是什么？

2011-08-09T12:24:03Z

今天，我读到一篇好文章。

它用图片通俗易懂地解释了，"数字签名"（digital signature）和"数字证书"（digital certificate）到底是什么。

我对这些问题的理解，一直是模模糊糊的，很多细节搞不清楚。读完这篇文章后，发现思路一下子就理清了。为了加深记忆，我把文字和图片都翻译出来了。

文中涉及的密码学基本知识，可以参见我以前的笔记。

====================================================

数字签名是什么？

作者：David Youd

翻译：阮一峰

原文网址：http://www.youdzone.com/signature.html

鲍勃有两把钥匙，一把是公钥，另一把是私钥。

鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。

苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。

鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。

鲍勃给苏珊回信，决定采用"数字签名"。他写完后先用Hash函数，生成信件的摘要（digest）。

然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。

鲍勃将这个签名，附在信件下面，一起发给苏珊。

苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。

苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。

10.

复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。

11.

后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。

12.

鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。

13.

苏珊收信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。

14.

下面，我们看一个应用"数字证书"的实例：https协议。这个协议主要用于网页加密。

15.

首先，客户端向服务器发出加密请求。

16.

服务器用自己的私钥加密网页以后，连同本身的数字证书，一起发送给客户端。

17.

客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。

18.

如果数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告。

19.

如果这张数字证书不是由受信任的机构颁发的，浏览器会发出另一种警告。

20.

如果数字证书是可靠的，客户端就可以使用证书中的服务器公钥，对信息进行加密，然后与服务器交换加密信息。

（完）

文档信息

版权声明：自由转载-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0
原文网址：http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
最后修改时间：2011年8月23日 00:35
付费支持（说明）： |

新浪，你个阴险、卑鄙、低劣、没品、无耻、下流、混帐、小人、肮脏、不堪、怯懦的网站

2011-08-02T09:55:46Z

Shared by zhiwei
在骂新浪微博的时候也肯定了新浪微博的价值。一个产品不可能讨好所有人，只要满足大部分的需要就行了。我个人觉得，麦田在这件事中有点自以为是，还是那句话，要享受言论自由就要接受言论自由带来的负面影响。

确切地说，是新浪微博。不过，到底新浪微博尚未独立上市，新浪还借着新浪微博股价一路飙升，所以，还是得骂新浪。

这件事的起因大概是这样的：

动车特大事故，罗玉凤在微博上写了好几段被麦田称之为“反人类”的话，大意就是这些人死得其所云云。麦田深表愤慨，发起了一个要求新浪微博封杀罗玉凤的活动，并说如果新浪微博不封杀罗玉凤，他就退出新浪微博。不过，新浪微博并没有封杀罗玉凤（她那几条反人类的微博倒是没了），麦田就开始自删过往微博，表示他退出了。

麦田最后留下了一条微博（http://weibo.com/1406355875/xh09k0A01），我转帖图如下：

这条微博，很诡异的，在被转发1000多次后，被禁止转发了。

对于麦田要求封杀罗玉凤这档子事，我基本持中立倾向。麦田有麦田的理由，因为不是什么话都可以“言论自由”的，但罗玉凤那几条微博不见了，也许是新浪微博站方去删除的，这个事本来就到此为止了。麦田兑现诺言，自删微博退出，这是他个人的事，我深表敬佩之余，也学不来。但是，新浪微博禁止转发麦田这条微博，我着实怒了。

我对新浪过去的一些自我审查行为，向来是很理解很体谅的，中国媒介生态自有所谓的“中国特色”。但这条微博，怎么看都没有犯到什么有司忌讳，只能说：新浪微博运营者为了某些纯属商业利益的目的，偷偷摸摸地干了这么个事。

在微博内容管控上，新浪是很有些中国式微创新的。什么删除微博或删除微博帐号，那是小儿科。因为这会让用户马上感知到。为了所谓“用户体验”，新浪微博捣鼓出一点让普通用户毫无察觉的勾当。我试举例如下：

其一、不可搜。

某个关键词什么搜索记录都没有，这个十分“昭然天下”，谁都看得见。但偷偷摸摸把一些微博从搜索记录去除，就不是所有人都看得见的。有些微博帐号是不可搜状态。

其二、仅自己可见

你发了条微博，在你处于登录的状态下，你就一直看得到这条微博。但事实上，这条微博的状态被设置为“仅自己可见”，也就是说，所有人都看不见，就你看得见，你还觉得站方很大度，居然没删。下面的上图就是我处在登录的状态下看到的，而下图就是处在未登录下状态看到的（有没有发现区别？）：

其三、不可转不可评

麦田这个事件，就是标准的不可转。有些微博不可评。发微博的博主还不知道自己这条微博已经被禁止互动了。

其四、粉不上

有些微博帐号，其他用户是怎么都粉不上的。关注了也白关注，或者，当下给你关注上了，过两天，偷偷的从关注名单中被删除了。

其五、关小黑屋禁言

微博博主若干天不能登录（应该是暴力修改密码），ta的粉丝还以为ta这两天有事，没空微博呐。

其六、短链接失效

用户发微博带有超链接，会自动转为一个短链接地址。让短链接地址失效，会让点击者以为是链接地址不对。

以上种种，是我个人观察到的。虽然我所就职的交大媒体与设计学院与新浪有研究项目在合作，我也是其中一员。但我从未从新浪的任何在职员工中获知这些管控手法。这些手法，对普通用户可能起效，但对于我而言，老实讲一句，还是能琢磨出一二的。

新浪搞了这些手法（如有更多，请留言补充），我一向体谅，也不容易，被逼着搞那么多微创新。但今儿个麦田这档子事，就不可原谅了。我绝对不相信新浪来自于某些啥地方的压力，而去为罗玉凤保驾护航，却把麦田这条微博给禁止转发。这只能说明，新浪某些人，毫无底线。

有网友戏称：新浪有什么人被罗玉凤潜规则过？这个事没证据，不好乱讲。但新浪作为中国收入排名老七的数字公司，是不是也该稍许掂量掂量自己该尽的社会责任？你不封杀罗玉凤也就罢了，一个要退出贵站的用户的最后一条说明情况的微博，就这么给偷偷摸摸地禁止转发了？

如果不属实（我看主要是第三条，我也将信将疑），你可以摆证据，开新闻发布会，搞个新闻发言人出来说：你信不信？反正我不信。再不济，有种，你就索性删了嘛！

所以我说你：怯懦！很多人说新浪霸道是不对的，它压根就是个玩阴的懦夫！！

Copyleft © 2010 知识共享署名-非商业性使用-禁止演绎注意：转载勿改标题！
ItTalks -- 魏武挥的Blog (digitalfingerprint:fc4f8fc31f70097eea4b780b13146415)

欢迎浏览我收集的信息图关注我的微博访问我的分享

无觅猜您也喜欢：
背水一战的新浪	新浪微博之重	新浪的新闻	新浪微博：尚未到能独立飞翔之日
无觅

与本日志可能相关的文章有：

新浪，你个阴险、卑鄙、低劣、没品、无耻、下流、混帐、小人、肮脏、不堪、怯懦的网站

2011-08-02T09:55:44Z

Shared by zhiwei
在骂新浪微博的时候也肯定了新浪微博的价值。一个产品不可能讨好所有人，只要满足大部分的需要就行了。我个人觉得，麦田在这件事中有点自以为是，还是那句话，要享受言论自由就要接受言论自由带来的负面影响。

确切地说，是新浪微博。不过，到底新浪微博尚未独立上市，新浪还借着新浪微博股价一路飙升，所以，还是得骂新浪。

这件事的起因大概是这样的：

麦田最后留下了一条微博（http://weibo.com/1406355875/xh09k0A01），我转帖图如下：

这条微博，很诡异的，在被转发1000多次后，被禁止转发了。

其一、不可搜。

其二、仅自己可见

其三、不可转不可评

麦田这个事件，就是标准的不可转。有些微博不可评。发微博的博主还不知道自己这条微博已经被禁止互动了。

其四、粉不上

有些微博帐号，其他用户是怎么都粉不上的。关注了也白关注，或者，当下给你关注上了，过两天，偷偷的从关注名单中被删除了。

其五、关小黑屋禁言

微博博主若干天不能登录（应该是暴力修改密码），ta的粉丝还以为ta这两天有事，没空微博呐。

其六、短链接失效

用户发微博带有超链接，会自动转为一个短链接地址。让短链接地址失效，会让点击者以为是链接地址不对。

所以我说你：怯懦！很多人说新浪霸道是不对的，它压根就是个玩阴的懦夫！！

无觅猜您也喜欢：
背水一战的新浪	新浪微博之重	新浪的新闻	新浪微博：尚未到能独立飞翔之日
无觅

与本日志可能相关的文章有：

理解Linux系统负荷

2011-07-30T17:19:31Z

一、查看系统负荷

如果你的电脑很慢，你或许想查看一下，它的工作量是否太大了。

在Linux系统中，我们一般使用uptime命令查看（w命令和top命令也行）。（另外，它们在苹果公司的Mac电脑上也适用。）

你在终端窗口键入uptime，系统会返回一行信息。

这行信息的后半部分，显示"load average"，它的意思是"系统的平均负荷"，里面有三个数字，我们可以从中判断系统负荷是大还是小。

为什么会有三个数字呢？你从手册中查到，它们的意思分别是1分钟、5分钟、15分钟内系统的平均负荷。

如果你继续看手册，它还会告诉你，当CPU完全空闲的时候，平均负荷为0；当CPU工作量饱和的时候，平均负荷为1。

那么很显然，"load average"的值越低，比如等于0.2或0.3，就说明电脑的工作量越小，系统负荷比较轻。

但是，什么时候能看出系统负荷比较重呢？等于1的时候，还是等于0.5或等于1.5的时候？如果1分钟、5分钟、15分钟三个值不一样，怎么办？

二、一个类比

判断系统负荷是否过重，必须理解load average的真正含义。下面，我根据"Understanding Linux CPU Load"这篇文章，尝试用最通俗的语言，解释这个问题。

首先，假设最简单的情况，你的电脑只有一个CPU，所有的运算都必须由这个CPU来完成。

那么，我们不妨把这个CPU想象成一座大桥，桥上只有一根车道，所有车辆都必须从这根车道上通过。（很显然，这座桥只能单向通行。）

系统负荷为0，意味着大桥上一辆车也没有。

系统负荷为0.5，意味着大桥一半的路段有车。

系统负荷为1.0，意味着大桥的所有路段都有车，也就是说大桥已经"满"了。但是必须注意的是，直到此时大桥还是能顺畅通行的。

系统负荷为1.7，意味着车辆太多了，大桥已经被占满了（100%），后面等着上桥的车辆为桥面车辆的70%。以此类推，系统负荷2.0，意味着等待上桥的车辆与桥面的车辆一样多；系统负荷3.0，意味着等待上桥的车辆是桥面车辆的2倍。总之，当系统负荷大于1，后面的车辆就必须等待了；系统负荷越大，过桥就必须等得越久。

CPU的系统负荷，基本上等同于上面的类比。大桥的通行能力，就是CPU的最大工作量；桥梁上的车辆，就是一个个等待CPU处理的进程（process）。

如果CPU每分钟最多处理100个进程，那么系统负荷0.2，意味着CPU在这1分钟里只处理20个进程；系统负荷1.0，意味着CPU在这1分钟里正好处理100个进程；系统负荷1.7，意味着除了CPU正在处理的100个进程以外，还有70个进程正排队等着CPU处理。

为了电脑顺畅运行，系统负荷最好不要超过1.0，这样就没有进程需要等待了，所有进程都能第一时间得到处理。很显然，1.0是一个关键值，超过这个值，系统就不在最佳状态了，你要动手干预了。

三、系统负荷的经验法则

1.0是系统负荷的理想值吗？

不一定，系统管理员往往会留一点余地，当这个值达到0.7，就应当引起注意了。经验法则是这样的：

当系统负荷持续大于0.7，你必须开始调查了，问题出在哪里，防止情况恶化。

当系统负荷持续大于1.0，你必须动手寻找解决办法，把这个值降下来。

当系统负荷达到5.0，就表明你的系统有很严重的问题，长时间没有响应，或者接近死机了。你不应该让系统达到这个值。

四、多处理器

上面，我们假设你的电脑只有1个CPU。如果你的电脑装了2个CPU，会发生什么情况呢？

2个CPU，意味着电脑的处理能力翻了一倍，能够同时处理的进程数量也翻了一倍。

还是用大桥来类比，两个CPU就意味着大桥有两根车道了，通车能力翻倍了。

所以，2个CPU表明系统负荷可以达到2.0，此时每个CPU都达到100%的工作量。推广开来，n个CPU的电脑，可接受的系统负荷最大为n.0。

五、多核处理器

芯片厂商往往在一个CPU内部，包含多个CPU核心，这被称为多核CPU。

在系统负荷方面，多核CPU与多CPU效果类似，所以考虑系统负荷的时候，必须考虑这台电脑有几个CPU、每个CPU有几个核心。然后，把系统负荷除以总的核心数，只要每个核心的负荷不超过1.0，就表明电脑正常运行。

怎么知道电脑有多少个CPU核心呢？

"cat /proc/cpuinfo"命令，可以查看CPU信息。"grep -c 'model name' /proc/cpuinfo"命令，直接返回CPU的总核心数。

六、最佳观察时长

最后一个问题，"load average"一共返回三个平均值----1分钟系统负荷、5分钟系统负荷，15分钟系统负荷，----应该参考哪个值？

如果只有1分钟的系统负荷大于1.0，其他两个时间段都小于1.0，这表明只是暂时现象，问题不大。

如果15分钟内，平均系统负荷大于1.0（调整CPU核心数之后），表明问题持续存在，不是暂时现象。所以，你应该主要观察"15分钟系统负荷"，将它作为电脑正常运行的指标。

==========================================

[参考文献]

1. Understanding Linux CPU Load

2. Wikipedia - Load (computing)

（完）

文档信息

版权声明：自由转载-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0
原文网址：http://www.ruanyifeng.com/blog/2011/07/linux_load_average_explained.html
最后修改时间：2011年8月10日 09:12
付费支持（说明）： |

InfoQ: Google Code Gets Git

2011-07-16T11:40:53Z

Today, Google Code flipped the switch on supporting Git repositories. Previously, Google Code only supported Subversion and Mercurial repositories, citing an investigation dating back to 2008.

With the meteoric rise of GitHub and the number of projects using GitHub storage with Google Code issue trackers, combined with the fact that the Eclipse Labs hosting has by and large been replaced with a bidirectional sync with GitHub, as well as the on-going Juno Git migration, Google Code was in danger of being sidelined for non-Git repositories. A Support FAQ is available, clarifying that the "smart http" protocol is required (with a base Git version of 1.6.6 required). In addition, the Eclipse Labs has gained Git support as well.

Partially, the Mercurial bias was due to Google's existing Python infrastructure, and the fact that it could map to the GFS back end in a simpler fashion than Git. However, with the release of Eclipse Indigo and the inclusion of JGit 1.0, it became possible for Google to integrate their back-end with a more up-to-date front end. Having said that, several other bindings exist for Git, such as the more open libgit2, which itself has spawned several language forks such as pygit2, which brings Git interoperability into the Python language.

Google doesn't say exactly what the implementation back-end is using, but the front-end effect is immediate; if you have an existing Google Code project, you can create a Git repository. The same is still true for new projects, which get a choice which repository you want to use.

It's unlikely that support for either Mercurial or Git will be dropped from Google Code in the future, but the days of SVN are likely to be numbered. The only major player whose future is bet on Hg is Bitbucket, who were acquired by Atlassian less than a year ago. The only significant player still using Mercurial is the OpenJDK forest at hg.java.net which is the development ecosystem that Sun initially set up.

Whatever the implementation or reasons behind it, Google Code's availability of Git repositories is only likely to swing the balance towards Git as the de-facto repository of choice for new and existing open-source projects.

数学常数e的含义

2011-07-09T04:15:54Z

e是一个重要的常数，但是我一直不知道，它的真正含义是什么。

它不像π。大家都知道，π代表了圆的周长与直径之比3.14159，可是如果我问你，e代表了什么。你能回答吗？

维基百科说：

"e是自然对数的底数。"

但是，你去看"自然对数"，得到的解释却是：

"自然对数是以e为底的对数函数，e是一个无理数，约等于2.718281828。"

这就构成了循环定义，完全没有说e是什么。数学家选择这样一个无理数作为底数，还号称这种对数很"自然"，这难道不是很奇怪的事情吗？

昨天我读到一篇好文章，它把这个问题解释得非常清楚，而且一看就懂。

它说，什么是e？简单说，e就是增长的极限。

下面就是它的解释。

假定有一种单细胞生物，它每过24小时分裂一次。

那么很显然，这种生物的数量，每天都会翻一倍。今天是1个，明天就是2个，后天就是4个。我们可以写出一个增长数量的公式：

上式中的x就表示天数。这种生物在x天的总数，就是2的x次方。这个式子可以被改成下面这样：

其中，1表示原有数量，100%表示单位时间内的增长率。

我们继续假定：每过12个小时，也就是分裂进行到一半的时候，新产生的那半个细胞已经可以再次分裂了。

因此，一天24个小时可以分成两个阶段，每一个阶段都在前一个阶段的基础上增长50%。

当这一天结束的时候，我们一共得到了2.25个细胞。其中，1个是原有的，1个是新生的，另外的0.25个是新生细胞分裂到一半的。

如果我们继续修改假设，这种细胞每过8小时就具备独立分裂的能力，也就是将1天分成3个阶段。

那么，最后我们就可以得到大约2.37个细胞。

很自然地，如果我们进一步设想，这种分裂是连续不断进行的，新生细胞每分每秒都具备继续分裂的能力，那么一天最多可以得到多少个细胞呢？

当n趋向无限时，这个式子的极值等于2.718281828...。

因此，当增长率为100%保持不变时，我们在单位时间内最多只能得到2.71828个细胞。数学家把这个数就称为e，它的含义是单位时间内，持续的翻倍增长所能达到的极限值。

这个值是自然增长的极限，因此以e为底的对数，就叫做自然对数。

有了这个值以后，计算银行的复利就非常容易。

假定有一家银行，每年的复利是100%，请问存入100元，一年后可以拿多少钱？

回答就是271.828元，等于100个e。

但是，实际生活中，银行的利息没有这么高，如果利息率只有5%，那么100元存一年可以拿到多少钱呢？

为了便于思考，我们取n等于50：

我们知道，在100%利息率的情况下，n=1000所得到的值非常接近e：

因此，5%利息率就相当于e的20分之一次方：

20分之一正好等于5%的利率率，所以我们可以把公式改写成：

上式的rate就代表增长率。这说明e可以用于任何增长率的计算，前提是它必须是持续不断的复合式增长。

再考虑时间因素，如果把钱在银行里存2年，可以得到多少钱？

在时间t的情况下，通用公式就是：

上式就是计算增长量的万能公式，可以适用于任何时间、任何增长率。

回到上面的例子，如果银行的利息率是5%的复利，请问100元存款翻倍需要多少时间？

计算结果是13.86年：

上式最后一个等号，表明用72除以增长率，可以得到翻倍的大致时间，这就是72法则的来源。

（完）

文档信息

版权声明：自由转载-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0
原文网址：http://www.ruanyifeng.com/blog/2011/07/mathematical_constant_e.html
最后修改时间：2011年7月27日 15:33
付费支持（说明）： |

蛤蟆身体欠佳，回顾几个瞬间

2011-07-06T03:11:12Z

苹果日报报道，海外中文网站引述北京消息人士透露，中共前总书记江泽民近期因大面积心肌梗塞，须入院救治，目前要靠呼吸机维持生命。有关消息在内地微博广传，引发不少人关注江的健康。新浪微博昨又有人贴文，引述知情人士消息指：已出京领导（部级以上），已被通知全部缩短行程，赶回京城，其馀人等留京待命。

以上不知真假，不过作为在少先队旗下宣过誓的人，也是有必要回顾一下江总人生中的一些精彩镜头。
【1】

【2】

【3】

【4】

【5】

【6】

【7】

【8】

【9】

【10】

【11】

【12】最后来一张一寸免冠黑白遗像，先帝永垂不朽

昨晚在新浪上发了这些瞬间，反响不错，可惜马上遭遇删除，哥账号又被审核一周。

【外刊IT评论】代码的缩进和嵌套

2011-05-31T16:52:35Z

本文是从 Code Indentation and Nesting 这篇文章翻译而来。

Ash Furrow在关于避免不必要的代码缩进问题上这样说：

自从第一年一个睿智的高年级的学生向我展示了如何在代码里避免不必要的缩进后，我一直都保持着这种做法。我并不去纠正已有的代码，因为这并不能改善程序的性能，我只是在些新的程序里避免不必要的空格缩进。

我还有另外一个很相似的习惯，但并不是关于缩进的，而是关于避免嵌套。乍一看，这两个问题很相似(连视觉上都有缩进的表现)。但核心问题不一样，前者是关于程序书写问题的，后者是语义上的。

避免嵌套这种编写风格最大的好处是bailing early。跟深层次的嵌套你的语句(这样会同时导致你深度的缩进)的做法相反，简化你的语句，把你的程序设计成最终要执行的语句尽可能的少，简单的越容易让人理解越好。观察一下下面的例子：


        - (void)doSomethingWithString:(NSString *)s {
            if (nil != s) {
                if ([s length] > 0) {
                    NSLog(@"%@", s);
                }
            }
        }

        // 相对于
        - (void)doSomethingWithString:(NSString *)s {
            if (nil == s)
                return;

            if (![s length])
                return;

            NSLog(@"%@", s);
        }

细心的读者可能会注意到一些问题：

我的第二个例子实际比第一个要长。
第二个例子更可读。想象一下如果在主方法执行前你有5个判断条件要检查，你嵌套出来的语句将会有多么的可怕？
这个组合的nil 和 length 检查在这个特殊的例子中是没必要的(因为返回nil这样的消息时，nil的值是0x0，等于0，对于空字符或 nil 调用[s length]都返回0)。这是专门这样做的，为了说明问题。

当然，这种特别的”bailing early”的风格在处理内存管理上会有一些其他方面的问题。如果你使用这种风格，某些时候你必须做一些额外的操作。也就是你有时候会过于频繁的使用内存自动释放(autorelease)，或你需要在程序的多个地方使用重复的释放代码来避免对象分配泄漏。在真实工作中这种情况很少见，但我想你还是要把这点记在心里。

本文原始地址：代码的缩进和嵌套

人人网的衰落是必然的

2011-05-30T10:54:39Z

Shared by zhiwei
人人网将要完蛋，不喜欢人人网的风格。界面丑陋，杂乱无序。

刚读了点点网创始人许朝军的blog：关于点点网被人人网封杀有感而发。

最近开发一个iPhone app，集成了人人网和新浪微博的api，发现人人网的意识还处于封建农奴时代

新浪的开放平台，那是真正的开放，首先有完善的多平台代码，包括iOS下的代码，其次任何人都可以申请api获得所有权限，包括获取微博，发布微博等。

而人人网的开放就纯属扯蛋了，iOS下的api两个礼拜前才出来，而且bug超多，最牛逼的是，人人网把api分为两类，一类是基础api，一类是高级api，所谓高级api，只不过是读取状态，读取照片，发布状态之类的通用api而已，截图：http://d.pr/wake

这些api在任何网站都属于普通api，怎么到了人人那里就成高级api了？好吧，你一定要说高级，我也认了，我认真的填了表格去申请所谓的高级api，申请了10个常用的api接口。

结果我的申请被拒绝了4次。

第一次的理由是：“你申请的高级api太多了，用几个就申请几个，此外，每个api是如何使用的，都需要发详细的截图说明”，也就意味着，一共有20多个高级api，我每次都需要单独去申请，一共需要画20多张图去解释每个接口的用法。ok，我认了，我先把10个api缩减到了2个，然后噼里啪啦画了产品图去说明，还被迫泄露了公司的商业机密

结果还是被拒了，拒绝理由是“人人网不接受pdf格式文档，只支持word”，我靠，真是惊天地泣鬼神啊，居然有一个上市的互联网公司只支持word文档，拒绝国际通行的pdf文档。

好吧，我继续忍，于是我在Mac下安装了office for mac，噼哩叭啦的搞了一个word文档发过去，结果又被拒了，理由是：“抱歉，你的word文档打开后看不到图片”；哦麦嘎，我家小狗都知道word存在平台兼容性问题，为何还非要坚持用word呢？

于是我把图片都存到了网上，然后在word文档插入图片网址，这回全部是文字，总没兼容性问题了吧？结果还是被拒了，理由是：“抱歉，图片必须插入word文档里，不能用网址代替”。

这就是可爱的人人网，给我上个月的生活带来了无限惊喜。

我奇怪的是，既然你根本就不想开放，干吗搞什么开放平台呢？装逼不成反被骂，很爽么?

如今我已经全线迁移到新浪微博。与人人网诸君共勉。

运维的CAP原则

2011-05-28T07:23:42Z

小站上的文章大多以实际操作为主，这次就介绍点理论吧。

曾经跟几个同行聊起了数据库这边的容错方案，有朋友发过类似的牢骚：“网站（或者数据库）做了负载均衡，可用性提高了，单点故障也不怕了，但数据的同步总是慢半拍，无法适用某些应用。如果要求完全解决一一致性的麻烦，就只能到回去。”

程序开发上始终念念不忘的有个“摩尔定律”，归根结底的就是说不要放太多精力去隄防运算速度达不到的问题。在运维以及底层架构涉及上有着同样重要的定律“CAP”，最早由加州大学伯克利分校（又是他）的Eric A. Brewer教授提出的。所有的分布式系统的好坏主要有3个重要的指标来衡量：

一致性（Consistency）
可用性（Availibility）
容错性、鲁棒性原文翻译是“分区容错”（Partition tolerance）

任何一个分布式系统只能同时满足3个条件中的两个，无法同时达到3者兼备。

就拿磁盘RAID来说：

RAID0的情况是数据分散在多块硬盘之上，只存一份。由于只有一份数据，不存在数据不同步的情况，一致性得到保障。多磁盘分散IO，性能提升，可用性提升。多块磁盘拼凑一份数据，磁盘损坏的概率正比上升，同时增加磁盘的难度提升，容错性下降。即为了C和A，放弃了P。

RAID1的情况是数据在每个磁盘上做一个备份。由于有多个备份，可能出现多个磁盘上数据不统一的情况，一致性下降。多磁盘分散IO，性能提升，可用性上升。很容易增加备份磁盘，多个备份，磁盘损坏概率反比下降，鲁棒性上升。即为了A和P，放弃了C。

RAID5的情况是一份数据分散在多块硬盘上，另外保存一份校验数据以方便恢复。数据只有一份，不存在一致性的问题。数据读写的同时可能会需要生成校验数据，影响速度，可用性下降。任何一块磁盘的损坏都可以通过剩余的磁盘中的数据和校验数据恢复，鲁棒性上升。即为了C和P，放弃了A。

对于传统的关系数据库的要求又不得不提ACID：

原子性（Atomicity）数据和操作不可再次分隔
一致性（Consistency）操作结束后，仍可进行同样的操作
隔离性／无关性（Isolation）操作和操作不得影响
不可撤销（Durability）

“不可撤销”，“隔离性”，“原子性”都是限制鲁棒性和容错性的P，一致性本身就是C。剩余的A只能作为牺牲的指标。说得明显点就是目前尚没有什么有效的方法让一条SQL同时在多台主机上同时执行正常。跨表SQL很正常，跨数据库操作已经够变态的了，跨系统进行SQL操作而且保证数据的实时和一致几乎是不可能的。

对于传统的关系型数据库来说难度就是CAP三个之中在你需要任何一个的情况下，即便你愿意花钱去升级硬件，也必须以其他的下降作为代价。要么高可用（负载均衡），要么高安全（热备份），要么高容错（事务回滚），想要正比的升级来获取A是不可能的。

这些年大负载架构的出现带动了nosql型数据库。类似memcache，bigtable和Hbase这类的key-value也是一大亮点。相比关系型的数据库而言，新的数据模型仍然无法摆脱这个魔咒，唯一的优势在于这些架构相对灵活，可以根据需要进行CAP取舍，找出真正适合的C 、A、 P比例。

对减少HTTP请求的疑问

2011-05-19T05:51:15Z

教条

根据各种Web性能优化手册，“减少HTTP请求”这一条始终被放在显眼的位置，其中就包括著名的YSlow和Google Page Speed，两者对这一教条的解释分别是：

80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, stylesheets, scripts, Flash, etc.

YSlow表示，前端的多数时间是用在下载图片、样式表、脚本、Flash等，所以要减少HTTP请求。

RTT is the major contributing factor to latency on "fast" (broadband) connections.

Page Speed则表示，RTT（请求往返时间）是导致连接快不起来的主要原因，所以要减少，即减少HTTP的请求数。

疑惑

很少人会对这2大优化守则产生怀疑，因为它们即真理、即教条、即必须遵守之则，如有违逆，虽远必诛……

但是如果认真地去解读这2条规则，其他他们都表达了一个意思：网络上的往返越多，响应的速度就越慢。

但是他们却忽略了一个很重要的事情，那就是工作总用时多，并不代表任务完成时间也多，因为这里有一个概念，叫作并行。

试想一个任务，用一个线程跑，和用100个线程跑，哪一个总用时更少？答案其实是一个线程，因为100个线程之间有线程切换的开销、有结果join的时间、有任务分割的时间……但是从结论上来看，哪一个能更快地跑完任务？答案是多线程，这就是并行计算的理论来源。

事实上，资源的下载也是如此，如果并行的话，多个资源的下载时间不见得会小于一个资源，如下图是一个合并后的资源的下载示意：

上图用来表示一个较大的资源的下载过程，其中不同的颜色分别对应：

蓝色：TCP链接建立时间
绿色：请求头发送时间
紫色：服务器处理时间
橙色：响应头发送时间
红色：文件传输时间
灰色：文件解析执行时间

如果将这个大资源分解成3个相等的小资源的话，那么他们的下载就可能是这样的：

由于浏览器只有一个线程可以对文件进行解析和执行，因此灰色的解析部分必定是串行的，需要相互等待。

比较2张图，假设其中的每一小块的时间为t，可以发现这样一个结论：一个大资源的加载，使用了13t的时间，而将大资源分解后，虽然总共用了21t的时间，但是客户端真正等待的时间却只有9t，比合并资源的方式节约了4t。

这就是并行的效果，当然要实现这个效果，是有前提的：

并行的连接数没有超过浏览器的限制，这里假设4并行是一个比较合理地、照顾到各浏览器的值。
服务器能顶得住，不会因为并发连接过多而导致处理时间变长。
网络足够稳定，这一点将保证TCP建立、请求头发送、响应头发送这3段时间是稳定的。
浏览器的资源加载不会阻塞，如IE6-7在下载js文件时会阻塞后续资源的请求，则不可能实现并行。

缓存的考虑

合并资源有另一个好处，就是在缓存之后，只需向服务器验证一次即可。但是再和拆分资源的加载过程作一个比较，如果采用带验证的缓存，不难得出下图：

而如果使用客户端的缓存，则是以下情况：

从上面2张图中可以看到，即便在有缓存的情况下，如果满足一定的条件，可以进行并发的话，若干个小资源的加载情况下客户端的等待时间和合并为一个大资源后是相同的，并没有多余的消耗。

总结

一个最基础的结论是，加载资源总用时和客户端等待时间是2个完全不同的概念，他们之间并不存在正比的关系，而在宽带普及的当前时代，多数网络资源并不是按流量收费的，因此前端的优化应该更关注于客户端等待时间，而不是加载资源总用时和流量之上。

事实上，一个最经典的应用就是下载软件，从90年代的NetAnt开始，到其后的网际快车、迅雷，无一不具有“多线程下载”的能力。事实上多线程下载同样会因为线程的切换、文件分段的空间分配、最后多段碎片的拼接等导致总耗时更多，但也确确实实极大地缩短了下载的时间。在对页面的资源加载作优化时，是不是也可以参考一下这个模型呢？

由此，对资源的切分将会从单纯的“合并”的级别，提升到一种完全艺术的程度，综合考虑不同浏览器对资源加载的策略，最大限度利用浏览器的并行下载能力，从而正确、最优地分配静态资源域名，切分静态资源，压榨浏览器全部的能力，进一步地提升页面加载的速率。这虽然大大提高了资源管理、分解的复杂度，但是对于追求极限而言，本人认为这样才是真正的最佳实践。

最后，本文完全没有全部否定减少HTTP请求数这一优化原则的意思，只是希望从另外一个角度看问题，保持着一定的怀疑的心态来重新审视这一原则，拒绝不经过思考的无意义的遵循，从而寻找到在特定环境下，最适合、最优化的方案。

mysql主备部署笔记

2011-05-11T11:48:20Z

本文说的mysql主备是指单向、异步的数据复制。可以是一个主、多个备。
这样做的好处显而易见：有利于健壮性、速度和系统管理。备用数据库可以做为只读查询和备份的机器，减轻主用数据库的负担。

实施前提：
主用数据库的配置里至少有：

[mysqld]
log-bin=mysql-bin
server-id=1

建议主备的数据库版本一致。

我所知道的最简单的实施方式（不需要停主库，甚至不需要长时间地禁止主库写入）：

主库操作：
在主库里建一个复制用的用户：

grant replication slave on *.* TO 'replication'@'备库地址' identified by 'replication';

导出主库的数据，并记下当然日志文件和偏移：

mysqldump --master-data=2 --single-transaction -uroot -p --all-databases >dumpfile

这里是把数据以SQL的形式导出，并记下导出瞬间的日志文件和偏移(得益于--master-data=2参数)，出来的dumpfile的前面会有一行类似以下的注释信息，就是文件名和偏移值了：

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000011', MASTER_LOG_POS=1061553673;

对于这步，网络上一般采用的方法为：
FLUSH TABLES WITH READ LOCK；--先把主库设置成只读，然后导出SQL或者直接复制数据文件
SHOW MASTER STATUS; --记下日志文件和偏移
UNLOCK TABLES;  --恢复主库写入
这样，至少在复制数据的那段时间，主库是不可提供服务的。

备库操作：
复制主库的/etc/my.cnf和dumpfile。
把主库配置里的 server-id 改成2（或者3、4，多个备库保存互不相同），再加上

relay-log = slave-relay.log 
relay-log-index = slave-relay-log.index

导入数据：

 mysql <dumpfile

进入mysql命令行执行：

SLAVE STOP;
CHANGE MASTER TO
MASTER_HOST='主库地址',
MASTER_PORT=3306,
MASTER_USER='replication',
MASTER_PASSWORD='密码',
MASTER_LOG_FILE='mysql-bin.000011',
MASTER_LOG_POS=1061553673;
SLAVE START;

然后，就搞定了，可以在备库执行

SHOW PROCESSLIST;

查看同步的状态，如果此命令的输出里有两个“system user”的进程，并且Command都是“Connect”的话，就差不多OK了，此时，任何对主库的修改，都能准实时地从备库里查询出来。

参考文章：mysql官方中文手册

如何选择开源许可证？

2011-05-01T17:26:31Z

如何为代码选择开源许可证，这是一个问题。

世界上的开源许可证，大概有上百种。很少有人搞得清楚它们的区别。即使在最流行的六种----GPL、BSD、MIT、Mozilla、Apache和LGPL----之中做选择，也很复杂。

乌克兰程序员Paul Bagwell，画了一张分析图，说明应该怎么选择。这是我见过的最简单的讲解，只用两分钟，你就能搞清楚这六种许可证之间的最大区别。

下面是我制作的中文版，请点击看大图。

（完）

文档信息

版权声明：自由转载-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0
原文网址：http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html
最后修改时间：2011年5月 2日 01:27
付费支持（说明）：

为什么应该去上大学而不是去创业？

2011-04-30T04:51:39Z

最近36氪上有关创业公司泡沫和高等教育泡沫的两篇文章引发了广泛、深入的讨论。本文就是精彩讨论之一。

zhuoqun用自己的亲身经历来论证自己的观点：应该去上大学，而不是创业。如果你支持或反对他的看法，请在评论中给出理由，当然，如果你觉得一两句说不清的话，欢迎投稿。以下是正文：

这两天接连看到了36氪上的两篇文章：《Peter Thiel：我们处在一个泡沫时代，不过并不是互联网而是高等教育》和《Thiel效应：扎克伯格应该更多而且更年轻》，我个人很不以为然。美国怎么样我不是很清楚，但是我认为国内的青年更应该去上大学，而不是去创业。在开始正文之前声明一下：本文并不试图教育和说服别人，它只是表达我个人的观点，我觉得在“创业流行风潮”之外应该有另一种声音。

1. 糟糕的中学教育

我觉得自己的中学教育是极为失败的，不知道现在的中学生的情况有没有发生好转。但是既然还有高考在，想来应该没有太大的差别。在中学的那几年，我们都是在高压之下为了升学而忙碌，学习的知识都是为了考试，没有什么时间去了解教材之外的东西，每个人几乎都被没收过课外书，课堂上的那些东西的唯一作用就是让你讨厌学习。没有人去启发你自由思考，谈恋爱被叫做“早恋”，看电影的正当理由只有“作业做完了”和“学习外语”，老师和标准答案是不容质疑的权威。在这样一个教育环境下，遇到一个好老师我们都会终生不忘，有多少人高中毕业的时候会有独立的头脑、可以承担创业的责任呢？在那篇颇具煽动性的《你是海盗吗》的文章中有这么一段话：

“我不在乎你是否腰缠万贯。如果你没有创过业，没有拿你的经历、金钱、乃至婚姻去疯狂地追求过自己的事业的话，那么你就不是海盗，你不属于这个圈子。”

请注意“自己的事业”这个词。在准备做牺牲之前请确定那真的是你“自己的事业”，而不是对金钱和成功的欲望，不是“要比别人强”的自卑感。我并不根据年龄去判断别人，但是我很难相信在经历了那么多年填鸭式教育的人会明白事业是什么东西。

2. 上大学的好处

现在很多人总是一再强调“在国内上大学没用”，我怀疑这些人从来都没有真正了解过自己的母校。没错，国内的教育制度是很差劲，大学也越来越不像样子，但是大学绝对不是一无是处，那些没有从大学得到任何东西的人只能责怪自己。举个例子吧，我的母校黑龙江大学不是重点大学，在周边大学中的名声也很不好，别人都说我们学校的学生“爱玩”、“只会谈恋爱”⋯⋯但是你如果早晨6点爬起来去实验楼看一下，你会发现每一层的走廊里都站满了晨读的学生，相信那些觉得“国内的大学没用”的同学从来都没有见过那副动人的场景，没有听过那些“喧闹”的读书声。下面我说一下大学有哪些好处：

<1> 闲暇

如果你反感现在的大学教育的话，你会发现你是在大学里开始反感大学教育的。这听上去好像是一个悖论，它说明了一个事实：大学提供给你反思的时间和空间。我们受了好多年糟糕的中学教育，在大学毕业之后又会面临很大的生存压力，这就显出大学的必要性：你有四年自由的时间，或者说比较自由的时间。我们中学的时候被灌输了那么多错误的东西，被压榨地失去了学习的乐趣，那么等你到了大学之后，你有四年的时间好好反思自己，把之前学习到的错误的东西都呕吐干净，然后重新发现自己的好奇心并找回学习的乐趣。如果你没有上大学直接去创业或者去工作的话，可能会立刻忙得没时间考虑自己内心的想法，只是被很多“不得不做”的事情推着往前走。或许你以后可以成功，变得有钱和有名，但是你很难成为一个有着远见卓识的企业家（entrepreneur）。企业家不是普通的只会赚钱的商人（businessman），他会创新，会创造真正的价值，也有社会责任感。我认为只有企业家做的事情才可以称之为“自己的事业”。

“闲暇”还意味着你有足够多的时间去尝试。 Facebook 就是 Mark Zuckerberg 在大学里做的众多项目中的一个（可以看一下这个视频，第5集）， Mark 当初的想法是“等我有了新点子想去实践，就把这网站丢弃不管了”。如果他当初在创业的话，绝对不会有这种游戏的心态，也不会有 Facebook 今天的成功。所以在大学里你有足够多的时间去尝试任何你想得到的好玩的点子，管它有没有用，管它是不是有“商业价值”，反正也没有人等着你盈利，说不定你会发现某个你做的好玩的东西真的能赚钱。反观一下中国的这些创业公司，它们无一不是目标明确，一开始就想到要做大做强，最终上市或者被高价收购。这样的公司做出来的产品或许可以赚钱，但是它总是很无趣。他们只能做到“有用”，因为一开始它们就完全没有好奇心和“游戏”的心态。

从“闲暇”的角度来看，我觉得很多大学的“不负责任”反而是一件好事。我个人很喜欢最后无论怎样都会让你毕业的大学，那意味着我可以支配自己所有的时间。很多大学觉得学生太自由就设定了不少硬性规定（比如有的大学有晚自习），那样很不好。如果一个人没有足够自制力的话，家长式的管理只能延迟而不能避免他的堕落，有些事情没办法教。

<2> 图书馆

我是从小城镇出来的孩子，那里没有一家图书馆，可能大中城市的情况会有所不同。爱默生说过：“好的书籍胜过最好的大学”。我非常认同这句话，但是因为中学教育的糟糕和图书馆的缺乏，很多人在大学之前没有时间和条件去读很多书，就我个人来讲，大学四年读的书比其它任何时期都要多。大学里读书也很快乐，因为那个时候读的书真的都是自己想要读的。

如果你的大学里有个不错的图书馆的话，那么你不用怎么上课也可以学到非常多的东西。你可以把所有业余时间都用来泡图书馆，利用图书馆去了解任何你感兴趣的东西，这种没有目的的学习会让你学到更多东西，你会无意中就拾到很多珍宝。相信很多想要创业的人都对乔布斯的那个演讲印象深刻，他在演讲中说过一段话：

“要不是我当初在大学里偶然选了这么一门课，Macintosh 计算机绝不会有那么多种印刷字体或间距安排合理的字号。要不是退了学，我也不会碰巧选了那门书法课。当然，我在大学里不可能把当时的点向前延伸，连成一条线;但是现在回过头去看，那条线却无比清晰。”

如果你选择创业，那么你平时学习的东西肯定都是“创业相关”，比如商业、营销、技术等，很难想象你平时会有时间去读一些“没用”的书。你的视野会局限在某个领域，就算你想要超越也没有太多“闲暇”可以利用，那么你就没有足够的“点”去连成一条线。

<3> 青春

很多人没有上过大学也很成功，但是他们没有和大学同学一起逃过课，没有迷茫过，没有在考前熬夜复习过，没有给喜欢的姑娘写过情书或者当众表白，没有为了庆祝毕业喝酒到趴下⋯⋯可能他们早早进入了社会有了更多社会经验也更有钱，但我个人觉得这样的青春实在太荒凉了。一个人从少年直接进入成年也应该算是某种形式的拔苗助长吧，从长远来看，这样违反自然生长的方式对一个人未必就是利大于弊。

关于“创业”和“大学”就说这么多，写得很仓促，欢迎批评指正。当然，我不否认有少数人确实很早就有了创业的能力，天才的确存在。但是对于大部分国内的高中生来说，选择上大学会更好。

最后引用茨威格的一段话作为结尾：

“一个人的肌肉缺乏锻炼，以后还是可以补偿的；而智力的飞跃，即心灵中那种内在理解力则不同，它只能在形成时的决定性的那几年里进行锻炼。只有早早学会把自己的心灵大大敞开的人，以后才能够把整个世界包容在自己心中。 ”

作者新浪微博zhuoqun，作者博客：Dreamer’s Blog 配图：shaigoldman

转载请注明： “转载自@36氪”，谢谢:)

人人网站内信安全漏洞导致用户隐私泄露

2011-04-29T15:28:00Z

yangzhe1991 写道 "4月29日晚，大量人人网用户收到一个标题为《有人暗恋你哦，你想知道TA是谁么》的站内信，用户发现若打开此站内信将会自动将此站内信内容发给所有好友。通过查看站内信网页源码，发现其中有一行代码为<script src='http://qiutuan.net/2011/51.js'>。显然，一个稍微有点网站编程常识的人都知道“<>”一类标签符号在显示的时候需要转义为普通文本防止浏览器执行，但人人网的转化方式为在用户发送端转化，若绕过此机制直接发送（如此js脚本中直接post站内信内容）则文本中包含的HTML均可被正常执行…… 显然作者的意图并非只是恶作剧，通过查看连混淆都懒得做的代码，我们可以很清楚的看到其主要目的是收集用户的人人id、学校、生日、姓名、qq、msn、手机，并且通过一个伟大的功能——通讯录，还可以得到所有好友名片中的上述信息……全部信息会发送到http://qiutuan.net/2011/log.php 由于此站内信的传播之广泛，目前只知道此域名几乎是针对性的使用并且托管在美国，唯一能稍微解决此问题的方法是所有会写代码的人都写一个脚本随机生成数据去稀释被上传的数据，当然要在其收手前做完。 "

【热腾分享】腾讯云计算平台介绍

2011-04-28T00:27:33Z

腾讯做云计算不是人云亦云，也不是孤立的看待云计算本身的商业价值，而是腾讯开放共享战略的一个重要组成部分。

腾讯开放的成功，依赖于一个蓬勃发展的产业链，依赖于千千万万成功的应用。而今天，我们在中国互联网产业链中，还看不到这么多优秀的产品。这是因为打造一个成功的互联网应用很不容易。一个成功的产品要能够经得起海量用户对可用性、产品性能、运营质量、安全水平、运维能力、甚至客服等各各方面的冲击，这需要长时间的经验和积累。

早年的QQ空间用户可能经历过这样的体验：进入QQ空间后，界面上有一个小地球在不停的跳动，有时候在这个界面上需要等几个小时才能进入个人空间。这是早期QQ空间应对海量访问考验时为了避免雪崩而采取的策略，将用户引导到一个等待界面。

今天互联网用户对产品的要求比那个时候高的多，很难想象他们再像当年那样对一个优秀的应用如此包容和谅解。而应对海量的能力，绝不是一朝一夕能够形成的，QQ空间今天可以轻松的支撑起千万级的同时在线用户，是长时间技术积累的结果。

腾讯打造云计算平台，就是要把腾讯多年积累下来的海量技术和运营能力，和所有互联网行业的创业者分享，让他们少走弯路，更容易的创业成功。这种能力包括了：海量运维、海量计算、海量存储、海量数据分析、云安全、支付营销以及客服等各种能力。

在分享的同时，腾讯不希望把开发者捆绑在自己的云平台上，所以我们不会开发类似于Google的GAE这类平台。相反，腾讯希望能够用一种非常快捷、简单的方式，把这些能力分享给各种各样架构、开发语言和应用场景的互联网应用。我们希望能够去适应业界主流的开发模式，让大多数开发者可以在已经开发好的应用基础之上，不经过大的改动，就可以接入到腾讯的云计算平台。

腾讯云计算平台开始建设还不到半年，但也取得了一些阶段性的成绩：

已有108多款第三方应用跑在腾讯云计算平台上

4个月应用总安装次数超过3亿次

日活跃用户总数达到2千5百万，最高同时在线用户超过400万

有三款应用平均日登录超过千万，超过10款应用平均日登录过百万

单个游戏月度分成收入超过1000万

从产品的角度出发，腾讯云计算平台针对广大开发者推出了以下产品：

[云存储]

每款应用都有其生命周期，而Social Game的生命周期相对较短，往往数周之内迅速达到用户峰值，接着步入稳定和衰减期。在这个期间，开发者往往疲于奔命，需要在访问量不断增加时进行持续的数据层重构，需要进行频繁的机器扩容和数据迁移，在后期又要进行数据合并和资源退出。

腾讯根据数据层研发过程中的实际经验，以及应用从小到大的发展过程中遇到的各类技术问题，推出了自助化和运维透明化的海量存储服务。

从今年1月份开始，我们相继推出了基于Key/Value的全内存持久化存储方案CMEM，和兼容MySQL协议的存储方案CDB，以帮助接入腾讯社区开放平台的第三方应用应对同时在线用户数在短时间内迅猛增加时面临的访问压力。

CMEM和CDB针对不同的服务场景，开发者可以根据成本和性能来选择不同的实例。

使用CMEM和CDB，开发者无需关注数据层具体实现，通过云存储解决数据层性能、容量、安全及可用性问题，而将更多的精力聚焦于应用本身的逻辑开发和产品运营。

后续，腾讯还将提供基于不同介质的存储服务，例如对于CMEM，将会在不影响90%请求的延时的基础上，把非热点数据存放到SSD和硬盘存储介质上。

[虚拟设备]

从去年十二月始，腾讯推出了基于虚拟机的设备管理方案，除了适应开发者的各种架构需求外，也提供针对应用或流量的监控、扩容、缩容功能，并提供多种方式保护用户计算资源的安全，包括防DDOS攻击、访问控制、业务隔离等。

目前的虚拟机方案是基于Xen的，管理简单、接入便捷。该方案以多种不同配置类型的虚拟机为服务单元，用户在Web页面上即可进行计算资源的申请、使用、退还。

即将推出的基于Linux Container的虚拟机方案LXC，将提供性能更高，安全性更好的服务，并让资源管理更加精细化。

[应用安全]

一个成功的互联网应用在安全方面会面临很多挑战。如果不加以保护，外挂，恶意信息等很快会纷至沓来。

腾讯基于自身多年运营SNS应用的经验，为开发者提供的数据安全和实时数据分析服务，可解决大部分开发者在安全方面意识淡薄或经验不足的短板，对保护用户安全，提升用户体验非常重要。

腾讯云计算平台目前为开发者提供的安全服务包括：

运维安全。腾讯建立了完备的应用安全评估体系，对第三方应用进行安全评级，并提供网络攻击防护、防入侵、挂马检测、漏洞扫描等服务。

业务安全。腾讯提供OpenAPI给开发者调用，根据应用上报的数据进行实时分析，开发者可获取外挂用户信息并针对用户账号以及IP实施精准的限制策略。

信息安全，腾讯提供OpenAPI给开发者调用，以实现垃圾消息过滤，评论频率控制，以及验证码下发等功能。

[运营数据分析]

腾讯产品拥有6亿注册用户和强大的用户粘性，这些都依托于公司多年积累下来的海量数据收集和处理分析能力，以及海量运营方法。这些能力和方法，将会逐渐开放给第三方开发者。

目前开发者已经可以看到应用的一些简单的运营分析数据，开发者可以进行初步的产品挖掘，为产品优化提供决策支持。

未来，腾讯将提供一些成熟的运营分析模式，例如传播模型，用户画像，漏斗模型，营销模型等。这些工具可以让开发者可以深度挖掘产品，持续优化产品特性，提升用户体验，并通过快速高效的分析研究如何推广应用、存留用户和提升利润，让应用更好更快的发展。

[自动化运维]

腾讯为开发者提供的自助化运维平台，可以让开发者自主维护自己的应用，实施各种资源申请，应用上线、发布、版本升级、故障处理、回滚、扩容、缩容等等。这些流程的自动化可以极大的减轻开发者的运维负担。

[支付营销体系]

腾讯成熟的用户帐户体系，以及依据这个体系建立的支付营销体系，为产品的在线营销提供强有力的支持。

已经开放的腾讯支付体系让开发者可以用Q币兑换应用中的虚拟货币。同时腾讯也在推动一种让开发者可以在应用中直接使用Q币的方式。

后续，活动营销将被打包成服务，让开发者可以快捷的进行各种活动推广。

[客服系统]

腾讯一直尊崇并努力向第三方应用开发者传递“一切以用户为依归”的理念。让这个理念得以实施的，让几亿注册用户获取优质服务的，是腾讯完备的客服系统。

开发者接入这个客服系统后，不仅可以使用完备的系统工具，也可以复用腾讯积累的优秀实践，方法论，标准和规范，从而在提高服务质量、吸取用户反馈、优化产品、加强用户粘性上做出进一步的努力。

写在最后

腾讯云计算平台，意在让广大有创意有想法的应用开发者以降低的创业成本开始希望之旅；通过降低技术和运营门槛让优秀的应用不断涌现，为互联网用户提供高质量的产品；通过收入分成的共赢机制让SNS应用平台不断扩大，共生共荣。

让我们一起期待互联网产业链上百花齐放，百家争鸣，共同繁荣的局面！

腾讯云计算：

再给中国教育一个响亮的耳光

2011-04-26T01:33:23Z

Shared by zhiwei
本末倒置，现在的大学教育就是这样。

上周回学校交毕业实习报告，剩下的就只有答辩和拿毕业证书，也意味着我的学业生涯即将告终。回顾十多年接受到的教育，我只能用坑爹二字形容，虽然期间我认识了非常多优秀无比的老师和同学，但是在大的框架下，感觉到更多人还是像麻木了的机器人一样去教和学。

高中毕业的时候，我的一位老师请我吃饭向我请教如何教好她的儿子，当时我觉得挺神奇，我一个刚成年的学生，也没有多少人生经验，怎么就适合来聊这个问题了。后来我和老师说了一些，大致总结为一句话就是，千万不要让你的儿子太听话，要能够独立思考，要能辨别是非。现在，大学即将毕业，难得回学校一次，系里一些熟悉的老师纷纷找我，向我咨询他们所教授的专业课应该如何设计如何上。我的建议大体还是，花更多的时间在教会学生独立思考和学习上，培养学生这样的能力和学习习惯。

本末倒置。

我们追溯到根源，学校没有教会学生独立思考，没有告诉学生如何去学习，没有培养学生探索和钻研的精神，除了分数和文凭就没有别的可以用来衡量学生的标准，不去想更好的解决方案说一句“如果不用分数更不公平”这种推卸责任的话来糊弄愚昧无知的学生和信以为真的家长。结果就导致一届又一届天真活泼的孩子最终被打造成了形状一样的机器人产出到社会。

在这个过程中，教育部是杀手，学校是杀手，老师是杀手，家长是杀手，什么都不懂的学生就是不幸的受害者。事实上，越来越多的人能够意识到社会出了大问题，能够意识到其根源在于学生没有信仰上。看，这个时候又是在指责学生了，学生又莫名地成为了受害者。很少有人去想出问题的是不是自己，自己是不是也参与了扼杀学生创造能力和塑造自己人生的机会。

这些问题，很多有知觉的朋友都能意识到，但是光能够指出问题、骂社会远远不够，需要有能力的人身体力行。

昨天有一些正在创业的复旦的朋友与两位他们的合伙投资者找到我和我一起吃了顿晚饭，向我阐述了他们正在做的两个项目，以及一些他们的情况，然后征求我的一些意见和想法。大体上来说就是，两位有成功投资经验的投资者(CSDN与途牛网早期投资者)有着投资社会性企业的想法，于是找到了有好的想法和实践经验的复旦学生一起来做一些教育项目，这样一个教育项目不灌输知识，不培训考证，而是真正的去通过服务学生，向学生提供有价值的职业规划、学业规划的信息等服务项目，来获取可以维持自身发展的资金以及一定的盈利。

这不仅仅是一种盈利模式，我看到的更多的是解决目前中国很多荒诞问题的方法。

我们想要改变中国的教育质量，要让尽可能多的人享受到优质的教育，做到真正的国富民强。那就不能是只提概念和下放一个拍屁股想出来的政策，现在很多概念是空中楼阁。但是，空中的那个楼阁是真正存在的，需要有阶梯上去，大家眼睛都看着那楼阁，都想上去，但却没有人主动去造阶梯，最多只有羡慕身边那些父亲叫李刚的开着直升飞机来接上去的份。所以，需要有造阶梯的人，来让更多的人通向这个教育事业的空中楼阁，相同的，在国内每个行业都会自己的空中楼阁，如果有一个造阶梯的故事成功了，更多的人会不再用眼睛看，会去效仿开始建造自己行业内的阶梯来让自己和身边的朋友攀登上去。

这是我认为的解决问题的最行之有效的做法，也是一条漫长的但是必须去走的道路。

最后，我希望我的这些朋友能够成功的将这个社会性企业做好，将阶梯造好。并且，我更希望他们的公司尽早倒闭，因为在那个时候，学校与家长早就有意识与能力主动提供给学生优质的教育与人生观、价值观、世界观的培养，我的这些朋友，也一定是已经去做更有意义的事情去了。

zhiwei's shared items in Google Reader

Android应用程序需不需要手动退出？

返回键：

支付宝为苹果与Linux用户提供无控件支付方案

让一个端口同时做两件事：http/https和ssh

数字签名是什么？

文档信息

新浪，你个阴险、卑鄙、低劣、没品、无耻、下流、混帐、小人、肮脏、不堪、怯懦的网站

与本日志可能相关的文章有：

新浪，你个阴险、卑鄙、低劣、没品、无耻、下流、混帐、小人、肮脏、不堪、怯懦的网站

与本日志可能相关的文章有：

理解Linux系统负荷

文档信息

InfoQ: Google Code Gets Git

数学常数e的含义

文档信息

蛤蟆身体欠佳，回顾几个瞬间

相关日志

【外刊IT评论】代码的缩进和嵌套

人人网的衰落是必然的

运维的CAP原则

对减少HTTP请求的疑问

教条

疑惑

缓存的考虑

总结

mysql主备部署笔记

如何选择开源许可证？

文档信息

为什么应该去上大学而不是去创业？

人人网站内信安全漏洞导致用户隐私泄露

【热腾分享】腾讯云计算平台介绍

再给中国教育一个响亮的耳光