前两天说想用9.04正式作为工作桌面了, 但是使用了两天的表现来看还是想呆在8.10下面, 使用9.04目前确实带来了启动速度的提高, 我机器上的测试是从27秒,减少到了18秒,提速30%.
但是也还是存在一些问题, 首先是双显示器的问题
(1) 使用ATI官方驱动,窗口最大化时会把两个屏幕认成一个屏幕, 所以会跨越两个屏幕, 这点非常不爽
(2) 使用开源驱动不玩游戏, 不开compiz也可以接受, 但是不知道怎么回事, 使用fvwm会搞反双屏, 或者干脆有一个屏幕起不来, 真是奇怪.
由于metacity不支持配置快捷键切换窗口屏幕, 所以平常用fvwm居多, 而上面两条问题, 会让我感觉工作巨不爽, 甚至还没有windows下双屏感觉好, 在windows下顶多只是切换屏幕低效一点, 偶尔hydravision控制软件不响应一下, 其他的感觉都还不错.
其实9.04虽然没有宣称有什么巨大的改变什么的, 但是实际上是跨越很大的一个版本, 内核升级, xorg升级, 这些"大头"的升级在各个版本上甚至都造成了问题, 我也是从Arch上遇到问题改回到ubuntu, 现在这些我以前遇到的问题在9.04上虽然有所改善, 但是还不够, 所以继续我的8.10吧!
另外, 最近的很多业余时间都花在配置系统上了, 这样是不对的, 使用好的操作系统的目的是为了加速工作, 提醒下自己不能本末倒置了!
2009年4月28日星期二
2009年4月26日星期日
使用metacity内置的符合特性
说道窗口特效， 都会想当然的是compiz, 在ubuntu, 说道要开窗口特效，那么在桌面效果中开放， 可是日常工作中，并没有对特效有那么高的要求，而只想有个窗体阴影和透明， 有时候是显卡或者驱动不支持，比如我现在使用ubuntu 9.04就无法在双屏下开窗口特效， 这样本来也没有什么， 不过看着那个使用频率最高的gnome-do, 默认的那个很丑的界面， 心里总不是个滋味， 而皮肤选择要在符合窗口管理器打开的前提下才能使用，我原来也想当然的认为要开compiz, 心想这个没有戏了，必须承受这样的状况了。今天突然想到，以前看过一条文章，metacity在早几个版本就支持复合特性了，那么这个复合特性是不是gnome-do要求的符合特性呢？
使用配置编辑期把metacity的符合特性打开了， 嘿， 居然可以了， 很漂亮， 而且tilda也可以透明了！原来我总以为要开xcompmgr才可以开tilda透明， 原来是要用metacity的复合特性！以前在8.10中试过metacity的这个功能， 但是觉得比较卡，不好用，有时候有花屏的情况，但是在9.04中，使用开源ati驱动， 完全没有问题！^_^
使用配置编辑期把metacity的符合特性打开了， 嘿， 居然可以了， 很漂亮， 而且tilda也可以透明了！原来我总以为要开xcompmgr才可以开tilda透明， 原来是要用metacity的复合特性！以前在8.10中试过metacity的这个功能， 但是觉得比较卡，不好用，有时候有花屏的情况，但是在9.04中，使用开源ati驱动， 完全没有问题！^_^
163有了ubuntu 9.04的源了
这几天一直都在盼星星，盼月亮，以至于每天都上163的源看看有没有9.04的源上来，其他的源不是速度慢，就是有问题，从ovh.net移到163的源上了后，ovh.net的源速度还可以，但是昨天我使用AMD官方ATI驱动时把我的locales还有libc包搞坏了，造成升级软件包都报错，说找不到/sbin/locale-gen, locale指令也有了， 163的源，赞一个！
2009年4月25日星期六
ubuntu 9.04的一些贴心改变
首先， 替ATI显卡在ubuntu 9.04下的表现平反， 随发行版发布的的确不行， 在我这里会造成xorg cpu占有100%, 但是今天心血来潮使用了从AMD网站下载的ati-9.4版本的驱动(catalyst-8.602)发现非常好， 对双屏的支持很完美，也可以在双屏下开compiz效果，非常舒服。不过设置双屏的时候要用xrandr来做， 使用catalyst-control-center配置是不行的。它上面的相关选项为灰色不可用状态。
顺便记一下使用AMD官方驱动的方法， 以前没有搞过的
但是还有几个欠缺就是
(1) 使用ATI驱动，驱动X时，副显示器会狂闪几秒钟才启动，而主显示器不会，这让我感觉奇怪， 也担心是否会对显示器有影响
(2) 不知道是显卡还是X的问题，窗口最大化时认为两个显示器是一个桌面，所以会最大化到两个桌面上，这让我有点抓况！
只能用拖动来改变窗口大小了。
除了广为宣传的启动迅速， 支持EXT4之外， 还有几个地方让我感觉非常舒服
(1) gnome-display-properties, 对双屏的支持增加， 可以单独设置显示器， 它应该是调用xrandr命令来做这个事情，但是目前用起来还是有点不顺，比如设置无法保存， 设置不对的问题， 还需要改进。
(2) 在language support中， gnome界面菜单等希望用英文，而核心语言又希望是中文，能方便中文输入的要求，这两个在语言设置中可以分别设置不同的了。
(3) 新版本的gnome-do, 很有意思， 它的皮肤当复合窗体特性打开的时候特别有意思，有一个dock模式， 特别像苹果下的dock, 既可以快捷键打开命令， 又可以当任务栏用， 这点跟苹果系统很像， 用起来很方便，有些喜欢用苹果样式的就不用再去装AWN了。gnome-do就可以满足你了。
其他的，等待进一步发掘吧！ 决定试着往9.04上转了， 如果显卡还有ext4文件系统经过一段时间的测试使用正常的话.
顺便记一下使用AMD官方驱动的方法， 以前没有搞过的
./ati-driver-installer-- .run --listpkg
#follow the instrunction
#e.g for ubuntu 9.04
./ati-driver-installer-- .run --buildpkg Ubuntu/jaunty
#use dpkg -i install the generated deb files.
但是还有几个欠缺就是
(1) 使用ATI驱动，驱动X时，副显示器会狂闪几秒钟才启动，而主显示器不会，这让我感觉奇怪， 也担心是否会对显示器有影响
(2) 不知道是显卡还是X的问题，窗口最大化时认为两个显示器是一个桌面，所以会最大化到两个桌面上，这让我有点抓况！
只能用拖动来改变窗口大小了。
除了广为宣传的启动迅速， 支持EXT4之外， 还有几个地方让我感觉非常舒服
(1) gnome-display-properties, 对双屏的支持增加， 可以单独设置显示器， 它应该是调用xrandr命令来做这个事情，但是目前用起来还是有点不顺，比如设置无法保存， 设置不对的问题， 还需要改进。
(2) 在language support中， gnome界面菜单等希望用英文，而核心语言又希望是中文，能方便中文输入的要求，这两个在语言设置中可以分别设置不同的了。
(3) 新版本的gnome-do, 很有意思， 它的皮肤当复合窗体特性打开的时候特别有意思，有一个dock模式， 特别像苹果下的dock, 既可以快捷键打开命令， 又可以当任务栏用， 这点跟苹果系统很像， 用起来很方便，有些喜欢用苹果样式的就不用再去装AWN了。gnome-do就可以满足你了。
其他的，等待进一步发掘吧！ 决定试着往9.04上转了， 如果显卡还有ext4文件系统经过一段时间的测试使用正常的话.
2009年4月24日星期五
ubuntu 9.04试用手记
我的显卡是ATI Radeon HD3600 Series.
ubuntu9.04昨天正式发布，了解到ubuntu 9.04上使用xorg-server 1.6, 这点和Arch的配置相同，由于之前在Arch上ATI显卡的问题，所以不甘心的想在ubuntu 9.04上试一下，是否是我配置Arch的功力不够，还是确实在软件方面有问题。
Desktop CD启动计算机的结果是双屏只有一个点亮，安装fglrx驱动之后，提示不能插入fglrx模块，这是由于和已经载入的radeon冲突造成的，但是desktop CD不是那么容易听你调摆的，当手工停用gdm之后，想手工卸载radeon模块，加载fglrx模块，系统居然死了，所以这让我狠下心来把以前装arch的分区拿来装这个9.04了，当然把arch打了个包备份了，防止要回来。
首先是顺便使用desktop cd安装，发现desktop cd硬盘安装时，它始终提示有磁盘分区挂载了，确实也是挂载了，但是只要安装的分区不是放iso的分区应该就没有问题，可是desktop cd还是在那提示，于是只有再下载了一个alternative cd了。安装成功。
安装私有驱动之后，光重启X是不行的，要么就自己把gdm的服务停掉，然后手工卸载radeon模块，然后自己加载fglrx模块，所以干脆重启好了。
但是重启之后，启动X故障，键盘都不响应，也退不出来，只有重启了，在这之前学聪明了，把gdm服务停掉了，在测试的时候使用startx来启动X。在xorg.conf serverFlags节中加上DontZap为false的配置，这样就可以使用Ctrl+Alt+Delete关闭X了。
重启之后才发现刚刚可能不是启动故障，而是使用fglrx驱动造成X CPU占用100%，所以需要很久才能启动起来，在查资料的时候，发现了ubuntu关于这个问题的讨论。从文中貌似到了现在fglrx已经可以和xorg-server-1.6合用了，但是我这里的结果还是不行，另外也了解到了-ati驱动中已经加入了对ATI r6xx芯片的支持，也许这个驱动可以呢？于是卸载了fglrx驱动，改了xorg.conf, 使用开源驱动。
使用开源驱动默认只点亮了一个显示器，比如我只点亮了左边的显示器，这个时候，如果使用xrandr或者gnome-display-properties调整，会造成左边（主）显示器，显示整个虚拟桌面的右边，于是都没有办法点到菜单了。找到了开源ati驱动的网页，这个网页上的内容值得一读，另外关于双屏的设置，这个网页中所提到的文章应该好好读一下。由于xrandr是比较新的东西，以前做双显我了解到都是在xorg.conf中来作，并且aticonfig也是这么来做的，复制Device, Screen, Monitor节，然后在ServerLayout中配置两个屏幕的关系，但是这样做，在现在的xorg中，搭配ati驱动是会造成xorg不能启动的。我照着xrandr的how to实验xrandr的命令才后然发现下面的指令：
这样才点亮了右边的显示器，也才让我看到了在ubuntu 9.04下配置双显示器的可能性。
如果要连接在DVI-1上的显示器在主显示器的右边，使用下面的指令：
如果xrandr报错，提示屏幕大小不对，那么需要检查一下xorg.conf中关于虚拟屏幕的设置，比如我两个17的显示器，每个分辨率为1280x1024,那么虚拟屏幕大小至少应为2560x1024，我那时在arch上配置不成功，它提示屏幕最大只支持1280x1280,我曾经怀疑是开源radeon驱动仅仅可以支持到此大小，所以一度放弃了，但是也没有在xorg ati驱动的页面上找到此限制，所以才决定今天再试一下的。
但是很有意思的是，在ubuntu 8.10下，fglrx私有驱动工作得非常好，所以没有那么多限制了，直接使用ATI catalyst contrl center配置好就可以了，管它什么VitualScreen的设置！
一般的how to都会说要把xrandr的命令做到.xinirc,或者Xsession中去，但是ubuntu不用那么麻烦，使用gnome-display-properties改双屏设置之后，会在$HOME/.config下生成一个monitors.xml文件，里面保存了显示器的分辨率，相互关系等信息，在这方面ubuntu这是做得不错！
使用开源驱动，对于r6xx以上的显卡，3D支持还没有，性能也不佳，所以桌面效果就不能开了；否则就要等哪天fglrx驱动和xorg-server-1.6可以完美合作了。
看来我还是继续使用ubuntu 8.10好了！显卡支持好，偶尔还能打下Nexuiz呢！
ubuntu9.04昨天正式发布，了解到ubuntu 9.04上使用xorg-server 1.6, 这点和Arch的配置相同，由于之前在Arch上ATI显卡的问题，所以不甘心的想在ubuntu 9.04上试一下，是否是我配置Arch的功力不够，还是确实在软件方面有问题。
Desktop CD启动计算机的结果是双屏只有一个点亮，安装fglrx驱动之后，提示不能插入fglrx模块，这是由于和已经载入的radeon冲突造成的，但是desktop CD不是那么容易听你调摆的，当手工停用gdm之后，想手工卸载radeon模块，加载fglrx模块，系统居然死了，所以这让我狠下心来把以前装arch的分区拿来装这个9.04了，当然把arch打了个包备份了，防止要回来。
首先是顺便使用desktop cd安装，发现desktop cd硬盘安装时，它始终提示有磁盘分区挂载了，确实也是挂载了，但是只要安装的分区不是放iso的分区应该就没有问题，可是desktop cd还是在那提示，于是只有再下载了一个alternative cd了。安装成功。
安装私有驱动之后，光重启X是不行的，要么就自己把gdm的服务停掉，然后手工卸载radeon模块，然后自己加载fglrx模块，所以干脆重启好了。
但是重启之后，启动X故障，键盘都不响应，也退不出来，只有重启了，在这之前学聪明了，把gdm服务停掉了，在测试的时候使用startx来启动X。在xorg.conf serverFlags节中加上DontZap为false的配置，这样就可以使用Ctrl+Alt+Delete关闭X了。
重启之后才发现刚刚可能不是启动故障，而是使用fglrx驱动造成X CPU占用100%，所以需要很久才能启动起来，在查资料的时候，发现了ubuntu关于这个问题的讨论。从文中貌似到了现在fglrx已经可以和xorg-server-1.6合用了，但是我这里的结果还是不行，另外也了解到了-ati驱动中已经加入了对ATI r6xx芯片的支持，也许这个驱动可以呢？于是卸载了fglrx驱动，改了xorg.conf, 使用开源驱动。
使用开源驱动默认只点亮了一个显示器，比如我只点亮了左边的显示器，这个时候，如果使用xrandr或者gnome-display-properties调整，会造成左边（主）显示器，显示整个虚拟桌面的右边，于是都没有办法点到菜单了。找到了开源ati驱动的网页，这个网页上的内容值得一读，另外关于双屏的设置，这个网页中所提到的文章应该好好读一下。由于xrandr是比较新的东西，以前做双显我了解到都是在xorg.conf中来作，并且aticonfig也是这么来做的，复制Device, Screen, Monitor节，然后在ServerLayout中配置两个屏幕的关系，但是这样做，在现在的xorg中，搭配ati驱动是会造成xorg不能启动的。我照着xrandr的how to实验xrandr的命令才后然发现下面的指令：
xrandr --output DVI-1 --mode 1280x1024 --rate 75
这样才点亮了右边的显示器，也才让我看到了在ubuntu 9.04下配置双显示器的可能性。
如果要连接在DVI-1上的显示器在主显示器的右边，使用下面的指令：
xrandr --output DVI-1 --right-of DVI-0
如果xrandr报错，提示屏幕大小不对，那么需要检查一下xorg.conf中关于虚拟屏幕的设置，比如我两个17的显示器，每个分辨率为1280x1024,那么虚拟屏幕大小至少应为2560x1024，我那时在arch上配置不成功，它提示屏幕最大只支持1280x1280,我曾经怀疑是开源radeon驱动仅仅可以支持到此大小，所以一度放弃了，但是也没有在xorg ati驱动的页面上找到此限制，所以才决定今天再试一下的。
但是很有意思的是，在ubuntu 8.10下，fglrx私有驱动工作得非常好，所以没有那么多限制了，直接使用ATI catalyst contrl center配置好就可以了，管它什么VitualScreen的设置！
一般的how to都会说要把xrandr的命令做到.xinirc,或者Xsession中去，但是ubuntu不用那么麻烦，使用gnome-display-properties改双屏设置之后，会在$HOME/.config下生成一个monitors.xml文件，里面保存了显示器的分辨率，相互关系等信息，在这方面ubuntu这是做得不错！
使用开源驱动，对于r6xx以上的显卡，3D支持还没有，性能也不佳，所以桌面效果就不能开了；否则就要等哪天fglrx驱动和xorg-server-1.6可以完美合作了。
看来我还是继续使用ubuntu 8.10好了！显卡支持好，偶尔还能打下Nexuiz呢！
2009年4月22日星期三
使用vim开发python的quickfix方案
这个问题用google一搜就能看到很普遍的一种做法, 但是我认为不对的设置方法:
在vimrc中设置:
对于vim设置, 我并不是特别熟悉, 所以我也照抄了上面的设置, 使用一下这个设置就知道了, 如果你的python脚本中出错了, 那么quickfix会把你定位到错误堆栈的最高点, 但是在python中错误信息是most recent call last, 所以quickfix捕获到错误实际上是函数调用的顶端, 而在此并非你的代码真正错误的地方, 加入你的代码比较长的话, 那么实际上还会被mislead,然后你再傻傻的去找你的错误, 而且上面的设置把整个错误堆栈下面的信息吞掉了, 要找错误根本还不好找.
这个问题一直没有体会到,直到最近使用wxPython开发, 才知道没有一个好的quickfix是多么的痛苦, 所以下定决心要解决, 花了一个下午加一个晚上, 下面是我的心得.
从上面的分析可以想到最直接的办法, 修改errorformat, 让quickfix可以捕获错误堆栈中所有的内容, 然后用:cl查看, 用:clast定位到实际的错误处, 这个方案再vim站点上有, 可以看一下,不过仍然非常麻烦, 而且用wxPython编程时, 有时会包wxPython lib中的错误, 你就会被定位到lib中,而不是你在你的源代码中出错的地方.
方法二: 借助万能的google找到了别人的一个解决方案:
这个解决方案的核心思想是把python的error message逆转过来, 那么就能让quickfix默认停到第一条出错处, 不过这个解决方案值得改进的地方我认为有两个, 第一, 要能处理当你的源文件没有错误时,防止那个efm_filer.py出错, 应该对errors进行判断, 列表非空才调用pop方法, 第二, 它仍然没有解决在上个方案中我说的在wxPython编程中会被定位到类库中的情况, 也需要进行判断, 只有在当前编辑文件中找到的错误才是我们需要定位的错误. 下面是我改进之后的
efm_filter.py源代码:
为了避免上面的链接失效, 我把在compiler/python.vim中的设置贴过来
另外, 在python.vim中, 它说可以改写efm_filter.py,让其将它得到的输入直接输出, 处理后的输出写到vim quickfix临时文件中 (这个临时文件是vim传递的), 这样做的好处是可以在错误信息中看到熟悉的python错误信息, 又可以让quickfix捕获到准确的出错位置, 这个改写很容易,这里就不贴了, 感兴趣的可以试一下.
从python.vim中可以看到, shellpipe中用到了管道符号, 这是*nix系统下才有的概念, 在windows不能使用, 所以上面的解决方案仅仅适合于*nix系统的, 如果你的主要工作环境是Linux, 那么上面的方案非常不错了.
在windows下我也用gvim做编程工作, 那么在windows下如何解决呢? 我的方案是使用一个python脚本调用python解释器,然后做进一步的处理, 这样也许在速度上有点影响, 但是在windows系统上测试使用效果还不错. 改写上面我贴出的efm_filter.py, 你可以重新命名为pymake.py, 把从标准输入流读取错误信息的部分改为如下代码
把pymake.py放置到PATH中, 然后改vimrc, 指定使用pymake编译:
autocmd FileType python set makeprg=pymake.py\ %
autocmd FileType python set efm=\ \ File\ \"%f\"\\,\ line\ %l\\,\ in\ %*[^\\,]\\,\ %m
当然你要愿意, 通过改python.vim的compiler设置也可以, 不过我认为, 既然不涉及到对其他配置文件的改变, 改这里更加直接.
当然上面的解决方法也同时适合Linux, 如果你同时在windows和Linux下面开发, 需要共享VIM配置的话, 最后一个方案看起来是最好的, 对于速度方面的影响, 一般配置的电脑是感觉不到的.
在vimrc中设置:
autocmd FileType python set makeprg=python\ %
autocmd FileType python set efm=%C\ %.%#,%A\ \ File\ \"%f\"\\,\ line\ %l%.%#,%Z%[%^\ ]%\\@=%m
对于vim设置, 我并不是特别熟悉, 所以我也照抄了上面的设置, 使用一下这个设置就知道了, 如果你的python脚本中出错了, 那么quickfix会把你定位到错误堆栈的最高点, 但是在python中错误信息是most recent call last, 所以quickfix捕获到错误实际上是函数调用的顶端, 而在此并非你的代码真正错误的地方, 加入你的代码比较长的话, 那么实际上还会被mislead,然后你再傻傻的去找你的错误, 而且上面的设置把整个错误堆栈下面的信息吞掉了, 要找错误根本还不好找.
这个问题一直没有体会到,直到最近使用wxPython开发, 才知道没有一个好的quickfix是多么的痛苦, 所以下定决心要解决, 花了一个下午加一个晚上, 下面是我的心得.
从上面的分析可以想到最直接的办法, 修改errorformat, 让quickfix可以捕获错误堆栈中所有的内容, 然后用:cl查看, 用:clast定位到实际的错误处, 这个方案再vim站点上有, 可以看一下,不过仍然非常麻烦, 而且用wxPython编程时, 有时会包wxPython lib中的错误, 你就会被定位到lib中,而不是你在你的源代码中出错的地方.
方法二: 借助万能的google找到了别人的一个解决方案:
这个解决方案的核心思想是把python的error message逆转过来, 那么就能让quickfix默认停到第一条出错处, 不过这个解决方案值得改进的地方我认为有两个, 第一, 要能处理当你的源文件没有错误时,防止那个efm_filer.py出错, 应该对errors进行判断, 列表非空才调用pop方法, 第二, 它仍然没有解决在上个方案中我说的在wxPython编程中会被定位到类库中的情况, 也需要进行判断, 只有在当前编辑文件中找到的错误才是我们需要定位的错误. 下面是我改进之后的
efm_filter.py源代码:
#!/usr/bin/env python
import sys
import string
import re
errors = sys.stdin.readlines()
#find current filename, only errors
#in current file will be considered as *true* errors
current_file = None
for error in errors:
m = re.search("""^\s+File\s+"([^"]+)".+""", error)
if m is not None:
current_file = m.group(1)
# print current_file #for testing
break
if len(errors) > 0:
message = errors.pop()[:-1]
errors.reverse()
for error in errors:
if string.find(error, ' File \"%s\"' % current_file) == 0:
print error[:-1] + ", " + message
message = "Traceback"
为了避免上面的链接失效, 我把在compiler/python.vim中的设置贴过来
" python.vim
if exists("current_compiler")
finish
endif
let current_compiler = "python"
setlocal makeprg=python\ %
setlocal shellpipe=2>&1\ \|\ ~/.vim/tools/efm_filter.py\ \|\ tee
setlocal errorformat=\ \ File\ \"%f\"\\,\ line\ %l\\,\ in\ %*[^\\,]\\,\ %m
另外, 在python.vim中, 它说可以改写efm_filter.py,让其将它得到的输入直接输出, 处理后的输出写到vim quickfix临时文件中 (这个临时文件是vim传递的), 这样做的好处是可以在错误信息中看到熟悉的python错误信息, 又可以让quickfix捕获到准确的出错位置, 这个改写很容易,这里就不贴了, 感兴趣的可以试一下.
从python.vim中可以看到, shellpipe中用到了管道符号, 这是*nix系统下才有的概念, 在windows不能使用, 所以上面的解决方案仅仅适合于*nix系统的, 如果你的主要工作环境是Linux, 那么上面的方案非常不错了.
在windows下我也用gvim做编程工作, 那么在windows下如何解决呢? 我的方案是使用一个python脚本调用python解释器,然后做进一步的处理, 这样也许在速度上有点影响, 但是在windows系统上测试使用效果还不错. 改写上面我贴出的efm_filter.py, 你可以重新命名为pymake.py, 把从标准输入流读取错误信息的部分改为如下代码
from subprocess import Popen, PIPE
from cStringIO import StringIO
if len(sys.argv) < 1:
sys.exit(0)
pysrc = sys.argv[1]
output = Popen(["python", pysrc], stderr=PIPE).communicate()[1]
buf = StringIO()
buf.write(output)
buf.seek(0) #move pointer to the start of the file
errors = buf.readlines() #take place sys.stdin.readlines()
buf.close()
把pymake.py放置到PATH中, 然后改vimrc, 指定使用pymake编译:
autocmd FileType python set makeprg=pymake.py\ %
autocmd FileType python set efm=\ \ File\ \"%f\"\\,\ line\ %l\\,\ in\ %*[^\\,]\\,\ %m
当然你要愿意, 通过改python.vim的compiler设置也可以, 不过我认为, 既然不涉及到对其他配置文件的改变, 改这里更加直接.
当然上面的解决方法也同时适合Linux, 如果你同时在windows和Linux下面开发, 需要共享VIM配置的话, 最后一个方案看起来是最好的, 对于速度方面的影响, 一般配置的电脑是感觉不到的.
2009年4月20日星期一
说说ubuntu的一些设定
今天又花了一点时间，仿照着ubuntu的方法试图配置下Arch，可是显卡还是不行，另外才发现使用arch时显卡的glxgear测定值只有1200左右而用ubuntu有5000多，并且Arch下有拖影和延迟，所以决定完全换到ubuntu上来，之前是用的装arch那个盘上的grub,现在想用ubuntu的了。在安装ubuntu之后，如果没有设定grub，那么/boot下是没有grub目录的，要先grub-install /dev/sdaX一下(boot partition). 我开始以为只要在grub shell中写 root (hd0, X)， setup (hd0)即可，结果setup提示没有找到stage1. 其实menu.lst可以完全从arch那边复制过来，但是我记得debian,ubuntu的menu.lst有些特别它可以在内核升级时自动的修改menu.lst,并且选项都可以按照你在注释中写的体现出来，可是不知道该怎么生成阿，看了下grub安装包的内容，看到有一个update-grub命令，猜想应该是这个了，果然它可以在没有menu.lst时自动生成一个。在设定智能化方面，debian/ubuntu可是非常不错的。
另外，usplash改分辨率时，光在usplash.conf中改是不行的，它只能影响到重启时的splash，而要在内核启动时就显示，那么还必须使用update-initramfs声称一个新的initrd.img才行！
另外，usplash改分辨率时，光在usplash.conf中改是不行的，它只能影响到重启时的splash，而要在内核启动时就显示，那么还必须使用update-initramfs声称一个新的initrd.img才行！
2009年4月19日星期日
逃回到Ubuntu
在Arch下面为了显卡的问题困扰了很久，升级到了xorg-server1.6之后，根本就是双屏用不了了，而不谈透明效果的问题！看到catalyst-9.4版本时使用了ubuntu中的catalyst-installer-8.60版本，我突然想，像ubuntu这样关心用户体验并且有商业公司支持的linux发行版本这个问题应该考虑了吧？下载了ubuntu8.10的desktop cd，放到硬盘里面，搞了个硬盘启动，看了下，ubuntu下开启私有驱动完全没有问题！我才知道我从换了电脑以来，我是对于ATI显卡误会太多，不是Linux不行，而是发行版本的问题，从这点来看，ubuntu的优势体现出来了，我配置ArchLinux到现在零零总总的业余时间不下一个星期了！想当年，刚从ubuntu下转到arch下是多么的兴奋，想到可以像gentoo那样滚动升级，有简单的PKGBUILD，很多大软件还不用自己编译！后来配置的时候参照了很多ubuntu的东西，当时可是深深体会了ubuntu的用户体验了，之前我总以为Linux发行版本之间的区别很小，都是用一样的kernel，都是用一样的开源软件，那么能有多大区别，我当时所理解的Linux发行版的定义其实就是一套自己软件包管理系统和一些定制而已，而没有体会到定制用所包含的玄机：对于用户看见的定制是对系统的一些初始设定，这个设定适合于大部分的人，如果你不是有特别的偏好，使用其提供的已经足够；对于用户不可见的定制则是很多发行版独有的patch,虽然这些patch是公开的，但是不是每个发行版本都能用上考虑到的。所以Linux发行版本现在我理解不是一些自由软件的简单集合，而应该是优选的一系列软件并且通过系统的测试的软件产品！用了将近半年的arch linux之后，总结下来，升级之后，停下来配置系统的经历有好几次，有几次是udev,hal的问题，然后换了电脑之后，显卡的问题也一直困扰着我，arch确实给了用户很大的自由和可定制性，可是我感觉arch的很多方面测试不够，软件包提供和更新不够仔细，这可能是因为开发者少的原因吧，对比gentoo，gentoo尽管是通过源代码编译需要花费很多时间，但是配置基本上都是自动化进行的，软件版本的的管理也更加的灵活，而arch这方面似乎做得不够，不过总体看来Arch仍然不失为一个优秀的Linux发行版本，其非常简单和灵活，只是我现在的硬件环境不合适罢了。这些问题让我甚至从Linux世界逃离到Windows，不过这样的经历之后，特别是看过了《productive programer》之后，把windows好好配置了一番，再加上gvim，linux下的命令行工具的windows移植版本，发现自己慢慢喜欢上windows xp了，再加上偶尔电驴，迅雷一下，windows也用得非常舒服。而且在公司，用的是正版的windows xp，也没有心理上的障碍了，再者我觉得微软的开源策略慢慢开放起来，VS2008很好用，提供的框架还是免费的，DotNet3.5编程新功能让人欣喜，ASP.NET MVC也对胃口，eclipse在windows上更加的漂亮和迅速，开源的dotnet library也慢慢多了起来，这些都让我对windows更加喜欢了。
时间到了2009年，Linux 64位操作系统已经非常成熟了，我所关心的JDK, eclipse, flash，多媒体codecs, 在64位操作系统下都表现完美了, 如果使用ubuntu的AMD 64bit版本，那么就不存在arch i686优化对于ubuntu i386的速度优势了，我想可以尝试下Ubuntu 64bit了。安装之后体会也确实如此，不知道是计算机硬件升级带来的感觉还是真的64bit操作系统的速度优势，感觉操作流畅了很多。
值得一提的是ubuntu对于双屏的支持也非常好，在8.10中由于xorg-server的自动侦测功能的加入，ubuntu的xorg.conf文件非常简洁，并且双屏配置可以通过xrandr动态配置，使用catalyst control center配置起来更是方便，所以很喜欢。不过仍然有一点遗憾的是gnome的窗口管理器，没有方便的窗口双屏间移动的功能，在windows下可以使用amd提供的驱动来达到虚拟桌面和窗口控制的功能，而Linux下有现成的虚拟桌面功能，但是窗口切换目前只有fvwm很方便，可以配置快捷键，要是gnome的窗口管理器也可以做到该多好阿，使用fvwm好是好，但是从整体表现上来看，如果不考虑性能，gnome还是要易用一些，fvwm则要自己配置很多。看看有没有时间自己找找能否在gnome的metacity窗口管理器中增加这样的功能，最好是同时在窗口的右键菜单中增加还有就是快捷键支持。尽管fvwm可以和gnome一起使用，但是使用起来感觉不伦不类的，不舒服，所以试着要patch一下metacity了
再好好用ubuntu吧！把配置Linux的时间变成生产力！
时间到了2009年，Linux 64位操作系统已经非常成熟了，我所关心的JDK, eclipse, flash，多媒体codecs, 在64位操作系统下都表现完美了, 如果使用ubuntu的AMD 64bit版本，那么就不存在arch i686优化对于ubuntu i386的速度优势了，我想可以尝试下Ubuntu 64bit了。安装之后体会也确实如此，不知道是计算机硬件升级带来的感觉还是真的64bit操作系统的速度优势，感觉操作流畅了很多。
值得一提的是ubuntu对于双屏的支持也非常好，在8.10中由于xorg-server的自动侦测功能的加入，ubuntu的xorg.conf文件非常简洁，并且双屏配置可以通过xrandr动态配置，使用catalyst control center配置起来更是方便，所以很喜欢。不过仍然有一点遗憾的是gnome的窗口管理器，没有方便的窗口双屏间移动的功能，在windows下可以使用amd提供的驱动来达到虚拟桌面和窗口控制的功能，而Linux下有现成的虚拟桌面功能，但是窗口切换目前只有fvwm很方便，可以配置快捷键，要是gnome的窗口管理器也可以做到该多好阿，使用fvwm好是好，但是从整体表现上来看，如果不考虑性能，gnome还是要易用一些，fvwm则要自己配置很多。看看有没有时间自己找找能否在gnome的metacity窗口管理器中增加这样的功能，最好是同时在窗口的右键菜单中增加还有就是快捷键支持。尽管fvwm可以和gnome一起使用，但是使用起来感觉不伦不类的，不舒服，所以试着要patch一下metacity了
再好好用ubuntu吧！把配置Linux的时间变成生产力！
2009年4月9日星期四
fvwm使用双显示器
换了机器之后， 由于显卡的问题， 基本就没有使用Linux了， 今天没有什么心情编程，突然想把自己的机器配置一下，由于最近ArchLinux的源速度也很慢，我也懒得升级， 甚至想把它降级到163的源对应的版本上去，由于显卡让我觉得很不爽，我甚至在考虑是不是使用Arch在日常工作中是否合适， 它让我花了不少时间去配置什么的, 也许用ubuntu更好， 并且我如果使用AMD64的版本， 就不用担心ubuntu i386版本只是为了i386优化，而不像Arch 特别为i686优化那样的，ubuntu应该也可以高性能的使用， 就算是臃肿， 那么如果换来易用性，那么也是值得的。
在Arch上使用Fvwm已经有一段时间了， 觉得也挺方便，但是换完电脑还有使用双显卡之后还没有怎么使用过，今天也好好的弄了一下， 把xorg. xinerama打开， 达到了那种big desktop的效果， 然后从vladstudio那下载了免费的双显示器的桌面壁纸，fvwm使用双显示器已经非常舒服了。后来看fvwm的文档，才发现fvwm对于multi-screen有特别的支持，它有MoveToScreen的指令， 我把这些绑定到快捷键上， 就像在windows上使用ATI的虚拟桌面一样， 用Alt+F1, Alt+F2控制屏幕选定窗口移动到屏幕1和屏幕2，然后用把9个虚拟桌面分别绑定在小数字键盘的九个键上，操作起来异常顺畅，而且没有使用windows切换虚拟桌面时窗口最小化恢复的延迟现象，所以fvwm使用双屏幕非常的舒服啊！
然而还是有些不满的事情，尽管ATI的catalyst Linux驱动已经更新到9.3版本了，但是还是不支持透明和compiz，以前用2.6.28内核和9.2版本驱动的时候开xcompmgr，窗口支离破碎；compiz反应缓慢；现在用2.6.29内核，9.3版本驱动时干脆报错No composite extension, google遍寻网络也没有一个有效的解决方法；如果使用开源的radeonhd驱动，它对于r6xx系列的显卡的2D加速还支持得不好，虽然透明可以打开，但是双屏幕配置就不行了；就在几个小时前，radeonhd1.2.5发布，在此版本中开始支持r6xx系列显卡， 也就是我的radeonhd 6350显卡的支持已经加入了，Arch源目前没有响应，自己修改PKGBUILD也不能编译成功，看来只有再等几天了，希望有可以完全的配置好。
我不知道自己的显卡是否目前在Linux世界已经可以支持得很好了，看到ArchLinux的catalyst 9.4版驱动开始使用ubuntu源中间的fglrx-installer-8.60来取得从官方下载的installer, 我其实一早就在怀疑ubuntu下面是否可以完美使用compiz和xcompmgr了，后来晚上有时间搞了个LiveCD用了一下，启动私有驱动之后， 居然可以， 看了一下catalyst版本， 8.20！难道老版本显卡驱动反而支持得更好？
要是不能解决， 决定换到ubuntu AMD64了，用Arch虽然觉得可以随心所欲， 但是用ubuntu觉得更省心！
在Arch上使用Fvwm已经有一段时间了， 觉得也挺方便，但是换完电脑还有使用双显卡之后还没有怎么使用过，今天也好好的弄了一下， 把xorg. xinerama打开， 达到了那种big desktop的效果， 然后从vladstudio那下载了免费的双显示器的桌面壁纸，fvwm使用双显示器已经非常舒服了。后来看fvwm的文档，才发现fvwm对于multi-screen有特别的支持，它有MoveToScreen的指令， 我把这些绑定到快捷键上， 就像在windows上使用ATI的虚拟桌面一样， 用Alt+F1, Alt+F2控制屏幕选定窗口移动到屏幕1和屏幕2，然后用把9个虚拟桌面分别绑定在小数字键盘的九个键上，操作起来异常顺畅，而且没有使用windows切换虚拟桌面时窗口最小化恢复的延迟现象，所以fvwm使用双屏幕非常的舒服啊！
然而还是有些不满的事情，尽管ATI的catalyst Linux驱动已经更新到9.3版本了，但是还是不支持透明和compiz，以前用2.6.28内核和9.2版本驱动的时候开xcompmgr，窗口支离破碎；compiz反应缓慢；现在用2.6.29内核，9.3版本驱动时干脆报错No composite extension, google遍寻网络也没有一个有效的解决方法；如果使用开源的radeonhd驱动，它对于r6xx系列的显卡的2D加速还支持得不好，虽然透明可以打开，但是双屏幕配置就不行了；就在几个小时前，radeonhd1.2.5发布，在此版本中开始支持r6xx系列显卡， 也就是我的radeonhd 6350显卡的支持已经加入了，Arch源目前没有响应，自己修改PKGBUILD也不能编译成功，看来只有再等几天了，希望有可以完全的配置好。
我不知道自己的显卡是否目前在Linux世界已经可以支持得很好了，看到ArchLinux的catalyst 9.4版驱动开始使用ubuntu源中间的fglrx-installer-8.60来取得从官方下载的installer, 我其实一早就在怀疑ubuntu下面是否可以完美使用compiz和xcompmgr了，后来晚上有时间搞了个LiveCD用了一下，启动私有驱动之后， 居然可以， 看了一下catalyst版本， 8.20！难道老版本显卡驱动反而支持得更好？
要是不能解决， 决定换到ubuntu AMD64了，用Arch虽然觉得可以随心所欲， 但是用ubuntu觉得更省心！
2009年4月4日星期六
在ubuntu dapper上更新subversion
ubuntu 6.06上的subversion是1.3.2版本的， 服务器上的subversion旧就旧点， 本来也没有什么问题，最近用mercurial了，心里想要是能把mercurial和subversion结合起来多好阿，在自己电脑上， 笔记本电脑上， 使用u盘可以开发时可以小步提交到本地， 到了公司再提交到subversion服务器，以前我都是带个电脑过来直接同步代码到笔记本电脑上去， 省得把个u盘倒来倒去。
以前从网上看到mercurial和subversion结合的方法， 看到那长段的说明文字，就感觉到太复杂了， 而hgsubversion目前还不成熟； 昨天从网上看到有人说现在hgsubversion可以用了， 于是想试一下。
编译安装好mercurial之后， 也配置好了hgsubversion, 连接到客户段， 发现svnclone下来没有东西， 而hgsubversion提示说服务器subversion太老， 小于1.4, 心想是不是subversion太老的缘故， 后面才知道不是这个原因（其实是因为我用hgsubversion去clone svn的trunk分支了， 而hgsubversion要求版本库的布局必须是branches, tags, trunk, svn clone也必须针对根目录来做， 这些是后面偶然发现总结的），于是决定要升级subversion服务器， 这一个决定便是我接下来24小时痛苦的开始；
上到subversion的主页， 看到1.6版本近日刚刚稳定放出， 心想， 既然要更新就更新到最新版本吧， 根据INSTALL说明， 下载了源代码包还有deps包，编译安装成功，客户段一连发现还是提示版本库过老，以为必须服务器上的版本库更新才行， 所以就挑了一个小点的代码仓库进行了版本库升级操作，这么一搞， 客户端居然打不开版本库了，这时庆幸自己只是用了一个很小的版本库做的实验。停下来想了一下， 通过svnserve访问没有问题， 才想到我是通过apache的mod_dav_svn访问代码库的， 那么mod_dav_svn可能没有更新， 在编译后的目录中找了一下，果然没有，又仔细看了INSTALL说明， 才发现要apx在路径中才可以自动编译mod_dav_svn和mod_authz_svn模块，用aptitude查了一下， 发现apache2-dev没有安装，安装之后再编译configure时提示说apache和APR版本不兼容， 好好看了一下subversion-deps中的内容， 发现其中带了apr和apr-utils依赖，是不是和系统中那些相关dev软件包冲突呢？ 重新解压了一个subversion源码包，这次不解压依赖，这个时候configure找到了系统中的apr, 版本为0.9.7, 但是还是提示不兼容， 比较晕倒， 网上一顿狂搜， 找到一个老外的博客说安装1.4.3成功了，根据他博客中说的，我总怀疑我有那个依赖没有安装， 找到ubutnu包查询的网站， 好好看了下还是不行， 这样左搞右搞从下午搞到晚上10点还没搞定， 下午到了办公室继续尝试， 突然想到是不是版本过高？于是下了一个1.5.6的版本来试了一下， 居然configure成功了！另外需要注意的是， 如果需要ssl支持， 那么需要在deps包中取得neon放到subversion源代码包中，系统自带的neon版本过老， subversion1.5要求neon>2.8. 这样成功之后, hgsubversion可以了，不给出警告了，可是有的库可以， 有的库不行？ 不行的就是我直接check某个子目录的！ 并且对我其中的一个版本库， 也是最重要的版本库， svnclone的时候报错，提示找不到文件。 这样忙忙碌碌搞了两天， 最终还是达不到我的要求，比较懊恼自己浪费了时间样， 不过倒是得到了subversion编译安装的经验， 写下来，给有同样需求的同学参考下。
以前从网上看到mercurial和subversion结合的方法， 看到那长段的说明文字，就感觉到太复杂了， 而hgsubversion目前还不成熟； 昨天从网上看到有人说现在hgsubversion可以用了， 于是想试一下。
编译安装好mercurial之后， 也配置好了hgsubversion, 连接到客户段， 发现svnclone下来没有东西， 而hgsubversion提示说服务器subversion太老， 小于1.4, 心想是不是subversion太老的缘故， 后面才知道不是这个原因（其实是因为我用hgsubversion去clone svn的trunk分支了， 而hgsubversion要求版本库的布局必须是branches, tags, trunk, svn clone也必须针对根目录来做， 这些是后面偶然发现总结的），于是决定要升级subversion服务器， 这一个决定便是我接下来24小时痛苦的开始；
上到subversion的主页， 看到1.6版本近日刚刚稳定放出， 心想， 既然要更新就更新到最新版本吧， 根据INSTALL说明， 下载了源代码包还有deps包，编译安装成功，客户段一连发现还是提示版本库过老，以为必须服务器上的版本库更新才行， 所以就挑了一个小点的代码仓库进行了版本库升级操作，这么一搞， 客户端居然打不开版本库了，这时庆幸自己只是用了一个很小的版本库做的实验。停下来想了一下， 通过svnserve访问没有问题， 才想到我是通过apache的mod_dav_svn访问代码库的， 那么mod_dav_svn可能没有更新， 在编译后的目录中找了一下，果然没有，又仔细看了INSTALL说明， 才发现要apx在路径中才可以自动编译mod_dav_svn和mod_authz_svn模块，用aptitude查了一下， 发现apache2-dev没有安装，安装之后再编译configure时提示说apache和APR版本不兼容， 好好看了一下subversion-deps中的内容， 发现其中带了apr和apr-utils依赖，是不是和系统中那些相关dev软件包冲突呢？ 重新解压了一个subversion源码包，这次不解压依赖，这个时候configure找到了系统中的apr, 版本为0.9.7, 但是还是提示不兼容， 比较晕倒， 网上一顿狂搜， 找到一个老外的博客说安装1.4.3成功了，根据他博客中说的，我总怀疑我有那个依赖没有安装， 找到ubutnu包查询的网站， 好好看了下还是不行， 这样左搞右搞从下午搞到晚上10点还没搞定， 下午到了办公室继续尝试， 突然想到是不是版本过高？于是下了一个1.5.6的版本来试了一下， 居然configure成功了！另外需要注意的是， 如果需要ssl支持， 那么需要在deps包中取得neon放到subversion源代码包中，系统自带的neon版本过老， subversion1.5要求neon>2.8. 这样成功之后, hgsubversion可以了，不给出警告了，可是有的库可以， 有的库不行？ 不行的就是我直接check某个子目录的！ 并且对我其中的一个版本库， 也是最重要的版本库， svnclone的时候报错，提示找不到文件。 这样忙忙碌碌搞了两天， 最终还是达不到我的要求，比较懊恼自己浪费了时间样， 不过倒是得到了subversion编译安装的经验， 写下来，给有同样需求的同学参考下。
说说163的源
cn99的源已经当掉很久了，这严重影响我用ubuntu的心情，想当年用cn99的源动辄上M的更新速度那就一个爽阿， 在公网了， 不比当年在教育网内用清华大学的源， 有CN99这种源真是我们这些用Linux的人的福气阿。
昨天更新服务器的subversion，试了一下ubuntu.cn99.com， 居然能上， ping一下， DNS解析居然指到了mirrors.163.com, 速度可真快， 可是ubuntu dapper用不了， 很多ubuntu dist没有i386架构的～
于是想想自己电脑上的Arch已经好久没有更新了， 163的镜像上主要的发行版都有了， arch也不例外， 把电脑上的源改到163试了一下， 才发现滞后了很多， 上面的包比我自己电脑上在两三个月前的还旧！看来不能用了，要是163的源更新再及时点就好了！
昨天更新服务器的subversion，试了一下ubuntu.cn99.com， 居然能上， ping一下， DNS解析居然指到了mirrors.163.com, 速度可真快， 可是ubuntu dapper用不了， 很多ubuntu dist没有i386架构的～
于是想想自己电脑上的Arch已经好久没有更新了， 163的镜像上主要的发行版都有了， arch也不例外， 把电脑上的源改到163试了一下， 才发现滞后了很多， 上面的包比我自己电脑上在两三个月前的还旧！看来不能用了，要是163的源更新再及时点就好了！
2009年4月2日星期四
关于VIM使用的惊喜发现
在windows下用官方的gvim有一点不爽的地方, 就是用python2.5不能自动补全, 通过看:version看python的编译参数可以知道, 官方的vim是针对python24编译的, 我今天下班的时候, 决定我必须要解决一下这个问题, 由于显卡的问题, 在桌面电脑上, 我已经很长时间不使用Linux了, 所以在windows上这个问题必须解决, 在google上一顿搜索之后, 知道我必须重新编译gvim或者下载别人编译的vim版本, 但是vim它是要针对多种脚本语言(多个interface)编译的, 那么我暂时没有安装的那些东西我肯定编译不了, 所以如果有别人编译的东西就非常好了, 在google上知道有一个cream的项目, 下载了之后, 发现安装包的文字我不认识, 非英文, 所以就不敢往下继续了. 后来在vim官方网站的下载页面上看到了alternate distribution, 看到另外一个链接"Yongwei's build", (吴咏伟), 介绍说是用了比较新的python, ruby, tcl interface, 这就正是我需要的, 遂下载使用了, 觉得非常好用, 省去了我自己编译的过程; 另外吴咏伟页面上的一篇VIM实用技术写得非常好, 总结了其vim的点滴经验, 在这里强烈推荐一下.
另外, 在这篇文章里, 有一个解决putty中文问题的方案, 解决了一个困扰我很久的putty中文显示和输入的问题, 我曾经在google上搜了很多, 很多人都说可以, 可以我好像没有成功过. 实际上只要保证了远程服务器的encoding为UTF-8, 不管你是zh_CN.UTF-8, 还是en_US.UTF-8; 而putty在连接之前设置encoding为UTF-8, 还有选中treat CJK ambiguous characters as wide, 然后连接, 就可以显示和输入中文了, 解决了这些问题之后, 我完全可以在windows下, 然后用putty连到服务器上去写程序和管理了.
另外, 在这篇文章里, 有一个解决putty中文问题的方案, 解决了一个困扰我很久的putty中文显示和输入的问题, 我曾经在google上搜了很多, 很多人都说可以, 可以我好像没有成功过. 实际上只要保证了远程服务器的encoding为UTF-8, 不管你是zh_CN.UTF-8, 还是en_US.UTF-8; 而putty在连接之前设置encoding为UTF-8, 还有选中treat CJK ambiguous characters as wide, 然后连接, 就可以显示和输入中文了, 解决了这些问题之后, 我完全可以在windows下, 然后用putty连到服务器上去写程序和管理了.
订阅：
博文 (Atom)
