bestes Archiv-Format ?

[~fricky]

GNU-Fan schrieb:

Von .rar würde ich abraten, da es zwar leistungsfähig ist, es aber keine bedienfreundlichen, freien Programme dafür gibt.

kennst nicht winrar? benutzerfreundlicher geht's kaum (ok, bis auf diese blöde einschaltmeldung, von wegen testversion und so).

[_matze]

~fricky schrieb:

GNU-Fan schrieb:

Von .rar würde ich abraten, da es zwar leistungsfähig ist, es aber keine bedienfreundlichen, freien Programme dafür gibt.

kennst nicht winrar? benutzerfreundlicher geht's kaum (ok, bis auf diese blöde einschaltmeldung, von wegen testversion und so).

Na ja, er meint wahrscheinlich, dass WinRAR im Grunde ne kostenpflichtige Software ist, die du nach den 30 Tagen (oder so) deinstallieren müsstest. Aber bei WinRAR ist das wohl auch von den Entwicklern so gewollt, dass die ganze Welt eine Testversion auf dem Rechner hat (bessere Werbung gibts ja wohl nicht). Insofern würde ich das eigentlich eher als Freeware für den privaten Gebrauch ansehen...

[GNU-Fan]

Dass es diese Doppeldeutigkeit von "frei" im Englischen gibt, wusste ich. Aber wir haben dieses Problem doch eigentlich nicht, oder?

[TdZ]

Zip ist kein Kompressionsverfahren, sondern ein Container. Aus diesem Grunde ist es sinnlos, Zip und z.B. BZip2 zu vergleichen, weil sie mitunter genau das selbe Verfahren nutzen können. Und ähnlich verhält es sich glaube ich auch mit 7zip, aber das ohne Gewähr.

[profi-archivierer]

ohne zu wissen wie lange es 'zukunftssicher' sein soll, wie gross die daten sind und wie heikel macht es wenig sinn backup lösungen aufzuzählen.

[u-ser_l]

GNU-Fan schrieb:

Die Spezifikation für tar passt vermutlich auf ein einseitig beschriebenes A4 Blatt.

thx für den link - tar ist also ein schön einfaches Format.

Sehr beruhigend: Im Notfall könnte man sich ja fast selbst einen rudimentären tar-Entpacker programmieren, falls es in 100+ Jahren keinen mehr geben sollte

[Fincki]

u-ser_l schrieb:

GNU-Fan schrieb:

Die Spezifikation für tar passt vermutlich auf ein einseitig beschriebenes A4 Blatt.

thx für den link - tar ist also ein schön einfaches Format.

Sehr beruhigend: Im Notfall könnte man sich ja fast selbst einen rudimentären tar-Entpacker programmieren, falls es in 100+ Jahren keinen mehr geben sollte

Nach dem Entpacken muss man dann nur noch die Programme zum Anzeigen der Daten nachprogrammieren.

[GNU-Fan]

Ja, aber denk dran, dass tar nur ein Aneinanderkleben von mehreren Dateien zu einer Datei ist.

Komprimiert wird extra. (Deshalb ja auch zwei Namensendungen)

[u-ser_l]

RandomAccess85 schrieb:

Um welche Datengrößen gehts denn dabei und wie lange müssen die archiviert bleiben?

1-3 G pro Woche, Haltbarkeit 10 Jahre. Für längere Haltbarkeit wird nach ein paar Jahren umkopiert.

Ich habe mit CDR bisher gute Erfahrungen gemacht.

gerade neulich habe ich alte CDRs umkopiert - die waren vor 8 Jahren mit Tempo 2x und 4x beschrieben worden und sind heute fehlerfrei mit hohem Tempo lesbar.
Beim Auslesen war für mich überraschenderweise kaum ein Unterschied zwischen no-name Rohlingen aus dem Supermarkt und diversen Marken-Rohlingen zu merken.

[u-ser_l]

also tar ist damit klar. Für ein solch einfaches Format kann man sich im größten Notfall ja sogar selbst einen Entpacker programmieren. Bleibt die Frage nach der zukunftssicheren Kompression.

[GNU-Fan]

Warum sollte ein Algorithmus, der ja auf mathematischer Sprache basiert, nach einiger Zeit nicht mehr reproduzierbar sein?

[noch ein gnu-fan]

gzip is ja open source, da kannst du dir den source gleich mitbrennen (wurd ja schonmal gesagt)

http://www.gzip.org/#sources

[u-ser_l]

ja, ist wahr, aber ich hätte wenig Lust, einen Algorithmus zum Entpacken von .gz zu codieren, falls es einen Entpacker für zukünftige Plattformen irgendann nicht mehr geben sollte, und außerdem können auch die Texte von Spezifikationen und Algorithmen irgendwann verloren gehen, wenn sich lange Zeit niemand mehr dafür interessiert.

Kurzum: es vereinfacht die Sache, wenn die Kompressions-Methode möglichst zukunftssicher (sprich: auf zukünftigen Plattformen lauffähiges Entpacker-Programm) ist.

[GNU-Fan]

Kannst dich ja in die Mailing-Liste von GNU zip eintragen. Dann wirst du benachrichtigt, wenn der Maintainer verstirbt oder die Arbeit niederlegt. :p

[bernibutt]

Ein kostenloses Archiv ist Winzip, man kann es sich auf der Herstellerseite kostenlos herunterladen unter dem Punkt "Downloads" herunterladen.

Einen schönen Feierabend,
bernibutt

[u_ser-l]

den source-code des Entpackers im Klartext mit auf das Medium zu bringen, ist eine gute Idee.

Vorausgesetzt, ich habe dann auch einen Compiler, der heutige sources anstandslos compiliert. Wenn ich da in die Vergangenheit blicke (K&R vs Ansi usw.), bin ich mir da aber nicht ganz sicher.

Einen passenden compiler mitzugeben, um den Entpacker zu bauen, bringt leider auch nicht viel mehr Zukunftssicherheit, denn als executable entsteht das Problem der Binärkompatibilität, als source wiederum entsteht die Frage nach einem Compiler, der den Compiler compiliert.

Schwierig.

[GNU-Fan]

In 10 Jahren müssen sowieso alle Datenträger mit Quelltexten drauf vernichtet werden, weil sie irgendwelche Softwarepatente verletzen. Also was solls.

[rüdiger]

Ich würde mir weniger um den Komprimieralgorithmus sorgen machen, als um das Format der eigentlichen Daten und über den Datenträger. Bis man sich sorgen machen muss, ob noch jemand bz2 kennt, werden die wenigsten Medien noch auslesbar sein.

[noch n gnu fan]

u_ser-l schrieb:

den source-code des Entpackers im Klartext mit auf das Medium zu bringen, ist eine gute Idee.

Vorausgesetzt, ich habe dann auch einen Compiler, der heutige sources anstandslos compiliert. Wenn ich da in die Vergangenheit blicke (K&R vs Ansi usw.), bin ich mir da aber nicht ganz sicher.

Einen passenden compiler mitzugeben, um den Entpacker zu bauen, bringt leider auch nicht viel mehr Zukunftssicherheit, denn als executable entsteht das Problem der Binärkompatibilität, als source wiederum entsteht die Frage nach einem Compiler, der den Compiler compiliert.

Schwierig.

du machst dir ja schon um alles sorgen
also, dann besorg dir ein externes cd laufwerk, nen Eee PC oder sonst was handliches, lad ein minimales linux mit gzip, unrar und anderen spässen drauf und lager das teil mit den cds zusammen. entpacken kannst dus dann auf jedenfall
ob du die daten noch lesen kannst? ..hm vielleicht solltest du die ascii tabelle noch mit packen

[Kenner der Stecker]

noch n gnu fan schrieb:

u_ser-l schrieb:

den source-code des Entpackers im Klartext mit auf das Medium zu bringen, ist eine gute Idee.

Vorausgesetzt, ich habe dann auch einen Compiler, der heutige sources anstandslos compiliert. Wenn ich da in die Vergangenheit blicke (K&R vs Ansi usw.), bin ich mir da aber nicht ganz sicher.

Einen passenden compiler mitzugeben, um den Entpacker zu bauen, bringt leider auch nicht viel mehr Zukunftssicherheit, denn als executable entsteht das Problem der Binärkompatibilität, als source wiederum entsteht die Frage nach einem Compiler, der den Compiler compiliert.

Schwierig.

du machst dir ja schon um alles sorgen
also, dann besorg dir ein externes cd laufwerk, nen Eee PC oder sonst was handliches, lad ein minimales linux mit gzip, unrar und anderen spässen drauf und lager das teil mit den cds zusammen. entpacken kannst dus dann auf jedenfall
ob du die daten noch lesen kannst? ..hm vielleicht solltest du die ascii tabelle noch mit packen

Wenn die Steckdosen sich ändern werden? Braucht man noch ein Kraftwerk