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

逃回到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的时间变成生产力！

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觉得更省心！