Thema: SkyNet Mod R32

[Bartzilla]

Teste 1.21
Mir ist aufgefallen, daß seit Version 1.20, wenn ich nach dem Ende des Grabbens, die Ordner temp, bad & nntp löschen, beim Neustart immer noch die alten Dateien in der Liste anzeigt.
Außerdem wird die Anzeige für deleted, ok, usw. nicht auf null zurückgesetzt, sondern zählt immer weiter hoch.

[pogo13]

Hallo,

@ Bartzilla: lösche files.dat, dort stehen alle Angaben für den erneuten Start damit skynet "fast" an der gleicher Stelle weitermachen kann.

@ R32: da skynet ein russisches "Erzeugnis" ist und nach dem s.o.v.a. mit der Weiterentwicklung aufgehört hatte und einige russische Programmierer weitere Mods veröffentlicht haben, entwickelt sich ein kleiner Wettbewerb zwischen den Modprogrammierern. Und nun kommt ein Deutscher der ein sehr aufgeräumtes Mod präsentiert, das zwar noch nicht alles kann (z.Bsp. udp wird angeführt), aber doch schon mal nicht schlecht läuft. Das weckt natürlich patriotische Gefühle bei den Russen ("wieso bekommen unsere "eigene" Leute das nicht so sauber hin?") und auch die Programmirer selbst fühlen sich auf den Schlips getretten. Da deine Version öffentlich zugänglich ist, wird dein Mod in der Zukunft immer mit anderen Versionen verglichen werden. Nimm es nicht tragisch, ich hoffe es ist ein Ansporrn für dich. Ein ähnlicher Ton herrscht auch zwischen den Programmierern. Ein paar Blödmänner (1941) wird es immer geben, wo gibt es sie nicht.

Ich habe versucht an den Code von 0.84 heranzukommen, leider bisher ohne Erfolg.

Das "Platzreservieren" für Datein die gerade mal angefangen haben zu laden liegt nach Aussagen aus o.g. Forum, daran das diese in mehreren Streams übertragen werden (hoffentlich habe ich das richtig übersetzt) und dafür schon mal der Platz auf der Platte reserviert wird.

Mit Dateigröße für nntp jenseits von 500MB hat auch meine HW Probleme. Ich glaube aber nicht daß es mit der Größe zusammenhägt, sondern das diese Dateien nicht ganz reine sind (siehe oben "Platzreservieren"). Diese Probleme habe ich nicht bei skynetix (basiert auf 0.84). Also die Größe selbst ist nicht das Problem, denn Platz auf der Platte ist genug da. Aber die eingebaute Defragroutine kommt genau so damit nicht zu recht wie der perlscript. Möglicherweise ist das der Grund des Abschmierens.

@ Plastic: Hi, wo warst du den verschollen gewesen

da ich die uud Dateien regelmäßig per bat uudeview zufühge und danach lösche, lasse ich auch die no_yend gleich mit löschen. Ist viel einfacher. Auch stimme ich R32 zu die NNTPdefrag über das nntp Verzeichnis laufen lassen um den Rest zu decodieren. Das funktioniert gut.

Das mit dem Virtuellen Speicher meine ich: Arbeitsplatz/Eigenschaften/Erweitert/Systemleistung/Einstellungen/Erweitert/Virtueller Arbeitspeicher/Ändern/Größe wird vom System verwaltet ankreutzen. Es wird berichtet, dass dadurch die discontinuity verbessert werden können.

Grüße
Pogo

[bigobelix]

@R32

es läuft nun seit 75h ohne Absturz  , nur ist der Cache fast nur noch und dauernd bei 100% 

bigobelix

[pogo13]

Hallo R32,

ich habe es noch mal getestet. Meine Vermutung hat sich bestätigt. Da ich einen relativ schwachen Rechner habe (1400 Athlon) bringt die eingebaute Defragroutine alles aus dem Tritt. Es sind jede Menge discontinuities und irgendwann beist sich die Routine an einer "aufgeblasener" Datei die Zehne aus und das skynet schmiert ab.

Also habe ich die Defragfuktionen abgeschaltet. Es sind keine diskontinuities mehr da und es läuft ganz gut. Allerding hatte ich innerhalb von 3h etwa 50GB nntp Dateien. Allerdings waren dabei etwa 20-25 "künstlich aufgeblasene" Dateien zwischen 200MB und 1GB und höher.

Grüße
Pogo

[bigobelix]

@R32

120h und läuft 

bigobelix

[pogo13]

Hi bigobelix,

hast du keine "riesen" nntp Dateien?
hast du möglicherweise in der ini was verändert?

Grüße
Pogo

[Orlogri]

Die 1GB-Datei-Problematik bei nntp ist ein ziemlich grundlegender Fehler in den skynet 0.91er Abkoemmlingen.

Tritt bei deiner Version gelegentlich auch bei .htm und .bin Files auf, wenn man per rules.txt von einzelnen MAC-Adressen etwas mehr ziehen möchte als das Übliche, also die Einschränkungen lockert.

Bei DataSky ist mir dieses Verhalten hingegen noch nicht aufgefallen. Stellt aber in dem Fall ohnehin kein Problem dar, da man die Sache mit Größenbeschränkungen in rules.txt in den Griff bekommt.

CPU-mäßig (XP-3200, 8°West) sind meine 45 Rules-Einträge nicht sonderlich anspruchsvoll, an Werte über ca. 20% kann ich mich nicht erinnern, dafür erreicht der Cache relativ oft 100%.

Ciao, Orlogri

[bigobelix]

@pogo,

ja sicher gibt es die großen nntp und ich habe nichts verändert. Es rödelt da eine 320 GB Seagate S-ATA mit 16MB Cache, ein Asrock mit AMD XP 4000+ (die gabs wirklich mal) und 2GB RAM DDR400. Und natürlich ein Netzteil, liegt alles offen da...

bigobelix

[bigobelix]

@R32,

nach 125h28min hat sich Dein Progi verabschiedet. Das ist ein neuer Rekord, denn sonst ging das schneller. Ich kann damit leben 

bigobelix

[spoke1]

Ja, so besonders begeistert mich das eigentlich nicht.
Genau diesen Thread habe ich mir letzte Woche schon mal durchgelesen (mit translator.ru übersetzt).
Das Ergebnis der automatischen Übersetzung ist ziemlich schlecht, so dass ich nicht besonders viel davon kapiert habe. Die Brocken, die man sich dann zusammenreimen konnte, waren aber ziemlich krass.
Es scheint dort in einen Kleinkrieg gegen den Mod auszuarten. Sogar die Jahreszahl 1941 ist gefallen ... 
Ich weiß nicht, was der Quatsch soll, aber damit möchte ich nichts zutun haben.

Vielleicht kann pogo13 ja mehr dazu sagen. Von ihr gab's in dem Forum auch einen Beitrag, wenn ich mich nicht irre.   

Das das passiert war doch klar. Fakt ist aber nun mal das der Code im Netz ohne Probleme zu finden war. Aus die Maus!!

Überspitzt dargestellt:
Da den russischen Entwicklern offensichtlich nicht die Spur an einem konstruktiven Teamwork gelegen ist (?!) sollte man sich evtl. doch Gedanken machen dieses Projekt nur noch registrierten Usern zugänglich zu machen. Notfalls mit Wasserzeichen in der Soft um eventuelle Lecks festzustellen. Wäre von der Sache her etwas was meinen Grundsatz geht,
ich sehe aber auch nicht ein das wegen ein paar ******* wieder mal was eingedampft wird, was mir Spaß macht. Das hatte ich schon oft genug und bedarf keiner Wiederholung.

Insgesamt eine traurige Entwicklung.

@R32
Eine Möglichkeit warum sich das Projekt so schnell "herumgesprochen" hat vermute ich zu kennen. Ein "alter Bekannter", noch aus den Zeiten wo solche Art Softentwicklungen in den Kinderschuhen steckte, geht diesem Hobby offensichtlich heute noch nach und betreibt nebenbei auch noch eine HP. Ich hab ihn damals im 4free kennengelernt, vermutlich liest/schreibt er hier noch mit, da wir damals auch über dieses Forum Informationen zum Thema besorgt und ausgetauscht haben.

[pogo13]

@ R32: Lässt sich der Code nicht irgend wie schützen? Die anderen machen es doch auch?

@ bigobelix: und kriegst du aus den Risendateien irgend was raus? Die werden auch in ok Ordner verschoben, sind aber halb leer

Da mir manch mal mehrere Teilarchive hintereinander fehlen, kamm mir folgende Gedanke: ist es Möglich, dass die Dateien die Empfänger auf den verschiedenen Frequenzen erreichen (11222, 11261 und 12524)? Denkbar wäre doch, dass die Empfangssoft entsprechend die Transponder wechselt.

Grüße
Pogo

[R32]

Teste 1.21
Mir ist aufgefallen, daß seit Version 1.20, wenn ich nach dem Ende des Grabbens, die Ordner temp, bad & nntp löschen, beim Neustart immer noch die alten Dateien in der Liste anzeigt.
Außerdem wird die Anzeige für deleted, ok, usw. nicht auf null zurückgesetzt, sondern zählt immer weiter hoch.

Works as designed ...
Ich habe nur die originale skynet Funktionalität wieder aktiviert. Der Grund ist, daß durch das neue Feature "Partial Files" es sinnvoll sein kann, sie wesentlich länger in der Liste zu lassen. Evtl. fehlende Parts können die Datei ja auch später noch komplettieren. Die meisten der partial files scheinen übrigens aus dem P2P bereich zu kommen (Kazaa).
Stimmt, es wäre aber tatsächlich auch sinnvoll, die Files nur in die Liste aufzunehmen, wenn sie noch auf Platte sind.

ich habe es noch mal getestet. Meine Vermutung hat sich bestätigt. Da ich einen relativ schwachen Rechner habe (1400 Athlon) bringt die eingebaute Defragroutine alles aus dem Tritt. Es sind jede Menge discontinuities und irgendwann beist sich die Routine an einer "aufgeblasener" Datei die Zehne aus und das skynet schmiert ab.

Das fällt einem mit einer Doppelkern CPU echt nicht auf. Es klingt aber wirklich überzeugend. Was machen wir denn da? Besorgst Du Dir eine andere Maschine?   
Nee, ernsthaft ... Versuch doch mal den Tip von Plastic ... Für nntp könntest Du ja (falls möglich) eine separate Platte verwenden.

... und auch die Programmirer selbst fühlen sich auf den Schlips getretten. Da deine Version öffentlich zugänglich ist, wird dein Mod in der Zukunft immer mit anderen Versionen verglichen werden. Nimm es nicht tragisch, ich hoffe es ist ein Ansporrn für dich. Ein ähnlicher Ton herrscht auch zwischen den Programmierern. Ein paar Blödmänner (1941) wird es immer geben, wo gibt es sie nicht.

Ich habe versucht an den Code von 0.84 heranzukommen, leider bisher ohne Erfolg.

Es ist für mich weder Abschreckung noch Ansporn. Ich hacke in dem Code herum, weil es mir persönlich momentan Spaß macht. Außerdem macht es mir momentan Spaß, mich mit Euch hier drüber auszutauschen.
Ich denke, wir sind hier "unter uns" und falls es zu Ausfällen kommt, vertraue ich auf die Top Moderatoren, die wir hier haben.

Den Code der 0.84 für die SS1 hab ich. Zumindest in dieser Version ist aber noch kein nntp enthalten. Was wolltest Du denn damit?

Tritt bei deiner Version gelegentlich auch bei .htm und .bin Files auf, wenn man per rules.txt von einzelnen MAC-Adressen etwas mehr ziehen möchte als das Übliche, also die Einschränkungen lockert.
CPU-mäßig (XP-3200, 8°West) sind meine 45 Rules-Einträge nicht sonderlich anspruchsvoll, an Werte über ca. 20% kann ich mich nicht erinnern, dafür erreicht der Cache relativ oft 100%.

Aha, bei htm und bin habe ich es noch nicht gesehen. Danke für den Hinweis.
Den Cache kannst Du ja mal testweise vergrößern (cache_scan, cache_flush).

nach 125h28min hat sich Dein Progi verabschiedet. Das ist ein neuer Rekord, denn sonst ging das schneller. Ich kann damit leben 

Ich auch! Hauptsache es war kein Zufall. Konntest Du aus dem Logfile irgendwelche spannenden Erkenntnisse gewinnen?
Wirst Du es in Zukunft auch wieder laufen lassen oder war das ein einmaliger Stresstest?


[/quote]

Das das passiert war doch klar. Fakt ist aber nun mal das der Code im Netz ohne Probleme zu finden war. Aus die Maus!!
Überspitzt dargestellt:
...
Insgesamt eine traurige Entwicklung.

Welchen Code meinst Du? Meine Änderungen habe ich im Source nicht veröffentlicht.

Stimme Dir voll und ganz zu. Sehr traurig die Tendenz.
Es scheinen aber nicht alle russischen Entwickler und User so zu sein. Erstens hätten wir sonst den Quelltext von skynet nicht und zweitens kamen auch schon einige positive Reaktionen über mtron's Site.
Lassen wir es erstmal dabei ... wie pogo schon sagte: ******* gibt es überall.

Eine Möglichkeit warum sich das Projekt so schnell "herumgesprochen" hat vermute ich zu kennen. Ein "alter Bekannter", ...

Wenn man auf G**gle nach skynet sucht, ist die skynetR32 site bereits auf der 3. Seite gelistet. Da kann wohl nahezu jeder "Schuld" sein.
Ist denn der "Bekannte" Russe?

@ R32: Lässt sich der Code nicht irgend wie schützen? Die anderen machen es doch auch?

Die Frage verstehe ich jetzt nicht ganz. Meinst Du den Quelltext oder die binaries?
Eine Maßnahme, um weniger Angriffsfläche zu bieten, wäre wohl noch, keine Release Notes mehr zu schreiben. Wenn niemand weiß, was sich geändert hat,  muß man schon einen direkten Benchmark machen, um auf interne Änderungen zu kommen. Muß ich mir mal überlegen ...

Gruß,
R32

P.S. Sorry für die Länge des Posts ... da hat sich aber ein wenig angesammelt.



 

[spoke1]

@R32

Ich meine natürlich die Originalquellen. Gibts ja so ziemlich in jedem "guten" ULC.

Und ja, der Gute ist russischer Emigrand. War äußerst konstruktiv mit ihm. Die Fangemeinde war damals nicht so gross. Da konnte man noch in alle Ruhe Selbstgespräche übers Thema führen.  Außerdem war Kontakt mit den Entwicklern fast nicht machbar, da wurde viel abgeblockt. Scheint ein Metalitätsproblem zu sein, wie man unter anderem aus einigen Beiträgen von Terwi vs. Prog lesen kann.

[pogo13]

@ R32:

an neue Maschine habe ich auch schon gedacht, aber in Zeiten von Flatrate ist grabben eher nur Spaß. Und da ich noch mehr Hobbies habe und in fast jedem Zimmer ein PC steht, ist es schwierig noch mehr Euronen für skynet freizumachen.

Mit schützen meine ich deinen Code. Denn aus anderen Mods kannst du auch nicht sehen was die verändert haben. Ich spreche davon weil ein anderer Mod Entwickler meinte, dass du nur 8 Byte weggelassen hättest. Daraus hatte ich geschlossen, dass er dein Code lesen konnte. Ich hoffe ich habe mich verständlich ausgedrückt.

0.84 Code: die stabilste Version für nntp ist für mich bisher skynetx und sie soll auf der 0.84 Version basieren. Ich kann damit so wie so nichts anfangen, ich habe nur an dich gedacht. Vielleicht wäre es nützlich, aber da du sie schon hast.

Grüße
Pogo

[R32]

@pogo13

Hast Recht, es ist bei mir auch eines von mehreren Hobbies. Ich programmiere mittlerweile sogar lieber an dem Mod, als dass ich mir die Ergebnisse des Fischfangs anschaue.

Die Bemerkung mit den 8 bytes habe ich auch gelesen und mußte etwas länger grinsen. Die 8 byte sind aber lediglich die Abweisung von Partial Content files. Wenn man sie nicht abweist (mit anderen Worten: "wenn man die 8 bytes ändert"), kann der restliche Algorithmus trotzdem nichts mit den files anfangen. Bei mir stecken über 100 Codezeilen für diese files zusätzlich dahinter.

Meinen Code hat er natürlich nicht gesehen. Ist nicht veröffentlicht.
Aber eine Diskussion auf dem Level, wie sie die Russen führen, liegt unter meinem Niveau. Ich verstehe gar nicht, wieso die Jungs so gereizt sind.
Bis ich das gelesen hatte, dachte ich noch, man könnte ja sogar Code austauschen. Vergessen wir das Thema.

Tschau,
R32