Ich finde das eMule ein sehr toller Client ist und ich habe auch immer ihn bei unzähligen Horde-Diskussionen verteidigt, aber leider muss ich mich meine Meinung ändern. Ich habe jetzt seit fast einen Monat eDonkey ausprobiert und ich muss sagen, dass das System leider besser ist. Die Implementation von Horde und den 450 KB-Chunks mag schlecht sein, aber dass können die Entwickler von eMule anders lösen.

Das Credit-System funktioniert nicht. Das einzige wozu es mich in letzter Zeit gebracht hat ist, da ich ständig weniger Download als Upload hatte, alle meine Dateien aus dem Share zu nehmen. Und das machen viele Leute, da der Download dadurch erheblich schneller wird, und nur an das Gute im Menschen zu appelieren ist utopisch. Wenn man Credits bei eine Clienten sammelt, ist die Wahrscheinlichkeit, dass man ihn wieder sieht sehr gering bzw. man muss trotzdem lange in einer 5000 Queue anstehen. Außerdem werden sehr häfig durch Neuinstallation von eMule die Credits gelöscht.
Der Download im eMule startet erst nach ca. 20 Minuten bis einer Stunde und dann meist von Nicht-eMule-Clienten. Beim eDonkey meist schon direkt nach dem Hash-Vorgang.
Der Upload wird unnötig durch Public-Keys erhöht und sie machen es den Gegner der Tauschbörsen sehr einfach einen einwandfrei zu indentifizieren.
Seltene Dateien lädt man meistens nur von eDonkey Clients da diese eine Queue per File haben und bei den eMule Clienten die Queue fast immer überfüllt ist oder man auf Platz 4599 landet.
Ich habe selbst an einer populären Datei zwei Wochen mit dem Muli geladen während die mit eDonkey dank Horde innerhalb von zwei Tagen fertig war. Und das ist bei allen populären Dateien so.

Wenn wir uns jetzt die Punkte ansehen, was liegt da näher als das Credit System aufzugeben. Horde ist ein viel effektiverer Leecher-Schutz als das Credit-System und für die Benutzer viel effizienter. Man bekommt immer so viel Download wie Upload. Man spürt sofort Ergebnisse und es würden nicht mehr so viele Leute über zu niedrigen Download klagen. Man muss selbstverständlich die Horde-Slots auf beispielsweise die hälfte begrenzen und nur Horde für eine Datei zulassen, aber das wäre immer noch effektiver als jetzt. Der Overhead würde reduziert werden, da auf den ganzen Identifikations-Quatsch verzichtet werden könnte, populäre Dateien würde schneller fertig gestellt werden und auch seltene, da dafür auch Horde verwendet werden könnte. Außerdem könnte man auf die großen Queue verzichten, da das Credit System unnötig geworden ist, und ein Queue-Per-File System einführen, wodurch seltene Dateien mindestens so gut verteilt werden wie heute.
Außerdem bringt es damit nichts mehr seinen Share zu leeren. Man hat keinen Vorteil mehr davon und man hat auch mehr Nachteile wenn man den Upload ausschaltet. Somit ist eine Horde- und Queue-Per-File-System wesentlich effizienter als das eMule-Credit-System. Auch hätte Nicht-Flatrate-Nutzer Vorteile.

Ich finde es auch schlecht, dass eDonkey andere Clienten auschließt und irgendwelche neuen Chunk-System einführt, aber man muss, gerade als Open Source Client, mit der Zeit gehen, Fehler eingestehen und bessere Entwicklungen einbauen als an einem alten maroden System festzuhalten.
Man kann ja an allem festhalten nur das Credit-System und die riesigen Queue aufgeben und ein eigenens Horde und ein Queue-Per-File-System integrieren. Der Download wird im Schnitt effizienter sein als bisher. Außerdem werden die Leute im Schnitt mehr sharen und mehr uploaden als bisher bzw. der Overhead wäre niedriger.
Auch wenn die Idee von Metamachine stammt, heißt das noch lange nicht, das sie schlecht ist.

Versteht mich bitte nicht falsch, eMule ist der bessere Client, aber eDonkey hat das bessere System.

Man könnte ja während der Anfangsphase einfach eine Option anbieten über die man wählen könnte entweder 5000.-Queue und Credit-System oder Queue-Per-File-System mit Horde.

CU
Mr Faber

Kleinere Chunks möchte ich auch haben, diese 9,28 MB Brocken sind schon sehr groß. Man sieht besonders bei neuen Releases von diversen Urlaubsfilmen dass sich erst mal zwei Tage lang nichts tut weil so gut wie niemand einen fertigen Chunk hat. Müssen ja nicht gleich 450K sein, aber etwas kleineres wäre schon sinnvoll.

Ausserdem sollten wichtige Daten wie Userhash und die Keys im Homeverzeichnis des Benutzers gespeichert werden bzw. gleich in die Registry, dann ist eine Neuinstallation kein Problem mehr. Hab ich übrigens schon vor langem mal gepostet, auch ins englische Forum denk ich.

Eine Queue per File würde irgendwie zu BitTorrent-artigen Zuständen führen, was ja aber auch nicht schlecht sein muss - wenn ich eine seltene Datei runterlade dann ist davon auszugehen dass diese mir etwas wert ist und ich daran interessiert bin dass sie weiter im Netz bleibt, also kann man auch eine Queue für diese einzelne Datei einführen damit andere schneller zum Zuge kommen. Für die verbreiteten Dateien gibts doch eh genug Slots insgesamt - im Moment ist meine Queue fast nur von Clients belegt, die Version 3 eines bestimmten Urlaubsfilmes haben wollen, und diejenigen die nach den gezeichneten Abenteueren gewisser glücklicher Bären suchen sind ganz unten. Weil die Clients, die den Urlaubsfilm wollen, natürlich von vorhergehenden Urlaubsfilm-Uploads mehr Credits haben als die anderen, sind die fast chancenlos.

Vielleicht einfach das eMule-Protokoll so erweitern, dass die kommenden Versionen ihre Files zweimal hashen und dann kleinere Chunks bereitstellen können? Dürfte kein so wirklich großer Aufwand sein. Ausserdem sollte der Optionendialog mal aufgeräumt werden, z.B. bei "Servers" gibt es jede Menge Optionen wo es keinen Sinn macht sie überhaupt abzuschalten.

wegen dem queue per file system viele emule mods nutzen dies bereits ich weis jetzt nur nicht ob der off. client das auch nutzt.

Bzgl. der begründeten Kritik am Creditsystem ist jeder weitere Kommentar unnötig. Also wer es nicht nutzen möchte, einfach abschalten und eMule 1-2mal die Woche neu installieren (mache ich ebenfalls). Erhöht ebenfalls die durchschnittliche Down- und Uploadgeschwindigkeit (merkwürdigerweise?!).

Tatsache ist leider: Nur über die aktuelle Releasefunktion lassen sich brauchbare Quellen für eigene Downloads sozusagen effizient "anlocken". Führt dazu, daß man nur noch das auf Release setzt, was man selbst man schnellsten haben möchte. Funzt auch sehr gut.

Wer etwas Anderes als die Mainstream-Urlaubsfilme downloaden möchte, ist mit Alternativen oft besser dran. Aber mit eMule lassen sich dafür auch etwas angestaubte Mainstream-Urlaubsfilme recht gut downloaden, da es im Prinzip nicht notwendig ist, eigene Shares zu löschen. Sie erhalten einfach nur eine Prioritaet <=normal. Sobald die eigenen Downloads auf dunkelblau stehen und die Quellenzahl im 3stelligen Bereich liegt, kann man auch den ein- oder anderen Urlaubsfilm mit Saharaausblick auf Release bringen und dafür die eigenen Downloads rücksichtsvollerweise auf "hoch" zurückstufen.

Fazit: Ich möchte auf eMule nicht verzichten, aber ich bin auch nicht allein auf eMule angewiesen. Shareaza, eDHyb & Bittorrent vertragen sich im Parallelbetrieb auf unterschiedlichen Ports ausgezeichnet mit eMule.

Das mit dem unsharen oder relase-stellen der Dateien ist im Prinzip eigentlich nichts anderes als das BitTorrent-Modell und das darauf basierende Horde. Bringt zwar viel speed, ist aber der Tod seltener Files, was mich alles andere als Glücklich macht. Wobei der Horde-Speed durchaus auch allein von den kleineren Chunks (=schnellere Verbreitung) herrühren könnte. Aber lassen wir das, es wurde schließlich schon zu genüge darüber diskutiert.

Für viele der anderen von MrFaber genannten Probleme gibt es allerdings bereits Lösungen in MODs, die ohne Aufnahme in den offiziellen Clienten aber leider chancenlos bleiben. Ich denke hier besonders an das bereits genannte nWay-Queue oder Save Upload Queue Waiting Time, die, wenn sie geschickt angewendet werden, das jetztige Creditsystem überflüssig machen könnten. Andererseits ist es auch nur Fair für viel Upload belohnt zu werden. Es müsste nur gut genug ausbalanciert sein. Vielleicht ist das nur Subjektiv, aber das Credit-System scheint mit SUQWT dank der längeren in der Queue "verbrachten" Wartezeit an Effektivität zuzunehmen.

Was das Chunk-System angeht: Soweit ich weiß, arbeitet Moonlight im Moment an einem neuen System, das auf Hash-Trees basiert und beliebig wählbare Chunk-größen zwischen ein paar Kilobyte und 16 Megabyte möglich machen soll. Außer der Möglichkeit korrupte Transfers mit wenigen Kilobyte download zu reparieren und der fast beliebig wählbaren Chunkgröße ist es außerdem noch sehr viel sicherer als die momentanen MD4-Hashes.
Das wäre zwar noch inkompatibler mit dem Netz als eDonkeys Crumbs, aber da es so viele Vorteile hat, würde es sich sicherlich durchsetzen und könnte, da die Devs ja mittlerweile anscheinend mit MetaMachine kooperieren, vielleicht auch für eDonkey zur Alternative werden.
Notfalls könnte man immer noch, so wie Tantal vorgeschlagen hat, mit zwei Systemen parallel arbeiten.

Ich persönlich glaube, wir blicken goldenen Zeiten entgegen... alles was nötig ist, ist ein wenig mehr Zeit.

Mfg,
Drangon

Hi also, was Mr Faber im ersten Topic schreibt hört sich sehr gut an, also ich wär auch für diese veränderungen. Wie man merk wo ich vor einem Monat die Platte leer gemacht habe Muli neu installiert dann hat er geladen, ohne ende. Und jetzt wo mein Share wieder so mit mehreren Daten voll ist geht fast garnichts mehr und das kann es ja nicht sein. Genau so wie das mit den Seltenen Daten ist, ist ja ganz mieserabel, es hies mal die Quelle wird gleich übernommen, na ja also dazu muß ich sagen das geht ja garnicht. Also es muß sich ja mal wieder was tun, sonst habe ich langsam klein Bock mehr auf Filesharing, kann man sich ja doch lieber alles Kaufen.

@Dragon
Ich glaube das Horde sogar sehr effektiv für seltene Dateien ist. Wenn nur zwei Leute unterschiedliche Teile und beide für diese Dateie Horde aktiviert haben, können sie dauerhaft gegenseitig von sich laden, solange bis beide dieselben Chunks haben. Das müsste zu einer wesentlich schnelleren Verbreitung führen.
Das mit dem Speichern ist zwar nicht schlecht, aber es sind nicht alle Leute 24 Stunden online und die Zwangstrennung, die in Deutschland sehr verbreitet ist, macht dem System ein Strich durch die Rechnung. Außerdem müsste man dann noch länger in der Queue warte, da viel weniger Clienten aus der Queue fliegen würden.

Cu
Mr Faber

@MrFaber:

Noch ein kleiner Kommentar zu deiner Aussage "seltene Dateien lädt man fast nur von eDonkey": Ich kann glaub ich zu Recht sagen, dass meine Downloads die meiste Zeit ausserhalb des Mainstreams liegen (Gothic-Alben, Dokus von eselkult, relativ unbekannte Software etc.). Trotzdem kommt 92.5% des Downloads von eMule-Clients, die in der Queue 97.2% ausmachen. Die Werte gelten für ein Downloadvolumen von 122 GB. Also finde ich deine Aussage zumindest in meinem Fall revidiert.

@MrFaber:

weiter oben wurde von variablen chunk größen berichtet, es ist zwar sehr schön das sich die devs gedanken über das problem machen nur wenn das dann ein paar KB sind ist der aufwand fürn arsch den dann würd man sehr viel overhead bekommen und wennns bei 16MB ist dann würd man noch länger warten. außerdem sollte man das upload system ein wenig überarbeitet wie soll man den verteilen wenn man an >4 läute uploaded das ganze sollte auf 1 slot reduziert werden. und nur wenn er nicht mehr gekomen will wird ein 2 slot geöffnet und wenn der erste fertig ist wird nicht sofort ein neuer slot geöffnet sonder erst probiert auf full-speed zu gehen. das sollte man vor allem vor allen anderen sachen wie abschaffung des credit systems etc. machen vieleicht reicht das ja schon und wir alle sind wieder wunschlos glücklich

Tja, hat halt alles so seine mehr oder weniger offensichtlichen Vor- und Nachteile.

Das eDonkey seine Queue ebenfalls abspeichert, wusste ich gar nicht, das ist nämlich tatsächlich das gleiche wie SUQWT. Seit wann ist das denn so?

@TheRunner

Das neue System würde, wenn ich das ganze richtig verstanden habe, eine variable Chunk-Size benutzen, so dass man praktisch sofort wenn man etwas heruntergeladen hat, dieses auch weiter sharen kann ohne darauf zu warten, dass ein Chunk von bestimmter Größe fertig wird. Das Problem bisher war immer, die downgeloadeten Daten zu verifizieren, was momentan noch nicht geht, wenn nicht ein Chunk voll und der Hash dafür vorhanden ist. Unglücklicherweise wird es aber noch eine ganze Weile dauern bis MAFS fertig ist und noch länger bis das *hoffentlich* in den offiziellen Client übernommen wird.

@Mr Faber
[Edit]: Bin momentan heftig übermüdet, ich glaube ich werde mir das lieber morgen nochmal durchlesen und bei Bedarf korrigieren...es denkt sich gerade nicht so klar...
[/Edit]

@Drangon
Ich weiß nicht genau, aber irgendwann seit der Hybrid-Version.

@pRAyNz
Für Releaser könnte man einen Option integrieren, mit der man Horde deaktivieren kann oder vielleicht könnte man Horde zusätzlich erweitern, auf ein Art variables System. Das heißt ich habe eine Datei komplett, die einer von mir mittels Horde laden möchte. Ich habe aber wiederum eine Datei auf Horde stehen, die ich von ihm haben möchte. Also könnten beide Horde jeweils für unterschiedliche Dateien benutzten und somit beide dauerhaft von sich gegenseitig laden.

Wenn nur" 50% der Bandbreite für File-Trading benutzt würde, würde immer noch genug für alle anderen zur Verfügung stehen und dank Queue-Per-File würde das auch gerecht verteilt. Außerdem würde man nicht Nutzer bzw. Upload-Kapazitäten an Clienten wie Bittorrent verlieren. Dann würde wieder vermehrt eMule für die Verbreitung von neuen Dateien benutzt.

Das Credit-System wurde ja nur gegen Leecher eingeführt. Es mag vielleicht bei Serien effektiv arbeiten, aber ich glaube das deren Anteil vernachlässigbar ist.
Horde arbeitet vom Prinzip her wesentlich effizienter, da man 50% seines Uploads im Prinzip immer zurück bekommt. Beim eMule-Credit-System verliert man oft Credits durch Neuinstallationen oder kommt gar nicht erst in die Queue rein. Außerdem bleibt der größte Teil, wenn man viele Dateien shared ungenutzt. Das ist nicht akzeptabel, denn es schützt somit nicht so effektiv vor Leechern und schadet wie gesagt Leuten, die viele Dateien sharen und erzeugt somit unabsichtlich ein virtuelles File-Trading-System.

CU
Mr Faber

Man kann als releaser bei edonkey2000/Overnet die Horde deaktivieren!

Rare Files werden nicht beeinträchtigt, eben wegen n-way - queue, uploadqueue save und Horde.

Ich verstehe nicht, warum so viele Leute auf die armen Horde einschlagen. Sowohl die Horde als auch das Credit System sind File Trading Systeme nach dem Motto "Haste was, kriegste was". Wenn man File Trading mag, hat das CS den Vorteil, daß es für alle Clients wirkt und die Horde, daß man sich wesentlich schneller (leider nur zwischen Donkeys) austauscht. Schade, daß emule das Horde System nicht adaptiert. Files mit wenigen Quellen sind ruckzuck fertig, wenn ein paar Donkeys mit von der Partie sind.

Versucht mal, von einer emule Source was zu ziehen, wenn Ihr selbst mangels geeigneten Files im Share nichts uploaden könnt...beste Bohne . Das hatte ich bei einer extrem seltenen Datei fünf Monate durchexerziert, bis sie endlich fertig war. Bei Donkeys bekommt man in dem Fall wegen der n-way Queue häufiger was.

Wer File Sharing möchte, muß konsequenterweise im Donkey die Horde und im emule das CS abschalten. Komisch, daß es früher auch ohne File Trading für alle sehr gut lief .

Ich finde eine unbegrenzte Queue eigentlich nicht so toll und auch unnötig. Wenn man eine Queue-Per-File verwendet und die Queue pro Datei auf 100-1000 (das sollte man wie in der aktuellen Version in den Optionen einstellen können) begrenzt ist, kann jede seltene oder mittel verbreitet Datei geladen werden ohne auf eine volle Queue zu treffen. Jediglich die sehr verbreiteten Dateien können nicht immer geladen werden, aber 100 Plätze pro Client reichen für solche Dateien völlig aus und außerdem gibt es noch Horde.
Unbegrenzte Queue belasten nur unnötig den Arbeitsspeicher und die CPU. Wenn man populäre Dateien mit dem eDonkey lädt, ist ein langsamer Computer nach einigen Stunden annähernd voll ausgelastet.

CU
Mr Faber

@Mr Faber

<ironie>
Das beste wäre eigentlich, dem Benutzer gar nicht mehr zu sagen, wie viel er gegeben hat. Dann kann keiner Ansprüche stellen, weil er gar nicht weiß wie viel ihm zustünde. Einfach immer Full Speed Upload und automatisch Upload drosseln, sobald die Leitung sonstwie gebraucht wird (naja n bisschen schwer aber es geht) damit keiner mehr merkt, dass da hintendran überhaupt was läuft. Standardmäßig die ganze Festplatte freigeben. Die ganzen Statistikfunktionen raus. Keine Anzeigen mehr. Was ich nicht weiß macht mich nicht heiß, und wenn ich mich nicht beschissen fühle komm ich auch nicht auf die Idee selber zu bescheissen.

Weil dann automatisch jeder Benutzer so viel gibt wie seine Leitung im Moment hergibt, steigt der durchschnittliche Download im Netz an und es gibt weniger Leute, die schlechten Download haben und auf die Idee kommen würden zu leechen.

Natürlich muss dann noch ein Kontrollorgan her, das die Clients der Benutzer überwacht. Die Leecher-Verbrennung findet täglich um 20 Uhr auf dem Marktplatz statt.
</ironie>

@Tantal

@pRAyNz

Ich wollte das eigentlich nur mal so generell aus Spaß sagen, die Ironie-Tags waren wohl nicht ganz passend. Mit dir persönlich hat das nichts zu tun, sorry wenn der Eindruck entstanden sein sollte, Humor kann manchmal seltsame Züge annehmen


Bezogen hab ich mich darauf:

hi,

ich würde denken, das wenn man ( wie schon erwähnt ) die upload slotts auf 1 slot begrenzen sollte, dann könnte man in einer 1/4 stunde eine chunk uploaden und man müsste nicht mal die chunk größe änderen !! damit sollte es auch nahe zu keine unfertigen chunks geben, da man locker eine 1/4 stunde warten kann und dann erst raus geht oder so. mit einer option " nach dem nächsten komplett geuploadeten chunk disconnecten" sollte der einzige grund für verstückelte chunks nur die zwangstrennung sein. falls man dann doch auf einen client mit einem unvollständigen chunk trifft und diesem weniger als 50 % fehlen, sollte man dann 1,5 chinks geben können, anstatt nur den halben.


grundsätzlich muss man immer noch beachten, das upload = download und deshalb man nicht soo einfach den muli beschleunigen kann. es gibt zwar verschiedene modelle für die warte schlagen, aber letztlich is es immer noch so, zum upload der gewünschten daten ( zu den clients in der queue ) insgesamt die immer gleiche zeit gebraucht wird, die frage ist nur, wie sie verteilt wird. am einfachsten ( und auch fairsten ) wäre es immer noch, wenn man die warteschlange nach dem fifo-prinzip gestalltet. da gibt es für alle die gleichen regeln -> warten bis vor einem alle weg sind ^^ ist zwar net so gut für die, die "schnell mal was saugen" wollen, dafür lohnt sich das warten dann richtig


das 0pf4 schlecht hin ^^

PS: wenn jemand ein problem mit mit der meinung hat: immer drauf, ich werd's vertragen ^^

Horde hin oder her..
Mit seltenen Files gibt es wirklich Probleme im offiziellen emule, daß man entweder vor einer Full Queue steht oder nur langsam vorrutscht.

Mein Mod hat alle diese Probleme gelöst.
- MultiQueue
- Allow Queue Overflow with Minimumcontingent, welches sicherstellt, daß für jedes File eine gewisse Anzahl von Clients immer in die Uploadqueue kommt.

Zudem hab ich noch den Code optimiert, welcher bei großen Queues emule unheimlich ausbremste wenn man "Aktualisiere Warteschlange in Echtzeit" aktiviert hatte.

Wären meine Features im offiziellen emule gäbe es keine Probleme seltene Files laden zu können.

@opf4:

Da gibts ein kleines Problem: Wenn dein gegenüber weniger Bandbreite hat als du (z.B. DSL an ISDN) ist dein Upload-Slot nicht ausgenutzt und du musst viel länger uploaden bis der Chunk fertig ist. Also ziemliche Verschwendung. Im aktuellen offiziellen Client ist die Queue bereits FIFO, mit kleinen Änderungen für das Creditsystem (Wer schon Credits hat ist halt ersterer als ein anderer )

Am fairsten und effektivsten wäre denke ich eine Art Scheduler-Prinzip:
Jede Datei bekommt eine eigene Queue, und es gibt nur einen Upload-Slot. Der Slot lädt an den ersten ein der ersten Queue einen vollen Chunk hoch (ich würde Chunks dann kleiner machen, sagen wir 1 MB) und springt dann zur nächsten Queue, am Ende dann wieder zur ersten. Damit bekommen alle Files im Share genau gleich viel Upload ab, wenn die Queue leer ist gehts halt weiter zur nächsten. Ein einziger Upload-Slot ist schneller als mehrere weil er auch weniger Overhead produziert, allerdings hab ich oben schon ein auftretendes Problem erklärt. Eine seltene Datei wird genau gleich oft mit Upload bestückt wie Mainstream.

Ich weiss dass sich das irgendwie nach BitTorrent anhört, aber es ist doch so: Solange ich selber was runterlade, gleicht sich das was ich hochlade wieder aus - wenn der Ratio 1:1 ist hat das Netz an mir also nichts gewonnen, ich nehm mir wieder was ich geb. Erst wenn ich mal eMule im Leerlauf hab gewinnt jemand anderer. Ich glaub ehrlich gesagt nicht dass es ausser Releasern noch viele gibt, die einfach laufen lassen, also ist ein Tauschsystem eigentlich gar keine wirkliche Verschlechterung. Dass Leute ihre Dateien im Share aus Platzmangel löschen passiert jetzt auch schon, das wird sich erst lösen wenn sich größere Festplatten immer weiter durchsetzen.

Irgendwie bekomme ich das Gefühl dass wir kein Problem mit Leechern oder dem System haben - was uns wirklich fehlt sind Bandbreite und Speicherplatz....

@ tantal:
sorry, war schon ein bissle spät, als ich dies geschreiben habe. ich stimme mit dir in sachen upload und dessen aufteilung komplett über ein.

das problem, das ich sehe, ist nicht unbedingt die bandbreite ( obwohl dies natürlich letztlich meist die begrenzende größe ist und 17 bis 19 stunden uploadzeit pro cd doch etwas lange ist ), sondern die tatsache, das viele user den muli ausschalten, sobald sie haben, was sie wollten, weil sie im inet spielen wollen oder die angst vor verfolgung doch noch immer da ist. somit wird aber nicht die komplette bandbreite für emule genutzt. ich muss gestehen, das ich ( leider ) auch zu dieser gruppe gehöre und damit nicht gerade sehr spendabel bin.

zum thema bandbreite: es fällt natürlich auf, das sich die computer technik sehr rasch voranschreitet ( prozessoren verdoppeln alle 18 monate ihr leistung, festplatten wachsen fast schon auf bäumen ^^) aber die übertragungsraten schon seit einigen jahren auf dem gleichen level bleiben. ich würde denken, das liegt daran, das immer mehr das inet nutzen wollen und somit das plus an transferleistung mit neuen anschlüssen draufgeht an statt diese auf die bisherigen verteilen zu können. doch wir können dagegen nix machen, da sich nicht jeder einen privaten t1 anschluss leisten kann ^^. dies würde auch ein bissle zu sehr auffallen bei den behörden.

das 0pf4

@CruelJ:

Ich hab mich auch eher auf die Bandbreite bezogen. Wenn jeder 10 MBit zuhause hätte und ein paar Leute dann noch mit 100 MBit sharen würden, wäre glaub ich jeder glücklich. Dann noch Festplatten im Bereich von einigen Terabyte und uns würde nach relativ kurzer Zeit nicht mehr einfallen, was wir jetzt noch alles brauchen könnten, weil wir es eh schon haben. Das würde allerdings zu einer massiven Informationsentwertung führen (Wie viel Wert hat ein Album oder ein Film zwischen 10.000 anderen noch?), irgendwann hätten MI und die Filmindustrie _wirklich_ kein Geld mehr für neue Produktionen, und es würde nix neues mehr nachkommen. Was wir am Anfang vielleicht gar nicht schlimm finden würden, weil man sich bestimmt einige Monate (wenn nicht Jahre) mit dem weiterbeschäftigen könnte, was man noch nicht gesehen hat. Ich zahl auch nicht gern für das was ich haben will, befürchte aber schon dass es irgendwann kaum mehr neue Werke geben könnte. Auch im Sinne von Büchern, Sachbücher gehen eh schon seit ner Weile den Bach runter weil alles im Internet steht und wer liest schon noch Romane, wenn es im IRC grad so schön abgeht.

Jetzt bin ich zwar total vom Thema abgeschweift, aber im Moment find ichs eigentlich ganz okay - das was ich haben möchte ist bis zum Wochenende meist fertig (davor hab ich eh keine Zeit/Lust es zu gucken), und wenn ich noch mehr hätte würd ich ernsthaft Probleme damit bekommen mir alles anzugucken ohne mein Privatleben zu gefährden.

Ich denke mal, die zweite Verwertungsstufe (CD/DVD) wird für Musikindustrie und Filmindustrie in nicht allzu ferner Zukunft komplett entfallen. Dann gibt's nur noch Kino und Konzerte - und keine 0-8-15-Musiker/Filmemacher mehr.

@upload2010:

Solange es Menschen ohne Breitband und genug Ahnung gibt, wird es auch Datenträger zum Kauf geben. Dass kleinere Bands aussterben stimmt aber, es ist jetzt schon so dass es schwer ist einen Vertrag zu bekommen (obwohl die MI jedes Jah mehr Umsatz schreibt!)

Ich denke allerdings dass es einfach immer Menschen geben wird, die kreativ sind, und dass die dann auch den Weg finden, sich selbst zu produzieren. Technisch ist das durch die Verbreitung von hochwertigen Soundkarten etc. ja nicht mehr so ein großes Problem, Vertriebskanal ist das Web und bezahlt wird über PayPal oder ähnliches. Dann kann man halt von seiner Musik wahrscheinlich nicht immer leben, aber das ist doch heute auch schon so - das große Geld machen nur einige wenige. Und Musik ist dann am Besten, wenn kein Kommerz dahintersteckt.

@tantal:
mit der entwertung geb ich dir vollkommen recht, deswegen bin ich auch recht froh so wie es ist
man sollte den muli eh nur zum testen von verschiedenen sachen benutzen und bei gefallen kaufen

btw, mein kommentar zielte eigentlich allgemein auf das ganze geschrei um schnellere downloads...

egoism rulz

@LeonardSkinner:

Für Leute ohne absolutes Gehör sind MP3's spätestens ab einer Bitrate von 192 kBit/s nicht vom Original zu unterscheiden. Das dürfte auf die meisten Menschen zutreffen. Diejenigen, deren Gehör nicht in das psychoakustische Modell passt, sind da halt arm dran. Allerdings finde ich dass auch viel nur psychisch bedingt ist: Ich kenen Leute die ernsthaft behaupten, eine kopierte Audio-CD würde anders klingen als das Original. Das ist dann einfach lachhaft.

Man kann durchaus auch mit sehr niedrigen Datenraten und MPEG-2 gute Ergebnisse erzielen, [...].

Qualität ist mit fast jedem Codec möglich, steht und fällt aber mit der Erfahrung des Benutzers.


sambal-olek: ich war so frei das mal etwas zu kürzen. Abgesehen davon, daß man sich hiergerade arg vom ursprünglichem Thema entfernt waren mir auch diese sehr netten Umschreibungen doch noch um einiges zu konkret.

hab im Moment keine Zeit alles zu lesen, aber den ersten beiden Posts von Mr. Faber kann ich mich nach einigen Tagen "Fremdgehn" mit Overnet 51 anschliessen.

EDIT: nach ein paar Stunden eMule siehts wieder anders aus.. mit etwas Anlauf wird ON niedergewalzt
Ausserdem hatte ich mit ON schreckliche CPU-last und Festplattenstress Probleme, das wäre mir der schnellere Start der Downloads auf Dauer nicht wert

Kann man ED-Horde eigentlich immer noch so leicht cheaten?
500kb UL einstellen und eine Qos-Beschränkung auf TCP Outgoing...ging zumindestens bei 2 älteren Versionen, weiß nicht mehr bei welchen.

Sollte SUQWT und XMan´s QueueOverflow in den offiziellen Muli eingebaut werden, dürfte IMHO das Problem mit seltenen Dateien geringer werden.

Subjektiv mag ich Horde nicht, da es, für meinen Geschmack, ein bisschen zuviel traden ist.

In diesem Sinne...

@sambal-olek:

Och, ich meinte ja nur einen Film über meinen Goldfisch und eine Doku über Martin Luther King

So ich mische mich auch mal ein, erstmal muss ich danke an Mr Faber sagen, ich war erst unentschlossen ob der Esel wirklich gut ist, denn früher habe ich ja nur zu emule gewechselt da mir der Esel zu langsam wurde. Aber ich habe es dochmal probiert und bin bei ihm geblieben, er ist zwar optisch nicht so schön aber ich bin lieber auf nen download scharf. Und auch mein Upload läuft mit 19 kb/s (192 kbit habe ich bevor welche fragen). Ich bin rundum zufrieden.

biber, darum gehts doch gar nicht, sondern wie gestaltet man eMule evtl. etwas effektiver oder gerechter, ohne den filesharing Gedanken aufzugeben.

Meine Meinung: Creditsystem im Zusammenspiel mit diesem leidlichen releasestellen von nichtfertigen dls weist ganz klar Tendenzen zum filetrading auf. Dann kann man es auch gleich richtig machen. Wobei jedem klar sein muß, das damit das incomming Verzeichnis noch weiter an Bedeutung verliert.

Horde mag für rare files evtl. funktionieren (hab da keine Erfahrung), aber die Eigenschaft von rare files ist ja, das nur wenige das file komplett haben und auch nur wenige aktuelle dls existieren. Quellen mit fertigen files nehmen meines wissens nach am Hordeverfahren nicht teil.
Für rare files sehe ich in eMule das Problem, wenn man nicht innerhalb den Zwangstennungen zum uploadslot gekommen ist, wird es auch in den darauffolgenden Zyklen nicht unbedingt besser. Ein "Save Upload Queue Waiting Time" (SUQWT) scheint mir hier nur teilweise eine Lösung zu sein, da nach Zwangstrennung meiner Quelle mit vollständigem file ich diese innerhalb einer Stunde erst wieder finden muß, was bei rare files fast aussichtslos ist. Ebenso würde eine nWay Queue über die Zwangstrennungsgrenze hinweg eher den mainstreem bevorzugen. Wenn bei einer nWay Queue auch die shared files berücksichtigt würden, könnte es ein Schritt in die richtige Richtung bzgl. Langlebigkeit der files sein. Aber auch hier muß jedem klar sein, das mit dem gegenwärtigen Creditsystem dies zu Lasten seines dl geht.

Also, wie mans macht, macht mans verkehrt

mfg - Sepp

@seppl

QueueOverflow with Minimumcontingent + SUQWT müsste doch eigentlich reichen.