auch tar bz gepackt war in der selben Liga 
Sowas läßt sich, wie vieles, nicht allgemein beantworten. Packer haben irgendeinen Allgorithmus, der auf irgendwas abgestimmt und optimiert sein muß. Es hängt also davon ab was du Packen willst und wie die Daten dann vorliegen. Das alleskönnende Supperding wird es einfach, wie so oft in der Informatik, nicht geben können. Man muß halt Kompromisse eingehen und Schwerpunkte legen.Picknicker hat geschrieben: Jetzt zu meiner eigentlichen Frage , welcher Linux Packer komprimiert am besten .
man gzip hat geschrieben:-# --fast --best
Regulate the speed of compression using the speci
fied digit #, where -1 or --fast indicates the
fastest compression method (less compression) and
-9 or --best indicates the slowest compression
method (best compression). The default compression
level is -6 (that is, biased towards high compres
sion at expense of speed).
eagleman bzip2 hat geschrieben:-1 (or --fast) to -9 (or --best)
Set the block size to 100 k, 200 k .. 900 k when
compressing. Has no effect when decompressing.
See MEMORY MANAGEMENT below. The --fast and --best
aliases are primarily for GNU gzip compatibility.
In particular, --fast doesn't make things signifi
cantly faster. And --best merely selects the
default behaviour.
Das Archiv wurde nicht mit einem Amiga gepackt. Ich vermute unter Windows .. Da die darin inthaltenen Dateien alle samt sogenannte Diskimages im .adf Format sind.pdreker hat geschrieben: .......
Der Unterschied in dem RAR Archiv köpnnte sich dadurch erklären lassen, dass das Amiga RAR (welcher Amiga?) 16-bittig ist, während es unter Linux natürlich 32 Bittig ist. Ich zweifle stark an, dass das Problem auf den Algorithmus zurückzuführen ist, weil Faktor 2 schon *extrem* viel Unterschied ist...
......
Klar das hatte ich natürlich eingestellt -9 wars glaub ich .. Und da der Unterschied echt enorm war kam mir das schon komisch vor ..eagle hat geschrieben:Also die Unterschiede zwischen 350MB und 600MB finde ich schon heftig. Vielleicht kann man beim rar ja auch Komprimierungsstufen angeben wie bei gzip oder bzip2..
.....
Picknicker hat geschrieben:
ups so wie bekomem ich denn unter Linux die größe eines Verzeichnisses raus ?
Code: Alles auswählen
du -sh <verzeichnisspfad>Einzeln? Dann ist es verständlich (auch wenn der Unterschied doch ein wenig zu extrem ist). Denn Packer wie rar oder gzip packen dann am effizientesten, wenn sie nur eine Datei packen. Deswegen packt man viele Dateien ja in der Regel auch in ein tar. Rar macht das intern sehr ähnlich.Picknicker hat geschrieben:Ich habe das original RAR damals entpackt und hatte zig .adf a 900.000 kb Files auf der Platte .. danach habe ich alle einzeln mit zip auf höchster Stufe gepackt
Code: Alles auswählen
./optrar: error while loading shared libraries: libargh.so: cannot open shared object file: No such file or directory
Hast du denn das ganze auch mal unter Windows ausprobiert, um einen Vergleich zu haben? Ist im übersetzten Programm vielleicht auch noch der Debugcode drin?Picknicker hat geschrieben:..nach über 1.5 Stunden war er imme noch nicht über die 1% Hürde hinaus
Schade das Linux in der Beziehung Win nicht das Wasser reichen kann
Kann jedem mal passierenPicknicker hat geschrieben:Jepp dieses ja .. ich hab mich dann doch mal auf die Niederen des Windows System begeben..
. Trotzdem sind die Werte natürlich vernichtend und möglicherweise wird die Linuxversion von rar nicht besonders gepflegt.
. Vielleicht hängen die Unterschiede ja tatsächlich von der Art der zupackenden Daten ab. Nun ich denke das genau das mein Fall ist .. wenn ich andere Dateien Packe werden sie beide wohl recht nah zusammen liegen liegen.pdreker hat geschrieben:Ha! Ich hab's rausgefunden...
RAR hat ein Feature, das sich "solid archives" nennt. Dieses Feature treibt die Kompressionsraten in die Höhe, wenn man viele ähnliche Dateien packt. Da die ganzen Disk Images sehr viel ähnliche Strukturen (Filesystem) enthalten, kann RAR einfach die erste Datei normal packen, und speichert dann nur noch die Differenzen der anderen Dateien dazu (nochmal gepackt).
........