Osobně nechápu pointu testu výkonu v článku. Jednak souborový systém tohoto typu asi nemá výkon jako jednu z hlavních priorit, jednak bzip2 je nejpomalejší rozšířený kompresní nástroj na linuxech. Gzip má daleko rychlejší kompresi/dekompresi (zde by bylo vhodné srovnání), LZMA aspoň tu dekompresi.
Navíc nechápu, o jaké „filesystem cache“ je řeč. I takový „dd“ umí O_DIRECT (jako iflag/oflag).
Tak mne by „výkon“ docela i zajímal, ale ne tak, jak je uveden. To, že měření vyplivlo pár čísel na 100MB archivu s 5 soubory je sice super, ale u (de)komprimace jaksi nemalou měrou záleží např. i na CPU a už jsem si tam nevšiml, zda-li to (de)komprimoval nebušený Xeon nebo Pentium po rodičích.
Navíc když si např. v Midnight Commanderu otevřu takový prťavý archiv s 5 soubory, tak výsledek se dostaví takřka okamžitě, ale co když archiv obsahuje desítky čí stovky tisíc souborů a má několik GB nebo raději desítek GB? To je přesně ten okamžik, kdy se mi nevyplatí archiv prostě rozbalit, ale rád do něj nakouknu. V tuhle chvíli je již Midnight Commander v podstatě nepoužitelný. U jakých hodnot je ona mazní míra použitelnosti u daného řešení? Klidně na to nemusíme být zlí a vyjděme z předpokladu, že se takový archiv mountne jednou za půl roku a pak tam někde proste visí.
Musí se opravdu v každém článku o nějakém softwaru podrobně opakovat, jak rozbalit archiv se zdrojáky a jak je zbuildit, když je to pořád jedno a to samé? Odstavec o instalaci tady zabírá skoro tolik co zbytek článku, a přitom popisuje jen rutinní obecný postup instalace ze zdrojáků (a ještě zčásti blbě). Připadá mi to jako vata, aby měl článek „správnou“ délku.
Jasne, ze to muze cloveku pripadat uz hloupy, ale na druhou stranu, ja jsem pro. Muze to cist clovek, co to nikdy nedelal, nebo delal jen parkrat a tohle pomuze, kdyz si to chce zkusit. Taky to dokazuje (snad), ze autor to sam prosel a nenasel nejake zadrhele. Navrhhoval bych povinne psat, na cem to autor kompiloval a testoval.
Ja som využitie našiel, napríklad na nie časté ukladanie veľkého množstva krátkych textových súborov (mal som ten prípad). Tie súbory mali pár bytov, preto som zvolil tento spôsob a ušetril som spústu miesta na disku. Robil som aj ich zálohu, tam stačilo zálohovať archív – a to išlo oveľa rýchlejšie, lebo záloha išla na flash(fat32).
Kdyz v Ubuntu 10.04 (plain install) kliknu pravou mysi v Nautilu na .ISO , nabidne mi to „Open with Archive Mounter“… nebo je to neco jineho nez autor popisuje ?
Nicmene to nefunguje uplne dobre, protoze to nechce zrat obrazy vygenerovane pod Win. (teda aspon ty dva, ktere jsem zkousel, pritom Archiv manager, prip. mount s tim nemaji problem).
Musím říct, že (aspoň pro Čecha, nevím, jak pro Maďary či Hotentoty) je čtení tohoto článku utrpením. Uvědomil jsem si to, když jsem narazil na úryvek
se začaly objevovat různé zajímavé použití.
Aby to lépe vyznělo, představte si třeba text
„se začaly objevovat různé zajímavé telata“. ;-)
Ale i když odhlédnu od této, podle některých zastánců údajně „moravské“ chyby („hezké děvčata“), působí článek dojmem, že to autor opravdu přehnal s práškem do pečiva. Asi je placen od řádek. O (ne)potřebnosti věčného opisování posloupnosti – stažení zdrojáků – rozbalení zdrojáků – configure – make – make install – lze polemizovat. Ale zvlášť pokud je článek určen těm, pro které to může mít smysl, jistě smysl nemá opakované tvrzení o nesložitosti zdrojového kódu:
Začátek úvodu: Zdrojový kód není nějak složitý a má kolem 2500 řádek.
Začátek následujícího odstavce „Instalace“: Jelikož zdrojový kód není nějak komplikovaný, není potřeba ani moc závislostí, …
Mimochodem, může mi někdo vysvětlit, jak souvisí množství závislostí se složitostí (či „komplikovaností“) zdrojového kódu?
A proč jsem napsal do titulku „schizofrenie“? Čtěte se mnou:
První věta odstavce Instalace: …se budeme muset pustit…
Druhá věta téhož odstavce: …pokud máte v počítači…
Dále se celkem pravidelně střídá první a druhá osoba, a to i několikrát v jednom odstavci. Následují vybrané ukázky:
Na kompilaci nepotřebujete práva roota a postačí vám k tomu váš uživatel. Nejprve si vytvoříme nějaké místo pro zdrojové kódy a pak je sem stáhneme a rozbalíme:
(text z obrazovky)
V rozbaleném adresáři najdete vše, co budete potřebovat.
V opačném případě si vytvořte nějaký adresář, já mám nejraději ~/bin, a do něj binárku nakopírujte:
(text z obrazovky)
Nakonec ještě upravíme proměnnou PATH v ~/.bashrc:
Pro otestování si vytvoříme testovací adresář, v něm vytvoříme prázdný archiv a připojíme ho:
(text z obrazovky)
Archiv je připojený v adresáři ~/test/point a můžete s nim normálně pracovat, jako by to byl jakýkoli jiný adresář.
Myslím, že by článek měl být buď celý v první osobě, nebo celý ve druhé osobě. A hlavně by jeho délka při podobném obsahu mohla být asi tak poloviční. Ve skutečnosti na toto téma dobře stačila včerejší „zprávička“ (od stejného autora).
Snad neporuším Názorový kodex, když si rýpnu, že mnohem lepší by bylo tohle sepsat do zprávičky o třech řádcích… První část popisuje, co je FUSE. Druhá jak se instaluje software, který nemá nějaká distribuce ve formě balíčku. Část o výkonu postrádá imho smysl. Takže mi z toho zbyl jen ten "archivemount -o (readonly|nobackup) :-)
Zajímalo by mne, jak to vlastně funguje. Jak to vnitřně provádí operaci přidání souboru, smazání souboru z prostředka tar.gz, dostává se ten tar.gz během přimontování do nekonzistentního stavu? Jak to řeší přidávání dat na konec souborů (např. kdyby se to použilo na přimontování mojelogy.tar.gz do /var/log)?
Pokud netrváte na poslední verzi, můžete použít AUR: http://aur.archlinux.org/packages.php?ID=11888
Jinak článek zajímavý, teda hlavně ta informace, že něco takového existuje a jak se to jmenuje. Přesně toto mi chybělo.