火与冰--alva's blog

在linux下有两种磁盘自动挂载工具可用，用gnome的，一般会选择gnome-volume-manager,其他系统的用户会用ivman，说实在的如果你用gnome的话，那么gnome-volume-manager无可挑剔，它和gnome和Nautilus配合的提供的功能非常的人性化，插入U盘，就会自动检测到，并且挂载，弹出文件夹。ivman也不错，但是需要一些设置。这些我都嫌麻烦，它们至少要运行几个daemon，dbus，hald，对于我这样的U盘次数用得不是很多的，其实很多人都用得不多。如果不用gnome，那么没有必要自己再搞一个，ivman个人觉得挺麻烦的，root用户运行，还是普通用户运行都不太好搞，所以我放弃它们了。今天准备用一下它们，是因为我的U盘从/dev/sda1上挂载不了，后来偶然发现我的U盘居然是/dev/sda这个设备，真是奇怪，没有见过这样的。所以能用命令挂载了，我想我就不需要它，我犯不着为了一个并不经常用的设备，来启动n个Daemon。如果我不是在启动时让它自动启动，那么到用时来启动比我用mount命令不会少。

mount -t vfat -o iocharset=cp936 /dev/sda
#仅我的U盘是这样的，其他人的是/dev/sda1

另外对于我这样的Fvwm，Rox用户其实可以让Fvwm，或者Rox来做。当点需要挂载到的文件夹时，Rox会自动挂载，退出时会提示是否卸载。而Fvwm就可以做一个按钮来实现上面的命令了。其实最好是在/etc/fstab里面加上一行，以后挂载就更方便了，这样也方便在Rox中来用。

 /dev/sda                /mnt/usb        vfat            noauto,noatime,rw,iocharset=cp936,user,umask=002  

那么以后只需要

mount /mnt/usb

就可以了。
我想对于非gnome用户，自动挂载工具是不太必要的，如果你坚持的话，那么随意，呵呵。

我的系统中是mask了gtk1，今天准备重新emerge一下gftp，说依赖于glib1,觉得不可能，看了一下gftp的ebuild，发现它写得有点问题。所以必须在USE中指明了gtk和gtk2（默认的）才可以基于gtk2进行编译，但是系统中gtk往往就默认为gtk1,很多人会在USE中写明了不要gtk。

gentoo2006.0默认的内核是gentoo-sources-2.6.15-r1,但是经过多次的测试我觉得这个内核是有点问题的，它的initrd有问题，在做fbsplash的时候，一样的配置，但是在这个内核中不能很快的载入initrd中的splash，要等到差不多挂载分区的时候才可以。但是2.6.14.x没有这个问题，我现在用的gentoo-sources-2.6.15-r7也没有问题。今天重新编译了，其实这也是个人爱好，无关紧要，我不喜欢那么久才出来图形的控制台。并且尝试了一下把splashutils编译进内核，测试结果发现和用initrd相比速度几乎没有提高。现在大概一秒时间就可以完成内核解压缩启动到splash了。

发现自己差点冤枉gvim了，把系统上的gtk1去掉了，给use参数加上了-gtk的参数，所以编译出来的gvim界面丑得要命，我本来都打算以后不要gvim了，直接在终端里用vim好了，但是我明明记得，原来我的gvim的界面可以随着我gtkrc-2.0的设置而变啊。所以我怀疑gvim的编译参数搞错了。所以

USE="gtk" emerge -pv gvim 

没有发现对glib1的依赖，于是大胆的加上USE="gtk"编译了gvim，结果得到了pp的gvim。
另外还有个依赖是错的，就是gkrellm，它的ebuild写的是依赖gtk1,但是实际上却不是，所以不要管它的依赖关系直接装gkrellm好了

emerge --nodeps gkrellm

当然前提是其他的除了glib1以外的依赖已经装了。
再有就是更新tck到最新版本之后，python也可以带上tcktk编译，那么idle也能用了。
现在我的系统都是pp的gtk2了！！高兴！！
其他的一些常用的gtk2的程序取代gtk1的：
音乐播放，取代xmms，用audacious，基于beep-media-player和xmms的播放器，因为beep-media-player已经停止开发了，至少beep-media-player在gentoo里就因为upstream的原因被mask了。audaciouse和beep-media-player很象，并且兼容它们的皮肤。而且它依赖的东西很少，就一个包。它的设置选项跟beep-media-player基本一样的，但是比xmms的简单多了，只要设定了标题编码utf8码转换，也没有所谓的中文问题。可能象我这样应用fvwm或者fvwm-crystal的人，需要改动fvwm的脚本来适应这种变化，或者fvwm-crystal的有些功能根本用不上了。下面介绍一个简单的暂时的方案，因为audacious是基于xmms和beep-media-player的，所以我比较了xmms和audacious的命令，发现它们的基本操作命令是一致的，所以只要在/usr/bin里建立一个链接到audacious的xmms符号链接就可以了。

cd /usr/bin
ln -s audacious xmms

这样不会牺牲你什么功能，但是可以给你一个美观的界面，并且省掉你解决中文问题的时间。
电影播放，取代mplayer，mplayer就真没有冤枉它，它确实是基于gtk1的，不过现在正在向gtk2发展，如果你用gnome，那么totem很不错，至少我用那台装了ubuntu的工作站觉得很不错，不用象装mplayer时为了放rmvb的，而格外装一个realplayer，totem都一把搞定了（据说mplayer配置一下能播rmvb，但是没有试过,懒得搞）。对于非gnome用户，装totem太奢侈了，依赖了10多个gnome的包，如果你还用好多gnome的软件还差不多，但是象我这种当初因为stardict依赖的gnome包太多还犹豫装不装stardict的人，gxine是很不错的选择，在gentoo上是叫gxine，带有基于gtk2的xine前端。
再多说一点：
gentoo用户的编译选项，win32codecs默认是关闭，这一点可以用

emerge -pv xine-lib

可以看到，你需要打开win32codecs这个选项，进行编译。

USE="win32codecs" emerge xine-lib

并且根据需要，还可以根据你的需要打开asf，dvd等等编译选项。这样编译出来的xine-lib就可以使用那些编码器了。编译完成之后，需要在对应的配置文件中改变配置文件，如果你用的是xine或者xine-ui的前端，那么配置文件是~/.xine/config;你用的gxine那么配置文件在~/.gxine/config,其他的前端类似。注意到配置文件中有这样的几行;

# path to RealPlayer codecs
# string, default: /usr/lib/codecs
decoder.external.real_codecs_path:/usr/lib/codecs
 
# path to Win32 codecs
# string, default: /usr/lib/win32
# decoder.external.win32_codecs_path:/usr/lib/win32

下载的解码器就解压缩放到了/usr/lib/codecs中
如果有了all*那个包中的编码器，无论是利用mplayer还是xine都可以当成一个全能的播放器。我不喜欢mplayer是因为它基于gtk1。有人说mplayer的性能要更好一点，这一点我感觉不出来，并且它们没有在我机器上同时存在过。xine有很多的前端，比如totem也是其中只一。你可以根据你当前的环境选择合适的图形前端，如果你用gnome，那么建议用totem，个人觉得totem很不错。而如果象我这样只用了一个fvwm的，而主要用的是gtk2程序的,那么gxine很合适你，在gentoo上它只依赖三个包，不象totem依赖很多gnome的软件包，并且gxine-0.5.x支持简体中文。