Ubuntu Trusty translations are now open

We are pleased to announce that Trusty is now open for translation:


* Translation caveats. Remember that according to the release schedule [1] translatable messages might be subject to change until the User Interface Freeze [2].
* Language packs. During the Trusty development cycle, language packs containing translations will be released twice per week [3] except for the freeze periods. This will allow users and translators to quickly see and test the results of translations.
* Test and report bugs. If you notice any issues (e.g. untranslated strings or applications), do check with the translation team [4] for your language first. If you think it is a genuine bug, please report it [5].

Happy translating! :-)

[1] https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[2] https://wiki.ubuntu.com/UserInterfaceFreeze
[3] https://dev.launchpad.net/Translations/LanguagePackSchedule
[4] https://translations.launchpad.net/+groups/ubuntu-translators
[5] https://bugs.launchpad.net/ubuntu-translations/+filebug

GNOME Asia Summit 2012

It has been quite some time after my attending GNOME Asia Summit 2012 in City University of Hong Kong. The distinguished meeting happened between June 8th and June 11th, I was fortunately being invited as a speaker to talk about the status of Simplified Chinese translation and the overall status and concerns about input methods. It was my first travel to HK and everything was wonderful!

GNOME Asia Summit is an interesting event that worth attending, where you can meet some most active users and developers, especially local community leaders from Asia. Most meetings in free software communities are usually held in the US or EU area, where Asia attendees are rare. Also there might be some misunderstanding that our user base at Asia are small because the rate of free software users in whole are small, but we can’t ignore how large the base and the absolute number of user counts are. I’m very happy to see that the meeting helps a lot on exchanging ideas between Asia communities, especially various Chinese communities for me. It’s still a pity that there aren’t many local designers or developers working on GNOME, and we are having difficult time to explain things to western people – and there are difference in the way of using a desktop everyday.

Here are some photos we’ve taken during the event:

And I must say “thanks” to GNOME Foundation and GNOME Asia committee  for their sponsorship and help!

Hello Planet Debian!

Hello everyone, this is (not actually) my first post to the Planet Debian. There was some older posts I filed under this category, sorry.

My name is Aron Xu, and I’ve just passed my NM process so I’m now a Debian Developer who has his shiny new account to work on more Debian stuff. During the NM process, I have to say people involved are really really nice. And DAMs are busy guys which gives me a very deep impression. It is an honor to be accepted to this group of people, who have been doing splendid things to make the world a better place.

I live in China, where has many Debian users but very few DD or DM. Actually, there are more people here using the famous Debian derivative, Ubuntu. As I have been a person who tried to participate the communities of some projects in the past 6 years, from rpm-ish to source-ish and then deb-ish, my experience is that the technical differences are significant in some degree, but the people and ideas behind are far more important for a community. I choose to stay at Debian, and work hard to finally get my Debian Developer account. I have to say I like Debian and the people around it very much, or I won’t commit so much time to make it better, and help others with it.

From now on, apart from maintaining my packages, I would like to serve this project more by mentoring new maintainers and sponsoring (barely sponsoring is not so good, though, should point many of the maintainers and potential maintainers to existing teams), and help QA team to do something improve the general quality of Debian.

I am (still) a high school student, whose high school life is reaching its end in no more than half a month. So it takes me many time to work on preparing the upcoming college entrance exam, with some tension and excitement. After several (not too) bad setbacks during the past two years, now I still can’t tell whether I’m ready to face the challenge after this period of life with a strong courage, but anyway I need to keep on and fight for the sunlight of tomorrow. I think I know better about “life is not easy” than ever before at such a milestone. I am younger than many DDs who can tell me I haven’t really suffered from life’s difficulties; I am older than many boys and girls from whom I can see the shadow of my past days.

Thanks for your reading.

Announcing China national-wide Ubuntu 11.04 release parties

After six month’s development, a brand new release of Ubuntu has arrived – Natty Narwhal. We are having more and more people interested in our community happily, thus I am now announcing 18 release parities in 17 cities in China, which will have approximately 2000 participates. It will be a wonderful chance for people to share knowledge and joys, and generally enjoy the time getting together to celebrate a new release of the most widely used FLOSS distribution in China.

Here is the list cities and hosts (sort by alphabet order):
City / Host
Beijing / Beijing University of Posts and Telecommunications
Dalian / Dalian Maritime University
Deqing / Deqing High School
Guangzhou / Sun Yat-Sen University
Hangzhou / Alibaba, Inc.
Ji’nan / Shandong Polytechnic University
Jinzhou / Liaoning Railway Vocational College of Technology
Nanjing / Nanjing University of Aeronautics and Astronautics
Nanjing / Nanjing University of Posts and Telecommunications
Shanghai / Shanghai University
Shenzhen / Unconfirmed (*)
Tianjin / Tianjin Normal University
Wenzhou / Wenzhou Vocational College of Science and Technology
Wuhan / Wuhan Railway Vocational College of Technology
Xiangtan / Hunan University of Science & Technology
Yantai / Graduate School of China Agricultural University
Zhengzhou / Henan Experimental High School
Zhongshan / Zhongshan Institute of University of Electronic Science and Technology

* I haven’t confirmed where will host the release party in Shenzhen, however it has been handled by Shenzhen LUG already.

从一个翻译 bug 谈起

有朋友很意外地谈到一个翻译 Bug,这本是很正常的一件事:每个参与的人都是自由软件爱好者,是用业余时间来点做事希望对其他人有用,每个人都不可能一点错误不犯。

有问题的翻译出自 Bash,这个问题第一次出现是在 4.1 版本,当时正好有一位新任维护人员接手。的确,可以改进的地方很多,bash 的翻译也确实存在一些琐碎的问题。


翻译和编写代码都是软件开发过程中的组成部分。代码可以有几十、上百甚至上千个 bug,有人报告之后编码人员按照一定顺序修,开源社区中先修哪个后修哪个、修哪个不修哪个,很大程度上要取决于维护者的好恶。与之相对比的是,有一句翻译有点问题,就可能成为别人的笑柄、谈资,最后这些谈话的人都只是动动嘴而没有想过找翻译人员修正它。

我不禁想问,为什么代码可以有几十个 bug,而翻译却容不得一个失误?为什么代码的 bug 有人报告,而翻译的问题只能当作谈资?

有些人觉得翻译不是什么难事。如果只是翻译一句两句,的确不见得有多困难;然而不幸的是一个完整的桌面至少有几万条界面翻译,用户要翻译风格统一,要翻译准确,要翻译美观,要…… 哪位读者若不相信,想试一试,请和我联系,;-)


翻译决不是一个软件的附属品,翻译人员的工作也不比软件编写者低一等。如果你维护过一个有很多其他语言用户的软件,便能更容易体会到翻译对于一个软件的价值。翻译者常常是使用测试版软件的吃螃蟹的人,报告一部分 bug,还要为更广义的本地化、国际化做出思考和行动。

很希望将来发现了翻译问题的人都能站出来报告问题,而不是站出来发文聊天。类似的事情我遇见过多次,有我自己的过失也其他人工作的疏漏。目前自由软件的翻译急需大家的反馈:不管是错误,还是觉得哪里不舒服,选择一个翻译人员能听到的办法说,而且这显然比对着空气和不知处理办法的用户说有效得多 :-/

成为 Debian Maintainer 前要做的几件事

今天我收到了一封邮件,询问关于做 Debian Maintainer 的事情让我给他写几条建议。非常高兴看到越来越多的人参与到 Debian 社区之中,以下是我所写的一点东西,希望有用。

Debian Maintainer (DM)是有个别软件包上传权限的 Debian 开发人员,是成为正式 Debian Developer (DD)前的一个步骤。在开始前需要清楚,为 Debian 贡献点力量是很容易的事情,但要成为“官方”的人员则需要付出很多时间和努力。

1. 尽可能多地使用 Debian 完成日常工作。也就是说,成为开发者前,先做一个用户。

2. 阅读 Debian New Maintainer’s Guide 学习 Debian 打包的基本知识(英文版中文版)。这些知识能帮助你让不太复杂的软件包工作起来,但是与满足 Debian 标准之间还有相当大的距离。这个过程中可以独立地重新打包一个已经在仓库中的包,完成后和别人现有的工作进行对比,找出自己的不足。这个包一般不需要很复杂,初学时直接弄复杂的包很可能只会浪费很多精力。做包的过程中遇到任何问题都可以找有经验的人询问清楚,这对提高水平非常有益。

3. 寻找一个感兴趣的软件进行打包,WNPP (Work-needing and Prospective Packages)列表是一个不错的开始。打包前需要考虑:自己是否有足够的知识和能力来维护这个包?在可预见的一段日子里是否有充足的时间和精力来进行更新和修复 Bug?如果答案都是肯定的,那么就动手把它打包好,期间遇到问题则找人咨询指导。

4. 当经过反复检查和测试,觉得软件包已经比较完善时,寻找一位 Debian Developer 帮你检查和上传软件包,这位 DD 此时便是你的 sponsor。

当找到一位愿意帮忙的 DD 后,他会对你的软件包进行彻底的检查,指出(可能)存在的问题并请你修改。这时要做的就是参考他的意见修改软件包,并把结果再发给他,这是一个极好的学习机会。如此反复若干次后软件包最终会符合 Debian 的标准,之后 sponsor 便会将其上传到 Debian 仓库。需要说明的是,经由 sponsor 上传的软件包的维护者是打包人而非 sponsor,所以它的各种更新、任何 Bug 报告都是打包人的责任。在维护软件包上,普通维护人员与正式的 DD 间的差别仅在于能否直接上传,其他的完全相同。

这个步骤进行期间,需要多次阅读 Debian Policy Manual 并确保自己的软件包符合里面的全部要求。最好再读一下 Debian Developers Reference,里面介绍了很多 Policy Manual 中没有提到的细节和最佳经验。

如果打算申请 DM/DD,则应尽早开始维护软件包,因为申请 DM 需要经过一段时间的软件包维护作为评价的材料,以此证明你能够胜任。

5. 不是有软件包被上传到仓库就说明你已经符合了成为 DM 的要求。你必须通过一段时间的努力(更新软件、修复 Bug、回应用户请求),来使你的 sponsor 相信你已经有能力来处理好某个特定软件包,这样他们才会在接下来的申请流程中推荐你。

一些 sponsor 会在他们觉得合适时向你提议申请 DM,另外一些不会,作为新维护人员要在自己觉得差不多合适的情况下和 sponsor 进行沟通,听取他的意见看是否可以申请。

6. 申请 DM 前要让至少一位你 sponsor 之外的 DD 对你的 GPG 密钥进行数字签名,且密钥本身至少要 2048 RSA 或更强。签署密钥不需要对技能的考察,其目的是确认每个密钥的控制者确实是他本人,从而构建 Web of Trust,因而任何人都可以参与到密钥签名活动当中。签名时一般需要双方在现实生活中见面,互相检查身份证或护照确认无误后,交换事先打印好的 GPG key fingerprints 并在稍后进行签署、上传到公共密钥服务器。通常可以在一些较大型的开源软件活动前和时间/地点都方便的 DD 联系好,在聚会时举办一个密钥签名活动。另外,如果给你签名的只有你的 sponsor,则你的密钥仍不符合要求,因为 Debian 无法确信这份申请是否是你的 sponsor 伪造的。

接下来就是按照 Debian 的官方流程来进行申请。

经过一番辛苦成为 DM 之后,便可以考虑是否要申请 DD 以及可能的申请计划。申请 DD 的要求比 DM 更细致,涉及的方面也更多。DM 和 DD 都拥有或多或少的特权,如此多的要求是为了确保申请者能够正确把握手中的特权,为社区做积极的贡献。如果觉得这个过程好繁琐,那么就不要申请 DM,直接参与到维护过程中,其区别如前所述仅仅是能否直接上传而已。

附:Debian 项目里一些名词的含义

1. Maintainer: 泛指软件包维护人员,包括 Debian Developer (DD)、Debian Maintainers (DM) 和 Sponsored maintainers。

2. Debian Developer (DD): 又称 Debian Member,官方 Debian 开发人员,是 Debian 项目的正式成员。能直接上传到 Debian 的任意仓库,有大部分服务器的登陆帐号,有在全项目内选举、投票和提出议案的权利。

3. Debian Maintainer (DM): DM 是一部分能够直接上传某些特定软件包的开发人员,是打包人员通向正式 Debian Developer 的必经之路。

3. Sponsored maintainers: 很多开发人员没有申请 DM/DD,而是选择通过一位 DD 来协助上传软件包。他们对于自己的软件包和其他开发人员没有任何更多的区别,同时又不必去经历相对繁琐的申请流程。

4. Non-uploading DD: Debian 为迎接那些不参与打包,但是参与文档、翻译、网站和设施维护等工作的人进入 Debian 社区所设立的 DD 类型,与其他 DD 的区别是没有上传软件包的权限。(参考文档

5. Sponsor: 协助其他没有上传权限的开发人员,检查软件包并将符合要求的上传到官方仓库的 Debian Developer。

6. NM Process: New Maintainer Process,一位 Sponsored Maintainer 或 DM 申请成为正式的 DD 的过程,需要经过 ID Check, Process & Procedure 和 Task & Skills 等多项测试。不要将 NM Process 误认为是申请 DM 的流程,它是申请 DD 的。

7. Advocate: 一位现任的 Debian Developer 以个人名义向 Debian 项目正式推荐某人成为 Debian Maintainer 或 Debian Developer。

8. Debian New Maintainer: 又称 Applicant、Perspective Maintainer 等,是正在申请成为 DD 的人。不要与 DM 混淆,这是申请 DD 的人。

9. Application Manager (AM): NM Process 中申请人被确认有现任 DD 推荐后,会有一位专门的负责人来对他进行考核,这个人就是他的 AM。

10. WNPP: Work-Needing and Prospective Packages 的缩写,指需要有人接手或帮助的软件包。这个概念不是模糊的,而是有明确的定义的。

11. MIA: Missing In Action 的缩写,指某位 Maintainer 长时间不参与维护自己的软件包,同时别人也没能成功地与之取得联系。这样的 Maintainer 被称为 Zombie Maintainer 。如果他是 DD,那么他的 Debian 项目帐号会被锁定,一年内无回应则会删除。

12. Debian Project: Debian 项目是构建自由的通用操作系统(The Universal Operating System)而自发组织的,致力于满足各种各样的用户需求,并执着于追求其自身所信仰的“软件自由”。参阅 Debian Social Contract (Debian 社会契约),DFSG(Debian 自由软件指导方针) 和 Debian Constitution (Debian 宪章)。

申请成为 Debian 开发人员需要经历一些看似繁琐的过程,尤其是申请 Debian Developer 所需要经历的 NM Process,笔者认为来者难免会望而生畏,不胜其烦。如果你有这样的感觉,不妨看看这个幻灯片:Debian New Maintainer Process: History and Aims by bubbles, moray and daf.

Things to do before becoming a Debian Maintainer

Today I received a mail asking me to give him some advice on how to become a Debian Maintainer and Debian Developer, I am glad to hear more people getting interested on joining Debian, :-)

The 1st thing to keep in mind is that, involving Debian’s development is easy, but becoming something _official_ requires a lot of time and efforts, so just be patient, :)

Here are my advices:

  • 1. Become a regular user of Debian (use it to do your everyday work as much as possible, in other word you have to be a user before you are a developer).
  • 2. Learn to make Debian package by reading Debian New Maintainer’s Guide[1]. This step gives you some basic ideas and methods on how to package software for Debian, but it’s still a bit far from making your package fits the Debian standards. You can find an existing package to work on it independently and then compare your work with the official one so you can find if there is any thing you still don’t know yet. Please don’t make very complex package here because it may just cost you many time on figuring out problems. It’ll be good if you ask some skilled people to give their opinions on your work (and in fact you can ask at any time before, during and after the process).
  • 3. Find a software that you are interested in packaging it, and make sure you have enough knowledge/time to make and maintain it in the foreseeable future, if you can’t do either of the two you should find another one to work on. Then, package it and check for any problems you can find, never try to hide problems when you are stucked, what you need to is do is just asking others for advice and mentoring, :)
  • 4. When you believe your package is made to the best condition that you can do, find an official Debian Developer to check your package and to see whether it’s ready to become part of Debian release (he’s called a _sponsor_).

    If there is one would like to help, he would do a throughout check on your package and find problems (and land mines) as much as he can. He might reject your package and ask you for improvements, then don’t be shy and just do what he has advised (DDs always think it is a good time to train new maintainers) and send your result back. Finally he is satisfied and uploads you package to Debian archive.

    Try to get your first package uploaded as soon as possible if you’d like to achieve your aim at becoming DM/DD.

    You’ll have to read Debian Policy Manual[2] if you haven’t read it yet, and you may need to read it for several times while you are making your package. If you have enough time, it’ll be better if you read Debian Developers Reference[3] as well.

  • 5. It does not mean you can be a DM as your first (or even more) package being uploaded. Your sponsor must be convinced that you have the ability to manage upcoming updates and bug reports for some specific package and then he would be happy to advocate you. This could usually be achieved by several good uploads (means he is satisfied with your work and nothing is required to be changed) and some bug management (optional). You can talk to your sponsor about advocating you to be a DM when you see fit.
  • 6. It’s a requirement that your GPG key is signed by at least one Debian Developer and your key must be 2048R or stronger. If you don’t have, try to get one while you are processing the previous steps. Key signing does not need any skill-based judgment and you only need to find and meet some Debian Developers so they can check your identity.
  • So you are a DM after some time of hard work, then you could plan on becoming a DD now. Being a DD is much more complex than becoming a DM, since you’ll have many privileges and people have to make sure you have the ability to use it correctly. You’ll need to read through all Debian documents and read/ask again about the details then.


    在 Ubuntu 上换用 OSS4 声音系统

    首先介绍下背景,Linux 音频系统非常不完全简史:

  •  1. OSS3 是 Linux 内核中比较老的声音系统,目前已逐渐废弃
  •  2. OSS4 开发的时候是闭源软件,所以 2002 年 ALSA 被用来替代 OSS3 作为 Linux 内核中的声音构架
  •  3. 2007 年的时候 4Front Technologies 发布了 GPL 版本的 OSS4,此时 ALSA 已成气候
  • 关于 ALSA,OSS4,PulseAudio 和 Jack 一知半解版介绍(Esd 等就此省略一万字):

  •  1. ALSA 目前是 Linux 内核上标准的音频框架,但是仅支持 Linux 系统,没有软件混响。对各种设备的支持非常全面。
  •  2. OSS4 由于错过时机而没能成为官方内核的一部分,但是它的跨平台性远好于 ALSA,支持 Windows、BSD 和许多 UNIX,其 API 据说也更适合开发。OSS4 有实时、低延时的特性,支持软件混响,所有操作在内核层实现。但是对 USB 设备的支持明显薄弱许多。
  •  3. PulseAudio 是为 POSIX 兼容环境设计的一个声音代理程序,内置软件混响。PulseAudio 可以将程序对声音系统的请求代理到 ALSA、OSS 等多种后端,甚至可以通过网络传输这些讯息。
  • 4. Jack 是一个专业级的声音服务系统,跨平台性强,其表现对内核的实时性要求较 PulseAudio 高一些,在一般的操作系统上 Jack 没有前者流行。
  • Ubuntu 默认使用 ALSA 作为底层声音驱动,程序则与 PulseAudio 交互,这是一个很不错的方案。然而作者偶尔会遇到 ALSA 被独占其他软件无法发声的问题,才随着 -cn 上的 OSS4 热潮赶了把时髦。

    换 OSS4 是要折腾的,折腾就是有风险的,以下为折腾的理由:

  • 1. 默认的 ALSA 在你的电脑上不能正常工作
  • 2. 纯粹喜欢 OSS4,不喜欢 ALSA
  • 3. 想要跟风折腾
  • 换 OSS4 的具体好处:
    1. 某些情况下音质更好
    2. 低延迟,低 CPU 占用
    3. 自带软件混响
    4. 文档更全面

    换 OSS4 的具体坏处:
    1. 有些硬件不被支持
    2. 对 midi 支持很差
    3. USB 声音设备支持仍处于试验性阶段
    4. 自己折腾可能会把系统声音系统搞跨

    开始说安装 OSS4 的具体方法。
    到 OSS4 官方网站下载免费商业版, 下载页面
    选择相应的版本,比如 Linux 2.6 (x86) (DEB),点 Submit 获得下载链接。注意这个版本按许可证仅可以使用一年。
    得到 deb 文件后双击安装(或者 sudo dpkg -i oss-linux*.deb)。
    Ubuntu 10.10 可以直接从软件仓库安装版本略旧的 OSS4:
    sudo apt-get install oss4-base oss4-dkms oss4-gtk
    Ubuntu 10.04 和 11.04 不可以使用这个方法,10.04 仓库中的 oss4-dkms 存在打包问题无法正确构建内核模块,11.04 因为内核新(linux >= 2.6.36)而 oss4 版本太老而无法成功构建内核模块。
    首先安装 mercurial 以便取回最新版代码:
    sudo apt-get install mercurial
    cd ~
    hg clone http://opensound.hg.sourceforge.net:8000/hgroot/opensound/opensound oss-devel

    创建编译目录,OSS4 需要在空目录编译:
    cd ~/
    sudo rm -rf oss42build
    mkdir oss42build

    编译并安装,假设你的主目录是 /home/aron:
    cd oss42build/
    NO_WARNING_CHECKS=yes /home/aron/oss-devel/configure --enable-libsalsa=NO
    sudo make deb
    sudo dpkg -i oss*.deb

    1. 尽管 OSS4 内建了软件混响,我还是没有删除 PulseAudio,因为 Ubuntu 的桌面环境很多部件仅设置了 PulseAudio 后端。我不想一一折腾,而只是尽量让程序使用 OSS4,毕竟主要的播放器等都支持自定义音频输出。如果你也这样想,照下面做;如果你不想,跳过这段。

    A. 修改 PulseAudio 设置使其默认使用 OSS4 输出:
    gksu gedit /etc/pulse/default.pa

      load-module module-oss device=”/dev/dsp” sink_name=output source_name=input mmap=0

    B. 配置 gstreamer 使用 OSS4 作为后端:
    安装 gstreamer0.10-plugins-bad
    sudo apt-get install gstreamer0.10-plugins-bad
    将输入和输出均设置为 OSS。

    C. 设置 libasound 将传递给 ALSA 的声音请求转至给 OSS4:
    gksu gedit /etc/asound.conf

      pcm.oss {
      type oss
      device /dev/dsp

      pcm.!default {
      type oss
      device /dev/dsp

      ctl.oss {
      type oss
      device /dev/mixer

      ctl.!default {
      type oss
      device /dev/mixer

    D. 配置启动时默认启用 OSS4 而非 ALSA:
    sudo dpkg-reconfigure linux-sound-base
    选择 OSS 而非 ALSA 或 default。

    然后重启电脑,系统级配置基本完成。然后可以给支持自定义音频系统的软件配置成使用 OSS4,比如 Audacious,Wine,Audacity,VLC, (s)mplayer,clementine。

    2. 如果你想删除 PulseAudio,也有办法,但是不保证所有程序都能正确输出声音。首先是按照前一种配置方法里的 B、C、D 调整设置,然后按照 E 和 F 对 PulseAudio 开刀。

    E. 使用 GStreamer 接管 GNOME 声音系统,安装为 GStreamer 后端编译的 libcanberra:
    sudo add-apt-repository ppa:dtl131/ppa
    sudo apt-get update
    sudo apt-get purge pulseaudio
    sudo apt-get upgrade

    F. 配置 Rhythmbox 等程序使用 Gstreamer (没错,还需要配置)
    找到 system/gstreamer/0.10/audio/default,将其中所有仍被设置为 pulsesink 的键(如 musicaudiosink 和 chataudiosink)都改为 osssink。
    系统默认的音量控制插件会失效,因为它是基于 PulseAudio 的,可以在面板上单击右键,添加一个 GNOME 的声音控制。

    1.Flash,需要安装 flashplugin-nonfree-extrasound 来获得支持 oss4 的 libflashsupport。
    2.Firefox,xulrunner 无法编译成同时支持 Alsa 和 OSS4,所以可能有问题。


    1. 声音输入不能用,或者有噪音
    在显示的界面里把 pink 下拉菜单中选成 input,勾选界面里所有的 input-mix 和 input-mix-mute,然后在 pink 处拖动滑块减小音量,一般以 80% 上下为宜,否则会有噪音。

    2. 如何查看是否已经加载了 OSS4 内核模块,以及我的声卡用了什么模块?
    lsmod | grep -i oss
    比如我是 HD Audio,输出如下:

      oss_usb 104136 1
      oss_hdaudio 144219 3
      osscore 545146 2 oss_usb,oss_hdaudio

    3. 如何查看我的声卡型号?
    lspci | grep -i audio

    4. 64 位系统能用吗?

    5. KDE4 用 Phonon,能用吗?
    Phonon 默认应该可以直接检测到 OSS4。KDE 4.0.x 用 Xine 后端时可能无法使用。

    6. 用什么调节音量?
    如果保留了 PulseAuido,则使用它的程序可以用原来的音量控制,如果是用 Gstreamer,则可以使用 GNOME 的音量控制程序。
    当然,也可以直接使用 ossxmix 工具调整,或者例如 xfce-oss、kmix 这样的工具。

    不想用 OSS4 了,怎么复原?
    我针对上面的 A B C D E F 分别说需要的操作。

    A. 恢复 PulseAudio 默认的硬件检测
    gksu gedit /etc/pulse/default.pa

    B. 配置 gstreamer 使用 PulseAudio 作为后端
    将输入和输出均设置为 PulseAuido。
    如果你不想要 gstreamer0.10-plugins-bad,可以删除它:
    sudo apt-get purge gstreamer0.10-plugins-bad

    C. 设置 libasound 使用 ALSA:
    删除 /etc/asound.conf 中增加的所有行。如果你开始折腾 OSS4 之前没有对它做过修改,直接删除就行:
    sudo rm /etc/asound.conf

    D. 配置启动时默认启用 ALSA:
    sudo dpkg-reconfigure linux-sound-base
    选择 ALSA。

    E. 换回支持 Gstreamer 和 PulseAudio 的 libcanberra 后端:
    sudo apt-get install pulseaudio indicator-sound libcanberra-pulse libcanberra-gstreamer pulseaudio-esound-compat pulseaudio-module-bluetooth pulseaudio-module-gconf pulseaudio-module-x11 ppa-purge
    删除添加的 PPA:
    sudo ppa-purge ppa:dtl131/ppa
    sudo apt-get update


    F. 配置 Rhythmbox 等程序使用 PulseAudio
    找到 system/gstreamer/0.10/audio/default,将其中所有仍被设置为 osssink 的键都改为 pulsesink。

    然后把所有前面修改过使用 OSS4 的程序都换回使用 PulseAudio,重启系统。

    1. 为常见应用程序配置 OSS4:Configuring Applications for OSSv4
    2. 故障处理:OSSv4 Troubleshooting
    3. Archlinux Wiki 上的 OSS 页面:英文 中文

    Ubuntu 里的 ibus-pinyin

    前面写的《Ubuntu 中文拼音输入法小结》中说 ibus-pinyin 是 Python 写的,存在一些谬误。ibus-pinyin 已经用 C++ 重写,并且做了很多改进。

    可能有些用 Ubuntu 的朋友要问为什么现在还会有那些崩溃的现象,其实这是发行版的问题,迟迟没有能将新版推送到用户手中。

    感谢 Shawn P Huang,Shellexy 和 BYBird 的提醒,博客上的那篇文章也做了更新。

    Linux input method framework brief summary

    I am trying to keep this article concise for you to make you have an outline of current condition of Linux (and maybe other platforms like BSDs) input methods. It’s coverage is mostly CJK languages, but I think other languages that use input method would be sure to find there examples in this article. We will start with the most popular ones, and there will be some hints about other ones at last.

    Before we start our tour, there are two concepts to know, input method framework and input method engine:

  • An input method framework is designed to serve as a daemon and handle user input events, output the result to target applications or layers.
  • An input method engine is a program to analyze inputed characters and calculate a list of probably results, then send the results to their hosted input method framework to complete the reaction with users and applications.
  • 1. SCIM (Smart Common Input Method)

    Most Linux input method users may have the experience of using SCIM, which is created by Chinese developer Su Zhe for promoting his Intelligent Pinyin input method and providing a better input method framework.

    Some friends of mine are still keep using SCIM even though it is not being maintained, nor SKIM, its sister project on KDE. SCIM was the default choice of distros for years. People developed lots of input method engines for it, for example scim-pinyin, which has been mentioned above as Intelligent Pinyin input method. Users may be also familiar with scim-python, scim-xingma-*, scim-googlepinyin and the still-maintained scim-sunpinyin.

    On a distro maker’s point of view, the glorious age of SCIM has just finished.

    2. IBus (Intelligent Input Bus)

    IBus is the de facto standard of input method framework on nowadays Linux distros, whose author is a Chinese developer, Huang Peng, who has been mentioned as the author of scim-python and scim-xingma-*. IBus is aiming at a “next generation input framework” comparing to SCIM. I think this goal has been achieved – new comers may only know IBus from the very beginning of his adventure on Linux.

    IBus is written in C++, and is designed to be highly modularized: core input bus, gtk/qt interfaces, python binding, table engine, table modules and other input method engines. It uses Gtk immodule, thus is the best choice for GTK+ applications. What’s more, Flash Player support Gtk immodule only and IBus has no problem to work with it. The author of IBus is really helpful with other input engine developers, so there are many input method engines available on IBus framework.

    But IBus has obvious limitations from its design:

  • Firstly, it uses Gtk immodule only, which benefit GTK+ platform applications, but do poorly with QT.
  • Secondly, it depends on gconf, which is unacceptable for some users and distro makers (most of them are anti-gnome holic).
  • Thirdly, the most used input engine, ibus-pinyin is written in Python that caused serious performance limitation. And this engine has had some severe bugs like memory leak and dead loop (100%). Even though the condition is largely improved, users are still complaining about them.
  • Fourthly, the alternative Pinyin engine ibus-sunpinyin is not well maintained, and really lacks of testing. There are some obvious bug leaving their without people interested to fix.
  • Note: ibus-pinyin has been rewritten in mainly C++ with many improvements, and such changes will land on major in very near future (maybe some of them have already published it, I didn’t do a detailed research here).

    3. Fcitx (Free Chinese Input Toy for X)

    Fcitx is an old and new input method. It bears at the same time as SCIM, and now gets a new life with the brand new 4.x series. As name suggests, it is first designed to be a Chinese specific input method by Yuking. During 3.x series, the aim of being a feature rich Chinese input method gave it quite a few of fans, but also kept it from being a default choice of major distros. Fcitx uses XIM, which works well for most platforms (like GTK+ and QT), but has some small problems.

    However, starting from 4.x series, Fcitx has been given a new goal with a new maintainer – a college student at Peking University, Weng Xuetian. Now he has published 4.0.1, the second version of 4.x series, with features like customizable skins, tables which has been wanted for a long time. It has been heavily modularized: all tables are separated, developer-friendly input method engine interface, graphic user configuration tool. Also, 4.x series does not use GBK encoded Chinese configuration files anymore, and UTF-8 encoded English configuration files are used. I would like to highlight its perfect user experience of fcitx-sunpinyin, it is worthwhile for every Pinyin users to give a try.

    There are still issues on its way of (probably) being the default of distros:

  • Though the author has promised Gtk immodule support in 4.1.0 release, the feature is still not available now.
  • The internal Pinyin input method is old, and still not being separate out from the framework core because of too close integration before. The work will be done in 4.1.0 as well.
  • Fcitx is still lacking of people who are interested in developing input method engines, even if the interface is more friendly to developers. There is an example, fcitx-sunpinyin (written in C++) has only ~300 lines to make everything work perfectly with libsunpinyin.
  • Properly speaking, Fcitx is still not a input method framework because of the reasons listed above, but it will be, also as said above.

    Above are the most famous input methods, here is a list of other things in Linux input methods with short descriptions.

    1. ucimf (Unicode Console Input Method Framework)

    ucimf is an input method framework for Linux unicode framebuffer console, which is mainly with fbterm and jfberm. It is developed by Chinese developer, Mat. He maintains a series of input method engines ported from BSD licensed Mac OSX input method OpenVanilla.

    There are other solutions under framebuffer console, for example ibus-fbterm (development has stopped), but I still recommend to use ucimf because it full featured and well maintained.

    2. SunPinyin

    One thing to clarify, Sunpinyin isn’t a frame work, but it is important so I would like to mention it here. We have mentioned scim-sunpinyin, ibus-sunpinyin and the recommended fcitx-sunpinyin. In fact there is also a standalone xsunpinyin alive. SunPinyin is a statistical language model based Chinese input method, which was firstly developed by Sun Beijing Globalization team, and opened source to community with Opensolaris project, with LGPLv2 and CDDL dual-licenses.

    SunPinyin would be heavily used from now on, it is the best Pinyin engine on Linux and some other platforms.

    3. SCIM2
    SCIM2 was trying to be a next generation SCIM, but abandoned because of the emerging star during that period – IBus.

    4. ImBus

    ImBus is created by the author of SCIM, and he would like to make it a general input method framework including all known best techniques with minimal dependencies. But the project halted with the same reason like SCIM2, no code in its svn repository.

    5. Fitx (Fun Input Toy for Linux)

    Fitx was a flash in the pan on Linux, the project stopped soon after its emerging. Fitx is a ported version of FIT input method on Mac OSX, but implemented using SCIM framework.

    6. gcin
    gcin is a input method developed by traditional Chinese community, targeted to traditional Chinese users.

    7. uim

    uim is a input method framework made by Japanese developers. It is a little different because uim isn’t an input method server (XIM is a server), it’s just a library. Because the designer believe many people don’t need a full featured platform but only something enough to work.

    For information about input method types, there is a good website: http://seba.studentenweb.org/thesis/im.php

    2011-01-15 21:30
    Thanks to Zhengpeng Hou, I’ve added some description about uim, and a notice about whether fcitx should be considered as a framework now.
    2011-01-28 00:15
    Thanks to Shawn P Huang, ibus-pinyin has been rewritten in mainly C++ with many improvements.

    This work by Aron Xu is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.