形单只影……

由于openoffice的体积过于庞大（足足333.30MB！），而且使用的机会也比较少，就算用了只是用来看doc……
最终还是决定将其卸载，换成只有0.49MB的antiword，用来看doc最合适不过……
在使用的过程中发现了个小小的问题，就是在默认情况下antiword生成的文本把doc中的换行都改成了硬回车，明显有点多余……
用-h看了看，发现只须在“antiword”命令后"-w 0"（-w为设置行宽，0即无限制）便可解决问题……

经过了一整天的折腾，终于把arch64弄得跟原来的arch一模一样……
连wine也装好了，内核也编译了，甚至连32位下不存在的flash问题也被我解决了……
不过，我似乎感觉不到任何性能上的提升……
而最大的感受就是有些明明在32位下可以轻易安装的flash到了64位下却显得很麻烦……其实这很大程度是adobe自身的问题……
最后总可以得出个结论了，就是64位的linux（没试过64的windows，也很有可能以后也不会去试）是“可以”一试的，因为我至今（尽管只有一天）还没碰到任何解决不了的问题，不过离“值得”一试的境界还是有点距离的……

最后，我选择了回归i686……

今天难得放假……用了一整天时间将arch重装成arch64……

决心将系统轻量化到低……
干脆把xfce4-panel也删掉，换成了更加轻量级的pypanel……
这样一来，能跟xfce扯上关系的只剩下thuanr和terminal了……

费了我近一下午的调试，总算把rxvt-unicode弄得比较顺眼……
不敢独享，设置如下（很短吧？）：
URxvt.background:black
URxvt.foreground:white
URxvt.colorBD:yellow
URxvt.colorUL:green
URxvt.scrollBar_right:true
URxvt.scrollstyle:plain
URxvt.saveLines:2700
URxvt.font:xft:Monospace:pixelsize=20:Bold,xft:ZhunYuan:pixelsize=20:Bold
URxvt.preeditType:OverTheSpot
URxvt.perl-ext-common:default,matcher
URxvt.urlLauncher:firefox
URxvt.matcher.button:1

一个会聊天的智能机器人……
地址：alicebot.blogspot.com

最强大的是：
Human: What do you think about linux?
ALICE: Linux is the world's best operating system.

用了一段时间的xfce，感觉xfce已经很完美了，就是在窗口管理方面有点不足，听说openbox在这方面比较出色，但又不想废弃已经用得得心应手的xfce，今天突发奇想，用openbox来代替xfwm的工作不就能完美地解决这问题了？

方法如下（这是在arch下的，其它的发行版同理）：
先安装openbox及其设置工具：
sudo pacman -S openbox obconf
将openbox来代替xfwm：
sudo vim /etc/xdg/xfce4-session/xfce4-session.rc
将"Client0_Command=xfwm4"，改为"Client0_Command=openbox";
重启X，你会发现这时openbox已经是默认的窗口管理器了，最后再运行obconf对openbox进行简单的设置……

大功告成！
（本文完全原创！）

见又无聊，把linux下的两主流“办公软件”（一时想不到别的词来形容……）──openoffice与abiword粗略对比了一下……

堪称linux下最强大的备份工具！

今天，经过一番努力后，终于把/的文件系统从ext3转到了reiserfs，发现在用pacman时明显比ext3要快，而且挂载速度也没有传说中那么慢（大概慢不到0.2s）……

不知是什么原因，arch的源里竟然没有xfce4-time-out-plugin这xfce的实有插件……
实在看不过眼，刚才借强大的aur将其传了上去……
注：那PKGBUILD不是我写的，不记得是从哪里得来的了……我只是原封不动地将其传了上去……

编译内核过的人，对“.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本身已经很快了！

测试了一下arch的启动速度，结果是从grub菜单上回车开始到见到桌面（这时系统已经可以使用了）结束，大概用时25s……

用自己编译的wine运行exe比在windows下还要快……

就是Linux下一般会将中国的时区简称为CST，一开始还以为是识别错误了，查了查原来这CST是China Standard Time（通常都是指Central Standard Time）……
算是个不大不小的bug吧……
更奇怪的是，当我把时区设置成Etc/GMT+8时，系统虽然显示是GMT+8，但实际时间变成了GMT-8的……
而设置成Etc/GMT-8时，却成了GMT+8的……
不知这是怎么回事……

传说中的终极Shell，强大与否还不得而知，但明显比bash酷……

最近发现了个很不爽的问题，就是例如在leafpad复制完某些内容后，如果还没粘贴就随手把leafpad关掉的话，当你粘贴时会发现剪切板是空的……原来，当程序关闭时，通常会将其所占用的内存清空掉，自然所复制也就没了……
该怎么办呢？如果使用的是xfce桌面环境，那么安装xfce4-clipman-plugin将可以完美解决这个问题，不信？你试试看……