小机制反应大思想：符号链接和硬链接

在 Unix 环境呆的越久，就越发的感受到Unix哲学的伟大，然而蕴涵在 K.I.S.S 之中的机理的的确确就是那么简单。

在我的系统里， vim 是必备的工具，它不仅仅是IDE的替代品，更是编辑小文件的瑞士军刀，真的不习惯在终端里为了什么什么而启动个gedit或kate。这么个万金油，自己从源码构建，然而折腾写些相关的 插件 定是势在必行，甚至不屑于现成的安装包。这么一来就有个小问题，比如runtime文件如何管理，在以上背景下可能存在这么几种可能：
1.多个用户同步文件，我就是有这种癖好，不同的用户做不同的事，比如私人研究、公家任务等等；
2.虚拟机里或者另外一台个人电脑上再跑个类Unix系统，恰好它也需要共享这些文件。

很显然避免每次单独修改最好的方式就是搞个“多人协同开发”的环境，比如把整个runtime塞到 版本控制 系 统中去，只要一处有更新就commit，另外几处使用时先update。当然这种情况显然是不需要动用诸如Google Code、Sourceforge这类公共服务的，你放出去就得对其他用户负责，这一些列的手续不说，光是写“User Manual”就够烦的了，所以本机上搞一个服务器。但是又确实存在自己想与别人分享的小插件，比如 Hybridevel.vim ， 它们又同时单独隶属于另一个工作目录。怎么办呢，放一起容易产生混乱，不放一起，自己用起来也麻烦，更要命的是vim插件还真不能离开vim来执行。这下 子windows用户犯愁了，一下子还真找不到个简单的方法来处理。呃，我这里是说vista之前的windows用户，不过……看吧，Those who do not understand Unix are condemned to reinvent it, poorly[ The  art of UNIX programming ]。

不用说，你一定用过符号链接和硬链接，在这个问题上， Link 可真是帮了大忙，新建一个插件项目以示这里是另一 个工作目录，内部目录的结构与原目录保持一致但是所有文件都是硬链接过来的，既满足了要求又不多占用磁盘空间。至于为什么是硬链接而不是符号链接，一般情 况“用户数据”不会跨文件系统吧？硬件接增加了实际数据的“引用计数”，而不是单纯的指向目标文件，这就使得删除其中任一个不影响另一个，是不是更接近真 实的开发？而且原有的符号链接关系也被原样复制过来，在符号链接是相对路径时好处就更明显了，俨然一个原目录的克隆，而不是虫洞！

作为“小机制反应大思想”系列文章的第一篇，本来也就想述说一下链接的便利。 不过呢最后我们还是来看一些本可以借鉴这个 设计 结构但却没有借鉴的不好的案例：
1.优秀的博客系统如Wordpress，大家都体会到了，其一篇文章可以同时属于多个分类目录。但是我们再看一看MSN Space，无端的增加了博客撰写人的负担，TA得考虑这篇文章究竟放在哪个分类目录下最方便此文的受众……于是乎最完美的解决方案竟是创建“快捷方式 ”：在其他“次要”分类下也发一篇然后给个链接指向“主分类”——当然很少有人真的这么去做……
2.CSDN的论坛，一个主题只能隶属于一个子版块，于是一些提问心切的人就会依次发到各个相关版块去，没关系，反正我是旁观者可以不在乎，只关注我看到的那个就行了。但是贴主却不得不东奔西走以争取搜集到最有价值的讨论——当然，参与的其他人也看不到另外的精彩部分……