什么是VimIM呢，全名就是Vim Input Method，即Vim下的输入法，也许你已经习惯了Vim的插件能提供很多难以想像的功能，但却从来没有想到可以提供一个输入法，但是你不用怀疑，这是真的，并且这是一个强大的插件，只要你的Vim能显示中文，那么使用这个输入法就没有任何问题。

号外：要是vim不能显示中文怎么办呢，提供一个方法，重新编译vim，加上--multi_byte --iconv选项就行了，当然这个前提是你的系统支持中文，系统中文没有配好请参阅相关发行版的wiki。要是系统能显示，请加入下列行到vim配置文件（$HOME/.vimrc)

set enc=utf-8
set tenc=utf-8
set fenc=utf-8
set fencs=utf-8,usc-bom

这个插件继承了Unix的哲学，Keep it simple。使用非常简单，只要把两个文本文件拷到插件目录下就可用了（一般是$HOME/.vim/plugin)，这就安装好了，就是一个vim的script，天生跨平台（Windows, Mac, Linux），一个词库文件，词库文件就是自己的输入法（拼音，五笔，四角，音形，DIY），所以只要有vim的地方都能用，两个文本文件构成了一个输入法，简单又强大。

输入法主脚本下载：http://vim.sourceforge.net/scripts/script.php?script_id=2506

词库下载：http://code.google.com/p/vimim/downloads/list

无图无真相，看图

这是我使用五笔打出的效果，好了，下来说说怎么用。

它有两个模式，一个叫vim点石成金，英文字母是石，中文是金，一个快捷键，一下就点石成金。

比如要用拼音输入“我们”，就这样输入：women然后使用点石成金快捷键，CTRL＋\，一下就变中文。

上面这个适用于英文输入中偶然插入中文，它还有一个中文输入模式，就可以源源不断输入中文了，这个模式的快捷键是CTRL＋6，上面那个图就是在中文输入模式下截的。

这些就是基本的用法，当然由于它是和vim结合的，所以你可以自由的配置它，一切随心所欲。

想改变快捷键，可以啊！自己在vim的配置文件搞定 VimIM Mapping

想同时用好几个词库一起用，拼音五笔一起用，好吧!想法奇特，不过，在vim里奇迹总是可以发生的，下面就是见证奇迹的时刻：

vi 你的码表文件

:r 想要合并的码表文件1

:r 想要合并的码表文件2

……

:sort u

:wq

好了，r就是插入一个文件的内容到当前文件，因为码表文件本身就是文本，可以随意编辑，所以你插入几个都没问题，最后排一下序就行了（如果发现排序不对：VimIM 会自动帮忙排序，省您一份操心。），利用了一下vim的编辑功能，就可以把你的输入法打造的更强大。

对于一般用户来说，上面的功能足够了，但是总有愿意折腾的人，他们的需求也不可预料，不过vimIM还提供了N多的功能，像内码直接输入，比如Unicode内码输入，GBK内码输入，BIG5内码输入，四角数字输入（还有人记得这个不，当年我还有一个有这个索引的字典），还有造词，拼音智能匹配（像微软拼音那种）等，更有人工造词（这个也可以直接改码表文件，反正是文本，这就是unix设计思想的牛B之处，文本是通用的数据交流格式。）

算了，其实这些还只是冰山一角，更多功能参见主页：http://maxiangjiang.googlepages.com/vimim.html

吼吼，经过两天的努力，LFS的构建工作终于完成了。

先mark一下这个时间，2009.10.17 20:03

于是，从2009.10.15 19:00-2009.10.17 20:03  近50小时的时间，生产出来一linux。

哈哈哈，以前对编译内核是无比的恐怖，没想到这次编居然快了很多，真的不错，都说LFS就编译速度最爽了，果然不假。

介绍一下LFS：

全名是Linux From Scratch，意思是从零开始构建linux系统，整个系统中的工具都是通过现场编译出来的，是真正量身定做的操作系统，不过制作它还是需要一个可以编译程序的linux操作系统，livecd是一个很好的选择，当然正在使用的发行版也可以，不过livecd本身带好了所有的软件包，比较方便。

这个适合对linux有一定了解的人来做，适合想提高运行效率的人来做，适合想深入了解linux的人来做，想研究linux的人，建议都来做一次LFS来加深对linux的理解。

一些资源：

官方网站：http://www.linuxfromscratch.org/ 

linuxsir：手把手教你如何建立自己的Linux系统（LFS速成手册） （这个是6.3的文档，我是看这个和官方文档结合做出来的）

当前最新版本6.5，这里是官方文档：http://www.linuxfromscratch.org/lfs/view/stable/

ps：刚刚发现貌似编译的内核有点问题，有个驱动模块没有好，隔一段时间提示个错误信息。得去解决一下，然后考虑BLFS，毕竟操作系统是要用的，这个刚做好的LFS还缺很多应用呢！

自从今年寒假就想着要做一次LFS的实验，当时信心满满地下好livecd，结果寒假净看电视了，一直没有动手，现在终于下定决心搞一次了，下好了LFS6.3的livecd，因为第一次做，livecd的成功率比较高，而且包含了所有的源码包，不用再去网上下了，比较方便。工作从2009.10.15号晚上7点开始进行，这里大概记录下进程。

从硬盘分了10G出来给LFS用，分好区，挂上去，建好LFS的基地，正式开始LFS之旅。

看别人的说法都是先在虚拟机上做一次，然后有经验了再在真实机器上布署，我觉得还是真实机器效率高些，就直接划个分区给它，就在这开始了，说实话，我以前没有看过LFS的文档，但是据说文档是很详细的，只要你有一定的linux基础，能明白每条命令是干什么用的，然后就照着手册上的命令一路打下去，那也成了，是不是和windows的一路回车法有点像呢！

ps：这篇日志是在livecd自带的桌面环境的SeaMonkey中写的，这也是我在linux下的第一篇日志，而且现在机器的状态是没有windows。

好了，开始记录LFS中的一些杂碎。

2009.10.15 20:10

由于当时做符号链接时ln -sv $LFS/tools / 时少打了后面那个/，把符号链接生成在root目录里面了，导致后面用lfs用户编译时出现Permision denied。重启修改后正常进行。

由于寝室晚上要断电熄灯，故做完第一次生成工具链后就关机了。

2009.10.16

首先调整工具链，没有问题，然后编译安装各种工具，一点问题都没有，只是中间把数字1和字母l搞混过一次，不过很容易就发现错误了。

第一次遇到错误是构建目标系统（第6章）生成glibc时，test出现两个错误，以为哪里命令打错了，就重做了一遍，由于这里的make和make check时间都比较长，花了不少时间，同时也在查资料，文档说其中一个可以ignore，但是另外一个文档上只说是常见错误，没说怎么办，上网google一下，看好几篇都说可以直接ignore，只要后面工具链调整的时候没出现问题，就证明前面的都是正确的。

2009.10.17

接着昨天工作调整工具链，这是最后 一次调整工具链，然后以后编译生成的都是目标系统的组成部分，果然是good luck，没有问题，测试通过，于是开始一项项的编译utilities，好多的啊！

写这篇日志时，正在编译autoconf……

使用电脑死机是很正常的事，如果系统负载过大，那么程序不能及时响应，很容易死机的。对于个人用户来说，没什么大 不了的，我强行关机再重启就解决问题了，但是如果是在服务器上呢，且不说服务器需要全天候工作提供服务，不能停止，更重要的是数据的安全，强行关机的话未同步的数据就会丢失，这是不允许出现的情况，那要怎么办呢？

如果是在图形界面下死机的话，不要再依赖任何图形界面的工具，那样只会适得其反，可以先试试文字界面，按ctrl+alt+f2（F1－F6一般都可以），会切换到另外一个虚拟终端，需要一个账号来登入，这时键盘响应可能非常慢，但是是可以响应的，进入后打top命令看一下进程，等这个表刷那么一两次，就可以确定占用资源比较大的进程了，把它kill掉，这样可以解决相当一部分问题。

但是有的时候是比较底层的软件出现问题，那这个方法就不适用了，但是这就引出了这篇文章要说的强强的方法。reisub方法，说具体一点，是一种系统请求，直接交给内核处理。键盘上一般都有一个键，SysRq，和PrintScreen在一个键位上，这就是系统请求的键。这个方法可以在死机的情况下安全的重启计算机，数据不会丢失。

具体操作是，按住Alt+SysRq，再依次按下reisub几个键，按完b系统就会重启。

下面解释一下这个方法：其实 Sys Rq 是一种叫做系统请求的东西，按住 Alt-Print 的时候就相当于按住了 Sys Rq 键，这个时候输入的一切都会直接由 Linux 内核来处理，它可以进行许多低级操作。这个时候 reisub 中的每一个字母都是一个独立操作，他们分别表示：

unRaw 将键盘控制从 X Server 那里抢回来
tErminate 给所有进程发送 SIGTERM 信号，让他们自己解决善后
kIll 给所有进程发送 SIGKILL 信号，强制他们马上关闭
Sync 将所有数据同步至磁盘
Unmount 将所有分区挂载为只读模式
reBoot 重启

这里有个问题要注意一下，最好不要快速连续地按下这几个键，要有间隔，大概是估计每个间隔10秒左右，因为每一步操作都需要时间，而且s键之后因为同步数据比较慢，可以停20秒。

最后一个问题是怎么记住这个方法呢，当然记住了上面说的每一步操作的也可以记住，但是这里有个比较好一点的方法，那就是reisub正好是busier反着写的顺序，而busier这么好记，正好还有系统很繁忙的意思，不错。

这样的话在对付linux死机的时候又多了一个杀手锏。

更多关于sys request的内容请稳步这里。

最近做一个万年历的作业，粗粗了解了下历法，做农历的时候发现农历没有固定的算法，只能查表来计算，中华人民共和国提供了1800－2100三百年间的标准农历供使用，于是一下子限制了我的程序的查询范围。所以想着公历的准确，计算的容易，可是正想着公历算法的好呢，发现了一个问题，那就是以前公历不大完善的时候，也有问题。

比如这个，在linux下打入这个命令（windows限制时间范围是1980－2099，所以看不到这个现象）

crane@debian:~$ cal 9 1752
   September 1752
Su Mo Tu We Th Fr Sa
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

cal 9 1752就是查询1752年9月的日历，于是很跌眼镜的发现，2号后面就是14号，少了11天，怎么回事呢？

查了下资料，发现是因为历法调整的问题。

1582年2月，罗马教廷要求从1582 年10月中减去10天，因此1852 年10月4日后面紧跟着就是15日。在意大利、西班牙等国家都这样处理了。其他天主教国家也很快跟着这么做了，但是新教国家不愿意修改，而且希腊等东正教 国家直到20世纪初才修改，所以这个改革在英国及其殖民地（包括美国）在1752年9月才被执行。这样 1752 年9月2日后面跟着的就是1752 年9月14日。 这就是为什么cal会生成上面输出的原因了。

这里有个问题，上面说教廷说的是减去10天，但是刚才发现1752年9月减了11天，这是为什么呢？

这是历法转换的问题，现行公历叫格里历（Gregorian calendar），这是十六世纪的罗马教皇Gregorian XIII (格里十三世)针对当时使用的儒略历 (Julian calendar)进行修订后，于1582年10月开始实行的。所以就出现了上面的1582年10月调整10天的情况。但是由于写cal的是美国人，cal是从AT&T的Unix中出来的，前面说到过，美国跟从英国的历法是从1752年才开始改的，所以不太一样，所以还牵涉了1600－1800年的一些问题。

根本原因是因为1800年以前的闰年计算的问题，我们知道闰年是4年一闰，百年不闰，400年再闰，但是1800年以前(所以不包括1800年)没百年不闰，所以就出现了偏差，比如我们可以看一下

crane@debian:~$ cal 2 1700
   February 1700
Su Mo Tu We Th Fr Sa
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29

crane@debian:~$ cal 2 1600
   February 1600
Su Mo Tu We Th Fr Sa
                1  2
 3  4  5  6  7  8  9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29

可以清楚地看到，1600和1700年2月都是29天，一眼看去，想当然的认为多算了17天，其实实际上多算了13天，因为400，800，1200，1600是闰年，2月应该有29天。但是为什么调整的时候只少了11天呢，有个很纠结的原因，由于儒略历 (Julian calendar)公元前闰年的不规则，少算了2个闰年，从13天中去掉2天，所以在cal中看到的是少了11天。

话说回来，做万年历的时候这可是陷阱啊，得小心才是。