關於kMule的訪談

很榮幸邀請到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軟體，讓騾子健健康康活下去是非常重要的。