Amarok2中的MySQL-真相(渣翻译)

原文链接:http://amarok.kde.org/blog/archives/812-MySQL-in-Amarok-2-The-Reality.html

08年的老文,看有人聊到KDE里面的MySQL用的很多时搜索了一下,结果发现了这篇文章。读完之后,突然想翻译一下了。看到最后感觉感触颇深啊,真的,开发过一些小玩意,面对着或多或少的真正用户,心有戚戚焉,虽然这么讲也许有点妄自尊大,可是还是忍不住,想要做出更好的东西给大家……翻译完了之后略修改了一下,结果发现有很多看起来很囧的错误……有不少地方是意译,欢迎指出错误。每段都附上原文对照。

最近关于Amarok将MySQL作为唯一SQL后端这件事上有许多讨论。相当的一部分是对于不确定的恐惧——有些仅仅是人们对于改变的抗拒,有些仅仅是不理解这个决定。有些讨论(特别是Adriaan的博文)很有意思,并且有着深刻见解,但是却忽略了为什么做出了这些改变。本文尝试去解释为什么做出了这个决定,这个决定对于一个最终用户意味着什么,为什么你应该喝口茶歇一歇。

There has been a lot of chatter lately regarding Amarok’s switch to MySQL as its only SQL backend. A decent amount is FUD — either by people simply pushing back against change, or by people that simply don’t understand the decision. Some of it (particularly Adriaan’s blog post) has been insightful and interesting, but miss the mark in terms of why this change was made. This post attempts to explain why this decision was made, what it really means for you the end-user, and why you should have a cup of tea and relax.

我想首先指出的是,我说过MySQL将会成为Amarok的唯一SQL后端。Amarok2的收藏系统很强大。看看有多少各种各样的音乐源吧,来自Shoutcast的,Jamendo的,Magnatune的,Ampache的,MP3Tunes的,还有来自本地的,比如来自iPod和本地的文件系统,它们在Amarok2当中都被同等对待了。Amarok1的收藏仅仅是个收藏,并且被它自己所声明的功能限制了(当然,他能提供它自己的特定功能)。虽然我不这么想,但是同时还有一个基于Nepomuk的收藏选项没有被启用。(注:这个i don’t think看的我一头雾水)所以振作一点,这个变化只是影响Amarok的内部SQL收藏,但不包括其他来源(尽管如果那些来源乐意,他们也可以把信息存储在SQL数据库中)。

I want to point out first that I said that MySQL is going to be Amarok’s only SQL backend. A2’s collection system is very powerful. Just take a look at how varied music sources from Shoutcast, Jamendo, Magnatune, Ampache, MP3Tunes, as well as local sources like iPods and your local file system, are treated as equals in A2. A collection is a collection, and is limited only by what capabilities it advertises it can support (and of course, it can supply its own custom capabilities). It’s not currently enabled, I don’t think, but there’s a Nepomuk-based collection option too. So take heart — this change only affects Amarok’s internal SQL collection, and not other sources (although those sources can store information in the SQL database if they wish to cache information).

由于我提到了Nepomuk,我们也来谈谈另一个普遍的问题/需求/抱怨:KDE已经有了很好的Strigi-Nepomuk在工作,为什么我们不用它来搜索音乐并且存储信息?这有很多原因。第一个原因是Strigi和Nepomuk是可选的,并非必要的。(更新:Strigi是必要的,但Soprano不是,所以Nepomuk从整体上来说还是可选的。)我们不能指望用户安装了这些,而且就算他们安装了,我们不能指望用户正确地配置了他们(注意由于我们的计划是跨平台,这使得这件事更不大可能了)。第二个原因是速度:Amarok的自定义收藏扫描的速度非常快,并且利用taglib收集特定的信息。和Strigi比较起来,Strigi的速度就太慢了(它需要计算所有文件的哈希值,这意味着它将会读取整个文件),并且取得较少的信息。(更新:照Strigi开发者的说法,而不是在kde-apps.org, 维基百科,甚至在作者自己主页上的描述,Strigi默认并不计算文件的哈希值。这使得对于Strigi来说,如果配置得当的话,和Amarok的内置扫描相比能够一样快。尽管我不知道它是否将所有需要的信息都提取出来。但如果它配置成需要计算所有文件的SHA1哈希值,那么它肯定会非常慢。)在本地硬盘上,这并不是一个大问题,但是当你将基于网络的存储纳入考虑范围内的时候,这就是个大问题了,而且这是一个非常普通的场景。同时尽管我不记得细节了,但我也听说,和一般的SQL数据库相比,对Nepomuk的查询是很慢的。同时记得当基于Nepomuk的收藏完成的时候,来源于基于Nepomuk的收藏将会把它们的元数据修改存回Nepomuk当中。所以SQL收藏并不是Nepomuk的替代——它们是完全独立的。(更新:我忘记提到基于Nepomuk的收藏已经存在了。它已经由GSoCer在暑假开发完成。我不确定它的状态是否可以赶上2.0的发布,但是我们这些Amaroker都很喜欢Strigi/Nepomuk,并且对于打开应用程序之后所有音乐都正确可用,并且不需要任何预先配置这个点子感到兴奋。但是SQL收藏也确实占有一席之地。正如我说的:它们都是很好的技术。)

Since I mentioned Nepomuk, it’s time to discuss another common question/demand/complaint: KDE has this nice Strigi-Nepomuk thing going on…why aren’t we using it for scanning music and storing information? There are a couple main reasons. The first is that Strigi and Nepomuk are optional, not required. (Update: Strigi is required, but Soprano isn’t, so Nepomuk as a whole is still optional.) We can’t rely on the user installing them, and even if they are installed, we can’t rely on the user to configure them properly (remember that we’re going cross-platform, making it even less likely). The second reason is speed: Amarok’s custom collection scanner is extremely fast and pulls out specific pieces of information with TagLib. Strigi is, by comparison, very slow (it calculates hashes of all files, which means it needs to read the entire file) and pulls out less information. (Update: According to the Strigi developer, and despite what is said on kde-apps.org, Wikipedia, and even the author’s own home page, it does not calculate hashes by default. So it’s possible that Strigi, if properly configured, could be as fast as Amarok’s internal scanner, although whether it would pull out all necessary information, I don’t know. If it’s configured to calculate SHA1 hashes of all files, then it will indeed be far slower.) On a local hard drive, it may not be a big issue, but it sure is a huge issue when you throw networked storage into the picture, which is a very common scenario. I’ve also heard, though don’t remember specifics, that querying and such through Nepomuk is rather slow, compared to a normal SQL database.  Regardless, though, remember that when the Nepomuk-based collection is finished, tracks sourced through a Nepomuk-based collection will have their metadata changes saved back to Nepomuk. So, it’s not that the SQL collection is in place of Nepomuk — they are entirely independent. (Update: I forgot to mention that a Nepomuk collection already exists. It was developed by a GSoCer over the summer. I’m not sure what its status is as far as making the 2.0 release, but we Amarokers both like Strigi/Nepomuk and are excited about the idea of opening up the app and having all your music available right then and there with no pre-configuration. But there is a place for the SQL collection too. As I said: they are complimentary technologies.)

我们已经跑题了,现在回到正题上。

With those topics out of the way, on to the meat.

首先,理解两个关键的事实是很重要的。第一,我们不是搞数据库的。是的,我们可以把数据存进数据库,并且或多或少的提供一个工作的模式(注:Schema,因为平日和别人讨论都用这个词的英文(注之注:我是搞数据库的)……我一直纠结于要不要直接用Schema,后来还是用了模式这个词),但是我们当中没有一个是专家/天才/绝地武士/等等。这导致了第二个事实:维护三个数据库快把我们整疯了。每次一个很小的模式变动都需要对三类数据库进行编码。对于模式的修改对于一个数据库可能就是些琐碎的小事,对于另一个就可能非常困难(甚至不可能)。人们会回报那些我们无法重复的Bug,最后仅仅发现因为我们不能理解这些数据库是如何具体工作的(或者在另一些情况中,没有任何一个活跃的开发者使用那个类型的数据库)。还有许多类似的事情。所以在Amarok2开发之初(在Amarok1开发时的幻想中),我们就知道我们只想要一个数据库。

First, it is important to understand an important pair of facts. Number one: we are not database guys. Sure, we can store data in them, and more or less come up with a working schema, but none of us are gurus/wizards/jedis/etc. This leads in to number two: maintaining three databases was driving us crazy. Every time a minor schema change was needed, it had to be coded up for all three types of databases. Modifying a schema could be trivial for one database type, and super difficult (or impossible) for another. People would report bugs that we couldn’t reproduce, only to find out that it was because we didn’t quite understand how one database or another behaved (or in some cases, none of the active devs were using that type). And so on. So from the beginning of A2 development (and in our fantasies during A1 development) we knew we wanted just one database.

(我们确实看了那些抽象层,例如QtSQL等等。我不想过多的评论他们,因为我并没有对他们进行评估,但是总的说来如果不进行一些特定的SQL编程,他们并不灵活到足以应付我们所有需求(特别是在一些修改模式的任务上),这导致我们没有采用他们。如果你确实想知道更多信息或者坚持认为他们足够应付任务,问问eean,我想他对他们做了评估。)

(We did actually look at abstraction layers like QtSQL and others. I’m not going to comment on them much, as I didn’t do the evaluation, but in general they were found to not be flexible enough to handle all of our needs without doing some custom SQL coding (especially in the cases of things like schema changes), which kind of defeats the point. If you want to know more/want to insist that they are, try asking eean, as I think he did the evaluations.)

现在我们必须选择一个数据库。第一眼看来,SQLite是个不错的选择。使用事务的话,他的速度很快。十分稳定(那些抱怨奇怪的MySQL的bug的人应该和markey谈谈,他是1.4的SQLite后端维护者,可以证实SQLite有他的一席之地)。但是还是有一些问题把它踢出局了。第一个问题是性能。尽管对只有一个小收藏的人来说它工作的很好,有着大量收藏的的人在换到MySQL或者PostgreSQL之后汇报了他们在进行复杂或者很多查询的时候获得了很大的速度提升,例如把很多项目加入播放列表的时候,扫描文件的时候,以及对收藏进行搜索/过滤的时候。由于我们想要调和那些有着大收藏和小收藏的人的需求,并且数字音乐收藏的规模并没有缩小的趋势,有着大收藏的人的数量增长速度是很重要的。许多我们的开发者,在切换到mysqle(我们这么叫它,尽管这不是官方名称)之后,在每日的Amarok2使用中,注意到了巨大的速度提升,因此嵌入式服务器和一般的服务器相比也能带来速度提升。这是对SQLite的第一拳。

Now we had to choose the type. At first, SQLite seemed like a good choice. Using transactions, it’s decently fast. It’s pretty stable (those that complain about odd MySQL bugs should talk to markey, as he, being the SQLite maintainer in 1.4, can attest that SQLite’s had its fair share). However, there were a few problems that in the end knocked it out of the running. The first problem is performance. Although for people with small collections it performs fairly well, people with large collections that switched to the MySQL or PostgreSQL backends in A1 would report enormous speed gains when operations performing complex or many queries were performed, such as adding many entries to the playlist, scanning files, or filtering/searching in the collection. Since we want to accommodate users with large collections just as well as those with smaller collections, and since digital music collections aren’t getting smaller, the speed increase for our users with large collections was quite important. Many of our developers, after the switch to mysqle (as we call it, though that’s not the official name), have noticed huge speed increases in their day-to-day use of A2, so that speed increase is carrying through to the embedded server as well as the normal server. That was the first knock against SQLite.

另一个使我们不采用SQLite的原因是完全不同的。许多用户(包括我自己在内)有许多电脑,但是却只有一个Amarok数据库。假定所有电脑都可以通过一个挂载地点访问音乐(其他东西也配置正确),这使得你可以只扫描一次,但能在其他所有地方播放,无论在那里播放音乐都可以对同一个评分进行更新,还有其他很多事。就算你并不在多台电脑间共享数据库,许多用户由于速度,安全性,和备份的原因,也想要把数据库存储在一个特定的服务器上。如果你认为这并不是一个通常的用例,那么你就错了。MySQL和PostgreSQL对于这样的工作量工作的很好。对于SQLite就行不通了,因为它是为了一个不同的目的而设计的。因此SQLite被两击直拳重击,KO。

The other blow for SQLite came for a totally different reason. Many users (myself included) have multiple computers sharing a single Amarok database. Assuming all the computers have access to the music at the same mount point (and a few other things are configured right), this allows you to scan once, play everywhere, update the same ratings no matter where you play it, and more. Even if your aren’t sharing the database among multiple computers, many users want their database stored on a particular server for speed, security, or backup reasons. If you think either of these isn’t a common use-case, you’d be quite wrong. MySQL and PostrgreSQL were quite happy with this workload. It’s a total no-go for SQLite, simply because it’s designed for a different purpose. So SQLite had two big knocks against it. K.O.

但是,正如我们不能指望用户正确的设置了Strigi/Nepomuk那样,我们不能指望他们设置好了MySQL和PostgreSQL的数据库的表。因此我们需要数据库能够嵌入式的运作,这样它就能够在不做任何其他设置的情况下工作了。MySQL,和libmysqld,在4.1系列当中有着初步的支持,在5.0当中它就工作的很好了,并且在5.1中就被完全支持(据我所知)。PostgreSQL,相比较而已,没有这种功能。(但他有一个他们自己的有趣的嵌入式SQL的概念。更新:显然这现在成为了SQL标准的一部分。还是很酷。还是和我们认为的我们刚才谈到的嵌入式服务器不是一个东西。)

However, just as we can’t rely on the user to set up Strigi/Nepomuk correctly, we can’t rely on them to get their tables set up in MySQL or PostgreSQL. So we needed the database to be embeddable, so that it could just work for the user without any setup necessary on their part. MySQL, with libmysqld, had the seeds of this in the 4.1 series, it works decently in 5.0, and it’s becoming fully supported (AFAIK) in 5.1. PostgreSQL, on the other hand, does not have any such thing. (They have an interesting and cool concept of their own of embedded SQL though. Update: apparently that is part of the SQL standard. Still pretty cool. Still totally different from what we mean when we are talking about an embedded server.)

这使我们只剩下一种选择——正如你所猜想的那样——MySQL。它也许不是某些人最喜欢的数据库(尽管它是大多数人的),而且我并不了解究竟在运行嵌入式模式的时候多少真正的额外开销,但它确实完全符合要求。它同时可以按嵌入式在本地运行和或者用独立模式在其他的机器上运行(是的,这还没有在Amarok2当中被支持,但这会被支持的)。对于大收藏来说,它的速度很快,也很健壮。它被开发组的人员充分了解。最重要的,它可以作为唯一的后端解决我们所有的需求。

So this leaves us with — as you guessed — MySQL. It may not be any particular person’s favorite database (although it is for plenty), and I don’t know how much overhead it really has in embedded form, but it fit the bill. It’s both embeddable and can run standalone on the local or a separate machine (yes, this is not supported yet in A2, but it will be). It is fast and robust for large collections. It is well understood by the development team. And most of all, it is a single-backend solution that fills all of our needs.

如果你还是对于我们决定感到不愉快,我得说声抱歉。我们尝试去满足大多数人,但是没法满足所有人。但是是我们在开发并支持它,所以我们才基于我们开发者的需求,和来自成千上万在过去几年和我们沟通联系的用户共同的现实用例做出了这个决定。请记得就算大部分在Dot上的留言,或者在这篇文章后面的评论(例如很多突然出现的回应)是来自于对这个决定不满的人,这个决定事实上还是适合大多数人的,和我们其他选择相比,它是对于大多数我们的用户来说更好的决定。

If you’re still unhappy about our decision, I’m sorry. We try to please most and can’t please everyone. But we’re the ones that develop and support this thing, and so we made a decision based both upon our needs as developers and the real-world use-cases from the collective feedback of thousands of users that have contacted us over the last few years. Please remember that even if most of the comments on the Dot, or to this post, (i.e. much of the sudden visible feedback) are from people that are unhappy with our decision, it is a decision that will actually suit the vast, vast majority of our users better than the other options we currently have.

我们这个项目众所周知对用户很友好——我们倾听他们,尽量实现他们想要的特性,尽量响应与支持。这是使我们走到今天的一个因素。所以拜托,亲爱的读者们——请相信我们。这并不是一个简单的决定——我们讨论过,争论过,扔过东西,和解了,我们在和解后进行了一两次狂欢——但最终我们全体都认为这是一条正确的路,并且我们认为,终究,这将使得Amarok更好。希望你们也这么认为。

We’re a project that is known for being good to our users — we listen to them, we try to implement features they want, try to be responsive with support. It’s one of the things that got us where we are today. So please, dear readers — put some faith in us. This has not been an easy decision — we’ve discussed, we’ve argued, we’ve thrown things, we’ve made up, we’ve had an after-the-make-up orgy or two — but in the end it’s what we collectively felt was the right way to go, and we feel that, in the long run, it will make Amarok even mores awesomer. Hopefully you’ll feel that way too.

This entry was posted in KDE and tagged , . Bookmark the permalink.

12 Responses to Amarok2中的MySQL-真相(渣翻译)

  1. 右京样一 says:
    Internet Explorer 8.0 Windows XP

    网络化的数据库……对于一个音乐播放软件究竟有多重要呢?Amarok在我这里从来没有播放过本地以外的任何媒体,当然或许在国外(的Geek那里)这种状况更普遍一些。所以我最无法理解的是为什么他们那么希望一次扫描就能在所有地方播放并且评分。

    我对MySQL没什么排斥(当然可能是因为对数据库明显缺乏了解),但是nihui大神貌似认为MySQL已经通过Akonadi严重制约了KDE的速度和硬件消耗状况(似乎不光是Akonadi,MySQL几乎已经成了KDE基本依赖了)。对于KDE4在我PC上的速度,我倒是一直挺不悦的……

    顺带一提,您换的这个新背景是我最喜欢的一张。

    [Reply]
  2. csslayer says:
    Firefox 4.0b3 Windows 7

    这个我也蛮喜欢,不过没怎么用过。用的比较多的反而是自带的那个翻译成“感性”的壁纸。
    —————————————————
    不知道哎,MySQL的性能还是不错的,要知道很多nb系统后面都有mysql的支持哦,比如Twitter和Facebook……比起PostgreSQL来。(虽然我在实验室搞过不少PostgreSQL相关开发,对PostgreSQL还挺有感情的……)
    —————————————————
    云计算化,我蛮喜欢的,某种程度上这里的广播也算这种形式的呀。不过我连vps并不方便,万恶的cernet……要不然我试试把Amarok数据库扔上来我也挺乐意的。
    —————————————————
    说到nihui大神,nihui竟然在MagicLinux里面的kde drop掉Nepomuk……这是我没有想到的……这导致我恐怕永远都不会去试试MagicLinux……
    我向来是默认设置控,控的程度到什么程度呢?就是如果出现有包含这种“下次不再显示此对话框”这种,就算是我真的真的用不到它,我也不会把对勾打上,永远尽量保持设置原样。所以Archlinux这种超原汁原味的打包方式很合我胃口。
    —————————————————
    其实我只是对其中最后一段感触颇深……其他的都是陪衬啦……(反映就是你吐槽不够到位,我好伤心)

    [Reply]
  3. 右京样一 says:
    Internet Explorer 8.0 Windows XP

    我一般不下Artwork,都是去网上找,所以也不知道啥“感性”,看来以后还是得用默认包,啊哈哈……
    //
    我不是说MySQL性能不济(MySQL好像还被评为开源界十大贡献之一),不过在一个内存不是很充足的机器上跑个数据库,消耗还是很大的,毕竟内存对系统的流畅运行起到重要作用。内存大点的话我觉得可以学Vista和7,搞个按照使用频率预加载的设计。
    //
    国外每秒几兆十几兆乃至几十兆的网速,云计算大概是够了。像我这只体验过512k DSL的人么……通常能用本地就不用网络……
    //
    Nepomuk思路蛮先进的,但是Linux控大都是性能的压榨者(Linux是服务器本命系统的关系?),所以都想着关掉它,毕竟如果安排得有条理,内容搜索并不是时刻都要用到的。不过我一直想知道的是Nepomuk是逆向搜索么?
    //
    原来重点在最后一段,领会失当,还请见谅。其实我们这些用户都明白FCITX就在走这一条路,并且支持其新改变。既然如此我就再提点意见……
    FCITX在算法上目前好像还超不过ibus,在我这里准确率和SCIM相当(当然SCIM词库很老了,所以还是FCITX表现略好),所以应该在速度和易用性上确立优势。速度方面就不用说了,易用性方面……菜单、配置程序在开发中,这都是我很支持的特性,但如果能在设置里面解决掉默认输入法的配置问题,不用让我们改XIM配置文件就更好了。ubuntu10.10貌似加了默认输入法配置面板,但在其他发行版里还未得见,如果要新手手动去改配置文件,他们大概会因为看不懂而放弃的。
    我一直有这个体会,很多东西不是难,而是我们不习惯。大概改配置文件、终端输命令等等都是很好的体现。

    [Reply]
  4. csslayer says:
    Google Chrome 5.0.375.127 Windows 7

    关于XIM不改真没辙。谁让X Server下面的输入法就这破德行呢。。ubuntu只不过提供了这么一个工具,用于帮你配置那些个环境变量。所以只能说多多推广这东西吧,顺便做出个图形化的界面来。(fedora貌似就有图形化的……)
    ———————————
    竟然比SCIM好……?囧了。我一直当fcitx拼音最差劲呢……
    ———————————
    另外老实讲算法难改,为啥呢,主要是不了解,不是一行嘛……所以参见以前的blog,想支持sunpinyin……而且这条路很靠谱。

    [Reply]
  5. 右京样一 says:
    Internet Explorer 8.0 Windows XP

    其实算法倒未必太着急。用FCITX的人多半不是冲着算法去的,盲目改算法说不定效率一下就被拉下去了,搞不好再出几个Bug,保证用户群第二周就流失一半以上……
    //
    Sunpinyin是好物啊!虽然是Solaris的,但是开源界就应该联合起来,共同壮大,打倒Windows——啊不是,是和Windows共同发展。不过要是用XSunpinyin的算法的话FCITX不就成了XSunpinyin的外壳了么?感觉是个哲学问题,到底换几块木板的船算作一条新船……
    //
    另外上面那个回复忘了说了。关于字体的问题,附带一套字体没什么的,不会有人因为一套字体嫌FCITX臃肿,毕竟效率摆在那里。

    [Reply]
  6. csslayer says:
    Firefox 4.0b4 Windows 7

    算法现在就算你让我改我也写不出来,因为不懂……好比让化学家去解决物理问题一样,或者让搞量子的去搞大气一样……行内依旧隔行如隔山。
    ——
    sunpinyin又不是没有linux版……况且open solaris这是要死啊。外壳不外壳什么的,scim和ibus不知道是多少输入法外壳了……况且fcitx的优点又不在于此。另外老输入法并不会扔掉。

    外观上来讲fcitx的应该还是很强的,对于本国用户受到的熏陶来说应该有一些优势
    其次在各个输入法上fcitx有很多小功能(这点和sogou有点类似),单字和词组置顶啦,手动造词啦,以词定字啦。
    还有貌似是唯一自带输入符号的软键盘
    自定义输入(这点是还想做得更强的,这玩意目前拿来输入自定义符号很容易,比如表情什么的)
    ——
    字体问题在早些时候已经解决了。现在的fcitx在入门门槛上应该是降低了不少,一是字体不会是方框,无论任何locale都没问题。二是运行时会提示如何设置环境变量,这点是抄ibus的,不过我可能考虑以后改成只显示一次……

    [Reply]
  7. 右京样一 says:
    Google Chrome 5.0.375.127 Windows XP

    原来如此……那么您们目前的分工就是您写外围,Yuking大神写算法么?另外我还想问个问题,写输入法算法要不要很深的数学知识?
    //
    外壳这东西,SCIM和ibus的定位就是输入法外壳,并没有附带官方的“输入法”(好像是吧,至少我没听过);FCITX是个“Input Toy”。不过原来的算法不丢掉太好了。
    OpenSolaris……其实我最早还蛮期待的,毕竟不像Linux那样各自为战,经常自己削弱自己。结果就在我热情正高的时候SUN悲剧了,之后就好久没更新,我这新PC在硬件上肯定问题更多,最后也没尝试。
    外观上来说我倒无所谓,只要kimpanel集成能保留就满足了。当然也许有很多人喜欢搜狗、紫光那些漂亮的主题,关键是整体和谐,不然一个输入法给人的感觉太突兀……
    //
    字体不方框只是最基础的要求……还有无衬线,还有矢量渲染,甚至是自定义(当然自定义可以改配置文件,但能有个图形化的前端面板就更好了)。

    [Reply]
  8. csslayer says:
    Firefox 4.0b4 Windows 7

    ——关于yuking大神
    额,关于第一条:现在的问题在于,我也不知道yuking大神去哪了……似乎没有见到他的任何动作/消息
    根据这个http://code.google.com/u/yuking.net/updates,从5月就没有任何动作了…他也许有自己事情要忙啦。

    ——关于sunpinyin
    整句输入法是算法问题,嘛,和数学也有关系。sunpinyin用的算法起码在基础上和sogou,google pinyin是同出一门,都是通过建立语言模型。fcitx现有算法打比方相当于落后一个时代,也就是和智能abc一个级别吧。
    另外我不喜欢重复发明轮子。sunpinyin以前我以为和ibus结合过紧,所以只能重写一个……现在发现完全不用担心。另外fcitx本身也支持做输入法外壳这件事,不过没人用而已。

    ——关于kimpanel
    老实讲,我还想说现在真的还有人管kimpanel吗?所以你看aur上的kimpanel-plasmoid-svn是有几个patch的,能解决几个还比较严重的问题……我也找不着人,report bug给kde也没人鸟我。看看这里,你会发现,真的,没人维护(那些都是老外,估计仅仅是修改编译错误的)。
    http://websvn.kde.org/trunk/KDE/kdeplasma-addons/applets/kimpanel/src/
    kimpanel原作者wkai兄也不知所踪,他也是fcitx-dbus的原始作者,早先我想把我修改后的fcitx-dbus合并进入fcitx的时候就想找过他……kde-cn的邮件列表也找过,没找到啊。
    另外fcitx支持皮肤之后我其实可以蛋定的说,kimpanel去一边吧。想要和kimpanel一样的效果吗?ok,改日有空我写个小程序就可以实现一下根据当前plasma主题生成fcitx皮肤。给你个小链接说明这个事情是可行的:
    第一个是根据plasma主题生成kdm主题的
    http://kde-apps.org/content/show.php?content=102760
    第二个是根据plasma主题生成compiz的emerald主题的(这个的作者是我啦,不过参照了kdm那个作者的一些code)
    http://kde-look.org/content/show.php?content=106560
    kimpanel真的性能有问题……蛮卡的。

    ——关于字体
    无衬线这玩意是系统管的,管我嘛事……
    另外我发现在皮肤里面设置字体这件事情超级鸡肋。改日还是改成是全局设置。皮肤与字体何干。

    [Reply]
  9. 右京样一 says:
    Google Chrome 5.0.375.127 GNU/Linux

    果然回帖超过原帖了呢……并且已经严重歪楼。所以这次就简单点:
    只是关于字体,貌似现在是寻到第一个字体就用,但这个字体可能既没有矢量又是白体……

    [Reply]
  10. nihui says:
    Firefox 3.6.4 Fedora

    其实,我也是默认设置控,程度和 csslayer 差不多的,MagicLinux kde 的所有包都没有自带额外的配置文件,去掉 nepomuk 是因为发行单张 CD 的原因,需要为放其它更有用的软件腾出空间,另外就是我的测试机器只有 200MB 的内存,性能上的微小差异在我这边会被放得很大,mysql 也是。
    我如今越来越不喜欢用 amarok 了,juk 更容易一些。
    ——————————————————
    新背景真的很好看 ^^:)

    [Reply]
  11. 右京样一 says:
    Google Chrome 5.0.375.127 GNU/Linux

    nihui大神现身!
    200兆内存跑KDE太艰难了……我记得我当年在256兆内存跑OpenSUSE11.1,KDE倒还真能加载,不过最后显示错误+宕机。
    KDE在我这里的特点就是开机内存占用很多,但即使开许多Qt软件,内存占用也并没有很大的增加。

    [Reply]
  12. csslayer says:
    Firefox 4.0b4 Windows 7

    老实讲,性能这事也是日新月异的……许多新游戏不会考虑过于古老的硬件,Windows本身也没有考虑过这些。

    顺便,加点内存吧,呵呵,1G只要50的样子?

    Plasma蛮占内存的……而且有内存泄露……
    ————————————————
    关于背景……你是在夸KDE的Artwork品位吗……:)

    [Reply]

Leave a Reply

Your email address will not be published. Required fields are marked *

Note: Commenter is allowed to use '@User+blank' to automatically notify your reply to other commenter. e.g, if ABC is one of commenter of this post, then write '@ABC '(exclude ') will automatically send your comment to ABC. Using '@all ' to notify all previous commenters. Be sure that the value of User should exactly match with commenter's name (case sensitive).

This site uses Akismet to reduce spam. Learn how your comment data is processed.