Projektidee: Small YaCy Machines

Ereignisse, Vorschläge und Aktionen

Projektidee: Small YaCy Machines

Beitragvon lisema » Do Dez 18, 2008 2:53 pm

Moin,

in dem Kurzzeit Crawlen Thread wurde es gewisser Weise schon angesprochen, dass man mehr Knoten braucht die dem Netz helfen können. Für mich kristallisieren sich dort einige Probleme heraus. Deshalb schlage hier einfach mal eine noch frühe ProjektIdee raus. Ich will dabei so gut wie Null Ressourcen der Entwickler beanspruchen und die meiste Arbeit in Teams durchführen lassen.
Einen Trupp Programmierneulinge werde ich so auf Java trimmen und einige erfahrene Programmierer auf Java umschulen. Momentan rechne ich mit 10 Programmierern innerhalb von meinem Kreis und viel Expertise von anderen.

Die Idee:
YaCy soll für eine gewisse Umgebung optimiert und angepasst werden. Dabei soll der Knoten nur solche Aufgaben wahrnehmen, die _nicht_ zu einer Einschränkung der Arbeitsfähigkeit des Rechners führen.

Die Umgebung habe ich willkürlich gesetzt auf:
256 MB VM Size

YaCy darf von der Platte starten und sich dorthin beim runterfahren wieder zurückschreiben. Das wars. Der Knoten soll mehrere Wochen durchlaufen können und auch dann noch nützlich für das Netzwerk sein.


Warum diese Einschränkungen, gestern habe ich einem Physiker erklären dürfen, wie man eine Datenbank baut, insbesondere für den Fall von YaCy. Mein Ansatz war natürlich ein naiver und dummer Ansatz, mit wenig Optimierungen und sicher einigen logischen Fehlern. Bei dem Entwurf war sehr schnell klar wo ich Ende, in einer IO Hölle. Bei kurzer Hochrechnung hatte meine "dumme" Datenbank bei 100 ppm so viele Schreibzugriffe (ohne Caches) auf die Datenbank (Bei unseren Vorbedingungen 1000 Wörter pro Seite werden indexiert) sodass wir mehr schreiben als eine normale Platte kann. Das ganze für ein paar Wochen laufenlassen und die Platte bremst die Maschine wahnsinnig aus.
Teile der Problematik wird YaCy auch haben.

Deshalb die Überlegung ein klar definiertes Profil zu erstellen. Die Person, die YaCy laufen lassen will kriegt klare Angaben,was diese Installation braucht und verbraucht. Sie soll neben der Arbeit laufen können, beim Index einen Teil für das Netz mitstemmen und später noch als Remote Crawler zur Verfügung stehen. Da alles im RAM abläuft sind die Bedingungen auch gut zu halten.

Der zweite Schritt ist, dass man, wenn das erste Profil gut läuft, Festplattenplatz dazugibt. Ich sag mal 5 GB. Auch dort darf keine IO Hölle ausbrechen. Konzepte dafür müssen erarbeitet werden und so weiter und so fort.


Aus meiner Sicht haben die Entwickler so die Möglichkeit an "wichtigen" Themen (Saubere Datenbank, Crawler, IndexTransfer, viel viel wo man sich zu viel Einarbeiten muss um es "mal eben" mit Anfängern zu tun) zu arbeiten, während die Community solche Sachen übernimmt. Gleichzeitig können interessierte Jungentwickler mit angelernt werden.

Anfangen wird das ganze im März, wenn genug Leute sich bereiterklären zu helfen (hier aus meinem Umkreis), Leute von ausserhalb sind natürlich gerne gesehen. Auch Kritik und Anregung von Seiten der Entwickler wären nett :)

grüße
lisema
lisema
 
Beiträge: 110
Registriert: So Dez 14, 2008 8:06 pm

Re: Projektidee: Small YaCy Machines

Beitragvon ribbon » Do Dez 18, 2008 6:56 pm

Hallo Lisema,

heisst du zufällig Max?

ich finde die Idee gut, a) weil es neuen Schwung bringt, und b) weil ein Fork auch immer eine Weiterentwicklung ist.
Dennoch denke ich, dass man das alles bereits mit der normalen yacy installation machen kann und können sollte.
wenn nicht, dass muss yacy optimiert werden.Und ja, mir klaut das Teil zuviel CPU, Zuviel bandbreite, ich kann das nicht adjustieren und auch bei Festplattenplatz der knapp ist, kann ich nicht um jedes MB adjustieren, auch die Verteilung der URLs and andere im DHT würde ich gerne mit 32 Mbit Upload haben. All das kann man nicht einstellen, oder zumindest nicht wenn man das yacy-diplom nicht hat. Daher ist handlungs und programmierbedarf gegeben, wo man optimieren kann.
Aber das ist ja trivial und machen ja alle auch.
Mein Punkt ist, dass man es am dem bestehenden Clienten macht, keinen Fork.

zweitens, dein Anwendungsfall klingt sehr nach http://dooble.sf.net , oder zumindest, dass man es auch dort anwenden könnte in dem yacy browser. Da habe ich wiederum die Frageoder den Punkt, warum man nicht die normale version nehmen kann. Oder wie muss man die normale Version weiterentwickeln, dass man auch mit einem Knopfdruck eine Light Installation hat für schwache Rechner oder "nebenher"-Benutzer.

Wird das dann ein eigenes SVN oder bei yacy oder wo?
ribbon
 
Beiträge: 212
Registriert: So Jan 06, 2008 4:23 pm

Re: Projektidee: Small YaCy Machines

Beitragvon lisema » Do Dez 18, 2008 7:50 pm

ribbon hat geschrieben:heisst du zufällig Max?

nein

ribbon hat geschrieben:ich finde die Idee gut, a) weil es neuen Schwung bringt, und b) weil ein Fork auch immer eine Weiterentwicklung ist.
Dennoch denke ich, dass man das alles bereits mit der normalen yacy installation machen kann und können sollte.
wenn nicht, dass muss yacy optimiert werden.
Aber das ist ja trivial und machen ja alle auch.
Mein Punkt ist, dass man es am dem bestehenden Clienten macht, keinen Fork.


Schwer zu sagen. Zum einen forke ich gerne, denn dann hat man alle Freiheiten. Ja es wird ein eigenes SVN geben, ein GIT Repository, damit man sich auch leicht von der "normalen" Version entfernen kann und später Patches einspielen kann ohne grosse Probleme.

Ich denke, dass alle Komponenten vorhanden sind und das das YaCy Team dort entwickeln soll und muss. Ich denke auch, dass ich sehr viel experimentieren muss. DH ich bin vermutlich gezwungen Änderungen vorzunehmen, die gravierende Auswirkungen haben. Das kann und will ich nicht im Hauptzweig. Es kann sein, dass ich der falsche Fährte folge, und 4 Wochen Arbeit einfach Mist ist, es sich aber erst in den Langzeittests bemerkbar macht. Deshalb bin ich klar für einen Fork/Branch.

Deine Punkte sind zutreffend. Aber ich arbeite auch mit Programmieranfängern. Die lass oder will ich nicht ins Haupt SVN lassen, zumindest nicht am Anfang.

Fork klingt dramatisch, ist es aber nicht. Ich will von YaCy auf keinen Fall wegentwickeln. Es wird alles übernommen was in YaCy verändert wird, solange es für uns Sinn macht, arbeiten aber mit dem Ziel der Optimierung. Gibt es dann eine "gute" Version, die sich auch im YaCy Netz gut integriert, dann wird die ganze Arbeit zurück gehen. Also wieder mit dem Hauptzweig harmonisiert. Sodass im Idealfall die YaCy Entwickler noch einmal drüberschaun und sagen super, oder das geht nicht.

YaCy wird Komponenten basiert entwickelt, dh die YaCy Leute schreiben gute Crawler, schreiben gute Sachen etc und packen es in ein grosses Paket. Ich zerfledder das Paket, baue um, teste neue Ideen, und gebe, wenn es passt, es wieder zurück.

ribbon hat geschrieben:zweitens, dein Anwendungsfall klingt sehr nach http://dooble.sf.net , oder zumindest, dass man es auch dort anwenden könnte in dem yacy browser. Da habe ich wiederum die Frageoder den Punkt, warum man nicht die normale version nehmen kann. Oder wie muss man die normale Version weiterentwickeln, dass man auch mit einem Knopfdruck eine Light Installation hat für schwache Rechner oder "nebenher"-Benutzer.

Dooble kenn ich nicht, sieht aber nach einem Aufsatz für YaCy aus. Ob das von mir angestrebte nachher passt kann ich nicht beurteilen.

Dies Lightversion ist genau das, was ich erreichen will. Du entscheidest bei der YaCy Installation, wie und wie viel du beitragen kannst :)
Sodass nachher einfach keine Überaschungen folgen. Insbesondere sollten die Knoten auch den Index Mittragen (nur einen kleinen Teil). Ich hoffe, dass die Small Machines Version nochmal 100 bis 200 Peers bringt, die nicht nach 2 Wochen, wenn die Kiste anfängt langsam zu werden, verschwinden.
Es hat auch nichts mit langsamen Rechner zu tun. Wenn ich weiss, dass ich "nur" 500 MB RAM investiere, ich das in meiner Maschine einplanen kann, und dann mittels nice die Kiste in den Hintergrund schiebe könnte ich mir vorstellen sowas laufen zu lassen. Wenn ich aber vorher nicht weiss, was YaCy mir wegfrisst, dann lass ich es sein, sobald es zu viel wird.

Diese Knoten können aber nicht das YaCy Netz tragen (!), dh dafür werden noch immer die großen Rechner gebraucht.

Im nächsten Schritt würde ich mir mal Tiny Knoten anschauen. Also zB das NAS Setup. Dort wird man nur noch Teile einer YaCy Installation nutzen können. Und Endziel ist der Schwarm. Aber das ist lange, lange hin.


Also nochmal in kurz:
- Es wird eine eigene Spielversion geben
- Es wird eigene Entwicklerstrukturen geben in Form von GIT, Mailinglisten, Wiki (weil auch Anfänger dabei, und die Fragen haben, die seltsam sind)
- Es wird _nicht_ eigenständig laufen (Nein es kriegt keinen Namen)
- YaCy soll auch nicht übernommen werden, das ist Orbiters et al Projekt, das Projekt wird nur unterstützen
- Es wird immer nur YaCy unter bestimmten Gesichtspunkten betrachtet
lisema
 
Beiträge: 110
Registriert: So Dez 14, 2008 8:06 pm

Re: Projektidee: Small YaCy Machines

Beitragvon lisema » Do Dez 18, 2008 7:51 pm

Noch was:

Anfangs wird es nur ein normales YaCy mit anderen Default settings sein. Erst wenn das nicht ausreicht, wird es verändert. :)

Die Entwicklerstrukturen werden offen für alle sein.
lisema
 
Beiträge: 110
Registriert: So Dez 14, 2008 8:06 pm

Re: Projektidee: Small YaCy Machines

Beitragvon ribbon » Do Dez 18, 2008 9:05 pm

dooble ist der yacy browser, dann mach das SVN doch bitte da. Schreib die mal an!.
ribbon
 
Beiträge: 212
Registriert: So Jan 06, 2008 4:23 pm

Re: Projektidee: Small YaCy Machines

Beitragvon lisema » Do Dez 18, 2008 9:40 pm

Ich mag SVN nicht. Ich bin von CVS auch ein gebranntes kind

"... PS: ich hab das CVS mal aufgeräumt" "Wo ist mein ... NEIN ... du kannst doch nicht meinen Kram einfach löschen!"

Achja, ich mag eigene Technik, weil Kontrolle.

Das GIT/SVN/Mailingliste/Wiki wird bei uns gehostet. Kontrolle über die eigenen Ressourcen ist sinnvoll. Das Teil ist dann auf einem Hochverfügbarkeitscluster. Keine Einschränkungen, schnelle Anbindung, volle Kontrolle. Ich sehe keinen Nutzen, das eigene Rechenzentrum zu verlassen.
Des Weiteren ist eine höhere Identifikation mit dem Projekt vorhanden. Ich will ja aus meinem Dunstkreis Leute anwerben. Im nächsten Schritt will ich andere Drüberschauen lassen, das geht wieder besser wenn es im Haus ist.
Es sind also primär psychologische Faktoren.
lisema
 
Beiträge: 110
Registriert: So Dez 14, 2008 8:06 pm

Re: Projektidee: Small YaCy Machines

Beitragvon BlackFog » Fr Dez 19, 2008 2:21 am

Finde ich in jedem Fall eine interessante Sache, gerade aus der Sicht der "User"! Ich habe zu Hause eine kleine Linux-Kiste und 3072/512er DSL mit dem ich mich am Yacy-Netzwerk beteilige.
Wie ich im IRC bereist erwähnte kämpfe ich mit dem recht hohen Ressourcenverbrauch von Yacy: vor allem Plattenplatz- und Bandbreitenverbrauch machen mir "Probleme". Der relativ hohe Platzverbrauch wird mich früher oder später zwingen den Index wieder zu löschen oder sonstwie aufzuräumen und wenn ich spielen will (nein, nicht Schach ;) ) muß ich Yacy stoppen, da mein Ping von ca. 15 auf 85+ (und Stellenweise deutlich mehr) steigt (deutsche Server).

Ich würde mir wünschen Yacy vom Ressourcenverbrauch mehr auf meine Rahmenbedingungen anpassen zu können. Also nicht nur die Crawling-Geschwindikeit, sondern auch den verfübaren Plattenplatz, IO, RAM, CPU, Bandbreite*.
Um Yacy im Ressourcenverbrauch zu bremsen habe ich mir damit beholfen, das Remote-Crawling derzeit abzuschalten.

Neben den oben genannten Einstellmöglichkeiten wäre vielleicht eine höhere Modularisierung eine Möglichkeit "Thin Clients" leichter zu realisieren. Clients mit:
  • hoher Bandbreite ins Internet aber wenig Plattenplatz: nur crawlen und die Ergebnisse verteilen ohne sie selbst zu speichern
  • viel Plattenplatz aber relativ geringer Bandbreite: DB Knoten für entfernte Suche
  • hoher CPU Leistung: Reines Suchportal mit Cache oder Auswertung von Crawlergebnissen
Disclaimer: Das sind jetzt nur so Ideen ohne dem Wissen ob das überhaupt Sinn macht.

Just my 2 cents
BlackFog

* Bandbreitenbegrenzung mit IPTables o.ä. würde ich hinbekommen, der einfache User aber sicher nicht...
BlackFog
 
Beiträge: 2
Registriert: Fr Dez 19, 2008 1:15 am

Re: Projektidee: Small YaCy Machines

Beitragvon dulcedo » Fr Dez 19, 2008 5:24 am

Bin mir nicht ganz sicher wo es besser passt, denke hier:

Ich frage mich ob man wirklich forken muss um ohne grosse Kompromisse schlanke, vielleicht spezialisierte Clients einsetzen zu können.

Ich gehe nun mal von der Anwenderseite aus, was will der Anwender?
-Zuallererst eine Alternative zu Google, die er zumindest als Ausweichmöglichkeit zur Verfügung hat. Ich ertappe mich immer öfter wie ich Suchmaschinen als "Kollegen" benutze und fast schon mit der Suchmaschine rede, das klappt mittlerweile erstaunlich gut. Also wird das für mich ein Mittel im Alltag das auf keinen Fall mit einem Monopol belegt werden darf, ich denke das kapiert auch sofort jeder "normale" Anwender.
-Einen Rechner der benutzbar ist, die vorhandenen Resourcen aber auch ausnützen (Ökologischer Aspekt)

Was ist er bereit zu geben?
- Teile der vorhandenen Ressourcen.

Was ist er nicht bereit zu geben?
-Bequemlichkeit!

Das ist grob umrissen die Anwendersicht, wie das nun funktioniert interessiert vielleicht manche, den grossen Rest aber überhaupt nicht. Also muss es möglich sein bei einem Gamer z.b. mit einem Klick Yacy einzubremsen, vielleicht sogar automatisch, in allen Resourcen, ohne den Peer komplett zu stoppen.
Das wäre ökologisch wieder nicht sinnvoll, für DHT dürfte ein langsamer aber kontinuierlicher Datenfluss wohl auch besser sein?

So nun gibts es dann also eine Möglichkeit Yacy zentral zu bremsen (wenn das denn überhaupt technisch geht, aber ich kann es ja mit sehr langsamen Maschinen simulieren, und das ging!).

Warum diese dann nicht nutzen um einen schlanken Client zu konfigurieren, nicht programmieren, mit schlank meine ich nicht den Programmumfang sonder den Res-Bedarf?

Ich stecke viel zu wenig drin in dem Projekt um das technisch genauer abschätzen zu können, aber vielleicht hilft euch ja grade diese Sicht von Anwenderseite ein wenig weiter.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: Projektidee: Small YaCy Machines

Beitragvon ribbon » Fr Dez 19, 2008 6:24 am

ich denke auch, dass das über eine konfiguration machbar sein sollte und nicht über einen fork.
da es aber seit vielen jahren gefordert wird, und noch nicht da ist, muss es wohl ein fork sein.

ppm = 2
Remote Crawl = 2 ppm
nicht mehr als 200 MB RAM
DHT in/out mit je max. 2 KB/s
Default festplattenplatz 1 GB

Kann das jemand einstellen? Dann haben wir das schon jetzt.
ribbon
 
Beiträge: 212
Registriert: So Jan 06, 2008 4:23 pm

Re: Projektidee: Small YaCy Machines

Beitragvon Orbiter » Fr Dez 19, 2008 10:35 am

geht alles bis auf die Plattenplatzbegrenzung. Da ist noch nicht richtig entschieden was man machen soll, wenn das Maximum erreicht ist:
- (1) entweder aufhören Daten zu sammeln oder anzunehmen
- (2) oder altes löschen

(1) liesse sich leicht einbauen, das haben wir ja schon durch den resource checker, das müsste man nur erweitern. Mir persönlich gefällt die Vorgehensweise aber nicht besonders. Der Zustand ist ruck-zuck erreicht und dann macht das Ding nicht mehr viel. Nach ein paar Monaten sind solcherart betriebene Peers dann nur noch nutzlose Leichen mit veralteten Daten.
(2) gibt es noch nicht. Man könnt das weiter untergliedern:
- (2a) Löschen von Daten, die nicht die Grundfunktion (suchen) einschränken, sondern die Performance unterstützen würden (htcache). Das wäre sozusagen ein 'nicht-invasives' Löschen. Der htcache ist aber auch bereits heute stabil in der Größe begrenzbar (nach der letzten Designänderung). Der löscht sich also jetzt schon ständig immer wieder automatisch.
- (2b) Löschen von Indexdaten. älteste zuerst. Das geht aber nur mit Inkaufnahme von leichten Inkonsistenzen: URLs kann man löschen, die Referenzen in den RWIs behält man aber. Die lassen sich auch nicht einfach finden, das würde unglaublichen IO kosten. Man kann die Referenzen nur allmählich löschen, nämlich immer dann wenn ein RWI sowieso angefasst wird, beispielsweise beim RWI Versand. Da wird so ein Check auch jetzt schon gemacht.

Ich muss aber dazu sagen dass ich noch nie ein Platzproblem durch YaCy hatte. Egal was du für eine Platte hast, bis du da einige Gigabyte voll hast vergeht schon ein wenig Zeit. Und Plattenplatz ist momentan in alten und neuen Geräten fast unbegrenzt vorhanden. Jeder Spielfilm den du bei einer DVB-T Aufnahme speicherst (rd. 2.5 GB) brauch so viel Platz wie der Betrieb von YaCy in einem Monat, bei den Leistungsdaten die du oben schreibst eher weniger.

Ich würde aber trotzdem eine Löschung für einen anderen Grund sinnvoll halten: für die Erhaltung von Performance und Aktualität. Das halt ich für viel wesentlicher als eine reine Begrenzung um Platz zu sparen. Das würde aber auch bedeuten, das man (2) machen sollte.
Orbiter
 
Beiträge: 5799
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Projektidee: Small YaCy Machines

Beitragvon Lotus » Fr Dez 19, 2008 12:05 pm

lisema hat geschrieben:- Es wird eigene Entwicklerstrukturen geben in Form von GIT, Mailinglisten, Wiki (weil auch Anfänger dabei, und die Fragen haben, die seltsam sind)

Mir stellt sich die Frage, ob die YaCy Kern-Funktionen ab diesem Zeitpunkt nur noch gefixt werden sollten wenn nötig, um eine spätere Zusammenführung des Codes zu vereinfachen.

Ein weiterer Aspekt der mir wichtig erscheint ist die Frage: soll YaCy hinter einem NAT ohne zugängliche Ports funktionieren? Dann wäre ein Nutzen der DB dieser Peers nämlich schwierig.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Projektidee: Small YaCy Machines

Beitragvon Orbiter » Fr Dez 19, 2008 12:37 pm

Lotus hat geschrieben:Mir stellt sich die Frage, ob die YaCy Kern-Funktionen ab diesem Zeitpunkt nur noch gefixt werden sollten wenn nötig, um eine spätere Zusammenführung des Codes zu vereinfachen.

Wer das Projekt kennt, der weiss das innerhalb eines Jahres der Kernbereich immer wieder völlig umgekrempelt wurde. Das wird sich auch nicht ändern, weil wir hier ja dazulernen und das dann umsetzten. Die Idee eines YaCy-Fork finde ich ja ganz interessant, aber es ist ja wohl klar das derjenige, der einen Fork macht, nicht dem root-Projekt erzählen kann das er jetzt nichts mehr ändern darf weil das maintainen dann schwierig sei.
Orbiter
 
Beiträge: 5799
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Projektidee: Small YaCy Machines

Beitragvon lisema » Fr Dez 19, 2008 1:28 pm

Orbiter hat geschrieben:
Lotus hat geschrieben:Mir stellt sich die Frage, ob die YaCy Kern-Funktionen ab diesem Zeitpunkt nur noch gefixt werden sollten wenn nötig, um eine spätere Zusammenführung des Codes zu vereinfachen.

Wer das Projekt kennt, der weiss das innerhalb eines Jahres der Kernbereich immer wieder völlig umgekrempelt wurde. Das wird sich auch nicht ändern, weil wir hier ja dazulernen und das dann umsetzten. Die Idee eines YaCy-Fork finde ich ja ganz interessant, aber es ist ja wohl klar das derjenige, der einen Fork macht, nicht dem root-Projekt erzählen kann das er jetzt nichts mehr ändern darf weil das maintainen dann schwierig sei.


Da musste ich dann doch laut loslachen :)

Nein,nein. Genau so ist es ja nicht gedacht.
Das entscheidende ist, dass man mit Programmieranfängern sehr viele komische Commits hat. Teilweise wird Mist gebaut teilweise nicht. Einiges braucht sehr viel händische Eingriffe, andere committen broken ohne es zu markieren. Das ist alles ein Lernprozess. Auch wird viel experimentiert werden. GIT bietet die Möglichkeit Branches wieder zusammenzuführen, und das weitestgehend automatisch. Forks werden also billig. Es kann hier gearbeitet werden wie man will, und nachher kann man die sinnvollen Commits umstrukturieren und einfliessen lassen. Aber auch (!) das Hauptentwickler SVN automatisch wieder als neue Wurzel zu deklarieren und unsere Anpassungen automatisch umrechnen lassen.

Das Horrorszenario hat Orbiter geschrieben, das dieses "kleine" Projekt auf das große Auswirkungen hat in der Art, dass wir das grosse dominieren. Das soll nicht geschehen und darf aus meiner Sicht nicht geschehen. YaCy wird immer viele Designentscheidungen tragen müssen, die für uns schmerzhaft sind, aber für das Netz sinnvoll. In meiner (naiven) Idealvorstellung könnten wir sogar einen Teil des YaCy Netzes mal simulieren (Viele Knoten für kurze Zeit haben wir ja) und innerhalb des kleinen Projektes wird es auch viele "kleine" Forks geben, wo sich zeigen muss, ob etwas funktioniert. Vielleicht wird hier ja ein Wikipedia Mirror hochgezogen, der dann als Benchmark mit dem aktuellen Dump gecrawled wird von uns.

Grosse Teile von YaCy neu zu schreiben ist einfach Wahnsinn. Warum sich die Arbeit neu machen?
Erster Ansatz ist immer die Konfiguration anzupassen, im zweiten Teil werden vielleicht, wenn sinnvoll, Tools dazugeschrieben und im dritten Schritt geht man in den YaCy Source. (Neu schreiben ist teilweise einfacher, als sich reindenken. Ab einer gewissen Komplexität aber auch nicht)

Wie gesagt es ist in niemanden Interesse wenn wir uns wegentwickeln, und nachher im schlimmsten Fall inkompatibel werden. Andersrum ist es auch nicht sinnvoll sich von vornerein zu beschränken. Vielleicht wird ja ein YaCy Protokoll notwendig, an das sich beide Seiten halten können/müssen. Aber das ist schon wieder sehr weit in der Ferne. Und das Protokoll müsste sehr viele Vorteile bringen.
lisema
 
Beiträge: 110
Registriert: So Dez 14, 2008 8:06 pm

Re: Projektidee: Small YaCy Machines

Beitragvon ribbon » Fr Dez 19, 2008 3:48 pm

ppm = 2
Remote Crawl = 2 ppm
nicht mehr als 200 MB RAM
DHT in/out mit je max. 2 KB/s


kann man im Weihnachtsrelease diese Konfiguration im Installer als Small YaCy bekommen und einstellen?

Danke
ribbon
 
Beiträge: 212
Registriert: So Jan 06, 2008 4:23 pm

Re: Projektidee: Small YaCy Machines

Beitragvon BlackFog » Fr Dez 19, 2008 4:31 pm

Orbiter hat geschrieben:Ich muss aber dazu sagen dass ich noch nie ein Platzproblem durch YaCy hatte. Egal was du für eine Platte hast, bis du da einige Gigabyte voll hast vergeht schon ein wenig Zeit. Und Plattenplatz ist momentan in alten und neuen Geräten fast unbegrenzt vorhanden. Jeder Spielfilm den du bei einer DVB-T Aufnahme speicherst (rd. 2.5 GB) brauch so viel Platz wie der Betrieb von YaCy in einem Monat, bei den Leistungsdaten die du oben schreibst eher weniger.

Da muß ich dir etwas wiedersprechen: Habe mein Peer nun, mit einigen Unterbrechungen, seit Anfang Oktober fast ohne selbst zu crawlen am laufen: Yacy verbraucht bei mir derzeit 8 GB (also 4GB/Monat). Die Restlichen 110 GB habe ich aber nicht vor Yacy zu spenden sondern in der Tat für meine DVB Aufnahmen zu verwenden. Um den Lärm und Stromverbrauch meines kleinen Servers in Grenzen zu halten, habe ich (vorläufig) genauso wenig vor neue Platten hinzuzufügen oder mir mehr Arbeit zu machen und sie auszutauschen.

Das ist jetzt nicht böse gemeint, soll nur meine Haltung zum Thema Plattenplatz darstellen.


BlackFog
BlackFog
 
Beiträge: 2
Registriert: Fr Dez 19, 2008 1:15 am

Re: Projektidee: Small YaCy Machines

Beitragvon lisema » Sa Dez 20, 2008 2:30 am

Lotus hat geschrieben:Ein weiterer Aspekt der mir wichtig erscheint ist die Frage: soll YaCy hinter einem NAT ohne zugängliche Ports funktionieren? Dann wäre ein Nutzen der DB dieser Peers nämlich schwierig.


Kurz drüber nachdenken.

Und ja sie taugen. Wir haben zumindest das KIT mit massenweise Bandbreite, wir haben andere mit viel Bandbreite und wir haben andere Möglichkeiten.

Wer sagt dass die geNatteten Geräte von aussen ansprechbar sein müssen? Die können genausogut mit 2-3 Master Servern verbunden sein (zB billigen WRTs) Dann kann man den NATS sagen, wer mit ihnen sprechen will, wohin sie verbinden sollen, oder aber was gerade gesucht wird. So viel Aufwand ist das nicht :)
Von Lösungen wie Skype halte ich dagegen nichts (Löcher in Firewalls etc zu schiessen).

Das ist aber sehr weit hin. Ich denke vorher sind noch Knoten interessant, die kein Permanentes Netz haben. Dh man schnürt schicke fertige 10 MB gepackte Archive. Die koennen schnelle Kisten in CrawlSprints erzeugen (ohne Indexierung) und die werden dann zwischengespeichert und belasten dabei die Leitung nicht. Knoten wie der von BlackFog können sie sich dann später anschauen und haben dadurch erstmal eine gewisse Zeit zum rödeln, egal wie schnell das netz ist. Aber auch das ist eine Baustelle die man erst viel später angehen sollte.

Im Prinzip würde ich es so sagen, wenn das Gerät Netz und/oder Rechenleistung hat, kann man es für YaCy nutzen. Wenn Festplattenkapazität mit einer guten Verfügbarkeit dazu kommt, kann es das YaCy Netz stemmen. Dabei würde ich mich auch nicht auf JAVA festlegen. Ein kleines Script im WRT kann schon helfen. Java ist nur zum entwickeln sehr angehm.


Ein Satz der mich geprägt hat, wo ich auch viele Konzepte gelernt habe, ist aus dem Wireless Sensor Network Bereich:
"The real egoistic behavior is to cooperate"
Das ist der Untertitel von einem guten Buch und eigentlich auch ganz zutreffend für P2P und YaCy. Wir haben, wenn wir wollen, viele unzuverlässige Clients, billige neue Clients (kurze Werbung bringt 20 neue) die aber auch jederzeit wieder wegfallen. Wie nutzt man nun das grosse ganze?
Das ist aber etwas, was man betrachten sollte und kann, wenn man mehr hat. Im Moment ist die Resource Entwickler.
Orbiter et al machen solide normale Clients, die das Netz aufspannen und alles haben, ich schau mir mit lokalen Leuten an, wie man optimieren kann für bestimmte Einsatzgebiete.
Da würde ich auch nicht um grosse Sachen von Orbiter hoffen oder fordern, sondern ihn seine Ideen weiterbringen lassen, genauso wie ich meine. Jeder wird seinen Teil dazu beitragen :)
lisema
 
Beiträge: 110
Registriert: So Dez 14, 2008 8:06 pm

Re: Projektidee: Small YaCy Machines

Beitragvon liebel-lab » Mo Dez 22, 2008 9:40 am

...ok los sagt was ihr braucht :-)...noch ist ja VOR Weihnachten :-)
und noch eine bitte....wenn ihr mal alle trauemen dueftet? qwo soll yacy hin? was wuerde final gebraucht werden? hardware? netzwerk?
eine antwort ohne die beruehmte bescheidenheit...einfach mal WIRKLICH sagen was sache ist...was man braucht? wenn wir gross helfen sollen/duerfen brauchen wir ein planungsziel 2009 und zahlen/werte fuer die wir gelder einfordern koennen.... was mich derzeit ein bischen nachdenklich macht.
Yacy gibt es seit etlichen jahren und immer sind es so um die 50-80 nutzer....also die die kommen bleiben ein paar monate und gehen dann wieder...weil zuwenig "masse" vorhanden ist? Weil google eh so toll ist? weil ...whatever...daher die bitte ein mittelfristiges ziel zu projektieren...1000 stabile "grosse maschinen? 2 yacy peers an jeder uni? 10.000 "schwarm-crawler"....?
Info: Das KIT wird von 2010 - 2015 weiter in yacy investieren (hardware/manpower). wieviel ist noch nicht ganz klar. daher
--> bitte zahlen/ideen/visionen :-)
liebel-lab
 
Beiträge: 175
Registriert: Sa Jan 26, 2008 7:00 pm

Re: Projektidee: Small YaCy Machines

Beitragvon lisema » Di Dez 23, 2008 5:29 pm

Träumen... wo geht YaCy hin, wenn ich das bestimmen könnte.
Einige tausend Knoten sind vorhanden, die alle unterschiedliche Aufgaben wahrnehmen. Personen haben YaCy so selbstverständlich und ohne Einschränkungen laufen, wie früher Seti@home.
Es sollte sich eine Community bilden, die stabil ist. An Unis sind dafür natürliche Keimzellen, vielleicht kann man dort unterstützen

Ich will meine Energie erstmal in kleine Kisten stecken. Die habe ich hier relativ zahlreich. Was ich mir wünschen würde, sind einige schnelle Server, die Puffern können. An die ich fix meine Daten übertragen kann, und die danach das Netz mit stützen und diese Daten weiternutzen. Das ist aber aus meiner Sicht ein Software Problem.

Danach geht es weiter auf NAS und andere Geräte, kleinere Geräte und exotischere Geräte. Einige davon stehen in vielen Haushalten, andere könnte man anschaffen. Man stelle sich ein NAS vor, dass 3-5 Platten hat, davon 1 Platte nur für YaCy nutzt. Man unterstützt es, mit einem begrenzten Umfang, hat dabei einen grossen Mehrwert. (Thecus 2100 und Thecus 5200 nenne ich mal, da viele Geräte zu diesen Baugleich sind). Wenn es dafür Gruppen gibt, die diese Geräte "erschliessen" könnten, sollten Testgeräte zur Verfügung stehen.

Weitere interessante Plattformen sind VServer, viele haben sie (auch RootServer) und man könnte versuchen YaCy dafür zu optimieren. Dafür sind für Entwickler VServer zum lernen wichtig. Auch können diese Server gute Verteilungsfunktionen übernehmen. Wenn dafür ein paar gute Server zur Verfügung stehen würden, könnten dort Leute entwickeln (sofern es Personen gibt). Also ein Server mit einem typischen Setup. Wenn also ein paar partitionierte Server (c2q, Raid 1, paar gb RAM) zur Verfügung stehen würden, könnte das helfen. (Einer mit XEN, einer virtuzzo und was es dort alles gibt :) )

Ansonsten denke ich, dass Orbiter besser weiss, was man braucht um das Netz gut zu stützen :)


Was man sicher brauchen wird, sind Entwickler und eine Community. Vor allem Leute, die mir zB auf die Finger hauen vernüftige Doku zu schreiben. Das ist Kleinkram, das kann auch fast jeder mit Interesse. Des Weiteren wäre es super wenn man mit YaCy Netzwerkprogrammierung lernen könnte. Ansonsten würde ich mir Unterstützung von der Community wünschen und fände eine aktive Community wünschenswert. Ich denke das viele Dinge dann auch automatisch kommen. Soweit erstmal meine Gedanken. Mal schaun ob ich hier etwas aufbauen kann, ähnlich den FreeCulture Chapters.

Frohe Weihnachten
lisema
 
Beiträge: 110
Registriert: So Dez 14, 2008 8:06 pm

Re: Projektidee: Small YaCy Machines

Beitragvon bluumi » Di Dez 23, 2008 10:54 pm

Für mich die wichtigesten Faktoren für die Zukunft sind:
- "enorme stabilität", so dass Peers über *Monate wartungsfrei* laufen können
- senken der IO Last / Ram/Hdd fressens ;)
- pro 100 "normalos" ~ 1-2 "Verteiler Peer's" (also schnelle Server an welche man seinen Index "abgeben kann")
- gute ziehende "Geschäftsideen" (wie die Idee mit dem Jugendschutzproxy, wenn es auch davon schon "gute und bekannte gibt")
- 100x mehr Peers um gute Suchresultate zu liefern im Internet :)
- Crawl Ideen! :lol: (Meine Worker Peers laufen ab und zu leer und es hat zuwenige mit RemoteCRawl Jobs)
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: Projektidee: Small YaCy Machines

Beitragvon ribbon » Mi Dez 24, 2008 8:02 am

1. wichtig ist, dass es mehr nodes gibt.
Die Idee, dass es einen Mitarbeiter gibt, der zu jeder Uni/FH fährt, damit das dortige Rechenzentrum einen yacy peer laufen lässt für die Homepage (eingebunden in Freeworld und als Portal) und einen weiteren peer als Unterstützung des Netzwerkes, halte ich für eine gute Idee. So kann man Deutschlandweit jede Uni-Webeite in yacy finden. Dazu benötigt man in erster Linie einen Beauftrageten, der die Institutionen anspricht die Homepage-Suche umzustellen. Zwei alte Kisten sollte die Uni dann noch selbst haben. Invest: 1 Stelle zur Beratung öffentlicher Institutionen .

2. Wichtig ist also an erster Stelle, die Anzahl der Nodes zu steigern, da jetzt viele Jahre immer 60 Leute dawaren, aber auch wieder 60 Leute gingen, sehe ich die Konstante in instituitonellen Peers. Die Unis bieten sich an und auch KIT und Metager. Manch einer ist sicherlich auch bereit, Hardware zu spenden oder Geld, aber dazu müsste man wissen, wie die Hardware ausgestattet sein müsste, damit man Metager noch einen Rechner zusenden kann (2 oder 4 core? mehr RAM oder CPU? Disk?). Ein Spendenfonds oder Gelder für Freeworld-Portale: Kit, Metager, und ein drittes Projekt. In neugebauten Theatern kann man sich einen Stuhl kaufen mit seinem Namen des Sponsors. Warum läuft im Metager-Pool nicht ein Peer namens KIT, der von KIT finanziert wurde? Patenschaften finanzieren... genau wie man sich ein Tief oder Hoch beim Kachelmann kaufen kann..

3. Wenn eine Kritische Masse von 1000 ständig online präsenten institutionellen Nodes vorhanden ist, finden sich sicherlich auch normale User, die es mehr unterstützen. Das Dooble Browser Projekt als yacy Projekt finde ich auch nicht schlecht. Wenn hier ein Entwickler hinzukäme, yacy optimal zu unterstützen, wäre das doch toll, wenn es jeder im Browser anwenden kann und selbst zugleich mit wenig Bandbreite und Plattenplatz am DHT teilnimmt.
2 Halbtagsprogrammier (Java / c++) für den yacy browser.

4. Das Userinterface ist auch zu komplex, Es gibt ja drei alternativen, aber keine ist richtig zu ende programmiert.
Die Blaue sollte default werden.
1 Html Programmierer für das blaube Interface.

5. KIT muss ans Freenet angeschlossen werden (ist es das schon?), ebenso wie Metager.
Kosten: Keine.

6. Drittes Projekt: KIT und Metager habe ihre Funktion: Wissenschaftliche Inhalte bzw Suchabfrage, das Dritte Projekt sollte ein Pool von 20 Yacy Nodes sein, die einen reinen Crawl Pool bilden. Angesiedelt sein sollte es an einer anderen Institution als KIT und MG oder zumindest an einer anderen Fakultät. Metager würde sich trotzdem gut anbieten, indem die URLs der User gleich in yacy gecrawlt werden. Wurde ja schonmal vorgeschlagen, aber scheint man nicht zu wollen.
OpenAccoon wollte sich ja mal an yacy DHT anbinden? Am Standort von KIT sollte es ein Crawl Pool geben, an den Metager die Url sendet, die jeder Metager-User generiert. OpenAccon kann diese dann auch mitCrawlen.

7. Es liegt weder an den fehlenden Nodes, noch an der für Otto Normalverbraucher nicht zu bedienenden Technik, sondern ggf auch am Wollen. Ein Fork schafft ggf. gute Entwicklung, die Small Light Peers sind daher zu begrüssen. Wo ist das GIT/SVN für dieses Projekt?

8. Sechs und Sieben und auch die anderen erfordern viel Abstimmung, es sollte daher einmal im Quartal einen Fachkongress oder Workshop der institutionellen Yacy Admins geben. Die Ausrichtung erfordert ein Büro oder Kommunikationsbeauftragte(n).

9. Wir brauchen Geschenkpapier, um die Einzelpackete 1-8 einzupacken.
ribbon
 
Beiträge: 212
Registriert: So Jan 06, 2008 4:23 pm

Re: Projektidee: Small YaCy Machines

Beitragvon Low012 » Mi Dez 24, 2008 10:38 am

ribbon hat geschrieben:5. KIT muss ans Freenet angeschlossen werden (ist es das schon?), ebenso wie Metager.
Kosten: Keine.

Mein Peer kennt derzeit 11 Peers vom KIT: http://4o4.dyndns.org:8080/Network.html ... rch=Search
Metager hat 2 Peers im Freenet: http://4o4.dyndns.org:8080/Network.html ... rch=Search
Soweit ich weiß, hat Metager/das RRZN kein privates YaCy-Netz.

Das "Problem" ist, dass der Rest der Peers, der das Sciencenet bildet, ja einen geschlossenen Suchindex bilden soll, dessen Inhalt nur von Mitarbeitern des KIT definiert wird, weil Sciencenet ja primär ihnen helfen soll und sie am besten wissen, was sie brauchen. Es wäre also als erster Schritt ein Konzept nötig, was es erlaubt, einen Cluster aufzubauen, dessen Index gegen DHT von außen abgeschottet ist und der bei der Suche nur auf den eigenen Index zugreift. Gleichzeitig müsste sich der Cluster für die Suche von außen in das Freenet einbinden lassen und, wenn das durch den Betreiber gewünscht ist (Traffic!), DHT ins Freenet ermöglicht werden, aber ohne dass die Inhalte aus dem Sciencenet abwandern. Ich denke, dass das alles nicht trivial ist und dabei immer die Integrität des Sciencenets im Vordergrund stehen sollte, da es ein Werkzeug ist, auf das sich die Nutzer verlassen können sollen und dies eventuell bereits tun.

9. Wir brauchen Geschenkpapier, um die Einzelpackete 1-8 einzupacken.

http://www.das-originelle-geschenk.de/g ... rvice.html ;)
Low012
 
Beiträge: 2214
Registriert: Mi Jun 27, 2007 12:11 pm

Re: Projektidee: Small YaCy Machines

Beitragvon lulabad » Mi Dez 24, 2008 10:56 am

Was wirklich was bringen würde wären mehr Entwickler.
Finanziert doch einfach mal Orbiter für ein Jahr. Das würde was bringen. Oder noch besser, finanziert gleich mehrere Entwickler. Stellt euch mal vor was es bringen würde wenn 5 Entwickler gleichzeitig Vollzeit für ein Jahr an yacy programmieren würden.
lulabad
 
Beiträge: 709
Registriert: Mi Jun 27, 2007 11:40 am
Wohnort: Im Herzen Bayerns

Re: Projektidee: Small YaCy Machines

Beitragvon Low012 » Mi Dez 24, 2008 11:18 am

Das stimmt, wenn Orbiter richtig Zeit hat, sich YaCy zu widmen, kommt man mit dem Installieren der Updates kaum noch hinterher. ;)

Mich kann man prinzipiell übrigens auch buchen, was bei mir allerdings über meinen Arbeitgeber laufen müsste.
Low012
 
Beiträge: 2214
Registriert: Mi Jun 27, 2007 12:11 pm

Re: Projektidee: Small YaCy Machines

Beitragvon ribbon » Mi Dez 24, 2008 11:30 am

Mehr entwickler bringen nicht mehr nodes.
Marketing geht vor Entwicklung.
entfernen wir das beta Tag.
schauen wir nicht auf die Tastatur, sondern in die Schweiz.
institutionelle Verlässlichkeit ist wichtiger als private Nodes.
DHT out zu ermöglichen und DHT in zu begrenzen sollte trivial sein
(man kann Datenbanken auch einfach in einen Freeworld peer kopieren).
Wollen ist wichtiger als Nicht-Können, daher ist Vorschlag 8 zu betonen.
Orbiter hat zurecht betont, dass yacy eine bibliothek ist, die auf Anwendungsfälle wartet.
Wie finden Institutionen diesen Anendungsfall und wie können wir sie sehend machen, wenn sie ihn nicht allein finden?
Zusammenfassend: wir sollten 1000 institutionelle Nodes finden/sponsorn. Metager würde ich gerne 2 weitere schenken, welche Spezifikationen müssen diese haben?
ribbon
 
Beiträge: 212
Registriert: So Jan 06, 2008 4:23 pm

Re: Projektidee: Small YaCy Machines

Beitragvon Lotus » Mi Dez 24, 2008 12:50 pm

Für die Reichweite wage ich einmal einen Vergleich mit TOR. Dort gibt es heute ~1100 Nodes. So viele Peers können wir sicher im Moment ebenso "einfach" errreichen. http://torstatus.blutmagie.de/
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Projektidee: Small YaCy Machines

Beitragvon lisema » Mi Dez 24, 2008 8:37 pm

ribbon hat geschrieben:Mehr entwickler bringen nicht mehr nodes.
Marketing geht vor Entwicklung.
entfernen wir das beta Tag.

Vorsicht vor so etwas. Viele lassen Tor im Hintergrund laufen und es stört nicht, das ist bei YaCy leider anders.

Vorhin hatte ich ein Gespräch mit einem Bekannten, der kannte YaCy. Vor vielen Jahren hatte er von YaCy mal gehört. Warum nutzt nun so einer YaCy nicht? Ressourcen.

YaCy ist bei Informatikern bekannt, aber die Hürden sind gross, insbesondere mit den Resourcenverbrauch. Tor wird dagegen von vielen daheim genutzt.

Ein zu aggressives Marketing mit unfertiger Software bringt aus meiner Sicht eher Frustpotential. Deshalb denke ich das mehr Entwickler, die für die Nutzer entwickeln, mehr bringen. Des Weiteren muss aber auch eine Community sich bilden. ZB schau ich mir gerade an, wie mein Client bei Default Einstellungen sich fröhlich in MediaWikis reinfrisst. Ein Löschen der URLs dauert hier relativ lange. Joelsonsoftware.com frisst sich auch fest. Ich tippe auf primär 404er in meinem Cache.
Dort muss kein "Entwickler" dran arbeiten, da hilft ein guter Satz von Regexen.
lisema
 
Beiträge: 110
Registriert: So Dez 14, 2008 8:06 pm

Re: Projektidee: Small YaCy Machines

Beitragvon Orbiter » Do Dez 25, 2008 3:03 am

einen Punkt den ich unterstreichen möchte ist, dass wir mehr aktive Entwickler brauchen, die mehr Zeit haben. Wir brauchen auch mehr Leute die Doku schreiben. Wir brauchen aber vor allem auch aktive YaCy User, nicht nur Supporter. Mein Weg zu den Usern führt m.E über die Leistungsfähigkeit, und die erreichen wir nicht unbedingt mit mehr Supportern, denn der bisherige sehr kleine Kern an Peers leistet schon erstaunliches. Aber die Software muss noch viel besser werden. Ich will das Ding performancemäßig noch viel weiter treiben, und ich will zurecht behaupten können das wir in der Leistung Solr/Lucene locker schlagen können. Erst wenn man von YaCy sagen kann, das wir die besten Ergebnisse und die schnellste Software haben, werden sowohl Portalbetreiber als auch Google-User stärker auf uns gucken. Meine persönlichen Ziele bei der Entwicklungsarbeit liegen momentan ganz klar auf Performance und Solr-ähnliche Fähigkeiten (index push per XML objects, auto-drill-down, klare API).

Insofern ist es nicht schlecht, dass lisema die Community-Fähigkeit und -Erträglichkeit als 'stille Software' weiter treiben will. Dieses Ziel widerspricht meinem eigenen nicht unbedingt, aber lisemas Ziele haben mehr mit Usability zu tun, meine mehr mit Performance. Ich finde es daher ganz spannend was lisema vorhat, das kann uns viel helfen, aber wir sollten auch nicht 'auseinanderdriften'. Das sollte aber zu schaffen sein.

Ganz kurzfristig sollte es möglich sein, eine Plattenplatzbeschränkung einzubauen. Das sehe ich zwar leicht kritisch, aber es ist machbar. Wer es verwenden will soll es tun. Wenn das dazu führt das 'small machines' eher YaCy ausführen ist das ja super.
Orbiter
 
Beiträge: 5799
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Projektidee: Small YaCy Machines

Beitragvon ribbon » Do Dez 25, 2008 10:18 am

plattenplatz = 1gb, ppm own & remote je 3, bandbreite in & out je = 2 KB/s => light modus = grosse klasse.
ribbon
 
Beiträge: 212
Registriert: So Jan 06, 2008 4:23 pm

Re: Projektidee: Small YaCy Machines

Beitragvon Phiber » Fr Dez 26, 2008 5:07 pm

Was mich halt wirklich wichtig dünkt bei vielen momentanen Probleme (Index-Volumen, Platzprobleme, Bandbreite, usw.) ist eine bessere Differenzierung und allgemeine Verbesserung vom DHT. Orbiter scheint ja schon kräftig an der Verbesserung vom DHT-Out zu arbeiten, was wohl vieles dann automatisch löst. Es würde sicher auch schon sehr viel ermöglichen, wenn man die Einstellungsmöglichkeiten beim DHT besser machen könnte, statt nur diesen an oder auszuschalten und die Performance vom ganzen DHT zu steuern. Es braucht eine getrennte Einstellungsmöglichkeit von DHT-In, DHT-Out und Suchanfragen(welche ja jetzt automatisch ausgeschaltet werden wenn DHT-in ausgeschaltet wird). Und damit meine ich eben nicht nur ein Ein/Aus Knopf sondern Memory, Performance und Bandbreiteneinstellung.

Könnte man eine gute Balance finden zwischen Crawl-local+remote+dht-in vs dht-out, könnte man sich so auch sehr gut eine gewünschte Indexgrösse modellieren, man könnte sich schöner Bandbreiteneinstellungen einstellen, usw.

Dazu noch weitere IO-Optimierungen beim Zugriff auf die Festplatte und es wird auch einfacher YaCy in der Grösse und Performance zu skalieren wie hier für den Fork gedacht.
Phiber
 
Beiträge: 96
Registriert: So Okt 05, 2008 9:04 pm


Zurück zu Mitmachen

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste

cron