形单只影……

昨晚发现kms很省内存，那开机内存占用一下跳到56m左右了……之前由于觉得它不太稳定而禁用了，昨晚重新启用到现在还没出现什么问题。

在很久之前就曾自己编译内核来用，但后来嫌麻烦就用回了官方的。 直到上星期不知怎么搞的，忽然惦记起这事，便在昨晚回到家后就开始弄这事，起初还是嫌麻烦打算放弃，但今天醒来后又重新振作，不断地调试来调试去，试着把用不着的东西都从设置文件中取消掉……就这样反反复复折腾了一整天……总算基本上把内核精简完毕了（减到我感觉已经不能再减了）。最终，将其（安装后的体积）从原本的86.84m减到最终的8.68m，刚好是原来的十分之一（真的很巧合），而包的大小降为3.4m，也远小于官方的22.9m。 不过嘛，从实际操作上而言与之前并没感觉有多大差别，除了开机后的内存占用比之前少了7m左右（突破了90m大关）外，好像就真的真的没有什么改变了（开机速度大致相等）。 我只能说，现在arch的内核已经优化地很好了（准确来说是一向都很好），没什么必要还是别去为这几乎感觉不到的改变而折腾一整天吧。 其实，编译内核这东西也没什么技术可言的，主要还是考耐性啊。 另外再提一下，在整个linux的源码里一共有80903行goto……说明goto还是可以用的，就看你怎么用罢了。

由于nvidia（180.22）对新内核（2.6.28）存在的兼容性问题（表现在定期的假死），只好等nvidia发布新版本的驱动，谁知一等就等到现在，导致我从上年圣诞到今天早上一直在使用版本为2.6.27.10的旧内核（相信这绝对是我用得最久的内核了）！
这还没完呢……更新后发现x居然启动失败！在把xorg.conf删除后才勉强以低分辨率进入桌面，在fx下看了一大堆英文后才知道nvidia把我的显卡列为了“古董”(legacy)，不被最新版的驱动所支持，只需把nvidia换成nvidia-173xx即可解决问题……晕死！原来我白等了它几个月……
算了，不等也等了……以后吸取教训吧……
随后，又下载了200多m的更新文件，装上了刚编译的新内核（2.6.28.7）,用clonezilla备份……
这样一来，我的系统又成了全新的……

最大的改动就是ext4终于stable了……
ext4 or jfs?
这是一个问题……

编译内核过的人，对“.config”这文件是绝对不会感到陌生的，因为对于内核的所有设置都包含在里面……
我发现无论怎么设置都好，在这文件总会有这么的一行：
CONFIG_SCSI_WAIT_SCAN=m
由于我把所有的东西都编译进了内核，这也就成了我唯一的modules（不计nvidia），总觉得很别扭……
怎样解决呢？
我通过搜索得知大概是源码文件夹下的/drivers/scsi/Kconfig的问题……
果然，里面有这么的一段：
config SCSI_WAIT_SCAN
    tristate
    default m
    depends on SCSI
    depends on MODULES
显然与其它不同的是，对于这个参数，内核并没有提供对应的选项……（原因不得而知，不过这个问题应该出现了很长时间了）
想禁用它的话就把default后面的m改为n，想将其编译进内核的话就改为y……

希望官方能早日跟进这个问题吧……

经过了一早上的不断调试，不但使用上了最新的linux-2.6.27（arch官方还没来得及更新），更重要的是把vmlinuz26文件的体积从原来的2.8M减少到现在的2.0M……
不知距离极限还有多远呢？

尽管前两天曾经宣布废弃，但对于更快速度的追求使我再次起步……

这次编译内核实现的了多方面的优化：

1.把几乎所有东西编进内核（就算如此vmlinuz26也低于3M），实现了无initrd启动（开机时间减少了大概近5秒，现在开机到桌面的时间只需20s），现在lsmod只看见nvidia模块（这东西不能编进内核）；

2.大大精简了内核（主要是去掉了大量不需要的驱动），kernel26+nvidia从近80M减少到11M左右，编译时间也从原来的一个多小时减少到了5分钟左右！

3.解决U盘的中文乱码问题……

这个国庆总算没白过了……

今天，为了寻求更快的开机速度，我决定尝试编译内核（上次尝试已经是ubuntu时代的事情）……
经过了n(n>5)多次的失败（平均每次编译需要1h（后来发现精简的话，可以减少到5分钟左右）），最终总算实现了传说中的无initrd启动，用秒表准确地计了计时，发现只比原来的内核快了不到1s……我晕！
还是用回原来的那个吧……

得出了个结论，就是arch本身已经很快了！