MixMax Geschrieben 13. Januar 2020 Teilen Geschrieben 13. Januar 2020 Neustes Java Update: https://www.java.com/de/download/java8_update.jsp Zitat Sonstige Hinweise: Veraltete NIST-EC-Kurven aus den TLS-Standardalgorithmen entfernen Bei dieser Änderung werden veraltete NIST-EC-Kurven aus den standardmäßigen benannten Gruppen entfernt, die während der TLS-Verhandlung verwendet werden. Folgende Kurven werden entfernt: sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 und secp256k1. Die EC-Kurve secp256k1 wird für die Signaturen bei Bitcoin verwendet. Java hält sie also für veraltet und entfernt sie. Richtig wäre es umgekehrt: Java sollte entfernt werden, weil es völlig veraltet ist und noch nicht mal 64bit Arrays unterstützt! Die ganze Sache hat aber auch Vorteile: Ich hab mir eh meine eigene ECDSA Bibliothek programmiert und bin damit völlig unabhängig. So können auch keine Bugs aus der Java eigenen Bibliothek kommen. Ich empfehle das jedem auch selbst zu machen! Mit der neuen Java Version, ist jetzt ja auch jeder dazu gezwungen. Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Jokin Geschrieben 13. Januar 2020 Teilen Geschrieben 13. Januar 2020 vor 36 Minuten schrieb MixMax: Ich empfehle das jedem auch selbst zu machen! Mach ich! ... sobald ich mit meinem Nullpulsinduktor fertig bin - den sollte sich auch jeder mal selber gebaut haben. (ernsthaft? Wer ist denn als Laie schon in der Lage eine eigene 'fehlerfreie' ECDSA-Bibliothek zu bauen? Ich musste schon bei den 5 Abkürzungsbuchstaben die richtige Reihenfolge zweimal kontrollieren) 3 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
PeWi Geschrieben 13. Januar 2020 Teilen Geschrieben 13. Januar 2020 (bearbeitet) 1 hour ago, Jokin said: ... sobald ich mit meinem Nullpulsinduktor fertig bin - den sollte sich auch jeder mal selber gebaut haben. Du meinst aber schon die verbesserte Version mit dem Differentialdiskriminator vor dem Eingangssignal, damit man die Fluktuationen des Nullpulses besser generalisieren kann? Bearbeitet 13. Januar 2020 von PeWi Schreibfehler Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Ulli Geschrieben 13. Januar 2020 Teilen Geschrieben 13. Januar 2020 Denkt bitte auch daran, immer genug Material für den Fluxkompensator bereitzuhalten. Inzwischen kann man damit sogar die Natur schonen, da der Müll direkt dafür verwendet werden kann. 1 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MixMax Geschrieben 13. Januar 2020 Autor Teilen Geschrieben 13. Januar 2020 vor 1 Stunde schrieb Jokin: (ernsthaft? Wer ist denn als Laie schon in der Lage eine eigene 'fehlerfreie' ECDSA-Bibliothek zu bauen? Als Softwaeentwickler steht man oft vor der Entscheidung eine fremd Bibliothek zu nutzen oder es selbst zu machen. Allgemein wird geraten die Bibliothek zu nutzen. Meistens stimmt das, aber eben nur meistens. In speziell kritischen Fällen kann es aber sein, das genau dort die Abhängigkeit zum Verhängniss wird, weil die Lizenz nicht passt, Module verändert oder eingestellt werden, oder Schadsoftware genau über diesen Kanal unbemerkt eingeschleust werden könnte. Dieses Beispiel zeigt, dass ich mich richtig entscheiden habe, es selbst zu machen. Klar ist es ein großer Aufwand, aber wenn es notwendig ist, lohnt es sich hinterher. 1 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
¯\_(ツ)_/¯ Geschrieben 13. Januar 2020 Teilen Geschrieben 13. Januar 2020 vor 3 Stunden schrieb MixMax: Richtig wäre es umgekehrt: Java sollte entfernt werden, weil es völlig veraltet ist und noch nicht mal 64bit Arrays unterstützt! Programmiere ja auch bissle Java, aber was ist denn ein 64 Bit Array ? Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MixMax Geschrieben 13. Januar 2020 Autor Teilen Geschrieben 13. Januar 2020 (bearbeitet) vor 51 Minuten schrieb ¯\_(ツ)_/¯: Programmiere ja auch bissle Java, aber was ist denn ein 64 Bit Array ? byte[] b = new byte[2147483646+1]; Genau das geht nicht, die Länge des Array ist auf 32bit begrenzt. Also auf Integer.MAX_VALUE. Dabei sind Arrays die Grundlage von fast allen Komplexen Klassen. Ein Datenbank z.B. kann mit Java dann nicht größer als dieser Wert sein. Ein 46bit-Array wäre dann ein Array welches die maxial Länge von 2^64 haben kann. Bearbeitet 13. Januar 2020 von MixMax Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Jokin Geschrieben 13. Januar 2020 Teilen Geschrieben 13. Januar 2020 vor 9 Minuten schrieb MixMax: byte[] b = new byte[2147483646+1]; Genau das geht nicht, die Länge des Array ist auf 32bit begrenzt. Also auf Integer.MAX_VALUE. Dabei sind Arrays die Grundlage von fast allen Komplexen Klassen. Ein Datenbank z.B. kann mit Java dann nicht größer als dieser Wert sein. Ein 46bit-Array wäre dann ein Array welches die maxial Länge von 2^64 haben kann. Ich mach in PHP: $byte = "2147483646"; // Strings sind toll $byte++; // einer geht noch, einer geht noch rein! Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
battlecore Geschrieben 13. Januar 2020 Teilen Geschrieben 13. Januar 2020 Zwei Bibliotheken. Sacht die eine "Puh ey, alles ganz schön veraltet hier ne?" Sacht die andere "Waaah eine sprechende lib" Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
¯\_(ツ)_/¯ Geschrieben 13. Januar 2020 Teilen Geschrieben 13. Januar 2020 vor 4 Stunden schrieb MixMax: byte[] b = new byte[2147483646+1]; Genau das geht nicht, die Länge des Array ist auf 32bit begrenzt. Also auf Integer.MAX_VALUE. Dabei sind Arrays die Grundlage von fast allen Komplexen Klassen. Ein Datenbank z.B. kann mit Java dann nicht größer als dieser Wert sein. Ein 46bit-Array wäre dann ein Array welches die maxial Länge von 2^64 haben kann. Okay... wozu auch immer man diese Riesen Arrays braucht... für Datenbanken ganz sicher nicht... Kenne in Java implementierte Datenbanken, die haben damit anscheinend kein Problem. Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
¯\_(ツ)_/¯ Geschrieben 13. Januar 2020 Teilen Geschrieben 13. Januar 2020 vor 8 Stunden schrieb MixMax: Java hält sie also für veraltet und entfernt sie. Bezieht sich nur auf Oracle JDK 8 u231 oder ? ... hab das leider nicht mehr aufm Rechner, um die Oracle 8 Flags zu überprüfen mit denen man das wieder aktivieren kann. Zumindest mit OpenJDK 11, 12, 13 und 14 ist der "secp256k1" noch da... Hab mich aber auch net all zu tief mit der Thematik beschäftigt. ist das korrekt so ? KeyPairGenerator keyGen = KeyPairGenerator.getInstance("EC"); ECGenParameterSpec ecs = new ECGenParameterSpec("secp256k1"); keyGen.initialize(ecs, new SecureRandom()); KeyPair pair = keyGen.genKeyPair(); PrivateKey priv = pair.getPrivate(); PublicKey pub = pair.getPublic(); System.out.println(pub.toString()); Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MixMax Geschrieben 13. Januar 2020 Autor Teilen Geschrieben 13. Januar 2020 (bearbeitet) vor 26 Minuten schrieb ¯\_(ツ)_/¯: Hab mich aber auch net all zu tief mit der Thematik beschäftigt. ist das korrekt so ? KeyPairGenerator keyGen = KeyPairGenerator.getInstance("EC"); ECGenParameterSpec ecs = new ECGenParameterSpec("secp256k1"); keyGen.initialize(ecs, new SecureRandom()); KeyPair pair = keyGen.genKeyPair(); PrivateKey priv = pair.getPrivate(); PublicKey pub = pair.getPublic(); System.out.println(pub.toString()); Ob es korrekt ist, weis ich nicht, hab ja meine eigene ECDSA Bibliothek die ich nutze. Aber sieht mal gut aus. Hab es mal in eclipse Kopiert: Sun EC public key, 256 bits public x coord: 112758068002153022625078478295291747283781294379435620512715355697155022578995 public y coord: 20135104044387078135880922179441490526785410273179790892918959045391968766675 parameters: secp256k1 (1.3.132.0.10) Da wird einfach nur nen Random Priv.Key erzeugt und der Pub.Key ausgegeben. vor 36 Minuten schrieb ¯\_(ツ)_/¯: Okay... wozu auch immer man diese Riesen Arrays braucht... für Datenbanken ganz sicher nicht... Kenne in Java implementierte Datenbanken, die haben damit anscheinend kein Problem. Also "Riesig" ist was anders. Integer.MAX_VALUE ist so klein, das man damit nur ne Datenbank für die Eissorten der Eisdiele um die Ecke machen könnte. Was glaubst du wie viel Transaktionen in der Blockchain sind? Ich schreibe gerade meinen lokalen Blockchainexplorer und dort ist Integer.MAX_VALUE viel zu klein für alle Transaktionen die in einen Bloomfilter sollen. Und andere Datenbanken? Na ja, frag mal Google wie viel Webseiten es gibt. Oder schau dir mal SAP-Datenbanken an. Die würden über Integer.MAX_VALUE nur müde lächeln. Und warum müssen die in ein Array rein? Also die gesamte Datenbank kommt nirgens in ein Array rein, sonder ist auf viele Datein verteilt. Nur muss man die auch Indizieren um einen Datensatz finden zu können. Dazu gibt es große Index-Listen mit Bloomfiltern und noch viel mehr Kram wie HashTabellen oder TreeSetz, in denen die Index Listen dann sortierte Schlüssel haben, nach denen gesucht wird. Diese HashMaps, TreeSets und BloomFilter verarbeiten aber intern Arrays die dann in Java bei Integer.MAX_VALUE ein Ende haben und so mit nicht zu gebrauchen sind! Und genau darum geht es, hier ist dann das beschriebene Problem. Das Thema ist also etwas komplexer als es den Anschein macht. Bearbeitet 13. Januar 2020 von MixMax Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
¯\_(ツ)_/¯ Geschrieben 13. Januar 2020 Teilen Geschrieben 13. Januar 2020 vor 15 Minuten schrieb MixMax: Also "Riesig" ist was anders. Integer.MAX_VALUE ist so klein, das man damit nur ne Datenbank für die Eissorten der Eisdiele um die Ecke machen könnte. Was glaubst du wie viel Transaktionen in der Blockchain sind? Ich schreibe gerade meinen lokalen Blockchainexplorer und dort ist Integer.MAX_VALUE viel zu klein für alle Transaktionen die in einen Bloomfilter sollen. Und andere Datenbanken? Na ja, frag mal Google wie viel Webseiten es gibt. Oder schau dir mal SAP-Datenbanken an. Die würden über Integer.MAX_VALUE nur müde lächeln. Keine Ahnung was du da erzählst... zumindest scheint es kein grosses Problem zu sein. Sind dir PB genug ? Dann nehm einfach Apache Cassandra. Kann gut Peta-Byte an Daten speichern. Ist in Java Implementiert.... Ansonsten probier mal ElasticSearch aus. Kann auch sehr riesige Datenmengen speichern. ist auch in Java implementiert... und das sind beides keine Datenbanken für Eisdielen... Aber wünsche Dir viele Erfolg deine eigene Datenbank zu schreiben... Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MixMax Geschrieben 13. Januar 2020 Autor Teilen Geschrieben 13. Januar 2020 vor 2 Minuten schrieb ¯\_(ツ)_/¯: Aber wünsche Dir viele Erfolg deine eigene Datenbank zu schreiben... Sie ist ja schon lang fertig. Natürlich gibt es immer Mittel und Wege etwas über Umwege doch hinzubekommen. So hab ich es ja auch machen müssen. Einfacher währe es allerdings, wenn Java mit der Zeit gehen würde und nicht bei ihren 32Bit Integer stehen geblieben wäre. Aber sie haben wichtigere Dinge zu tun, wie die Secp256k1 Kurve als veraltet zu erklären. Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
¯\_(ツ)_/¯ Geschrieben 13. Januar 2020 Teilen Geschrieben 13. Januar 2020 (bearbeitet) vor 36 Minuten schrieb MixMax: Einfacher währe es allerdings, wenn Java mit der Zeit gehen würde und nicht bei ihren 32Bit Integer stehen geblieben wäre. Aber sie haben wichtigere Dinge zu tun, wie die Secp256k1 Kurve als veraltet zu erklären. Du verwechselst hier irgendwie eine Programmiersprache und die Implementierung dessen. Das hat mit Java, der Programmiersprache, nicht viel zu tun. Sondern Oracle hat es in ihrer Implementierung im OracleJDK entschieden. Und secp256k1 ist nicht entfernt worden, sonder per default einfach nur nicht aktiv für TLS Handshake z.B. Per Flag kann es aber wieder aktiviert werden. Der entscheidende Faktor ist, dass TLS 1.3 wohl secp256k1 als deprected markiert hat. Ganz interessant dazu zu lesen ist:https://crypto.stackexchange.com/questions/68269/does-secp256k1-have-any-known-weaknesses Wie auch immer.. Du hast deine eigene ECDSA lib implementiert... du hast deine eigene Datenbank implementiert. Hauptsache du bist glücklich. So schlecht scheint Java ja dann doch nicht zu sein, wenn du das alles mit Java implementiert hast... Bearbeitet 13. Januar 2020 von ¯\_(ツ)_/¯ Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MixMax Geschrieben 13. Januar 2020 Autor Teilen Geschrieben 13. Januar 2020 vor 26 Minuten schrieb ¯\_(ツ)_/¯: Du verwechselst hier irgendwie eine Programmiersprache und die Implementierung dessen. Das hat mit Java, der Programmiersprache, nicht viel zu tun. Sondern Oracle hat es in ihrer Implementierung im OracleJDK entschieden. Und secp256k1 ist nicht entfernt worden, sonder per default einfach nur nicht aktiv für TLS Handshake z.B. Per Flag kann es aber wieder aktiviert werden. Der entscheidende Faktor ist, dass TLS 1.3 wohl secp256k1 als deprected markiert hat. Ganz interessant dazu zu lesen ist:https://crypto.stackexchange.com/questions/68269/does-secp256k1-have-any-known-weaknesses Ja mag sein, danke für die Info. Ich hab das tatsächlich nicht genauer untersucht, sondern hab das in der Update-Beschreibung gelesen. Danke für die Aufklärung, dann ist es nicht ganz so schlimm wie ich dachte. vor 29 Minuten schrieb ¯\_(ツ)_/¯: Wie auch immer.. Du hast deine eigene ECDSA lib implementiert... du hast deine eigene Datenbank implementiert. Hauptsache du bist glücklich. So schlecht scheint Java ja dann doch nicht zu sein, wenn du das alles mit Java implementiert hast... Ja, so schlecht ist Java nicht. Das stimmt schon, sonnst würde ich wohl kaum damit programmieren. Es gibt immer irgendwas, was einem stört, in jeder Programmiersprache sicherlich. 1 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
PeWi Geschrieben 15. Januar 2020 Teilen Geschrieben 15. Januar 2020 On 1/13/2020 at 10:01 AM, MixMax said: Ich hab mir eh meine eigene ECDSA Bibliothek programmiert und bin damit völlig unabhängig. fefe hält anscheinend wenig von ECDSA: "[...] Denn wir reden hier von ECDSA. ECDSA war damals schon angeschossen, weil es so fragil ist, und es so einfach ist, damit einen Totalschaden zu produzieren. Die Playstation war über ihr DSA gehackt worden. djb hatte bereits mit explizitem Hinweis auf die Fragilität von ECDSA und den NIST-Kurven seinen Gegenvorschlag Ed25519 publiziert. Und unter diesen Umständen haben die den Code nochmal angefasst und ihn schlimmer gemacht. Dazu muss man wissen, dass Krypto-Code so der am wenigsten volatile Code überhaupt ist. Alle sind sich bewusst, wie kritisch da jedes Bit und jeder CPU-Zyklus ist, und keiner will da irgendwas anfassen. [...]" Quelle: https://blog.fefe.de/?ts=a0e1ef44 (Disclaimer: Mir fehlen die Kenntnisse, das zu beurteilen. Und ob diese Fragilität für BTC eine Rolle spielen könnte.) 1 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MixMax Geschrieben 15. Januar 2020 Autor Teilen Geschrieben 15. Januar 2020 (bearbeitet) vor 33 Minuten schrieb PeWi: fefe hält anscheinend wenig von ECDSA: "[...] Denn wir reden hier von ECDSA. ECDSA war damals schon angeschossen, weil es so fragil ist, und es so einfach ist, damit einen Totalschaden zu produzieren. Die Playstation war über ihr DSA gehackt worden. djb hatte bereits mit explizitem Hinweis auf die Fragilität von ECDSA und den NIST-Kurven seinen Gegenvorschlag Ed25519 publiziert. Und unter diesen Umständen haben die den Code nochmal angefasst und ihn schlimmer gemacht. Dazu muss man wissen, dass Krypto-Code so der am wenigsten volatile Code überhaupt ist. Alle sind sich bewusst, wie kritisch da jedes Bit und jeder CPU-Zyklus ist, und keiner will da irgendwas anfassen. [...]" Quelle: https://blog.fefe.de/?ts=a0e1ef44 (Disclaimer: Mir fehlen die Kenntnisse, das zu beurteilen. Und ob diese Fragilität für BTC eine Rolle spielen könnte.) Ha ha schön, dass du es ansprichst. Die Playstation wurde gehackt, weil die so absolut selten dämlich bei der Implementierung wahren und die Zufallszahl "k" überhaupt nicht beachtet hatten und sie auf einen festen Wert gesetzt hatten, so konnte der Priv.Key einfach zurückgerechnet werden. Die Stabilität von ECDSA ist ganz einfach zu beschreiben: Entweder ist sie 1 oder 0. Entweder ist die Signatur am Ende nun richtig oder falsch. Dazwischen gibt es nix, was irgendwie instabil sein könnte. Wenn die Signatur fehlschlägt, hat man entweder nen Bug drin oder sie ist falsch. Die ganze Berechnung ist eine deterministische Rechnung, die gar nicht irgendwie instabil sein kann. Ist einfach wie eine Formel die ausgerechnet wird. Hier der Link zu meiner Version, falls die sich jemand rein ziehen möchte.https://github.com/MrMaxweII/Secp256k1-Calculator/blob/master/Secp256k1.java Bearbeitet 15. Januar 2020 von MixMax Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
PeWi Geschrieben 15. Januar 2020 Teilen Geschrieben 15. Januar 2020 54 minutes ago, MixMax said: Die Playstation wurde gehackt, weil die so absolut selten dämlich bei der Implementierung wahren und die Zufallszahl "k" überhaupt nicht beachtet hatten und sie auf einen festen Wert gesetzt hatten, so konnte der Priv.Key einfach zurückgerechnet werden. fefe würde schreiben: einmal mit Profis arbeiten! 54 minutes ago, MixMax said: Die Stabilität von ECDSA ist ganz einfach zu beschreiben: Entweder ist sie 1 oder 0. Entweder ist die Signatur am Ende nun richtig oder falsch. Dazwischen gibt es nix, was irgendwie instabil sein könnte. Wenn die Signatur fehlschlägt, hat man entweder nen Bug drin oder sie ist falsch. Wenn das so simpel, verstehe ich die Aussage von fefe nicht. Ich hätte spekuliert, dass man sich womöglich leicht um ein Bit vertun kann, es diverse Sonderfälle beim Errechnen der eliptischen Kurven o.ä. geben könnte, ... oder sonstwas. 😉 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MixMax Geschrieben 15. Januar 2020 Autor Teilen Geschrieben 15. Januar 2020 (bearbeitet) vor 23 Minuten schrieb PeWi: Wenn das so simpel, verstehe ich die Aussage von fefe nicht. Ich hätte spekuliert, dass man sich womöglich leicht um ein Bit vertun kann, es diverse Sonderfälle beim Errechnen der eliptischen Kurven o.ä. geben könnte, ... oder sonstwas. 😉 "simpel" hab ich nicht geschrieben. Es ist ne komplexe Rechnung, die aber nicht irgendwie instabil wird. Wenn man sich "um ein Bit" vertut (also irgendwo nen Fehler einbaut) dann funktioniert es halt am Ende nicht und man bekommt dadurch keine Verifizierung die gültig ist. "Sonderfälle" gibt es eigentlich nicht. Es ist ein deterministischer Rechenweg, der vom Anfang bis zum Ende genau stimmen muss. Simmt am Ende das Ergebnis (Dafür werden Prüfcodes geschrieben) stimmt alles. So wie bei einem Taschenrechner z.B. Bearbeitet 15. Januar 2020 von MixMax Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
PeWi Geschrieben 15. Januar 2020 Teilen Geschrieben 15. Januar 2020 4 minutes ago, MixMax said: "simpel" hab ich nicht geschrieben. Mit "simpel" meinte ich die von dir erwähnte Stabilität ("Entweder ist sie 1 oder 0. Entweder ist die Signatur am Ende nun richtig oder falsch."), nicht den Rechenweg. Ich habe kurz in deinen Quelltext reingeschaut, aber als weitgehender Kryptolaie ist das für mich alles China (falls du diese Redewendung kennst). Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MixMax Geschrieben 15. Januar 2020 Autor Teilen Geschrieben 15. Januar 2020 (bearbeitet) Also falls du wirklich Interesse daran hast ECDSA zu lernen oder nen Überblick zu bekommen kannst mich gerne Details fragen. Gibt nicht viele mit denen ich mich über dieses Thema austauschen kann. Ich könnte auch nen Thema erstellen, in dem ich ne kleine Anleitung darüber poste? Die Arbeit sollte aber nicht für die Katz sein, also nur wenn es wirklich jemand interesseirt. Bearbeitet 15. Januar 2020 von MixMax Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
PeWi Geschrieben 16. Januar 2020 Teilen Geschrieben 16. Januar 2020 11 hours ago, MixMax said: Also falls du wirklich Interesse daran hast ECDSA zu lernen oder nen Überblick zu bekommen kannst mich gerne Details fragen. Danke für das Angebot. Wie mein bisheriges Unwissen zeigt, reicht es mir, Anwender zu sein. 🙄 11 hours ago, MixMax said: Gibt nicht viele mit denen ich mich über dieses Thema austauschen kann. Das glaube ich gerne. Ich habe früher auf der Basis der Infozip-Sourcen Backup-Programme mit Deduplizierung geschrieben. Das fand/finde ich super, es hat sich nur auch kein anderer dafür interessiert. 😁 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
MixMax Geschrieben 16. Januar 2020 Autor Teilen Geschrieben 16. Januar 2020 Oh je, noch nie gehört, aber klingt interessant. Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
PeWi Geschrieben 16. Januar 2020 Teilen Geschrieben 16. Januar 2020 23 minutes ago, MixMax said: Oh je, noch nie gehört, aber klingt interessant. Das ganze wurde vor 30 Jahren angeregt durch ein DOS-Backup-Programm namens BackMagic. (Leider wurde das nicht weiterentwickelt.) Das hat die Festplatte blockweise in einen Backupcontainer gespeichert. Das nächste Vollbackup wurde in den selben Container hineingeschrieben. Da sich meist nur wenige Dateien ändern, aber die meisten gleich bleiben, wurden für die gleich gebliebenen Blöcke nur Verweise angelegt. Das funktioniert so gut, dass nachfolgende Backups nur ganz wenig zusätzlichen Speicherplatz brauchen, obwohl du jedesmal ein Vollbackup machst und auch auf jedes Backup wahlfrei zurückgreifen kannst. Oder speichere mehrere verschiedene Windowsrechner in den gleichen Container. Der erste wird auf vielleicht 50% komprimiert, die anderen aber auf 1% bis 5%. Da es das für mein damaliges OS/2 nicht gab, habe ich angefangen, das nachzuprogrammieren (allerdings filebasiert und nicht sektorbasiert). Ich verwalte meine Bot-Sourcen mit einer Linuxversion davon - momentan 670 Vollbackups mit insgesamt 340GB Platzbedarf in einem Container, der nur 853MB benötigt. Und ich kann auf jede einzelne Datei dieser 340GB direkt zugreifen. Ausschnitt: NDBList V0.7.9w0: startup at Thu Jan 16 11:30:39 2020 Using zlib-1.2.3 and source parts of zip-2.3 and unzip-5.50 Chapter List: No Date Files Size Packed Ratio Name ---- ---------------- ----- --------- --------- ----- -------------------- [...] 640 2019-04-28 15:08 4514 624471184 306672 100% kurz vor Freigabe 0.8.0 641 2019-04-28 15:31 4514 624470827 252398 100% Freigabe 0.8.0 642 2019-04-29 23:20 4494 625350754 546849 99.9% Anfang DCAScalper 643 2019-05-08 02:22 4503 626312771 576962 99.9% Updates Rebal 644 2019-05-08 20:39 4505 626314248 262421 100% Rebal vor Umbau 645 2019-05-08 22:59 4507 626550326 478298 99.9% Zwischenstand Rebal 646 2019-05-09 20:45 4500 619157242 296644 100% Zwischenstand Rebal 647 2019-05-10 09:37 4501 619175185 294350 100% Debugging Rebal 648 2019-05-10 22:01 4503 621036970 485602 99.9% Strat New changed 649 2019-05-11 01:25 4503 621069813 335195 99.9% Zwischenstand New 650 2019-05-11 23:35 4504 621074348 278824 100% Zwischenstand New 651 2019-05-13 11:21 4504 621072852 317233 99.9% Wriggle Check for MA3 652 2019-05-15 19:39 4505 624377285 701522 99.9% before changing SL function 653 2019-05-15 22:02 4506 625274454 415938 99.9% double SL (Tharp method) 654 2019-05-16 09:57 4506 625419516 883084 99.9% polish double SL 655 2019-05-16 10:14 4506 625418968 259058 100% double SL on both testbots 656 2019-05-21 13:51 4507 625609514 1428732 99.8% try new at ma3 657 2019-05-21 22:15 4508 627449072 482565 99.9% Umbau lrexchange 658 2019-05-23 10:56 4508 627501379 411557 99.9% vor Position Sizing 659 2019-05-25 10:08 4511 627552722 352920 99.9% Test mit Parabelscheitel 660 2019-05-28 22:51 4518 630180347 723138 99.9% Anfang DualMomentum 661 2019-05-30 23:04 4521 630457395 511728 99.9% added covariance to rebal 662 2019-06-01 22:22 4520 629086030 285758 100% updated rebal 663 2019-06-08 14:04 4526 629234268 554442 99.9% dualm �berarbeitet 664 2019-06-10 20:08 4528 630641116 436574 99.9% Fehler in Rebal behoben 665 2019-06-11 17:03 4622 633158345 471684 99.9% Fehler in Rebal behoben 666 2019-06-30 17:43 4628 634941543 1047159 99.8% Zwischenstand 667 2019-09-04 11:39 4640 634236225 971037 99.8% vor Umbau von ma3 668 2019-09-06 19:57 4637 631084413 338631 99.9% ma3 vereinfacht 669 2020-01-05 23:31 4651 647154611 1421300 99.8% lrpairs.py: setfullbacktestpric ---- ---------------- ----- --------- --------- ----- -------------------- 340.50G 853.37M 99% 670 chapters NDBList: finished at Thu Jan 16 11:30:40 2020 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde Dich hier an.
Jetzt anmelden