生产环境下，稳定是第一要务，没事不要升级内核，除非你有充分的理由。
技术层面的原因，前面几楼已经说的很清楚了。
redhat/centos 对内核的优化，通常比我们个人水平要高，也没必要去折腾

以前想过，感觉有点难。
算是个代理，直接跟微信官方服务器通信，把官方消息分发给不同的服务商，这里就要一个分发规则，对于使用的人来说，要做 N 多的设置，太恐怖了。
当然，可以满足一些极端情况。然而，这种功能，有多大市场呢？
没有这方面数据，不评判。

网页版满足需要的东西，尽量不装应用。

@supvesonico 为什么要在 windows 下读取这些东西呢？ windows 不就是用来玩游戏的么……
+65535

@lock522 已发，谢谢

刚才登录了一下，“帐号已经被禁用，请联系客服”，不知道啥节奏。。。

这是灌水的节奏啊。。。
两年前， upyun 的人来联系我说免费用 cdn 产品，“没有存储空间以及使用流量的限制”，博客太小，当时国外 vps 速度还是很快的，所以就没有用。

文件名加个后缀，如
diskext.exe 改成 diskext.exe.txt 然后再压缩

gitolite 不要后台服务，严重推荐

gitolite ，很简单，值得试用。
多搞几个托管，有主有副，反正多个源之间也不会错乱

github 可以直接上，其它用 shadowsocks ， linode 日本服务器，丢包还是很高。
btw ， github 上 ss 项目清空了。。。。。

@julyclyde 依赖包确实不在编译目录下，每个依赖包都得独立 make install 。所以这个方法并不轻松，只不过少了编译等待过程。
在大批量的安装的情况下，最好还是借助包机制，如使用 rpmbuild 生成 rpm 包 @sbmzhcn

表述方式更正*（或不做 rpm 或 deb 打包也行，把编译后的大文件夹整体打成 tar 包，传到目标机器的同目录下解压， make install ）

正式环境下，严重不推荐用集成安装包，想自由控制，源码编译，想简单，使用现成的 rpm, deb 包。
epel 源里有 nginx ，可以直接用。

如果你要在 N 台机器上装，或者目标机器性能差或其它原因，还可以在性能好的机器上编译，自己打包 rpm 或 deb ，传到目标机器上安装。（或不打包也行，把编译后的大文件夹整体打包，传到目标机器的同目录下， make install ）

甚至还可以玩交叉编译，不过 web 类软件通常没这个必要。

windows server 都 2014 了

这内容还要注册登录，开放一点不好吗？ 这得挡掉多用读者啊
btw ，我这里打开速度还不错，上海电信。