始终

本着 Homebrew 真香的原则，我尝试在 CentOS 上安装 Linuxbrew。至于不用 Yum 的原因，请看刚才提到的真香原则。

但随即，我就陷入到了 Glibc 的泥潭。这个泥潭是一个需要自举（bootstrap）的循环依赖；这个泥潭长这样：

• Linuxbrew 安装任何东西都依赖 curl 和 git，而且它不想用系统中自带的 curl 和 git。
• curl 和 git 都直接或间接依赖 Glibc。
• Linuxbrew 里的 Glibc 版本比较高，目前是 2.23，因此依赖高版本的 GCC（>= 4.7），以及因为 Linuxbrew 的缘故依赖 curl 和 git。
• 系统里的 GCC 版本较低，因此 Linuxbrew 安装 Glibc 失败；而通过 Linuxbrew 安装高版本的 GCC 又再次依赖 Glibc。

泥潭里有两个循环依赖：

• Glibc 和 curl 及 git 等基础工具相互依赖；
• Glibc 和 GCC 相互依赖。

早些年，第一次使用 USB 3.0 硬盘的时候，我就发现了它对 Wi-Fi 网络信号的影响。为了解决这个问题，当时投资几百块，换了 NetGear 的路由器，并启用其 5GHz 的 Wi-Fi 信号。最近，在结合 rMBP 使用无线鼠标时，我发现鼠标经常出现跳帧的现象。因为距离上一次踩坑的时间已经过去六七年的时间，一时完全没想到可能是 USB 3.0 带来的问题。在经历了一系列折腾之后，才突然想起这个坑。特此记录。

今天有同事问到 top 命令里的 running, sleep, stop, zombie 等进程状态分别是什么意思。于是借这个机会写一下 Linux 系统里的进程状态。

假设有本地 Git 仓库 A，而后在本地自 A 克隆仓库 B（即，在 B 的视角，A 是远程仓库，只不过物理位置在本机）。若从 B 向 A 推送提交，则 Git 可能会报错。这是因为，A 默认是 non-bare 的仓库，粗略理解即是工作区不为空；此时，从 B 向 A 推送的话，A 仓库中的内容可能和 A 工作区内容不一致。

众所周知，Git 相较 SVN 的一个优势在于它会将版本库的所有历史信息下载到本地，但它的背面则是：如果版本库很大，则 git clone 会消耗很长时间。使用 git svn 桥接 SVN 仓库时，如果 SVN 仓库很大（例如有超过 100,000 次修订），则 git svn fetch 会花费很长时间（可能超过 24 hours）。

如果你觉得，git svn fetch 这么多修订只是一次性的工作，因此勉强能够忍受。那我只能说，能有这种想法，还是「太年轻」。