-----------------------------
Es ist ein wahres Vergnügen für uns, euch das Interview zu präsentieren, das euch tHeWiZaRdOfDoS und Tuxman, Entwickler des neuen Clients namens kMule, emule-mods.it freundlicherweise gegeben haben.
Wir danken ihnen für ihre unermüdliche und sehr geschätzte Arbeit und die Verfügbarkeit und die Freundschaft, die sie uns gegenüber stets gezeigt haben.
Falls ihr mehr über diese zwei Entwickler lesen wollt, könnt ihr die zwei vorigen Interviews lesen: tHeWiZaRdOfDoS - Tuxman
1) Könnt ihr euch und eure Erzeugnisse für das eMule-Projekt denen, die euch noch nicht kennen, kurz vorstellen?
Tuxman:
Tach, ich bin Tuxman (oder, kurz, bekannt als "tux", "tux-" und "tux."). Ich fing damals in den guten alten eMule-LSD-Tagen als normaler eMule-Benutzer an und wurde kurz darauf in die Entwicklung eingeführt, als ein anderer normaler Nutzer vorschlug, wir sollten versuchen, selbst eine Pawcio-basierte Mod zu bauen.
Es war eher ein Experiment, da wir beide nicht viel Erfahrung mit C++ hatten. Das Projekt hat allerdings nie die frühe Entwicklungsstufe verlassen, die einzige Veröffentlichung erlebte es, als eMule 0.44d immer noch "aktuell" war. Die Mod kann immer noch im Internet gefunden werden, aber ich bin nicht mehr sonderlich stolz darauf.
Anfang 2005 habe ich aus persönlichen Gründen mit eMule beba erneut einen Versuch gestartet. Wenngleich ich ziemlich bald den Kontakt zu der Person hinter dem Modnamen verloren habe, habe ich dennoch daran weitergearbeitet. Die erste beba-Version, die ohne sofortigen Absturz "funktionierte", war 0.2a. Da die (damals bekannte) VipeR-Mod (aus der bebas Häschensymbol stammt) im Begriff war zu sterben, lernten die Leute ziemlich schnell eMule beba für seinen leichtgewichtigen Ansatz zu schätzen, der in fast jeder neuen Version weiter verbessert wurde. eMule beba ist nun eine der aktivsten und weitestverbreiteten Nichtreleasermods. Darauf bin ich recht stolz.
Eine zweite Mod, die ich (aufgrund einer Anfrage eines eMuleFuture.de-Nutzers) entwickelte, war AnalyZZUL, die ungefähr identisch mit "ZZUL + Client Analyzer" war. Wie auch immer, da ZZUL tot zu sein scheint, habe ich AnalyZZUL ebenfalls zu Grabe getragen.
Wizard:
Hallo, mein Nick ist WiZaRd oder tHe WiZaRd of DoS. I fing als eMule-Nutzer an und war eine Zeitlang auch Leecher-Mod-Nutzer, der mit deren Funktionen experimentierte usw.
Eines schönen Tages schaute ich in den Code und dachte, dass ich auch anfangen könne zu programmieren - das muss um 2000 herum gewesen sein -, und mithilfe einiger Leecher-Mod-Tutorials beschaffte ich mir genug Wissen über den eMule-Code, um eine erste ("Leecher"-)Mod zu entwickeln, d.h. sie enthielt "verbotene" Funktionen wie Kicken/Verbannen, aber keine Ratioänderungen.
Dieser mysteriöse "DaRkMaGiC" war äußerst beliebt und kann immer noch im Internet gefunden werden, obwohl ich nicht mehr allzu stolz drauf bin.
Ich arbeitete danach lange an einer v2 und versuchte auch, anderen Möchtegernmoddern mit ihren Codingproblemen zu helfen, indem ich Anleitungen schrieb. Ich schrieb auch diverse Releasermods für einige bekannte Crews.
Nach einiger Zeit aber ging mir all das Copy-and-Paste-Programmieren in der "Leecherszene" auf die Nerven. Ihr müsst euch vorstellen, dass es viele Leute gab (und immer noch gibt), die nicht viel über C++ oder Programmieren im Allgemeinen wissen und immer noch Mods basteln, indem sie einfach Zeug aus einer Mod in eine andere kopieren... und einige von denen sind auch noch äußerst erfolgreich?! Nun, ich verließ die "Szene", aber trat für einige Zeit der iONiX-Modentwicklung bei. Anfangs waren Leute skeptisch (und einige sind's immer noch) bezüglich meiner Beweggründe, aber einige Leute gaben mir eine zweite Chance.
Ich ersann einige einmalige Features und behob auch einige Fehler in der offiziellen Codebasis und entwickelte schlussendlich den Client Analyzer und damit verbundene Clients (Tombstone/Tombstone Extended). Der CA wurde entwickelt, um "echte" böswillige Clients von "ein wenig" böswilligen Clients zu unterscheiden, wobei erstere ratioveränderte/Sofort-nicht-mehr-freigeben-/Nur-Community-Clients sind und letztere z.B. Releasecrews, die sich auf "verbotene" Funktionen stützen.
Der CA hat eine Menge Kontroversen hervorgerufen, aber ich glaube, er hat seine Anhänger und Benutzerbasis gefunden, was auch der Grund ist, wieso ich keine neuen Tombstoneversionen mehr veröffentlichen muss.
2) Was verleitete euch dazu, trotz eMule und der Vielzahl an vorhandenen eMule-Mods kMule zu entwickeln?
Tuxman:
kMule hat eine völlig andere Herangehensweise an eMule. Unsere Vision ist es, einen einfachen Nur-Kad-Client ohne aufgeblähtes GUI zu haben, der nicht viel händische Konfiguration benötigt und quasi sofort funktioniert. Der Schritt von Servern zu "nur Kad" ist eine Frage der Konsequenz: Server sind ein ziemlich veraltetes System, und es gibt keinen wirklichen Grund, sie immer noch zu verwenden.
Wizard:
Oh, ich hatte schon länger vor, einen einfachen, benutzerfreundlichen Client zu schreiben, aber ich habe erst Mitte 2012 die Zeit gefunden, damit anzufangen. Ich bat Tux um Hilfe, da es m.E. mehr Spaß macht, mit mehreren Leuten an einem Projekt zu arbeiten. Ich habe auch einige (frühere) Modder gefragt, die zu der Zeit keine Zeit hatten, obwohl ich immer noch hoffe, dass das noch kommt!
Wir fingen in der Planungsphase mit dem Namen "ed2kloader" an, aber um unseren Client einmalig zu machen und Kademlia als weit überlegenes Netzwerk zu ehren, haben wir als eines unserer zentralen Features die Serverunterstützung abgeschafft und uns darauf konzentriert, den allerersten Nur-Kad-Client zu schaffen. Außerdem haben wir viele nutzlose Funktionen und Einstellungen rausgeworfen, die Standardeinstellungen verbessert usw., so dass der Standardnutzer unseren Client nutzen kann, ohne ihn erst stundenlang einstellen zu müssen.
kMule soll außerdem ein Fork sein, keine Mod. Es mag momentan so aussehen, dass es nicht viele Unterschiede zu eMule gibt, aber das dient vor allem dem Zweck, den Umstieg zu kMule zu erleichtern.
3) Könnt ihr kurz die Hauptfunktionen von kMule vorstellen?
Tuxman:
Sicher:
http://sourceforge.net/p/kmuleproject/c ... atures.txt
Wizard:
Ja, natürlich, obwohl ich schon einige genannt habe; aber: kMule
* ... könnte eine Alternative zu aMule sein, da wir WINE-Unterstützung eingebaut haben
* ... ist der erste Nur-Kad-Client: wir verlassen uns nicht mehr auf veraltete und unsichere Server
* ... ist mit aktuellen Bibliotheken kompiliert worden, so dass sich unsere Benutzer nicht mit alten Sicherheitslücken herumschlagen müssen
* ... hat ein (halb-)automatisches System, um Aktualisierungen zu finden und herunterzuladen - falls ein wirklich schwerer Fehler gefunden wird, könnten wir das Update auch erzwingen, um die Verbreitung alter Versionen einzudämmen
* ... hat eine automatische Aktualisierung für alle wichtigen Erweiterungen (ipfilter, mediainfo, modicons)
* ... hat einen eingebauten, dynamischen Leecherschutz mit CA-Technik
* ... hat eine eingebaute Such-Fakeerkennung mittels einer verbesserten Version von Netfinitys FakeAlyzer
* ... hat eine eingebaute Download-Fakeerkennung mittels BlueSonicBoys Filename Disparity Check
* ... hat eine aufgeräumte, einfachere Benutzeroberfläche
* ... hat verbesserte Unterstützung für ed2k-Links und Collections mit Ordnerunterstützung (das ist ein Superfeature, wirklich!)
* ... hat Pro-Verzeichnis-Einstellungen für Dateifreigaben
* ... unterstützt automatisches Entpacken mittels 7z.dll
* ... hat SNARL-Unterstützung - ihr bekommt immer und überall die wichtigen Meldungen
* ... beinhaltet ICS, SOTN, Powershare und Anti-HideOS für Releases und bessere Dateiverteilung
* ... hat Verbesserungen, um mehr Quellen zu finden
Allgemein soll kMule ein "leicht zu benutzendes" Maultier sein.
4) Wie wurde kMule von der emule-project-Gemeinschaft aufgenommen?
Tuxman:
Die eMule-Gemeinschaft war ziemlich beeindruckt, da kMule einen anderen, viel versprechenden Ansatz und einen Schritt in eMules Zukunft darstellt.
Wizard:
Die Gemeinschaft war (oder eher ist) etwa zweigeteilt. Einerseits mögen Leute den Nur-Kad-Ansatz, aber andererseits wollen einige fortgeschrittene Benutzer einige ihrer Funktionen (wie das separate Logfenster) zurück.
Meiner Meinung nach fiel die allgemeine Reaktion positiv aus, und Some Support erlaubte es uns auch, unseren Client auf eMule-Project.net zu veröffentlichen, obwohl wir ihn als Fork und damit als "Konkurrenz" von eMule entwickeln.
5) Welche Verbesserungen habt ihr für kMule vorgesehen und was wollt ihr noch erreichen?
Tuxman:
Versau' dir nicht selbst die Überraschung, mein Freund.
Wizard:
Es gibt immer Platz für Verbesserungen. Natürlich wollen wir zunächst einmal alle Fehler und Ausrutscher loswerden.
Die Benutzeroberfläche wird einige Änderungen und weitere Vereinfachungen erfahren. Ich glaube auch immer noch, dass das Einbauen einer Art NAT-T gut wäre, aber momentan habe ich nicht die Zeit, mich damit zu befasse, und ich will keinen Code eines anderen Entwicklers benutzen, ohne ihn zuerst ausführlich zu überprüfen, also muss das noch warten, es sei denn, Tux möchte das übernehmen.
Ich würde außerdem gern die Geschwindigkeit und Dateiverfügbarkeit des Netzwerks verbessern, insbesondere für seltene Dateien. Das Problem ist zurzeit, dass die meisten Benutzer entweder den offiziellen Client oder eine darauf basierende Mod mit all seinen Beschränkungen nutzen, z.B. Chunkauswahl, Standard-Uploadgeschwindigkeit (3 kB/s pro Client - das geht heutzutage GAR NICHT, obwohl es künftig geändert werden soll) und andere. Wie auch immer, selbst, wenn wir einige Änderungen machen, wird es keine spürbaren Auswirkungen haben, bis die meisten Clients, die an eD2k teilnehmen, sie auch einbauen. Dies könnte irgendwann zu einem eigenständigen kMule-Kad führen, aber wir werden sehen...
6) Viele Leute sind enttäuscht, dass eMule ein totes Projekt ist. Wird kMule in wenigen Monaten/Jahren dasselbe Schicksal erleiden?
Tuxman:
Zunächst mal: Deine Frage ist falsch. Es gibt einen großen Unterschied zwischen Tod und Reife. eMule ist reif, nicht tot. Der Umstand, dass es keine öffentlich sichtbare Entwicklung gibt, heißt nur, dass es nicht viel gibt, was noch fehlt.
Wir hoffen natürlich, dass kMule der Reife nahe ist; obwohl es selbst, wenn wir eines Tages nicht mehr an kMule arbeiten, nicht bedeutet, dass kMule auch nicht mehr geht.
Wie auch immer, neue Entwicklungen werden aktiv beobachtet.Wizard:
Tatsächlich war die heutige "Besessenheit" von Updates ein weiterer Grund für kMule. Heute glauben die Leute, dass ein Projekt "tot" ist, wenn es nicht mindestens viermal im Jahr ein Update bekommt. Sie verstehen einfach NICHT, dass Software ein Reifestadium erreichen kann, in dem es einfach nicht mehr viel zu ändern/korrigieren gibt.
kMule wird dieses Stadium (hoffentlich) auch erreichen, aber wir haben genug Ideen (und nicht genug Zeit), um diesen Punkt nicht innerhalb weniger Monate zu erreichen.
7) Könnte kMule ein eigenständiges Projekt werden wie eMule Plus?
Tuxman:
Allgemein: Jep. eMule Plus ist aber kein gutes Beispiel. Wir warten immer noch auf Kad-Unterstützung ...
Wizard:
Eigentlich ist kMule schon als eigenständiges Projekt konzipiert, also: Ja.
Natürlich behalten wir ein Auge offen und könnten Änderungen aus neuen eMule-Versionen übernehmen - wir wollen mit Sicherheit NICHT zurückfallen, wie es eMule Plus getan hat (lange vor Unicode-Unterstützung, immer noch kein Kad usw.).
8) Glaubt ihr, kMule hat ein Wachstum erreicht, um eine Vorlage zu werden, auf deren Grundlage andere Entwickler ihre eigenen Projekte stellen können?
Tuxman:
kMule kann natürlich als Codebasis für interessierte Entwickler benutzt werden.
Das stimmt für alle Mods, die ich kenne. Ich bin mir nicht sicher, ob Wachstum für diese Entscheidung überhaupt von Belang ist.
Wizard:
Wie bei allen Versionen und Mods: ja, obwohl ich nicht ganz verstehe, was du mit "Wachstum" meinst.
Ich glaube, kMule wäre eine interessante Basis aufgrund seiner Funktionen, Updatefrequenz und der aktiven Entwicklergruppe.
9) Was haltet ihr vom Neoloader? Lasst ihr euch von diesem Client zu innovativen Funktionen für kMule inspirieren?
Tuxman:
Neo Loader mag nach einem interessanten Projekt aussehen, aber ich halte es eher für verdächtig.
Der Hauptentwickler, David Xanatos, ist wohlbekannt für seine Flames gegen eMule, völig ungeachtet dessen, dass er jahrelang aktiver Entwickler in der eMule-Gemeinschaft war. Ein großer Teil des Quellcodes ist aus keinem mir bekannten Grund nicht freigegeben. Ich wüsste immer noch gern, wieso.
Technisch gesehen kann der Neo Loader (na ja, die Codeteile, die ich kenne) als "jDownloader mit P2P-Unterstützung" betrachtet werden, so ziemlich das Gegenteil von kMule, da er auf das Herunterladen, nicht auf das Verteilen spezialisiert zu sein scheint. Ich glaube nicht, dass das die richtige Richtung ist.
Der Teil, den ich (wie beim jDownloader) mag, ist das Pluginsystem. Die Kernfunktionen automatisch auf dem neuesten Stand zu halten, ohne eine komplett neue Version installieren zu müssen, ist eine interessante Idee, die vor Jahren auch für eMule vorgeschlagen wurde. Mal sehen, ob und wann irgendjemand beschließt, das umzusetzen.
Wizard:
Es gibt einige recht nette Teile, ja... z.B. das Pluginsystem und die (theoretische) Plattformunabhängigkeit, aber davon abgesehen sehe ich außer einigen Kad-Änderungen nichts "innovatives" im Neoloader.
Ich will Neoloader allgemein nicht mit kMule oder *Mule vergleichen. eD2k dreht sich um TEILEN (und Sorgen), während der Neoloader nur für Downloads da ist... ja, es gibt auch ein P2P-Plugin, aber allgemein zielt er auf Sauger, nicht auf Verteiler.
Ich habe in der Vergangenheit mit David Xanatos zusammengearbeitet, und wenngleich er ein fähiger Entwickler ist, hat er es auch immer eilig, d.h. er hat keine Geduld, wenn es ums Coden geht. Das ist positiv, weil man so viele Funktionen in relativ kurzer Zeit zusammenbekommt, aber es führt auch zu Chaos im Code und vielen Fehlern - das ist nicht "meine" Art zu programmieren, und außerdem würde ich NIEMALS ein Closed-Source-P2P-Programm verwenden, selbst, wenn es nur teilweise geschlossen ist - das ist einfach eine Frage meines persönlichen Geschmacks und Sicherheitsempfindens.
10) Über eMule (offiziell), bedenkt man das Ausbleiben neuer Versionen und keiner Bereitschaft zur Änderung dieses Umstands, kann es für euch interessant sein, die Führung des Projekts zu übernehmen und eine neue Version herauszubringen?
Tuxman:
Falls ich und/oder WiZaRd die Entwicklung von eMule übernähmen, bin ich mir ziemlich sicher, dass jemand, der unsere Ansätze nicht mag (da kMule in eine komplett andere Richtung geht als zum Beispiel StulleMule), einen Fork entwickeln wird, was eMule nicht helfen würde, eine eigenständige soziale Gemeinschaft zu bleiben. -- Falls jemand die eMule-Entwicklung übernehmen muss, sollte er selbst kein Modder sein. Auf diese Weise kann er die Kontrolle über das Projekt behalten, ohne voreingenommen zu sein.
Wizard:
Nun, wie ich bereits sagte: eMule hat einen sehr reifen Zustand erreicht und es gibt nicht mehr so viel zu tun.
Die Führung zu übernehmen wäre eine heikle Sache... es gibt immer noch viele Vorurteile und Anfeindungen gegen entweder Tux, mich oder unsere Ansätze und Features - ich bezweifle, dass das eMule helfen würde.
Trotzdem würde ich ganz klar Teil des offiziellen Entwicklerteams werden, wenn mich jemand fragte... ich glaube immer noch, dass *Mule die beste P2P-Software der Welt ist und es wichtig ist, sie am Leben zu erhalten.
