- #21
J
josh51
Guest
Hallo
Ich halte es nicht für total bescheuet. Nur verstehe ich den Kommentar nicht. Es sind doch eindeutige Zahlen. Wer ein doc oder ppt per Mail verschickt, packt das auch, obwohl es ja gerade mal 10-25% bringt, oder? Traffic kostet Geld und daher findet man immer öfter rar und 7z-Dateien anstatt Zip, obwohl der Unterschied kleiner ist, aber die Masse machts.
Ich habe nach einem guten Packer für jpg, Video und ISO-Dateien gefragt. Um zu zeigen, warum 7zip ungeeignet ist, habe ich subjektiv gemessene Daten angegeben. was ist an denen->Mist'. Auf jeder x-beliebigen Seite zum Thema findet man vergleichbares. Es geht doch icht darum, ob 90% oder 91% angegeben sind.
Was ist daran so schwer zu akzeptieren, dass es Packer gibt, die jpg-Dateien auf ca 75% ihrer Größe komprimieren, wo 7zip 99% schafft. Bei 500Gb JPG-Dateien sind das 125 Gb Datenersparnis!!! Und man packt sowas nur _einmal_ der Zeitaufwand der Dekompression ist danach entscheidend.
Es ist eine müßige Diskussion, ob man den Platz braucht oder nicht. Aber es wird immer vom Zeitaufwand gesprochen, der nicht unerheblich sei, so was zu packen. Ich rede hier von einem Backup-System. das läuft zu 80% idle. Lass den Kram 1 Woche lang nebenbei laufen oder auch 2 oder 3. Ich habe doch nicht ohne Grund nach eine command line Version gefragt. Für ein Rechnersystem, was eh läuft ist der Unterschied eher sekundär.
Ich erhebe nicht den Anspruch jemanden von etwas zu bekehren. Wer es für sich und seine Anwendung als uninteressant oder schwachsinnig ansieht, soll sich davon nicht abbringen lassen. Wenn diese Person noch einen konstruktiven Tipp zu meiner Frage gibt, freue ich mich.
Abgesehen von mir -so habe ich das rausgelesen- sieht in der Frage nicht mehr als eine rein akademische Frage. Aber ich habe trotzdem super Antworten bekommen. Dafür nochmals herzlichen Dank.
Man muss doch nicht persönlich werden und etwas mit->Mist' abcanceln nur weil man für sich keine Anwendung sieht, oder?
@daikgd: beide KGB und UHARC sind nur bis 2Gb Dateien nutzbar.
Grüße
Microchip schrieb:
Ich halte es nicht für total bescheuet. Nur verstehe ich den Kommentar nicht. Es sind doch eindeutige Zahlen. Wer ein doc oder ppt per Mail verschickt, packt das auch, obwohl es ja gerade mal 10-25% bringt, oder? Traffic kostet Geld und daher findet man immer öfter rar und 7z-Dateien anstatt Zip, obwohl der Unterschied kleiner ist, aber die Masse machts.
Ich habe nach einem guten Packer für jpg, Video und ISO-Dateien gefragt. Um zu zeigen, warum 7zip ungeeignet ist, habe ich subjektiv gemessene Daten angegeben. was ist an denen->Mist'. Auf jeder x-beliebigen Seite zum Thema findet man vergleichbares. Es geht doch icht darum, ob 90% oder 91% angegeben sind.
Was ist daran so schwer zu akzeptieren, dass es Packer gibt, die jpg-Dateien auf ca 75% ihrer Größe komprimieren, wo 7zip 99% schafft. Bei 500Gb JPG-Dateien sind das 125 Gb Datenersparnis!!! Und man packt sowas nur _einmal_ der Zeitaufwand der Dekompression ist danach entscheidend.
Es ist eine müßige Diskussion, ob man den Platz braucht oder nicht. Aber es wird immer vom Zeitaufwand gesprochen, der nicht unerheblich sei, so was zu packen. Ich rede hier von einem Backup-System. das läuft zu 80% idle. Lass den Kram 1 Woche lang nebenbei laufen oder auch 2 oder 3. Ich habe doch nicht ohne Grund nach eine command line Version gefragt. Für ein Rechnersystem, was eh läuft ist der Unterschied eher sekundär.
Ich erhebe nicht den Anspruch jemanden von etwas zu bekehren. Wer es für sich und seine Anwendung als uninteressant oder schwachsinnig ansieht, soll sich davon nicht abbringen lassen. Wenn diese Person noch einen konstruktiven Tipp zu meiner Frage gibt, freue ich mich.
Abgesehen von mir -so habe ich das rausgelesen- sieht in der Frage nicht mehr als eine rein akademische Frage. Aber ich habe trotzdem super Antworten bekommen. Dafür nochmals herzlichen Dank.
Man muss doch nicht persönlich werden und etwas mit->Mist' abcanceln nur weil man für sich keine Anwendung sieht, oder?
@daikgd: beide KGB und UHARC sind nur bis 2Gb Dateien nutzbar.
Grüße
