继续等待ubuntu 9.04成熟

前两天说想用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吧!

另外, 最近的很多业余时间都花在配置系统上了, 这样是不对的, 使用好的操作系统的目的是为了加速工作, 提醒下自己不能本末倒置了!

使用metacity内置的符合特性

说道窗口特效， 都会想当然的是compiz, 在ubuntu, 说道要开窗口特效，那么在桌面效果中开放， 可是日常工作中，并没有对特效有那么高的要求，而只想有个窗体阴影和透明， 有时候是显卡或者驱动不支持，比如我现在使用ubuntu 9.04就无法在双屏下开窗口特效， 这样本来也没有什么， 不过看着那个使用频率最高的gnome-do, 默认的那个很丑的界面， 心里总不是个滋味， 而皮肤选择要在符合窗口管理器打开的前提下才能使用，我原来也想当然的认为要开compiz, 心想这个没有戏了，必须承受这样的状况了。今天突然想到，以前看过一条文章，metacity在早几个版本就支持复合特性了，那么这个复合特性是不是gnome-do要求的符合特性呢？
使用配置编辑期把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的源，赞一个！

ubuntu 9.04的一些贴心改变

首先， 替ATI显卡在ubuntu 9.04下的表现平反， 随发行版发布的的确不行， 在我这里会造成xorg cpu占有100%, 但是今天心血来潮使用了从AMD网站下载的ati-9.4版本的驱动(catalyst-8.602)发现非常好， 对双屏的支持很完美，也可以在双屏下开compiz效果，非常舒服。不过设置双屏的时候要用xrandr来做， 使用catalyst-control-center配置是不行的。它上面的相关选项为灰色不可用状态。

顺便记一下使用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文件系统经过一段时间的测试使用正常的话.

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的命令才后然发现下面的指令：

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呢！

使用vim开发python的quickfix方案

这个问题用google一搜就能看到很普遍的一种做法, 但是我认为不对的设置方法:
在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配置的话, 最后一个方案看起来是最好的, 对于速度方面的影响, 一般配置的电脑是感觉不到的.

说说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才行！