一个运维成本高的架构一定不是好架构。
但是，个人觉得，学习配置和模块开关和语言技巧应该是属于初级阶段做的事，学习各种库和原理，实现通用模块应该是中级阶段干的事。高级阶段应该要结合已知的各种技术的原理和优劣，评价各种设计模型的好坏，开始针对实际应用作系统设计，解决系统和框架层面的问题了。而且学习系统重要的是方法和设计模型，比如 libev ， libevent 和 libuv 的设计模型都一样，没必要每个都跟进细节去，了解一个就可以了。有那个时间不如研究下 IOCP 和 epoll 和 ASIO 的异同。

@niuniugood 后来又有个新的邮件，意思大致是不管你有没选同意，都会取消照片奖励和缩减空间。不过没提推荐奖励会不会取消，应该是不会。

所以我已经买了 Office365 。

PS: 微软的 Office 商城做得渣得一腿。之前空间缩减可以领一年免费 Office365 ，然后如果买的 Office365 家庭版往上面附加订阅会失败。和 MS 技术支持折腾了 2 天最后他说无解，因为我已有的 Office365 是活动给的，不是买的。所以提醒大家如果谁的活动渠道的 Office365 是个人版，就千万别买家庭版。 Office 的渣系统不会让你绑定成功的

全键无冲突，这个要求其实很高哇。我的 HHKB 只能全功能键无冲突，字母键只能同时 6 键。
我的 cherry 便宜货是 6 键无冲突并且还分左右，一边 3 个。
虽然没用过 filco 不过估计能做到全键无冲突的应该也比较困难

如果有重载 6 个参数的构造函数的话，用::kevent 也可以强制指定用顶层的函数

Win10+Ubuntu 子系统

按照 nginx 文档的话，对 location 的匹配是先找最长的前缀，再从前往后匹配到第一个匹配式。所以只考虑如果访问 php 的性能的话，第一个和第二个是一样的。都会检查 location /。然后第一个匹配式\.php$上 break 掉。第三个少一个 location /可能快一点。

不过这一点性能消耗远不如把数据传给 php-fpm 或者 proxy_pass 的消耗高吧，关注这点性能没有意义啊。

不过没理解为什么必须全放在一个 location /里

如果要深究的话， session id 不就是 session 的 token 吗？也就是 session 自带服务端缓存而已。

如果你只提供 API ，不需要长时间的交互（类似 OAuth 那样），那就不要用 session 缓存，否则就直接用 session 呗。其实 OAuth 更多考虑的是大量客户端时候的安全问题和性能问题，所以如果没必要的话，简单最好

相当不错啊，不知道垃圾邮件过滤怎么样？因为我发现自建 mail 服务器似乎很容易收到垃圾邮件，而且 gmail 和 outlook 这方面都做得不错

首先要英语好，我看 paper 和文档的时候感觉最大的障碍就英语了。看中文翻译，即便翻译得不是特别好也是 2-3 倍的速度

基础 ok 了下面那些优先考虑的因素都是可以再细化再学的，方向性很强啊。
c++大部分也业务驱动的啊。
《 c++ primer plus 》只是本很基础的书，其他的他不都写明了么？编译原理方向，图像处理方向和并行计算方向。找 paper+读代码哇

无解啊，只要你看得到代码，再不济截屏复制图片到 onenote 然后点一下识别图中文本。就全出来了哇。
或者其他的图片识别的工具也行哇。
关键在于代码太容易识别了哇

@clino 我刚刚看了一下是有些项目用 rebase 合并 PR 的，但是自动的是没有 rebase 的。考虑到 code review 的话可能 rebase 的确会让分支看起来简单一些吧。其实比如上面我发的那个图， code review 的时候只看“与第 2 个父节点比较差异”的部分就可以了。因为“与第 1 个父节点比较差异”的内容是之前 review 过的（当然前提是如果每次 merge 都被 review 过）。不过我猜 gerrit 会强制你 rebase 可能是为了减少分支数。

@clino 按你们喜欢的方式来吧。本来这些个功能就是针对不同场景提供的。我不建议 rebase 是因为我以前也是默认开 rebase 的，但是碰到好几次一个 commit 要 rebase 好几次，而且 commit 数量稍微多一点就要我等好久，再加上碰到过好几次相同类型的冲突要解决好几次。不甚其烦，自从去掉 rebase 以后天下太平。而且如果不 rebase 首先就没有了 @leonlh 提的这个问题。只是个人建议而已。

@msg7086 我说的很多人不理解 git 工作流的理念的结果就是你说的很多人“跑来问我这货到底要怎么用”。所以我才说默认开 rebase 是妥协的结果。其他的不想浪费时间争论了，用你喜欢的方式吧，最顺手的才是最高效的。随便贴一个 github 上的项目的图吧。

http://i.imgur.com/3i6h2Lb.png

@clino 所以我的回答里已经说了，每次拉取 rebase ，和 svn 相比优势也就剩下多分支了。缺点倒是多得一坨。

所谓 git 和 svn 的先进性相比，不是因为 git 比 svn 发明得晚，也不是它是 linus 发明的。而是它的工作方式和理念能解决实际的问题，这些实际的问题里，多分支 merge 是个比重比较高的点。只是多个 remote 的话用 svn 也不是很难解决，只是麻烦一点而已。

现在，其实很多人已经习惯了 svn ，经常容易拿 svn 的模式套在 git 上，导致很难理解这些理念，并且容易误操作。我的理念是，如果这些容易产生的误操作带来的解决问题的时间已经大于用 git 替换 svn 所节省的时间。那何必用 git 。难道只是很多人说 git 先进？先进的 scm 多了去了，和 git 相近的就有 hg ，为什么不用？还有 p4 ，为什么不用？

赞同 @xAx
@msg7086 我从来没说不要 rebase ，只是说尽量少用 rebase 。 history graph 里分支多有什么关系？ github 上分支多的开源项目多了去了。你看有几个 PR 会用 rebase 的？而且特别是性能问题，只有当你碰上复杂的多端合作开发，测试完成后一次 push 要合并很多 commit ，并且里面包含资源，你才能感受到 rebase 的局限性在哪

@msg7086 @clino
最简单地就是，如果尽量要 rebase ，为什么不用 svn ？而且 svn 原生就能版本精确到文件，不像 git 得拉取整个仓库，而且 rebase 的过程还巨慢无比（特别是变更多跨版本多的时候）。
难道仅仅是为了切分支不用换目录？@leonlh 合作开发需要设置多个 remote 的话想用 git 还勉强说得过去，但是也不是非要 rebase 啊。正常的 merge 完全可以。新版的 tortoisegit 为了提高 rebase 的速度，即便你选了 rebase ，在可以的情况也是用 merge 的。

另外回答下楼主的问题：高版本的（忘了哪个版本开始有的） git 的配置里，可以设置 automerge 和 autostash

我们这里除了非程序人员不会用 git ，为了让 git 尽量表现得像 svn 才给他们开 rebase ，程序一律走正常工作流，包括对外接入的东西。只是因为很多人已经被 svn 养成了习惯，不懂 git 的概念，导致很容易错误得 merge 才 rebase 的