´Hmm ich denke einfach das die Devs bei einigen Features überregaieren ich denke mal sie sollten erstmal ihre arbeit machen und nich die arbeit der Moderschlecht machen die in bestimmten dingen viel für orginal Emule gemacht haben.

Nabend!

Unfaire oder netzwerkschädliche Features wurden als negativ genannt (logisch).
Dies ist eine recht generelle Aussage, welche voraussetzt, dass die Modder sich über ihre Implementierungen Gedanken machen. Leider passiert dies nicht immer, oder der negative Aspekt wird nicht so wichtig genommen.
Nehmen wir das "Overflowing". Es erlaubt bestimmten Usern u.U. immer die Warteschlange zu betreten, während alle anderen abgewiesen werden. Der Haken daran wird um so deutlicher, desto kleiner man die Queue einstellt (hier ist also auch ein verringern der minimalen Queue negativ förderlich). Und dass zB Freunde immer in die Queue dürfen und andere nicht ist der Punkt des Anstosses.
Wenn Gleichberechtigung angestrebt ist, muss man sich auch über diesen Fall Gedanken machen.

Manche Ideen von Moddern sind in der Theorie desöfteren ganz gut. Jedoch wenns dann an der Implementierung hakt, dann stehen Hintertüre offen. So hat sich zB auch LSD nicht immer gekümmtert, wie sicher er seine Ideen umgesetzt hat, und so waren sie allzuleicht negativ nutzbar. (und nun sage kein LSDfan, sein Code(ing) wär reinste Sahne)
Als Entwickler kann man seine Idee nicht möglichst aufwandslos umsetzen, sondern muss auch Verantwortung übernehmen und die Sache komplett und akkurat durchziehen.
Auf "Hintertüren" angesprochen meinte LSD auch direkt es wäre ihm schnuppe.

Wichtige Punkte wurden bei LSD öffentlich gestellt. Dies sind auch die wichtigen Dinge. Manual Reask von Servern oder Clients ist, was durch die opcodes für alle gleich gestellt ist. Manchen ein manuelles Reasken zu gewähren, stäche(?) wieder heraus. Für einen Client alleine löst das sicher auch keinen wilden Netzverkehr, aber alle Funktionen muss man globaler sehen. Es handelt sich dann um hunderte/tausende von Clients (optimistisch gesehen).
Die Aussage, dass man im Notfall schon gebannt wird kann keine Wiedergutmachung sein, sondern deutlich machen, dass solch eine Funktion Risiken beinhaltet die man nicht in die Hand des Users geben sollte oder brauch.

SLS - Uneinigkeit - ja. Devs sind kritischer auf Folgeschäden, während User und auch MODs die unmittelbaren Vorteile nur sehen möchten.
Aber dafür gibts ja die Diskussion, damit sich darüber ausgetauscht wird.
Dass SLS in Grenzen vorteilhaft ist wird ja auch gesagt, jedoch nicht verantwortbar in den Grenzen mancher Implementierungen (Devil: 48h Gültigkeit, soviele Quellen wie möglich)

Zu mehreren Punkten wurden wiederholt unsere Gründe genannt. 5 Posts weiter scheints dann keiner mehr zu lesen.
zB die Punkte die an LSD nicht akzeptabel waren wurden gleich mitbegründet.

Allgemein, wir sind genervt, einerseits diese ganze Arbeit tun zu müssen, dass nicht ausreichend "Selbstkontrolle" da ist oder getan werden will. Wenns um 1-2 Quellen mehr geht, wollen manche durchs Feuer gehen und pöbeln dann die Devs an, dass wir nichts verstehen und die armen Modder vergraulen, ohne die der eMule natürlich schon längst tot oder nie aus der Versenkung gekommen wär. :shock:

Hackersondope2002: ah, danke, der richtige Beitrag von dir.
Ja, wir würden gerne "unsere Arbeit machen" (natürlich nicht dass auf unsere Freizei ein Anspruch besteht) - aber soll zugesehen werden, wenn manche Mods über die Stränge schlagen? Darkmule wollte in seinen jungen Jahren auch im Board posten. Sollte man das auch hinnehmen?
Wenn manche Modder nicht die Verantwortung übernehmen, muss was passieren. Obs gefällt oder nicht. Uns gefällts sicher nicht, aber im Sinne fürs Netzwerk denken wir, wir müssens tun.
Ich hatte auch mal mehr Laune beim Muli-programmieren, aber das ganze Taraa hier könnte sie einem nehmen. Aber vielleicht hast du ja einen viel umfassenderen Blick auf die ganze Geschichte?!



Mit tauben Fingern sag ich Gute Nacht, bevor ich noch mehr im Dilirium tippse. :)
Ornis

Ornis+,
danke für Dein Statement.
Im Grunde bin ich auch voll und ganz dafür, daß Moder sich Gedanken machen und Verantwortung übernehmen müssen. Ich für meinen Teil halte das so bei den von mir programmierten Features. Klar passieren uns allen mal Fehler die dann zu einem schlechten Verhalten eines Mods führen können. Aber schließlich sind wir eine große Community mit vielen Entwicklern welche die Fehler finden und verbessern sollten.

Ornis, meine PM an Dich wartet noch auf Beantwortung.
1) wäre ein Queue-Overflow nicht sehr nützlich wenn es so implementiert wird, daß für jedes File ein Minimumkintingent an Plätzen in der Uploadqueue vorhanden sein darf ?
2) mein Reask a Client ist ja kein Reask for Sources, sondenr vielmehr ein Aktualisieren. Wäre dies erlaubt wenn min. 5 (oder 10) Minuten zwischen der Benutzung liegen würde !?

Beide Punkte hab ich bereits (fast) fertig programmiert und warte eigentlich nur noch aufs ok ;-)

Ornis+, es sollten schon klare regeln zählen, aber dann solltet ihr dev's, die auch klar festlegen! vielleicht wäre es besser, wenn ihr die codezeilen, die nicht verändert werden sollen, als dll zu verfügungung stellt!
cyrex2001
ps: ich hab so gut, wie keine ahnung von c++!

cyrex2001,
da machst Du es Dir aber zu einfach ;-)
überleg doch nur einmal eine Kick-Funktion einzubauen... welche Codezeilen sollten die DEVs in diesem Fall als unveränderbar bezeichnen ?

Nun ja... über viele Features läßt sich eh streiten, ob die nun gut oder schlecht fürs Netzwerk sind. In so manchen Fällen findet man darauf sogar gar keine Antwort solange man nicht einen ausgiebigen Praxistest machte. Was ich mir aber öfter wünschen würde, daß über bestimmte Features mehr diskutiert wird. Erst wenn viele Meinungen zusammenlaufen werden bestimmte Dinge erst von allen Seiten durchläuchtet.

Ornis+
Auch von mir ein dickes Dankschön!
Endlich haben wir hier auf dem Board mal eine Aussage auf die man bei (den immer noch zahlreich und sogar per PM eintrudelnden Fragen auf das "Warum?" beim temp. Bann des LSD Mods) linken kann.

Ich denke, daß die Leute mit Hirn und Verstand und der nötigen charakterlichen Größe mal nicht nur an den eigenen Bauchnabel zu denken, die Entscheidung der Devs völlig nachvollziehen können. Ich jedenfalls und auch die Kollegen stehen hinter eurer Entscheidung.


Nur eine Frage quält mich wirklich: Wieso wird im Kademlia Testclient jetzt schon mit solchen Spielereien wie Skins gearbeitet ??? :roll:
Da kommt schon bei nicht gerade wenigen die Frage auf, ob es nicht wichtigere Dinge derzeit gibt. :idea:
Gleiches Spiel mit dem mobile-Zeugs...

Nichts für ungut! :D

Xman, worauf ich anspiele, sind die options in opcodes.h, wie reasktime usw.!
cosmic girl, ich hab noch nie, nie den mobile- und jetzt den skin-schnickschnack benutzt oder benötigt!
cyrex2001

Moin!

Es wird dadurch nicht Wichtiges vernachlässigt.
Aber bedenkt auch, dass wir das Entwickeln aus Spaß an der Sache machen. Und wenn einer eine Idee hat, die ihn interessiert, nicht ganz unnütz ist, dann machen wir auch mal was zum eigenen Interesse.
Sowohl die Sache mit den Skins war kürzlich ein Geistesblitz, als auch damals die Programmierung von Mobile Mule.
Entwicklungs-Herausforderungen reizen hin und wieder. Auch wenn nicht unbedingt ein allgemeins Interesse besteht.
Als ich letztes Jahr begann in eMule reinzuschauen, hab ich auch aus Interesse am Programmieren und der Vertiefung in C++ teilgenommen und nicht in erster Linie um den Usern zu dienen. (was jetzt natürlich Hand in Hand läuft ... meistens... :) )

Zu der Markierung der besser nicht zu verändernden Codezeilen...
Naja, wir können nicht alle Bereiche, in denen jemand negativ rumwüten könnte markieren, das würde ausufern. Einige Kernmethoden können noch entsprechend kommentiert werden, ja.
Andererseits ists natürlich auch eine Sache des Mitdenkens der jeweiligen Person. Wenn nicht nur an Vorteile, sondern an Nachteile von modifiziertem Code gedacht werden würde, gäbs manche Probleme nicht. Leider mangelt es manchmal am Willen oder auch Können dazu.

Die Kern-Opcodes sind ja mit einem Vermerk versehen. Das manuelle Reasken mancher Mods weicht dieses Limits dann wieder auf...
...was auch der Grund für das verneinen dieser Methode begründet.

XMan: Wenn aufgrund der Clients selber (Freund oder nicht Freund, hohe QR oder nicht,...) der Queuebeitritt entschieden wird, ist das nicht tragbar. Wenn die Entscheidung auf anderen Dingen beruht, dass zB Clients mit Anfragen für schlecht verbreitete Files zB bevorzugt in die Queue kommen) ist dies jedoch denkbar. Oder ein Minimumkintingent an Plätzen pro FIle... nunja
Oft hilft hier auch einfach der Einsatz der Release-Prioritäten.

2. siehe vorvoriger Abschnitt.


Mist, ich muss los... :)
Ciao
Ornis

Ornis+,
*grübel*
Wer von uns hat nun den Denkfehler !? Was nützt mir die Release-Prio, wenn der Client gar nicht in die Queue reinkommt ?
Nochmal, die Idee ist es, pro File das ich share ein Minimumkontingent an Wartelisteplätzen zur Verfügung zu stellen. Das ist fair für alle Clients die Anfragen... etwas "fairer" für Clients die ein seltenes File wollen.
Ich halte die Idee für so gut, weil sie maßgeblich die Leichenbildung verhindert.
So wie ich das jetzt verstanden hab, hab ich grünes Licht und werd das Feature heute mal fertigstricken. ;-)

Ja, mein Kommentar bezog sich allgemein auf Änderungen an Queues oder Dateipriorisierungen.Manche "extra-"Bevorzugungen für Dateien wären auch durch die Prioritäten steuerbar.

Wenns nicht Clients aufgrund der Clienteigenschaften bevorzugt (Freund, Client gab mir was,... etc) sondern dies anhand des angefragten Files entschieden wird, sollte es okay sein.

Neue Ideen kannst du auch gerne im Dev-Bereich (bei uns) posten und mehr Meinungen einholen. Ich will mich hier jetzt ja nicht als Alleinentscheider aufspielen. :)

Viel Spaß!
Ornis

Mit dieser Erklärung kann ich gut leben - hatte nicht daran gedacht, daß auch bei solchen Beiläufigkeiten eine gewisse programmiertechnische Herausforderung locken kann. :D
Klar sollt ihr auch Spaß an der Sache haben dürfen! ;)

Wie gut, daß wir mal drüber gesprochen haben jetzt und hier - das dürfte einigen, die diese Frage gerade in der letzten Zeit auch gestellt haben, ebenfalls eine neue Perspektive eröffnen..

Achja Ornis- die erde ist zum eine Scheibe

bin mal gespannt wie lange ihr euch blackhands friendslotspielereien anseht, weil das ist echt assozial und nurnoch friendsharing und kein filesharing mehr.

Xman,

wenn die DEV das Behaupten habe die echt einen Kanall weg.

Denn wenn ich das richtig weis werden doch die Quellen bei einem selber gespeichert und ich muss nicht den Server mit anfrage Belästigen oder ?

stern, soweit ich weis wird die hash-id gespeichert und diese ändert sich bei jeder zwangstrennung, damit werden dann doch die server belastet!
cyrex2001

Mal ganz vorsichtig mit solchen Aussagen!
Aber mit dem Rest deines posts hast du dich eh disqualifiziert.. :P