@cplus 其实并没有。我也在用 YCM 。但是 YCM 只有 linter 和基于语义的补全，并没有基于语义的语法高亮。

LZ 你也列出非目录何苦些这么长。 find $PWD -not -type d -exec chmod a-x {} \;就好了。

显示 not a dynamic executable 说明你的 binary 是静态链接的而已。

@yangff 实际上编译器并不总是把 switch 生成成 jump table 。

1. 你的$TERM 可能设置的有问题
2. 试一下 set-window-option -g alternate-screen on
3. tmux 1.8 这个版本也太老了，换新版本试试

很好奇 LZ 是怎么样在根下面执行 chmod 700 ＊的，难道是 root 账户？

LZ 你需要的是支持 lazy loading 的插件管理器，比如说 neobundle 。

除非 code style 上有要求，要不然这个 case 里面
if () {
throw
} else if {
}
和
if () {
throw
}
if {
}
有啥区别？不能光凭这一点就吐槽“能写出这种代码的人，还有人推崇。。。”吧。

这个键盘是要把功能键搞成 TP X1Carbon 二代那种触控的么？感觉好坑～

简单来说，第一次的时候 make 认为到处（包括 VPATH ）都找不到 main.o 和 Httpkit.o ，所以就要生成这俩。生成的时候需要 main.cpp 和 Httpkit.cpp ，而这俩正好是 VPATH 里能找到的，于是就正常编译了。 make 认为既然顺利经过了这一步， main.o 和 Httpkit.o 已经存在了，于是就不用找了。然而并没有，你修改的规则生成的是$(OBJS_DIR)/main.o 和$(OBJS_DIR)/Httpkit.o ，而不是 HttpKit 所依赖的 main.o 和 Httpkit.o 。所以就 fail 了。
第二次的时候 make 在 VPATH 找到了 main.o 和 Httpkit.o ，所以就直接用了。

Rule of Thumb ： VPATH 是适合用来找源代码的，而不适合找目标文件。

嗯，还有$(BIN_DIR)/HttpKit: $(OBJS_DIR)/main.o $(OBJS_DIR)/Httpkit.o

1. VPATH 只解决依赖文件在哪里找的问题，并不添加依赖的前缀。所以 Httpkit 依赖的是 main.o 和 Httpkit.o ，而不是$(OBJS_DIR)/main.o ，$(OBJS_DIR)/Httpkit.o 。同理 main.o 和 Httpkit.o 依赖的是 main.cpp 和 Httpkit.cpp ，而不是$(SRC_DIR)/main.cpp ，$(SRC_DIR)/Httpkit.cpp 。
2. make 的依赖处理是递归的。
第一次 make 的时候，编译这一步是在找不到./main.o 和./Httpkit.o 的时候执行的。编译的这一步理应生成./main.o 和./Httpkit.o ，而不是$(OBJS_DIR)/main.o 和$(OBJS_DIR)/Httpkit.o 。所以到链接的时候就 fail 了。
第二次 make 的时候，因为有了$(OBJS_DIR)/main.o 和$(OBJS_DIR)/Httpkit.o ，所以这个时候 VPATH 就发挥作用了。

arakashic
谢谢！

@gpw1987 超算最常用的是 Infiniband 和 10G Ethernet 。除此之外还有一些私有的网络，比如 IBM 的 3D/5D torus ， Cray 的 Gemeni 和 Aries ， K Computer 的 Tofu 。介质上一般以光纤为主，因为距离比较长（小集群除外），而且铜缆的体积也太大。

x86_64 现在最的就是 8 路 18 核的 E7 ，算上超线程也就是 288 个逻辑核。 RHEL 默认就支持这么多。至于超级计算机什么的，每个计算节点都有自己的 OS ，而每个节点的核数并不多。

看来终于被 neovim 逼出来了。不过没有 24bit color support ，看来还是继续 neovim 的节奏。

@chmlai YCM 可以在 neovim 用，和 vim 里面没有什么区别。

LZ 你要是觉得 Ctrl-a 很顺手的话，试试 Ctrl-q 没准也很顺手。

@isnowify iOS 怎么会是 based on Debian ？明明是 subset of OSX