WinRAR a oblíbený?
Jsou dva důvody proč něco zabalit.
1) Chci mít jeden soubor. => Použiji .ZIP
2) Potřebuji zmenšit velikost => Použiji .7z
Dnes kompresi používají všechny soubory (JPG, DOCX, PDF, DWG, ...) Takže bod dva ztrácí smysl protože druhá komprese už nic nešetří.
Celý RAR je zastaralý a k ničemu.
Podle mě RAR vyrostl na warezu. Uměl dělit archiv na bloky o požadované velikosti v době, kdy ARJ začínalo být mimo mísu a PKZIP to neuměl. Bylo důležité využít kapacitu diskety do posledního bajtu.
Dál už to je jen setrvačnost. Je dostatečně dobrý na to, aby se nikomu nechtělo vrtat v něčem, co funguje. Další velká výhoda je, že archiv jde snadno rozbalit, i když není stažený celý. Když už to takhle někdo zabalí, aby k tomu přiložil nějaké informace o warez skupině, co to má na svědomí, tak některé přehrávače dokážou video z takového právě stahovaného archivu průběžně přehrávat.
Nemyslím, že autor zprávičky použil slovo oblíbený podle toho, jestli se vám konkrétně RAR líbí, nebo ne. Spíš bych řekl, že zohledňuje rozšířenost toho formátu a koneckonců i software WinRAR mezi uživateli Windows.
Navíc někdo jiný to subjektivní hodnocení může mít úplně naopak, a třeba mu může vyhovovat tím, že RAR není tak pomalý při kompresi jako 7z a zároveň má vyšší komp. poměr než zip. Kompresor pro RAR také třeba automaticky detekuje PCM audio a obr. bitmapy ve vstupních souborech a nakládá s nimi efektivněji než většina ostatních komprimační formátů.
Nakonec je software WinRAR velmi dobře integrován do Windows, takže nemá problém se zvýšením práv přes UAC, když je to potřeba, umí korektně ukládat NTFS alt. streamy, ACL, high-precision timestampy atd.
No právě ta integrace do Win je peklo.
Brzdí to načtení kontextového menu (na HDD).
Po odinstalaci tam zůstal bordel.
Rychlost a poměr komprimace už jsem vysvětloval. Dnes když systémové disky jsou terové SSD ztrácí RAR poslední pozitiva.
A když něco posílám přes internet, tak 7z je mnohem lepší než RAR.
Jestliže rozšířený = oblíbený, tak to Win je mnohem oblíbenější než Linux?
Ale nechci slovíčkařit. Dá se to tak použít.
Moje chyba že jsem to blbě pochopil.
EDIT:
Znám jednoho člověka, co má WinRAR rád.
22. 8. 2023, 14:23 editováno autorem komentáře
Genialita WinRARu z mého pohledu spočívá v tom, že ho zvládne BFU a zároveň poskytne pokročilé funkce, když potřebujete. K tomu si vemte stálé GUI, kde ani po letech nemusíte složitě hledat, kam něco schovali, nebo dokonce zrušili, a je to jasná volba.
Navíc se s novými verzemi nezpomaluje, což o OS, prohlížečích a dalších říct nelze.
Ale svobodu volby Vám přeju, bez konkurence by ani ten RAR nebyl.
Jenže když se to nestáhne tak chybí třeba 10% a to vám ten recovery opravdu neopraví. Dost pochybuji, že nedostáhnete jenom 1% archivu. Navíc tohle nebude asi dobře fungovat, když bude chybět např. konec souboru. Aby to mělo smysl u stahovaných souborů, tak bys musel ten soubor stahovat paralelně s hodně connections. Takže vám tahle funkce bude k užitku v tak mizerném počtu případů, že za to vůbec nestojí.
Tady to i píšou https://www.win-rar.com/recovery-record-useful.html?&L=0 že to je primárně určené pro archivaci na nespolehlivých medií.
Mám vícero zkušeností se soubory, které byly po stažení nakopnuté. Někdy pomohlo opakované stažení, někdy ani to ne, asi byl nakoplý už u zdroje. Při porovnání poškozeného s nepoškozeným se ukazovaly různé způsoby poškození. Kus obsahu (několik kB) obsahoval něco zcela jiného, těžko říci čeho. Jednou se doprostřed souboru vloudila html chybová stránka. Jindy se kus obsahu o několik B posunul vpřed či vzad. Prostě se to děje, a kdo má méně spolehlivou RAM, tomu se to může stát i bez stahování. Mizerný počet případů bych tomu neříkal.
Tak to je fakt zajímavý mě se tohle třeba snad nikdy nestalo. Není to třeba tím, že to stahuješ z něčeho jako uloz.to atp. např. něčím jako je JDownloader? Podle mě, ale musel být pokaždé poškozený již zdroj dat a nepoškodilo se to přenášením. Moc si nedokážu představit, jak by se to mohlo na TCP stát (např. ten posun). Problém je spíš v aplikaci, která takový soubor stahuje než v přenosu.
Ano, povětšinou v různých download managerech, které používám právě z toho důvodu, aby se to umělo navázat po přerušení. Je to legitimní součást http protokolu, takže by to mělo fungovat, no akosi... Jedno to ale bylo vadnou síťovou kartou, to se tyhle chyby projevovaly i v lokální síti, stále častěji, a po výměně to ustalo.
Čímž ale chci říci, že se to stává, a důvod pro rekonstrukční data je. Chyba může vzniknout kdekoliv a pak jen smutně koukáte.
To se samozrejme odviji i od nastaveni webserveru, treba v nginxu vam do toho muze krasne hodit vidle direktiva max_ranges ;-) A podle RFC 7233 (section 2.3) to povinna soucast protokolu neni...