![]() |
Also bei mir habe ich SUC zwischen 6 und 16 eingestellt, Slotspeed ist 6250 (ist wohl default), und ich habe eigentlich auch immer zwei im Upload, manchmal kurz noch einen dritten. Sieht man gut in diesem Bild, die gelbe Linie sind die zwei Uploadslots, die kurzen Zacken darin ist der dritte. http://home.pages.at/usul/lovelace10everbindungen.png |
Zitat:
Ist doch eigentlich eines der am leichtesten zu implementierenden Features. @lovelace: Kannst du das vielleicht nicht einbauen ? Was noch interessant wäre: Hash-gebundene Friend-Uploadplätze. Alleine schon wegen der 24 Stunden Zwangstrennung der Telek*m finde ich die normalen IP gebundenen Uploadplätze für DSL-User benachteiligend. Wenn man dagegen den Uploadplatz Hash-gebunden machen würde, könnte man ihn jederzeit in der Friendlist aktivieren, auch ohne das diejenige Person connected ist, und der Uploadplatz würde auch nach einem Disconnect erhalten bleiben... Sagt mal, ich lese immer wieder, dass es so große Probleme mit "gestohlenen Userhash's" gibt. Seid ihr sicher, dass da so oft wirklich eine Userhash von einer anderen Person gestohlen wird ? Irgendwie kann ich mir das nicht vorstellen. Ich glaube eher, dass da zwei Leute zufällig die gleiche Hash bekommen haben, da die Hash-id ja komplett nur eine 256 Bit Zufallszahl ist. Man denke nur an das Geburtstags-Paradoxon aus der Wahrscheinlichkeitstheorie......... |
Zitat:
Zitat:
Zum Geburtstagsparadoxon: Die Wahrscheinlichkeit, das zwei am gleichen Tag Geburtstag haben, liegt bei 1:365 (bzw. 1:366 im Schaltjahr), und das ist gegenüber den obigen Werten doch seeeehr wahrscheinlich ;-) P.S. Ich hoffe, ich hab mich nicht irgendwo sehr verrechnet. Aber die Größenordnungen dürften in etwa stimmen. P.P.S. Das Killerargument zum Schluß: Die Hashs der Dateien sind genauso groß. Die werden zwar berechnet aus dem Inhalt der Dateien, aber dieser Inhalt ist ja mehr oder weniger auch zufällig. Und wie oft ist es dir schon passiert, das verschiedene Dateien (also verschiedener Inhalt) den gleichen Datei-Hash haben? Theoretisch ist das durchaus möglich, bloß eben genauso unwahrscheinlich wie ein zufällig gleicher Userhash ;-) |
Schock am Morgen... :shock: als ich vor 3 Stunden meinen Beobachtungsposten :wink: eingenommen habe, mußte ich 25 Leute in meinem upload sehen und das bei den Einstellungen die ich oben beschrieben habe. Mein upload schwankt zwischen 34 und 42 kB/s. Wenn ich bei 34 up 11 Leute drin habe und er geht auf 38 kommen Leute dazu. Geht der speed wieder runter bleiben die Leute drin, aber sobald er wieder Gas gibt kommen wieder Leute dazu. Ich hoffe, das ist einigermaßen verständlich erklärt :roll: An meinem Provider können die Schwankungen nicht liegen, weil ich zwischenzeitlich mit einem anderen Muli probiert habe, per messenger getauscht habe und per ftp. Immer konstanter upload. Ich werde jetzt mal den SUC ausprobieren. Mal schauen wie es dann läuft. |
Zitat:
Um zwei gleiche Hash-Id's bei 128 Bit Länge zu bekommen brauch man 2*10^19 verschiedene Zufallszahlen = User für einen Treffer, d.h. das 2. von dir angeführte Verhältnis ist richtiger - die Wahrscheinlichkeit liegt also sozusagen bei 1:2*10^19. Ist doch etwas mehr (bzw. weniger) als ich getippt hatte. Zitat:
Ich hab mal in EMule selbst ein wenig Debug-Code eingebaut um zu schauen, warum ständig unbekannte Namen in meiner Freundesliste drin waren. Ergebnis: Die setzen sich nicht selbst rein (wie ich erst gedacht hatte), sondern da wird der Name eines anderen Users in der Freundesliste geändert (eine tolle Debug-Meldung: "Friend changed his name..."). Sowas passiert ja nur bei gleichen Hash-Id's. Daher bin ich bis jetzt immer von Hash-Kollisionen ausgegangen. Zitat:
Das Geburtstagsparadoxon sagt: Wenn du 23 Leute in einem Raum hast, dann hast du zu 50% Wahrscheinlichkeit zwei mit gleichem Geburtstag ! Wenn du nur 2 Leute hast, ok, dann 1:365. Aber je mehr Leute du hast, desto grösser wird die Wahrscheinlichkeit - und zwar verflixt schnell ! Und im Donkey-Netz schwirren doch etliche tausend Leute rum, deren Hash-Id alle zufällig gezogen wird, und die mal alle bei der Berechnung gleichzeitig berücksichtigen muss. Zitat:
Das ganze funktioniert nur, wenn alle Zahlen zufällig sind. Hast du schonmal eine zufällige File-Hash gesehen ? Also ich noch nicht. 8) Bei strukturierten Daten sieht das immer anders aus. Da liegt die Wahrscheinlichkeit noch sehr viel weiter darunter... |
Ein Bug - die Frage ist nur: liegt es an der 0.28a, am [lovelace] Mod oder an der Plus.1d? :mrgreen: So oft den gleichen user in der DL-queue hatte ich seit den uralt-Versionen nicht mehr (0.24 oder wo das noch ein Problem war..) http://www.xi.awmspace.de/mu/lovelac...lti-Plus1d.png Der mule läuft nun seit 49 h und die CPU Last hat sich nach dem Ausreisser von 20 % gestern wieder bei gemütlichen < 10 % eingependelt (ok, kaum DL im Moment, da der 24-h-disconnect erst 40 min zurückliegt) - aber auch bei mehr DL nie über 10 % im Schnitt. |
@MightyKnife Ok, der Herr will es genau wissen, machen wir halt Nägel mit Köpfen :twisted: Ich beziehe mich auf diese Seite, dort steht auch, das man 23 Leute in einem Raum braucht für eine 50%ige Chance auf zwei gleiche Geburtstage, also scheint es sich ja mit deinen Informationen zu decken. Die Formel für die Wahrscheinlichkeit auf den gleichen Geburtstag bei n Leuten lautet p = 1 - 365! / ((365 - n) · 365^n). Münzen wir das mal auf Emule um, wir haben 2^128 potentiell verschiedene Userhashs, gehen wir mal von 1 Millionen Nutzer aus. Dann ist die Wahrscheinlichkeit von p = 1-(2^128)!/((2^128-1000000)· (2^128)^1000000) Dummerweise habe ich momentan kein Programm installiert, womit man das berechnen könnte :roll: Hat mal jemand Maple oder Mathematika installiert und kann das mal ausrechnen? Zitat:
Wie du das mit dem Killerargument meinst, verstehe ich nicht ganz. Mir ist kein einziger Fall bekannt, wo zwei Dateien den gleichen Hash haben und trotzdem verschieden sind. Das es gleiche Userhashs gibt, passiert anscheindend viel öfter. Vielleicht ist ja auch der Zufallsgenerator für den Userhash nicht so zufällig, wie er es sein sollte ;-) Das mit deiner Freundesliste: Nimm mal an, du hast einen Freund mit seinem Userhash in deiner Liste. Dann kommt jemand anders mit nem geklauten Userhash und seinem eigenen Namen, der Diebstahl wird nicht bemerkt, was passiert? Der User hat scheinbar seinen Namen geändert. Könnte das sein? Edit: das wird jetzt sehr offtopic, ich halte es bloß für sehr unwahrscheinlich, das zwei Leute den gleichen Userhash haben (immer vorausgesetzt, die Userhashfunktion funktioniert einigermaßen zufällig ;-) ) |
Zitat:
Ich hatte mit der e-Formel gerechnet, da sich so hohe Potenzen nicht ausrechnen lassen... aber es ist das gleiche. Kurz zu deiner Anmerkung "Könnte das sein ?" Ja, natürlich könnte das sein, daher hatte ich vorher ja auch geschrieben "glaube/glaubte". Die Sache mit dem Killerargument könnte ich auch noch erklären, aber du hast schon recht - wird offtopic. Daher lass ich's mal. |
So, um aber noch wenigstens ein bischen ontopic zu bleiben noch ne andere Frage an die, die sich mit SUC auskennen: Ich würde den SUC gerne so einstellen, dass er relativ schnell reagiert. Normalerweise Upload Min 1 Max 15 (Standard DSL über Router, an welchem 4 PC's dranhängen). Wenn ich ne E-Mail mit nem grossen Anhang von einem der Rechner versende oder ne grosse Datei auf nen FTP schiebe, wäre mir das liebste, er reagiert binnen 10-30 Sekunden und schraubt den Upload innerhalb dieser Zeit auf 1 runter. Danach könnte er dann wieder so binnen 1-2 Minuten auf 15 steigen. Ich hab selbst mal versucht, sowas mit den Parametern hinzubekommen, aber auch ich komme hinter das System nicht 100%ig hinter - er reagiert sehr träge. Ist sowas möglich ? Wie müssten Einstellungen für sowas aussehen ? Irgendjemand eine Idee ? |
MightyKnife Hm, bin auch nicht so wirklich glücklich mit dem SUC2 - auf dem offiziellen Board gibt's einen thread, lovelace hat dort auch mitgemischt: http://www.emule-project.net/board/i...=15&t=14701&s= @ all Um das offizielle Board lesen zu können, braucht man einen account dort (nicht so locker wie hier bei uns auf dem Board ;) ). |
hier mal ein zitat: Zitat:
also dass die sich nich mögen glaub ich nich... aber warum war das sonst so? zufall? |
Zitat:
|
Ich bin bei 5 LSD Clients in der Queue. Bei einem hab ich bisher 896kb gedownloadet von den anderen noch nichts. Ich werd die Clients mal im Auge behalten obs da Probleme gibt. |
Ich hab von jemandem mit einer LSD 8b Version 4,5 MB bekommen. Vielleicht auch noch von anderen, aber ich hab noch nicht weiter nachgeschaut. Irgendwie bin ich aber generell mit der V0.28 nicht ganz zufrieden. Zieht sich alles ein bisschen. Aber man darf ja nicht vergessen das das ganze ja nur eine beta ist. sharelook |
also ich muss wiklich sagen :!: :!: ALLE ACHTUNG :!: :!: diese Mod ist einfach nur geil zieht bie mir nach kurzer Zeit schon wie sau :lol: Upload ist auch ziemlich konstant, DL steigt was will man mehr :?: |
oweh, hier ist viel passiert ;) ...jaja, wenn man mal kurz nicht da ist: (jetzt kommen 3 postings in Serie, find ich eigentlich doof, ich kann ja editieren, ja eigentlich..schon..) zu Seite 3: Zitat:
Zitat:
lovelace mods benutzen auch ein dynamisches slotspeed management wie im offiziellen clienten. je mehr up, desto höher der speed per slot. Ich glaube, es waren 0,5% oder so. 0,5% von 42kB sind dann knapp 800, die müßtest Du noch auf die 3000B/s zuzählen. 3800*11=41,8KB/s. Nu geht's auf :) Zitat:
userhash theft: schau mal in die known clients, sortiere nach größtem download, und schau Dir mal die anzahl gleicher werte bzw hashs an. Wirst staunen. Tja, wenn Du öfter die Woche mal 'nen 6er im Lotto machst, dann ist ein zufällig doppelter userhash auch wahrscheinlicher. ;) Usul hats schon und noch besser erklärt...weiterlesen müßte ich können.. |
und einen ganz großen kuss an cosmic girl :roll: für die aufbauenden postings (und wegen der Namensgeschichte, mußte ich ja nochmal zuschlagen :) ). das andere mit den vielen usern in der download-queue ist mir auch schon aufgefallen, bei mir sinds aber nicht so viele, so 2 bis drei. Mir scheints, es ist seit 27 (offizieller client? ) so... |
empfindlicher wirds, wenn pitch und high pass runtergesetzt werden. also (700/../2500/..) mal als extremes beispiel. Jetzt müsste nur noch drift so eingestellt (erhöht) werden, daß die fehlalarme, die durch die überempfindlichkeit kommen, augeglichen werden... Außerdem soll der upload ja auch wieder steigen, wenn kein anderer transfer bremst, daher muß auch low pass gesetzt werden. Bei so empfindlichen sachen sollte das allerdings um die 500 oder höher liegen. ich poste hier nochmal eine englische erklärung zu den werten. passend zu der grafic in Suc options explained. Zitat:
|
http://www.penthesilea.ch/yabb-smile...plets/grin.gif Ist angekommen. Da ist mir jetzt nach eMule Neustart gleich noch was aufgefallen: Besagter user aus dem screenshot von ganz oben erscheint schon wieder - diesmal mehrfach im log: 4/27/2003 1:09:29 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed. 4/27/2003 1:09:30 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is outdated or using a stolen userhash and has been removed. 4/27/2003 1:31:09 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed. 4/27/2003 1:52:49 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed. 4/27/2003 2:14:29 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed. 4/27/2003 2:36:09 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed. 4/27/2003 2:57:50 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed. 4/27/2003 2:57:53 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is outdated or using a stolen userhash and has been removed. 4/27/2003 3:19:30 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is using a stolen userhash and has been removed. 4/27/2003 3:24:39 AM: Client 'dsldsldsl[ITA]' and 'Graaaaaaaaaham' have the same userhash or IP - removed 'dsldsldsl[ITA]' 4/27/2003 3:24:39 AM: AntiCreditTheft [lovelace]: client 'dsldsldsl[ITA]' is probably using a stolen userhash and has been blocked. Und dennoch habe ich den Vertreter noch vielfach in der DL-queue für das file. Müsste der dann nicht mal langsam ganz rausfallen? Oder ist das besagtes Problem der offiz. Version? |
Zitat:
Danke. Aber als wirklich empfindlich würde ich diese Einstellungen auch nicht bezeichnen. Eher als etwas empfindlicher als der Standard. Ich hab hier testweise mal eingestellt: 700/525/2500/750 mit Min=1, Max=14. SuC hielt hier zuerst den Upload konstant auf 14 K. Dann hab ich separat auf nem anderen PC eine FTP-Verbindung zu einem schnellen FTP-Server im Netz aufgebaut und mal ne 1,6 MB-Datei übertragen. Der Upload lag am Anfang bei 4,5 KB/Sek. Es hat dann ganze 3,5 Minuten gedauert, bis er auf 6,5 KB gestiegen ist - dann war die Datei aber auch schon drüben. In einem 2. Versuch hab ich mal 700/525/2500/50 benutzt. Diesmal fing er mit 5,2 KB/Sek an und war nach 3,5 Minuten bei 6,8 KB/Sek. Also sehr schnell reagiert SuC dabei nicht grade... :? |
Noch was: Der Mod (und damit auch die aktuelle Orginalversion) hat immer noch diesen Sommerzeit-Bug... scheint das niemanden zu interessieren ? Schade... :| |
Zitat:
|
Zitat:
Zitat:
|
Zitat:
Trotzdem mal ne kurze Erklärung, was ne Man-in-the-middle Attacke (ich nenns im folgenden mal MitmA) ist (damit ich nicht einroste :-) ):Angenommen, Alice und Bob wollen sich über eine sichere Verbindung unterhalten. Um dies tun zu können, müssen sie sich vorher über die Verschlüsselung einig werden (z.B. über den verwendeten Schlüssel). Nachdem das getan ist, können sie sicher kommunizieren. Bei einer MitmA hängt sich der Angreifer vor dem Beginn der Kommunikation zwischen die beiden beiden Clients und gibt sich gegenüber Alice als Bob aus und gegenüber Bob als Alice. Beide denken nun sie kommunizieren mit dem jeweiligen gegenüber, dabei kommunizieren sie beide nur mit dem Angreifer. Jetzt handeln beide eine Verbindung aus (mit Schlüssel etc.), aber halt mit dem Angreifer. Der fungiert praktisch als eine Art Proxy/Relay/wasauchimmer. Wenn dann eine angeblich sichere Verbindung besteht, schickt Alice mit dem mit dem Angreifer vereinbarten Schlüssel verschlüsslte Daten an den Angreifer, der entschlüsselt die, liest sie und schickt sie mit dem Schlüssel von Bob verschlüsselt an diesen weiter -> Alice und Bob denken, sie kommunizieren sicher, dabei liest der Angreifer in der Mitte mit. Falls das jetzt zu unverständlich ist, such in google ;-) Aber so ungefähr wirds wohl verständlich sein. |
schöne kurze Erklärung, wäre mir nicht besser eingefallen :-) btw, sivka hat eine ANTI community option, was haltet ihr eigentlich von der. jedesmal wenn ich ANTI lese, kommts mir kalt hoch |
anti-community.... gibts die nicht auch im mortillo??? also ich halt nix davon ...... aus welchem grund sollte man auch community-user ausgrenzen. und wenn es schon sowas gibt, dann sollte sie in beide richtungen funktionieren, also wenn ich denen nichts geben will, dann darf ich andererseits auch nichts mehr von denen bekommen ..... @MightyKnife, was für einen sommerzeitbug??? |
Zitat:
Bei mir hatte es in der Tat mit zwei Dateien über mehrere Tage das Problem gegeben, daß sie bei jedem Start von eMule neu gehasht wurden, aber seit die Dateien fertig sind, gibt's doch mit den neu hinzugefügten kein Problem mehr, oder doch? Klar, so ein Bug sollte beseitigt werden - aber wenn die offiz. devs von dem Problem wissen und nichts dagegen unternehmen, läßt das zwei Rückschlüsse zu.. |
Danke Usul :) habs kapiert denk ich mal *g*. Wär zwar für die Diebe mit einigem Aufwand verbunden, aber ein Diebstahl der Hash ist immer noch möglich :( |
Also ich bin mir zwar nich 100%ig sicher, wie Anti-Community-Sharing funktioniert, aber ich könnte mir vorstellen, das es das richtige Gegenteil von Community ist. Community-Mitglieder bekommen einen kleinen Bonus in der Warteschlange, Anti-Community-Mitglieder einen kleinen Nachteil, also nix mit "Ausgrenzung", nur Behinderung/Dämpfung. Inwieweit das Sinn macht, keine Ahnung, ich bin eh gegen Community-Sharing. Ich finde, man kann Community-Sharing viel besser ad absurdum führen, indem man Mitglied in jeder Community wird ;-) Das beste war letztens eine Frage, welchen Namen man dort "am besten" reinschreibt. Klar, wenn jeder so vorgeht, hat irgendwann jeder das gleiche als Communitystring, dann können wir es auch gleich wieder sein lassen. Ich finde es gut, das in Lovelace sowas nicht drin ist. Was ich nicht ganz verstehe, wieso ein "Member Lev. II" so eine Frage in diesem Thread aufwirft, wo sie eigentlich nichts oder nur sehr wenig zu suchen hat :twisted: Oder hat er auf keine Antwort gehofft? Eigentlich wäre das Thema einen eigenen Thread wert, finde ich, oder man müßte es dort diskutieren, wo es auch verwendet wird. |
Usul, ist sicher ein thema für nen eigenen thread. aber wie gesagt, wenn es schon anti-community gibt, dann soll sie in beide richtung funktionieren. aber schon richtig... irgendwann sind wir wohl soweit, das man es wieder bleiben lassen kann. |
credits der Community User werde um das vierfache erhöht, credits der Anti-Community User werde um die hälfte reduziert. es ist auch möglich den selben Community String in beiden feldern zu haben, dann werden die credits nur um das zweifache erhöht. *sich mit fremden federn schmückt* das was oben steht, hat sivka selbst geschrieben |
Zitat:
http://www.emule-web.de/board/viewtopic.php?t=2869 |
Zitat:
Ich bin nur jetzt drauf gestossen, als ich mir den Quellcode der aktuellen Lovelace-Version mal angeschaut habe... Zitat:
Bei mir hat er alle Dateien neu gehasht. Und das waren über 120 GB Daten. Das hat sich ganz schön hingezogen. Fand ich nicht sonderlich dolle, insbesondere weil dadurch alle Statistikdaten flöten waren incl. der Informationen, welche Dateien auf Release standen usw.... Ich hab das selber bei meiner Version korrigiert, da mir die Statistik wichtig war. Aber mal abgesehen davon wächst auch die known.met um das doppelte an (sofern man die neu gehashten Dateien hinterher nicht mit den alten wieder von Hand zusammenmischt) Zitat:
Ich hatte das hier ins Forum (genauer: ins Forum "EMule allgemein") gepostet. Lovelace hat's definitiv gelesen, aber ich hab keine Ahnung, ob irgend einer der offiziellen Entwickler Wind davon bekommen hat. Bei über 300 Treffern auf den Thread kann ich nur hoffen, dass es zu denen durchgedrungen ist... |
Zitat:
Bei meiner alten Morph-Version konnte ich das. Da konnte ich alle bekannten Dateien einblenden und Duplikate automatisch eliminieren lassen. Wär vielleicht auch mal ne Idee für ne Erweiterung... |
Zitat:
Zitat:
Im offiz. Board ist das Problem bekannt: http://www.emule-project.net/board/i...ight+saving&s= |
Zitat:
Hast recht :wink: Weiss gezz auch nicht, wie ich auf lovelace komme... Dann muss ich mich aber sogar doppelt entschuldigen, dass ich diesen Post mit der Sommerzeit in den Lovelace-Thread gepackt hab. Da hatte er dann eigentlich nichts zu suchen... |
[lovelace] wird's schon überleben. ;) Ist ja auch mal interessant, da sich wohl noch keiner der offiz. devs an das Problem rangetraut hat.. Hast du mal bei dem von xrmb gestarteten thread (link habe ich weiter oben ja gepostet) deine code-vorschläge gepostet? Davon abgesehen: was ist los Leute? Keine Feedbacks mehr? Läuft der Mod so spitzenmässig, daß es nichts zu berichten gibt? Das wäre doch auch mal einen post wert! ;) Ich bin jedenfalls sehr zufrieden! Ein feature request hätte ich aber doch: manuelles Neuladen von Quellen - mit den neuen mules geht öfter mal der "Schnarchanfall" durch - d.h. eine Quelle ist vorhanden, auch willig zu geben und dann bleibt er bei 0.0 kB/s stehen. Oder fragt gar nicht mehr nach, auch wenn man mit dem client direkt Kontakt hat (per eMule-chat) und sogar auf dem gleichen Server ist. (Heute erst erlebt) Dann hilft nur noch file auf stop stellen und anschliessend wieder resumen. Mit Quellen neu reinladen hab ich da meist auch recht gute Erfolge gehabt. |
Nochmal was zum Thema CPU-Last: ich hatte heute auch massive Probleme mit zu hoher Last, so das sich Emule kräftig verrechnet hat (150kb/s down bei Standard-DSL, man kennt das ja). Ich hatte etwa 25 Dateien im Download, Hardlimit auf 400, Anzahl der Quellen lag bei etwa 5200. Also hab ich das Hardlimit auf 200 gesenkt, die Anzahl der Quellen sank dadurch (das dauert aber schon eine Weile ;-)) auf 2700 ab, und die CPU-Last ist wieder in Ordnung. Nur so als Tipp, was die Betroffenen mal probieren können. Vielleicht läßt sich das Ergebnis auch auf anderem Wege erreichen, und jedes System verkraftet sicherlich andere Werte, aber vielleicht hilft die Beobachtung ja manchem. Ansonsten wieder einer diesen Spitzenmods, die den Glauben an Emule aufrecht erhalten ;-) Noch ein Feature-Request: Kann man nicht irgendwie die Quellen absolut angeben? Z.b. gebe ich an, das ich insgesamt max. 3000 Quellen haben will, so das bei 30 Dateien, die runtergeladen werden sollen, für jede Datei 100 Quellen zur Verfügung stehen und bei 15 Dateien für jede 200. Und dann am besten noch unter den Dateien dynamisch, also wenn eine Datei nur 20 Quellen hat statt den 100 maximal erlaubten, können die anderen die 80 übrigen mitverwenden. Aber die Zahl der absoluten Quellen bleibt gleich, damit gleicher Aufwand, und man muß das Hardlimit nicht mehr an die Anzahl der Dateien anpassen. Was haltet ihr davon? |
Usul, würd ich begrüßen den vorschlag. sowas hätt ich mir auch schon länger gewünscht. aber wichtig sind beim lovelace erst mal die möglichkeit die nicht benötigten quellen zu droppen. ich hab immer einige files, die sehr schlecht verbreitet sind und damit immer um die 200 quellen ohne benötigte teile pro file. |
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:35 Uhr. |
Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.