K.I.S.S. - 简单哲学

那些在 Python 3 中闪亮的

Iven — Tue, 15 Nov 2011 13:57:31 +0000

大家好，又到了科普时间，咳咳。

距离 Python 3 发布已经有一段时间了，主流发行版都已经带了 Python 3 的软件包，甚至 Arch 等发行版还将其设为了默认的 Python 版本。多数的库也已经带了 Python 3 的支持（也有 Twisted、Django 等例外），是不是偶尔也想着要不要将自己的程序升级一下呢？

昨天稍微有时间研究了一下 Python 3，就将我在文档中找到的有趣新特性分享给大家。

默认返回迭代器（Iterator）

print 成为一个函数、默认不用地板除（Floor Divide）之类的我就不说了，想必地球人都知道有这么回事。

值得一提的是，原来需要使用 xrange 、 iteritems 等等函数和方法才能返回的迭代器现在成为了默认，替代了原来返回列表的函数。就连 map 、 filter 、 zip 等函数都返回迭代器了。

大家都知道相对于返回完整的列表，迭代器省去了一次生成所有元素的开销，并且在循环 break 的时候，就停止迭代，防止了额外的开销，所以一般情况下迭代器要比列表快得多。

如果你仍然需要完整列表，可以通过 list(some_iter) 构造，不过这种问题往往使用列表解析（List comprehension）就能够解决。

字符串分为 str 和 bytes

在 Python 2 中，字符串分为 ASCII 码表示（'some text'）和 Unicode 表示（u'Unicode 字符串'），默认为 ASCII 码。

不过在 Python 3 中，默认就是万能的 Unicode 码了，所以字符串前面不用加字母 u 也可以写 Unicode 了，当然这不是重点，重点是不会有各种 ASCII 和 Unicode 转换和混用带来的错误了。

另外， Python 3 中增加了一种 bytes 对象（b'\xb6\xfe\xbd\xf8\xd6\xc6\xca\xfd\xbe\xdd'），专门用来表示编码后的（二进制）数据，所以现在对字符串的编码就是从 str 到 bytes 的转换，反之亦然，两者不能混用，这样编码与否一目了然，免除了很多错误。

源文件编码默认为 UTF-8

Python 3 在字符编码方面有很多改进，其中之一就是默认的源文件编码从 ASCII 变为 UTF-8 ，也就是说以前在文件头加上的各种花样的 coding=utf-8 不再需要了！

# coding: UTF-8
# vim:fileencoding=UTF-8
# -*- coding=UTF-8 -*-
# vim: set fileencoding=UTF-8

标识符支持非 ASCII 字符

这个自行理解，易语言表示压力很大。

>>> 所有 = all
>>>
>>> class 男人:
...     @classmethod
...     def 包括(cls, Ta):
...         return isinstance(Ta, cls)
...
>>> def 一起玩(人们):
...     if 所有(男人.包括(Ta) for Ta in 人们):
...         print('他们是基友')
...     else:
...         print('他们是朋友')
...
>>> 小攻 = 男人()
>>> 小受 = 男人()
>>> 一起玩([小攻,小受])
他们是基友
>>>

新的字符串格式化语法

原来的 %s %d %你妹语法已经不推荐，并且很快会被弃用，新的字符串格式化方法（2.6 版引入）为 str.format 或者内置函数 format 。比如：

>>> 三青年 = {'小红':'普通青年','小明':'文艺青年','小亮':'二逼青年'}
>>> '{小红}说我想吃罐头，{小明}说更上一层楼，{小亮}说阿伊呀伊呦。'.format(**三青年)
'普通青年说我想吃罐头，文艺青年说更上一层楼，二逼青年说阿伊呀伊呦。'
>>>

字典解析和集合解析

有了列表解析，当然也少不了字典解析：

>>> {k: v + '青年' for k, v in [('小明', '文艺'), ('小红', '普通'), ('小亮', '二逼')]}
{'小明': '文艺青年', '小红': '普通青年', '小亮': '二逼青年'}
>>>

还有集合解析：

>>> {小吃 for 小吃 in ('豆浆', '油条', '包纸')}
{'油条', '包纸', '豆浆'}
>>>

有序字典与 configparser

默认 Python 字典是无序的，不过新引入的 collections.OrderedDict 类提供了一种有序字典实现，并且被 configparser 默认使用，现在使用 configparser 类就可以得到有序的 ini 格式配置文件了！

而 configparser 模块现在完全支持使用类字典的方法进行读写了！你妹，我之前的工作全白做了！

ABC

抽象基类（Abstract Base Classes），就是像 C++ 里面虚类一样的东西。作为其子类，只有将所有抽象方法都实现，才能实例化。

抽象基类是对 Duck Typing 的补充，由于引入了 @abstractmethod ， @abstractstaticmethod ， @abstractclassmethod ， @abstractproperty 四个修饰符，强制抽象方法必须实现，所以可以一定程度上避免错误，用起来感觉比 Duck Typing 安心一些。

结局

以上就是我把 Python 3.0 到 3.2 的 What's new 看了一遍的成果，总体来说 Python 3 本身变得更加规范，更加灵活，如果你的程序不依赖于 Python 2 特有的库的话，来试试 Python 3 很不错！

结局？结局？结局就是小亮和小红幸福地生活在了一起，小明自己吃豆浆油条包纸。

（完）

你的下一个文件系统——Btrfs

Iven — Fri, 05 Aug 2011 06:57:59 +0000

提起 Btrfs ，相信广大折腾帝们都不会陌生，被誉为“下一代 Linux 文件系统”的它，具有扩展性好、支持数据校验、支持多设备管理等等强大特性，使得 Ext4 也只能成为悲剧的过渡产品，还不赶快找一个 Ubuntu 10.10、Fedora 15、Meego 什么的试一下？

慢着！支持什么多设备、什么数据校验跟你有一毛钱关系啊？根据 Ext4 和 Btrfs 的对比，Btrfs 在速度上似乎还差上一些呢！这么说 Btrfs 其实挺垃圾的？

本文就来为你从普通~~折腾帝~~用户的角度来解说一下 Btrfs 到底有什么好。如果你想从技术层面了解 Btrfs ，可以看一下《新一代 Linux 文件系统 btrfs 简介》。

注意：Btrfs 还处于实验性阶段，截止到本文写作为止，其磁盘检查工具 Btrfsck 还不能修复文件系统，请不要在工作环境下使用 Btrfs，以免数据丢失！再次警告，这不是演习！

错误修复

在正式开始讲之前，我假定你已经把系统弄坏了，你已经看到了系统提示你“You are on your own”，“Good luck~”，很好，我之前已经说过 Btrfs 还处于实验阶段了，所以就不要妄想把你的动作片全集找回来啦，乖乖格式化掉吧~

呃，当然，我们对于有共享精神的同志还是要宽容处理的，如果你真的很想找回来~~并且共享给我~~，你或许可以去 Arch Wiki 上看一下，那里有几条~~死马当活马医的~~良策，或许可以帮你度过难关，~~铁道部~~春哥保佑你。

其他特性

其实 Btrfs 对于普通用户有用的、能看到的特性主要就是其包含了卷管理特性，但是为了吊胃口，我们还是从其他特性开始说起吧。

其他的其他

Btrfs 支持在线的碎片整理，在线的卷增大和缩小，在线的块设备增添和删除，在线的块设备负载均衡；啥叫在线的呢？我理解就是文件系统挂载着就可以干这些事情，牛吧？虽然我不知道这些事情都是干嘛的跟我有毛神马关系。

可以从 Ext3/Ext4 无痛转换

不解释，详见《Conversion from Ext3 and Ext4》。

为 SSD 优化

Btrfs 高度为 SSD 优化，不仅提高存取效率，还延长了使用寿命。如果你在 SSD 硬盘上使用 Btrfs，那么可以在挂载选项中加入 ssd 来启用这一特性。

支持数据压缩

Btrfs 支持文件系统的压缩，这个有什么用呢？大家知道 NTFS 吧，它就支持压缩，支持压缩就可以存放更多的东西呗，动作片什么的。

不过压缩可不光是这个作用，大家都知道磁盘速度很慢，总是跟不上 CPU 的处理速度，所以 CPU 常常空闲着没事干。于是牛人们就想着给它找点事干，于是就有了压缩。压缩了之后磁盘读写就少了，原来闲着的 CPU 过来帮忙压缩解压缩数据，CPU 多快啊，这一来二去，往往就比原来不压缩的时候速度快得多。没看内核和 Ramdisk 都变着花样的压缩么，就是这个道理。

Btrfs 目前支持 lzo 和 zlib 压缩算法，而且很智能，像一些视频啊、音乐啊、图片啊，大家都知道它们本来就是压缩过存放的，再压缩也不一定减少空间，反而平白浪费 CPU，所以 Btrfs 会试着压缩一小段，如果压着困难，就会原样存放。怎么样，智能吧？

如果想要启用这一特性，可以在挂载选项中加入 compress 选项，你还可以手动指定压缩算法，例如 compress=zlib 可以获得更高压缩比，而 compress=lzo 可以获得更快的速度。

卷管理

终于到正题了啊，说到卷管理，很多人可能就想到 LVM 了，没错，说的就是这个卷！不过我虽然用过 LVM ，不过用的也不熟，如果说得有错误，请偷偷告诉我……

无须分区的文件系统

初入 Linux ，最大的难点是什么？当然是分区。其实这是大多数操作系统都会共有的问题，各位 MM ，你们当时是不是找暗恋你们的 GG 帮忙分的区？各位 GG ，你们当时是不是找暗恋你们的 GG 帮忙分的区？有了 Btrfs ，你们再也不用求人了！

什么 /boot 要分 200M 还有说不用单独分出来的啊，什么 /home 要分好多好多但是不能理解这是干什么用的啊，就算你已经算是 Linux 老鸟了，新换一个发行版的时候，也会犹豫 / 到底是分 15G 好还是 20G 好吧？

有了 Btrfs，你只需要分一个区就可以了，除非你想要休眠功能，那可以再分一个跟内存大小一样大的 swap 分区。

还在担心重装系统 /home 下文件会丢失？不用了，把 /home 分到一个单独的子卷中就可以啦！担心多系统问题？把 /boot 分到一个子卷中，就可以共享啦，然后再建一个其他操作系统的 / 子卷，往里面安新的操作系统吧！

子卷

上面的说明让你云里雾里？好吧，我来详细指点一下，多设备我不清楚，这里只说单设备，谁有多个硬盘自己研究去。

Btrfs 呢，自带了卷管理功能，所谓的卷呢，就是原来分区的概念，嗯，特别是在 LVM 中，就是这样。 LVM 中，划分子卷的时候也要指定子卷的大小，然后如果哪个子卷空间不够用了，可以用 LVM 的一套工具来改变大小。

这样其实跟原来分区的概念相差也不是很大，不过 Btrfs 中的子卷不是这样。在 Btrfs 中，所有子卷共用文件系统中所有的空间，在划分的时候是无需指定大小的。比如说你有个 80G 的 SSD 硬盘，全划分到一个 Btrfs 分区 sda1，而这个分区里面又有两个子卷 A 和 B，那么只要 A + B 的空间大小不超过 80G，两个子卷中哪个多点哪个少点根本没关系！

所以你再也不必为了 /boot 分小了而懊悔不已，不用为 / 分大了肉痛不已——它们共用一块空间，自身再也没有大小的概念了。

你可能要问，只分成一个 Btrfs 分区，那挂载的时候怎么办呢？仍然是通过挂载参数解决，比如：

mount /dev/sda1 /mnt -o subvol=root
mount /dev/sda1 /mnt/home -o subvol=home

虽然分区一样，不过由于子卷名称不一样，挂载时选择的子卷就不一样，很神奇。

快照

子曰：快照也是一种子卷，子卷是一种特殊的快照。

好，我们来挑战一下更难理解的概念——快照。说到快照，就不得不提系统还原，最常见的系统还原就是 Ghost 那种啦，把文件系统整个复制一遍然后压缩成一个镜像，这个又慢又费空间，大家懂的。Windows 自己也有系统还原，似乎是基于文件级的，把重要的文件备份一下，挂掉之后还原一下，能不能恢复正常全看天命，哈哈。

总之现在现实世界中各种系统还原办法还都不怎么完美（什么苹果、ZFS，我没用过的东西谁提我跟谁急！），不过在虚拟机的世界里，快照的应用已经相当广泛。嗯，或许你早已经用过 Virtualbox 的快照功能了，完全的增量备份方式，不会重复占用空间，并且可以方便地对快照进行增加和删除，是不是很爽？

现在这种异次元才有的技术终于降临在 Linux 上了， Btrfs 让真机上的文件系统快照成为可能。

COW

Btrfs 的快照功能是通过 COW(Copy on write) 技术来实现的，这种技术实现起来很难，不过说起来很简单。可能很多人听说过， Linux 内核中创建进程时 fork() 就用了这个技术，所以据各种书籍吹嘘， Linux 下建进程要比 Windows 下快得多。

举个例子，比如你把 Btrfs 分区分成了 / 和 /home 两个子卷，然后装上了系统，这时你想搞个对 / 子卷的快照，以便以后系统折腾坏了之后可以恢复过来。于是你就建了个快照，快照名叫 ooxx 好了。

Btrfs 中快照的建立几乎是瞬间的事，因为实际上它并没有备份数据，而只是增加了引用计数，比如一个文件 /lib/libc.so.6 ，初始引用计数是 1，你每建立一个快照它就加 1 ，所以现在你建立了 ooxx，引用数就变成了 2。

如果你哪天心情好，把 rm -rf /usr/lib 写成了 rm -rf /usr /lib，很遗憾你的默认子卷中的 /lib/libc.so.6 这个文件就没了。不过呢，这只是它的引用计数减 1 而已，快照 ooxx 中还对它持有一个引用，因此这个文件并没有真正消失，你还可以从 ooxx 中将其拷贝回来。

而哪天系统升级，默认子卷中 /lib/libc.so.6 被升级成了 /lib/libc.so.7，那么版本 6 的引用计数也是减一，同时在默认子卷中增加了一个版本 7 的文件。而快照 ooxx 完全不受此影响。

这就是 COW，也就是两者之间有差异的时候，再去修改差异的部分。如果没有差异，那么就无需重复的磁盘空间。

快照也是一种子卷，子卷是一种特殊的快照

这里反复提到默认子卷，也就是刚装系统时划分的那些子卷，这些子卷跟快照又是什么关系？

其实默认子卷只是一种特殊的快照而已，还记得之前说过划分子卷时要指定子卷名么？其实子卷名就是快照名，一个道理，你不管 / 的子卷叫 root ，而是叫它 xxoo 也是可以的，不管 /home 的子卷叫 home，叫它 oxox 也是可以的。

你可能糊涂了：快照不是死的、只读的么？怎么跟子卷又是一回事了？

错！快照不是只读的！

你可以把 Btrfs 中的快照想象成新建了一个一模一样的子卷，还记得之前的挂载命令么？现在你也可以使用快照名作为子卷名来进行挂载并且读写！

mount /dev/sda1 /mnt/root -o subvol=root
mount /dev/sda1 /mnt/snapshot_ooxx -o subvol=ooxx

没错！你甚至可以将默认子卷和快照同时挂载在系统上，同时进行读写，有 COW 技术的后盾，完全不用担心会有混乱！

想想这个技术可以干什么？你可以挂载一下以前的快照，轻松找回误删的文件；你可以新建一个快照，全盘删除，然后装个别的系统，完全不用担心原来系统的安全~~；你甚至可以建立一个快照，专门存放各种 MV, PV, AV, GV ，只要不挂载，即使是其他 Linux 高手也很难发现~~。

恢复系统

有了快照，怎么恢复系统呢？总不能把快照里面的文件都拷贝回来吧？

这个问题其实前面已经解答了。大家知道 Linux 下文件系统挂载主要是两个地方，一个是内核参数（也就是 GRUB 之类的配置文件里），一个是 /etc/fstab；大家还知道快照的挂载只需要修改挂载参数中的 subvol 的值就可以了，那么事情就简单了：想要恢复到哪个快照，直接挂载它就可以啦！

也就是说，系统的恢复只是改改配置文件的事，完全无需等待！当然以后可能还会有图形界面的工具出现。

快照的数量

我们可以在一个分区里面建立多少个快照？这个问题不要问我。我只能告诉你，如果你每天都在使用电脑，并且每天建立 100 个快照，那么你磁盘空间不足的时候， Btrfs 的 subvolid 肯定不会用完就是了。

所以你可以没事就建建快照，玩 RPG 的都会 S/L 大法吧？说不定少做了一次快照，前面就“请英雄重新来过”了，到时候哭都来不及。 Arch 下已经有了相应的工具自动建立快照，详情自行搜索。

总结

本文仅仅是从理论方面对 Btrfs 对普通~~折腾帝~~用户的用处进行了阐述，如果~~我心情好~~反响好的话我会写一篇实战篇，大家也可以去 Btrfs Wiki 上查看更详细的理论和实践知识。

根据最新接到的消息， Btrfsck 将在两周之内推出一个可以修复数据的初始版本，相信这个工具的推出，可以使更多折腾帝投入 Btrfs 的大潮之中，这篇文章，全当是为大家做个动员吧。

最后还是提醒，折腾有风险，千万别在 Btrfs 上存放重要数据，否则追悔莫及！谢谢支持！

PS: 长了草的博客，我对不起乃！我以后~~可能的话~~一定痛改前非，专心写博！

Wayland 独立运行的视频一段

Iven — Sat, 19 Feb 2011 08:33:53 +0000

X 的替代之一 Wayland 正在快速的开发之中，几乎每天都会收到很多来自其他开发者的补丁和反馈。随着开发的进行，在官方网站上的构建说明也日趋完善，普通用户也可以参照这份说明，构建一份自己的 Wayland 来体验一下了。由于构建说明很简单，这里就不再重复，有兴趣的朋友可以去官方网站上看一下，如果有不懂的地方可以在本文留言。

这里献上一段视频，是 Wayland 脱离 X 直接运行的情况，所以是用手机拍摄的，清晰度不是很高，不过足以说明问题（当然还是 youtube 上的，请自备工具）：

No related posts.

编译最新 Git 版本 GNOME Shell（附视频）

Iven — Sat, 22 Jan 2011 12:02:01 +0000

相信很多人都知道，GNOME 3 最早今年 4 月份就会正式发布了，甚至 GNOME 3 的官方网站都已经上线，那么 GNOME 3 的重头戏，GNOME Shell，现在已经发展到什么程度了呢？

如果你注意 GNOME 3 官网的最下面，可能已经发现官方提供的方法了，那就是 jhbuild！之前也曾经试用 jhbuild 编译过 GNOME Shell，不过最后都不能启动，这次克服了点小困难，终于成功了，简单说一下：

首先你要有至少 1.9.2 版本的 xulrunner，这个根据各个发行版自己解决吧～Arch Linux 下直接安装 xulrunner 这个包即可。

依次运行下面的命令：

sudo rm -rf /usr/lib*/*.la
curl -O http://git.gnome.org/browse/gnome-shell/plain/tools/build/gnome-shell-build-setup.sh
/bin/bash gnome-shell-build-setup.sh
~/bin/jhbuild build

如果是在 Arch 下，由于 python 3 为默认，编译 gjs 的时候，可能要修改一下一个脚本，将 python 改为 python2。

编译成功后，使用下面的命令运行：

cd ~/gnome-shell/source/gnome-shell/src
./gnome-shell --replace

如果出现下面的错误：

mutter: symbol lookup error: /home/iven/gnome-shell/install/lib64/gtk-3.0/modules/libcanberra-gtk-module.so: undefined symbol: gtk_quit_ad

可能是 API 变动导致的，删除那个文件即可，毫无危险：

rm /home/iven/gnome-shell/install/lib64/gtk-3.0/modules/libcanberra-gtk-module.so/pre>

基本上这样就可以执行了，这里录制了一段 GNOME Shell 的演示视频，不妨边编译边看（请自备犯罪工具）：

星际译王 StarDict 更新 3.0.2

Iven — Thu, 13 Jan 2011 12:52:36 +0000

提起 Linux 桌面上的翻译软件，就不得不想起星际译王，这个东西让人又爱又恨，它几乎是 Linux 上唯一一个稳定而功能强大的字典软件，无奈 BUG 多多，许久不更新了，作者胡正似乎沉迷于佛学和写书，久久也没有更新。

不过一位俄罗斯开发者 kubtek 的加入，让已经三年多没有更新过的星际译王重获了新生。事实上，从 2009 年 10 月开始，kubtek 就一直没有停止过开发星际译王，终于在两天前，发布了自开发以来第一个正式版本 3.0.2。

从修订记录来看， 3.0.2 相对于 3.0.1 的主要改变有：添加日志系统、新的文本词典格式、替换了广告插件、恢复在 Windows 和 Mac OS X 上的开发工作、Windows 版本特定的一些调整、修复了 Dict.cn 插件并在未找到单词时显示单词建议，当然 BUG 修复肯定不止这些。

总体来说，没有太多新的特性，属于调整期的维护版本。不过，想来在接下来的版本里，星际译王能够给我们更多惊喜。

更多信息可以在星际译王的项目主页上看到。

PS：考试完成，一身轻松！

No related posts.

使用 gtkaml 编写 GTK+ 界面

Iven — Sun, 02 Jan 2011 05:46:42 +0000

想必大家对 GTK+ 跑在 HTML5 上已经不感到惊讶了，那么用 XML 编写 GTK+ 界面呢？好吧，Glade 是这样做的，不过今天介绍的不是它，而是 gtkaml。

按照官网的介绍，gtkaml 是基于 Vala 的一种标记语言，旨在使用简洁的 XML 语法来描述 GTK+ 界面，乍看起来和 Glade 没有什么区别。

不过 gtkaml 采用的是类似于 Glade 2 的转换代码方式，将 XML 转换成 Vala 代码再进行编译。不过，不用担心图形界面和实际代码分离的问题，因为 gtkaml 在 XML 中预留了 Vala 代码的空间，也就是说，你不需要面对自动转换得到的很可能难懂的代码进行修改，而只需要在 XML 中直接书写 Vala 代码即可！

另外，觉得标准的 XML 太过繁复？ gtkaml 还提供了一种叫做 gtkon 的语法，允许你使用类似 JSON 的语法编写界面，语法一下子就简洁了好多，看个 Hello World 吧（来自 Vala Code）：

Window using=Gtk name=GtkHello type={WindowType.TOPLEVEL} title="First GTK+ Program"
        position={WindowPosition.CENTER} default-width=300 default-height=50 destroy=Gtk.main_quit
{
        Button label="Click me!" clicked={target.label="Thank you"};
        -{
                static int main (string[] args) {
                        Gtk.init (ref args);
                        var window = new GtkHello ();
                        window.show_all ();
                        Gtk.main ();
                        return 0;
                }
        }-
}

怎么样？在 Vala 代码中，根本就没有怎么写与界面相关的东西，是不是很 Cool？更多代码可以看官方 Wiki 的样例。

另外，虽然 gtkaml 现在仅支持 Vala 和 GTK+，不过根据官方介绍， Genie 的支持也在计划中，而只要有 vapi 的库，都可以使用 gtkaml 而不限于 GTK+，相信 gtkaml 的前景应该不赖。

为 Chromium 调教的 Google Reader

Iven — Thu, 23 Dec 2010 20:22:47 +0000

今天把 Firefox 换成了 Chromium，当然要搜搜 Chromium 的技巧什么的，之前在扩展网站上看的 Google Reader 的扩展都略过了，直到看到谷奥这篇《当 Google Reader 遇上 Chrome——打造 GR 专属浏览器》，才猛然发现， Chromium 上面居然有这么多神奇的扩展，比 Firefox 上的 Better GReader 要强上不少（油猴用户请无视），具体的配置在这里就不说了，看文章自己了解吧。

上图，还能认出 Google Reader 么？

从 Firefox 到 Chromium

Iven — Thu, 23 Dec 2010 10:09:19 +0000

以前不是没有试过 Chromium，当时好像还是 5 或者 6，体验一下，发现扩展程序很不全，功能也很单一，于是不得不放弃。

这次的起因是更新了 AUR 中的 Chromium 10 之后，所有链接都莫名其妙从 Chromium 中打开，即使把 Firefox 设置成默认浏览器也不行，于是就想， Chrome OS 都出了，不知道 Chromium 现在神马样子了，试试看吧。

到 Google 浏览器扩展程序的官网上狂找一通，发现 Chromium 的扩展已经很全很完善了，Firefox 上面的扩展基本都能找到替代，功能有些比 Firefox 上面的还要强，比如 AdBlock，居然支持这样过滤广告：

在翻 Wall 方面，Proxy Switchy! 和 AutoProxy 的 list 结合实在是不二之选，详见这篇文章。

鼠标手势有 Smooth Gestures，不过右键还是要双击才能出菜单，不知道 ChromePlus 的鼠标手势是怎么实现的呢？

Twitter 扩展 Chrome Bird 情况和 Echofon 差不多，虽然功能强大不少，但是和 Hotot 一比就是天差地别了，所以干脆卸载掉。

唯一不爽的是鼠标拖拽，现在用的是 Yet Another Google Bookmarks Extension，不过还是没有 Easy DragToGo 强力，不能在同一标签页内打开链接和搜索，求推荐类似扩展……

还有些在 Firefox 里面没有用过的扩展，比如 Auto HD for YouTube，自动选取高清版视频来播放；Google Dictionary，Google 提供的词典，不但可以划词搜索，还可以在地址栏生成一个字典按钮，星际译王可以休息了；还有维基百科伴侣，跟 Google Dictionary 相似，生成一个维基百科的按钮，点击弹出维基百科的小主页，很方便。

基本上就是这些了，总的来说，Chromium 现在已经完全可以替代 Firefox，而且其速度要比 Firefox 快得多，很多特性也很吸引人，如果你还在使用老掉牙的 Firefox，是时候体验一下 Chromium 了。

最后附上我现在所使用的全部扩展：

关于 Linux 内核的几篇心得

Iven — Fri, 17 Dec 2010 10:43:37 +0000

这学期学业繁忙，一直没什么时间更新博客，不过由于学校开了不少 Linux 的课程，对 Linux 的学习和研究可是一点也没有落下哦。

其中一门课程是《Linux 操作系统分析》，推上的同学可能想起我之前说过的用 Kubuntu 的女老师了，没错，就是她！

讲得如何精彩在此就不详述了，有兴趣的同学可以访问她的主页，里面还有全套的课件可供下载。

这里分享几篇我的作业，也就是老师主页上所说的 Project，希望对内核初学者有所帮助：

当然，我也是初学，由于水平有限，分析得很浅显，有些不懂的问题也不方便在作业中列出，因此或是忽略掉，或是不懂装懂掉了，希望不要对人产生误导才好……

No related posts.

Marlin —— GNOME 下新文件管理器启动！

Iven — Tue, 09 Nov 2010 06:32:49 +0000

首先得说明，这个不是 GNOME 官方的计划，而是 Elementary 项目的一部分。

相信 nautilus-elementary 大家都很熟悉了，这个 Nautilus 的修改版，为 GNOME 用户提供了一个更加美观易用的文件管理器。不过， Elementary 小组为 Nautilus 做的一些修改被上游认为是 Hacks 而迟迟不被接受，现在，他们终于开始研究自己的文件管理器了！

Marlin 采用 Vala 编写界面，而 C 用来编写底层函数。在界面的编写上，使用了 GTK+ 3 和其他的 GNOME3 的时髦技术；而在底层上，Marlin 则从 Nautilus 和 Thunar 里面“偷”了些代码。加上 Elementary 自己本身特长的发挥，相信 Marlin 相较于 Nautilus 会在多个方面有所突破！

当然，Marlin 的代码刚刚推送上 launchpad 还不到一天，不要期待能够马上用到稳定版本，不过 bzr 版本已经可以看出它的一些特色了：

电脑上没有装 GTK+ 3 的主题引擎，所以看起来丑了点。可以看出，Marlin 现在默认是这种小栏模式，嵌套进入目录，有点像 Ranger 的样子，操作起来很方便。当然那三个五角星预示着 Marlin 肯定会有各种传统的视图模式，另外，隐藏菜单栏之类的原有功能也是少不了的。

虽然，Marlin 还处于早期开发阶段，不过 Elementary 小组的品质一向很有保证，让我们见证这一文件管理器闪耀出奇迹的光吧！

Marlin 的源代码目前托管在 launchpad 上，可以通过下面的命令获得源代码：

bzr branch lp:marlin