eMule Fans 电骡爱好者

很荣幸邀请到tHeWiZaRdOfDos以及Tuxman两位参与本次由Emule-Mods.it主办的访谈，他们是新客户端kMule的开发者。
首先感谢两位孜孜不倦的宝贵工作，其次要感谢两位欣然接收我们的采访并表现出的深情厚谊。
如果您想更加详细地了解这两位程序员，可以阅读之前的访谈内容：tHeWiZaRdOfDos – Tuxman。

1) 可能有人对两位还不熟悉。两位能先介绍一下自己吗？简单说说您在eMule项目的经历。

Tuxman:
嗨，我是Tuxman（也可以简写为“tux”、“tux-”或者“tux.”）。我最初是一名普通的eMule LSD用户，那真是一个美好的时代，后来另一个普通用户提议说“嘿，咱俩试着在Pawcio的基础上做个mod吧”，于是我就走上了开发之路。
对我俩来说，那次经历主要就是积累经验，因为我们之前都没怎么搞过C++。我们的项目始终处于初级阶段，唯一发布一个版本还是在eMule 0.44d新发布的时候。这款mod到现在还能从网上找到，不过现在来看颇令我汗颜。

出于个人原因，从2005年上半年起，我又开始开发eMule Beba。没过多久，我就再也联系不上Beba的最初作者了，不过我还是坚持了下来。首个能比较正常地运行、不会立马崩溃的版本是0.2a。由于（著名的）VipeR mod（Beba的图标便是来自它的）那时停止开发了，人们很快开始喜欢上eMule Beba——因为它小巧轻便，而且每次升级都能得到持续不断地改进。eMule Beba是目前最活跃、传播最广泛的非发布用mod之一。我为此深感自豪。

我开发的另一个mod是AnalyZZUL（这是应eMuleFuture.de的一位用户的要求而开发的），实际上就是ZZUL与Client Analyzer的结合体。不过，由于ZZUL貌似已经停止开发，我也已经停止AnalyZZUL的相关工作。

WiZaRd:
嗨，我的昵称是WiZaRd或者tHe WiZaRd of Dos。我刚开始是个eMule用户，而且还用了一段时间吸血客户端，主要测试各种吸血客户端的各种功能。
某天风和日丽，我瞅了一下吸血客户端的代码，觉得我也可以开始编客户端了——那应该是2000年前后——通过阅读吸血客户端的教程，我获得了充足的关于eMule的基础知识，并开始着手写第一个（吸血）mod——也就是说，这款mod包含一些被官方明令禁止的功能，例如手动踢人、手动封禁等等，不过我可没打过上传/下载比例的主意。
这款mod名为DaRkMaGic，一度非常流行，时至今日也能在网上找到。不过我不会再为其感到那么自豪了。

很长时间里我一直持续开发这款mod的v2版本，也试图通过写教程来帮助其它有心的程序员所遇到的编程问题。我还给几个圈内的大水管写过发布用mod。
不过，过了一段时间，这种在吸血客户端圈内所泛滥的“复制/粘贴”式编程开始让我感到厌烦。你不妨想象一下，有好多人对C++或者编程技巧基本上没什么了解，仅仅是把代码复制粘贴一下就敢编写mod（这种情况持续至今）……更匪夷所思的是，有些这样的mod居然还非常流行？所以，我退出了这个圈子，加入iONix mod的开发团队并呆了好一段时间。刚开始有些人对我的意图抱持怀疑态度（可能直到现在也是），但也有些人给了我第二次机会。
我创建出好几种独特的功能，同时陆续修正了官方代码库中的多处bug。最后，我开发了Client Analyzer功能并且发表了相关的mod（Tombstone / Tombstone Extended）。CA系统是为了帮助用户从许多“稍有”恶意的客户端中甄别出“真正”恶意的客户端。后者是篡改上传/下载比例、下完就跑、只取不予的客户端，前者则是某些发布人员视情况使用了被官方明令禁止的功能。
CA系统遭受了很多的质疑和猜忌，但我觉得CA系统还是找到了它的粉丝、它的用户群，这也是我不需要再打造新版本的Tombstone的原因。

2) 现在已经存在eMule和许许多多的mod了，是什么促使两位开发全新的kMule？

Tuxman:
kMule的思路跟eMule完全不同。我们的想法是做一款只支持Kad的轻便客户端，它不需要过分复杂的GUI界面、不需要太多手动配置，并且能更安静地在后台运行。从“服务器”到“仅Kad”是一条必由之路：服务器实在是问题太多，已经没有理由继续使用了。

WiZaRd:
呃，其实我很久以来就一直打算开发一款简单且用户界面良好的客户端，但是直到2012年年中才有时间着手实施。我邀请tux来帮我干是因为我觉得多人合作的项目搞起来更有意思。我还向另外几位（前）modder发出过邀请，不过那时他们都没时间。我衷心希望他们有时间的话能再考虑考虑！
立项之初，我们将这款客户端命名为ed2kloader。但是为了让我们的客户端与众不同，同时为了凸显出Kademlia是如此优异的网络，我们便将与服务器相关的部分彻底剔除掉了，集中精力打造世界上首款仅Kad网络的客户端。此外，我们还剔除了许多没太大用处的功能和设置，改善了默认配置，等等，这样我们的用户凭默认设置就能用起这款客户端，不需要花几个小时研究各项设置。
kMule的志向是自立门户，而不仅仅是做一款mod。也许目前kMule看起来跟eMule差不多，但这是为了方便eMule用户的切换。

3) 两位能介绍一下kMule客户端的主要特点吗？

Tuxman:
当然。看这个链接就行了：
http://sourceforge.net/p/kmuleproject/code/72/tree/trunk/Mod/main%20features.txt

WiZaRd:
当然。虽然上面我已经列过一些了，不过kMule
*…可以作为aMule用户的另一种选择，因为我们改进了客户端对WINE的支持。
*…是世界上首个仅支持Kad网络的客户端：我们不再依赖于饱受诟病且安全性差的服务器系统了。
*…采用最新的库编译，确保我们的用户不会受到一些老旧的安全问题的威胁。
*…具有（半）自动上传管理系统，可以自动检查版本变化并下载升级包——一旦发生了严重bug，我们甚至可以强制升级以消除过期版本的隐患。
*…能够自动升级各个重要组件（ipfilter、mediainfo、modicons等等）。
*…内置采用CA技术的动态反吸血防护。
*…内置搜索虚假结果检测（采用Netfinity的FakeAlyzer的改进版本）。
*…内置下载虚假文件检测（采用BlueSonicBoy的文件名差异性校验的某个版本）。
*…具有更加清爽简洁的用户界面。
*…对eD2k链接和收藏集进行了改进，使其支持文件夹（这是一个真正重要的功能！）。
*…可针对每个文件夹设置共享权限。
*…可通过7z.dll库实现自动解压。
*…支持SNARL系统，不论何时何地、即刻获取重要提醒。
*…包含ICS（智能文件块选择）、SOTN（仅显示所需文件块）、强力发布以及反HideOS等重要发布功能，确保提高文件发布效率。
*…经细心调校，可找到更多来源。
总而言之，kMule期望成为一款“易上手”的骡子。

4) eMule-project的整个社区对kMule是否持欢迎态度？

Tuxman:
eMule社区对kMule印象深刻，它提供了另一个更有说服力的开发思路，指明了eMule的未来发展方向。

WiZaRd:
eMule-project社区分裂成了两派。一方面，人们喜欢这种仅Kad的形式；另一方面，很多高级用户希望我们把一些功能（例如独立的记录窗口）重新加上。
就我个人看来，总体反应还是良好的，Some Support（注：目前eMule仅剩的开发者）也允许我们把这个客户端发布在eMule-Project.net网站上——虽然我们是想自立门户的，某种程度上将会成为eMule的竞争对手。

5) 两位将来打算对kMule进行哪些方面的改进？预期达到一个什么状况？

Tuxman:
等着瞧、别吃惊，伙计。

WiZaRd:
改进的余地是无处不在的。当然首先我们要力求消除bug和各种不稳定因素。
用户界面将会进一步改进并简化。我也在考虑要不要添加一些NAT-T功能，如果加上的话当然很好，不过目前我没时间进行调研，并且我也不打算在没有完全弄懂的情况下采用其它开发人员的代码，所以目前这部分内容还得搁置——除非Tux愿意搞。
我还打算改善网络的传输速度，以及提高文件（来源）的可用性，尤其是稀有文件。目前eMule面临的最大问题在于：网络中的大多数用户都还在使用eMule官方客户端或者基于官版的mod，而eMule官版是有缺陷的，例如其文件块选择算法、默认上传速度（每个用户3kB/s，这在今天来看简直就是搞笑，不过将来应该会改变的）等等。不管怎样，即便我们对客户端进行一些调整，也不会对网络的现状造成太大影响，除非eD2k中的大部分用户也都采纳这些修改内容。某种程度上来说这可能会导致产生一个独立的kMule Kad网络，不过再看看吧……

6) 很多人对eMule（官版）目前开发停滞的现状感到十分失望。kMule会不会也在几个月或者几年之后面临同样的结局？

Tuxman:
首先，你的提问不成立。所谓“死亡”和“成熟”是有区别的。eMule目前的状态是成熟而不是死亡。没有进行持续开发，是因为没有太多需要增加的东西了。

我们当然希望kMule也达到成熟；不过即使某天我们不再开发kMule了，也并不意味着kMule的消亡——它仍然会被继续使用。
再者说来，我们还是会继续开发kMule的。

WiZaRd:
实际上，对升级的“执念”也是kMule产生的原因之一。今天，如果一个项目不会在每年升级个十次八次的，人们就会以为这个项目完蛋了。这些家伙根本不知道，一个项目开发到一定程度以后，会到达一个相对成熟的阶段，此时就没有太多需要修改/添加的东西了。
kMule也会到达那个阶段的（但愿如此），不过在接下来的几个月里，我们会把许许多多的新想法（遗憾的是时间不够）逐步落实，以期到达那个阶段。

7) kMule是否打算成为一个独立的项目、就像eMule Plus那样？

Tuxman:
总体来说是的。不过eMule Plus可不是一个好例子，这东西连Kad都还没有呢……

WiZaRd:
实际上kMule已经是一个独立的项目了，所以，“是的”。
当然我们也会虚心汲取其它项目的先进理念和经验，如果eMule新版本有良好的变化我们也会跟进——我们可绝对不想变成eMule Plus那样（好久之后才支持Unicode，而且直到现在居然还没有Kad，等等）。

8 ) 你们是否认为kMule已经进入成长阶段，足以成为其它开发人员创建自己项目的基础？

Tuxman:
kMule当然可以为对之感兴趣的程序员提供程序基础。
这对于我所知道的所有mod都成立。我不确定“成长”对于这类决定是否算是重要因素。

WiZaRd:
对于所有版本和mod来说，是的。尽管我不太明白你所说的“成长”是指什么……
我觉得kMule会是一个有趣的代码库基础，因为它功能完善、升级频率高并且开发团队活跃。

9) 你们对NeoLoader怎么看？你们会从NeoLoader吸取一些创新性的点子添加到你们的kMule中吗？

Tuxman:
NeoLoader看起来是个挺有趣的项目，不过目前为止我个人还是持怀疑态度。
其主要开发人员David Xanatos多年来都是eMule社区中非常活跃的开发人员，不过现在他更出名了，因为他持续不断地炮轰eMule。不知出于什么原因，Xanatos将NeoLoader的主要代码都给闭源了，我还不清楚这是为什么。

从技术角度而言（仅从我能看到的代码），NeoLoader可以描述为“支持P2P的jDownloader”，这跟kMule南辕北辙——看起来NeoLoader主要是给下载者而不是分享者使用的。我觉得这不是一个好苗头。

我对NeoLoader比较欣赏的地方是它的插件系统（跟jDownloader一样）。NeoLoader的核心功能模块是自动升级的，无需每次升级都全部重装，这是个非常有趣的想法，好多年前就有人建议eMule这么整了。看看有没有人决定在eMule中实现这个吧。

WiZaRd:
NeoLoader中的确包含许多很好的想法……例如插件系统，例如平台无关性（理论上来说）。不过除了这些，我并没有在NeoLoader中看到称得上“创新性”的东西，除了有些Kad的相关修改。
我不太想把NeoLoader拿来跟kMule或*Mule进行比较。总体而言，eD2k关注于分享，而NeoLoader关注于下载……是的，NeoLoader也有P2P插件，但总体而言它仍然是面向下载者而非共享者的工具。
我过去与David Xanatos共事过，他是一名技术卓越的程序员，但他也是个激进主义者，也就是说他只要有想法就会立即付诸程序。这一方面是好事，可以在相当短的时间内实现很多的功能；但另一方面也容易导致代码混乱和bug泛滥——这跟我的编程理念不太一致。另外我个人绝对不会使用闭源的P2P软件，即使只是部分闭源——这只是个人口味和安全观念使然。

10) 关于eMule（官版），就目前这样新版本难产并且（官方团队）迟迟没有动作的境况，两位愿意接手这个项目来发布新版本吗？

Tuxman:
假如我和/或WiZaRd接手eMule项目的开发，我们对eMule进行的改变毫无疑问将会遭到一些人的反对（kMule走的路线跟以往的mod、例如StulleMule是完全不同的），这样会导致这些人另起炉灶，使得eMule社区四分五裂。——（我的观点是：）假如有人愿意接手eMule项目，那么他自己绝对不能是个modder。只有这样他才能把握住eMule项目的方向而不被（过往的modding经历）影响而偏移。

WiZaRd:
嗯，就像我之前说的：eMule目前已经达到了一个十分成熟的状态，进一步改进的空间很有限。
接手eMule是一件很缥缈的事情……对于Tux、我、我们尝试的方向、以及我们所添加的功能，目前仍然存在很多偏见和敌视——我很质疑（由我们接手官方版本的开发）对eMule是凶是吉。
当然，如果收到邀请，我自然会义不容辞地加入eMule官方开发团队……我仍然认为*Mule是迄今为止最好的P2P软件，让骡子健健康康活下去是非常重要的。