Jaderné noviny – 17. 2. 2010

16. 3. 2010 | Jirka Bourek | Jaderné noviny | 3284×

Aktuální verze jádra: 2.6.33-rc8. Citáty týdne: Andrew Morton, Valerie Aurora, Harald Welte. Kompresní formáty na kernel.org. Rozšířené hlášení chyb. Sloučení kdb a kgdb. Jak staré je naše jádro?

Obsah

• Aktuální verze jádra: 2.6.33-rc8
• Citáty týdne: Andrew Morton, Valerie Aurora, Harald Welte
• Kompresní formáty na kernel.org
• Rozšířené hlášení chyb
• Sloučení kdb a kgdb
• Jak staré je naše jádro?

Aktuální verze jádra: 2.6.33-rc8

Současné vývojové jádro je 2.6.33-rc8 vydané 12. února. Linus říká: Myslím si, že tohle bude poslední -rc v této sérii. mělo by být opraveno mnoho regresí, a i když z jejich seznamu nejsem nadšený, už tam nemáme ten druh ošklivých věcí, které byly před -rc7 a ze kterých jsem měl obavy.

Všechny detaily lze nalézt v kompletním changelogu.

Podle nejnovější zprávy o regresích počet nevyřešených regresí stoupl na 31, což je v tomto vývojovém cyklu nejvíce.

Citáty týdne: Andrew Morton, Valerie Aurora, Harald Welte

Jsou tu ale věci, které můžeme udělat. Můžeme detekovat zápis do starého souboru a použít WARN_ON_ONCE("jsi blb"). Počkat rok, změnit to na WARN_ON("jsi velkej blb"). Počkat další rok a pak to odstranit.

-- Zastarávání vlastností podle Andrewa Mortona

Výhody, které se od doby Googlu v zaměstnání staly standardem – jídlo zdarma, možnost si zacvičit, autobus do práce – snadno umožňují denně mluvit jenom se spolupracovníky. Jestliže celý den trávíte se spolupracovníky, přátelíte se pouze se spolupracovníky a pak přijdete domů a sníte večeři – hádáte správně – se svým spolupracovníkem, může se vám stát, že několik let v kuse neuslyšíte slova: „Používat na desktopu Solaris? Děláš si srandu?“

-- Valerie Aurora

Každý klidně provozuje megabyty proprietárního objektového kódu bez jakékoliv ochrany paměti připojeného do nezabezpečené veřejné sítě (GSM). Kdo by tohle udělal na svém PC na Internetu bez filtrování paketů, bran na úrovni aplikací a nepřetržitého toku bezpečnostních aktualizací softwaru? Ale se svými telefony to přesto lidé dělají pořád.

-- Harald Welte

Kompresní formáty na kernel.org

Jonathan Corbet, 17. února 2010

Archiv kernel.org značně závisí na kompresi, aby omezil výdaje na úložiště a šířku pásma. Nekomprimovaný tar archiv verze 2.6.32 má 365 MB; pokud by stahující data přijímali v tomto formátu, výsledné datové přenosy by byly obrovské. Proto takové archivy nejsou k dispozici; místo toho si lze vybrat různé verze komprimované pomocí gzip (79 MB) nebo bzip2 (62 MB). Bzip2 je novější možnost; chvíli trvalo, než se uchytil, protože potřebné nástroje nebyly příliš široce dodávány. I přesto nyní lidé v kernel.org zvažují změnu kompresních formátů, které používají.

Diskuzi rozproudila dostupnost nástroje XZ založeného na kompresním algoritmu LZMA. XZ nabízí lepší kompresi – 53 MB u 2.6.32 – ale má obvyklý problém: Nástroje nejsou ještě široce dostupné v distribucích, obzvláště v těch podnikových. To vedlo k tlaku proti myšlence standardizovat XZ v blízké budoucnosti, což lze vidět z tohoto komentáře Teda Ts'o:

Je potřeba mít na paměti, že někteří lidé stále používají RHEL 3 a někteří z nich by mohli chtít stahovat z ftp.kernel.org. Takže lidé, kteří navrhují, abychom na kernel.org .gz nahradili .xz určitě kouří dobrej matroš.

Na nahrazení formátu .gz je ve skutečnosti tlak minimální. Komprese není nejlepší, ale na druhou stranu je rychlejší než alternativy. Z diskuze je zjevné, že některé lidi doba komprese zajímá. Pravděpodobnější je, že XZ by mohlo nahradit soubory ve formátu bzip2. Pak by volba byla jasná: rychlost a široká dostupnost nebo nejlepší možná komprese. I na takovou změnu si nicméně budeme pravděpodobně muset alespoň rok počkat; mezitím nejspíše budou na kernel.org všechny tři formáty.

(Tato diskuze také zahrnovala vedlejší vlákno o číslování 2.6.xx. Očekávaný flamewar se opět nedostavil – pravděpodobně o tuto změnu není dostatečný zájem nebo na to nikdo nemá sílu.)

Rozšířené hlášení chyb

Jonathan Corbet, 17. února 2010

Linux obsahuje mnoho systémových volání, která dělají složité věci; vstupem jsou rozsáhlé struktury – volání pracují s významnými interními stavy a občas vrací nějaká komplikovaná výstupní data. Informace o úspěchu je ale zmáčknuta do jediného čísla nazvaného errno. Programátoři aplikací, kteří pracují s některými subsystémy (v tomto ohledu je autorovým oblíbencem Video4Linux2), mají hodně zkušeností se zjišťováním toho, jaký nastal problém, když jádro hlásí jenom „nefunguje to“.

Andi Kleen popisuje problém takto:

Vždy to popisuji jako „přístup edu k řešení chyb“. Místo chybového hlášení vypíšete prostě ?. Prostě ? je v Linuxu EINVAL.

Můj oblíbený příklad je konfigurace plánovacích front [queueing disciplines] v síťování, kde se nastavují složité datové struktury a algoritmy a v mnoha případech existují desítky různých chybových stavů v závislosti na vstupních parametrech – a všechno vrací EINVAL.

Bylo by hezké poskytnout vývojářům aplikací lepší informace. Krátká diskuze zmínila tyto možnosti:

• Použít printk() a vložit informace do logovacího souboru systému. Tento přístup se používá široce, ale jádro narůstá kvůli řetězcům, riskuje se přeplnění logů a neprivilegovanému programátorovi nemusí být tyto informace k dispozici.

• Rozšířit systémová volání tak, aby se jim umožnilo poskytování bohatších stavových informací. Pouhé přidání nové verze ioctl() by řešilo mnoho z nejhorších problémů.

• Vytvořit mechanismus podobný errno, kterým by systémové volání mohlo vracet rozšířené informace. Takovou informací by mohl být chybový řetězec, nějaký zvláštní kód nebo, jak navrhl Alan Cox, ukazatel na pole ve struktuře, které způsobilo problém.

Rozhodně lze tvrdit, že úzký mechanismus errno již vykazuje příznaky stárnutí a zasloužil by si vylepšit. Jakákoliv vylepšení nicméně budou specifická pro Linux a ne-POSIXová, což většinou omezuje jejich přijetí. Také by se s nimi muselo žít navěky, takže je potřeba je navrhnout opatrně. I kdyby se tedy někdo této výzvy chopil, pravděpodobně řešení v hlavní řadě v blízké době neuvidíme.

Sloučení kdb a kgdb

Jake Edge, 17. února 2010

Když Linus Torvalds začlenil kgdb – pahýl [stub] pro komunikaci s debuggerem gdb – v začleňovacím okně 2.6.26, bylo to poměrně překvapivé vzhledem k tomu, že jaderné debuggery nemá příliš v lásce. Existuje ale další řešení pro ladění jádra, které již dlouho existuje mimo hlavní řadu: kdb. Jason Wessel navrhl sloučení obou řešení tak, že by kgdb používalo „kdb shell“, takže by obě řešení byla jaderným hackerům dostupná.

Tyto dva debuggery slouží různým účelům, kdb má mnohem méně funkcí, ale oba mají svá užití. Kgdb umožňuje ladění na úrovni zdrojových kódu použitím gdb přes sériovou linku, ale to vyžaduje druhý stroj. Pro systémy, kde je problematické nebo nepraktické nastavit sériové spojení, může kdb poskytnout dostatek možností k ladění problému. Krom toho věci jako jaderné nastavování režimu [kernel modesetting, KMS] zpřístupňují další možnosti, které kdb postrádalo. Jason popsal jednu variantu:

Příklad z roku 2010, kde může být kdb užitečnější než kgdb, je malý netbook bez sériových portů a podobných… máte na něm X a ovladač souborového systému shodí jádro. S kdb a kms máte možnost vidět pád, který by se do /var/log/messages nedostal, protože byl způsoben ovladačem souborového systému.

Zatímco kgdb umožňuje přístup ke všem standardním ladícím příkazům, které poskytuje gdb, sada příkazů kdb je mnohem omezenější. Lze prozkoumat a měnit obsah pamětí nebo registrů, nastavovat body přerušení [breakpoint] a získat zpětný výpis zásobníku [backtrace], tyto příkazy ale většinou vyžadují použití adres, a ne symbolických jmen. V současnosti je nejlepší návod k použití kdb k nalezení v článku na developerWorks, nicméně to Jason plánuje změnit. S patchi je dodávána dokumentace, ale popis příkazů bude záviset na tom, jaké kousky – pokud nějaké – se dostanou do hlavní řady.

Zde je vhodné poznamenat, že jedna z vlastností, která byla z kdb odstraněna kvůli začlenění, je disassembler. Byl specifický pro x86 a nový kód je podle FAQ k začlenění z 99 % nezávislý na platformě. Protože je kgdb implementováno pro mnoho architektur, jeho přepis nad kdb vedl u kdb k podpoře mnohem většího počtu architektur – místo omezení pouze na x86 kdb nyní podporuje i arm, blackfin, mips, sh, powerpc a sparc.

Krom toho kgdb a kdb mohou fungovat společně. Při kgdb sezení lze použít příkaz monitor a přistupovat přes něj k příkazům kdb. Několik jich může být užitečných, například ps pro výpis procesů nebo dmesg, který umožní podívat se na výstup logu.

FAQ vyjmenovává mnoho dalších výhod, které by plynuly ze začlenění, kromě toho, že by kdb bylo v hlavní řadě a jeho uživatelé by nemuseli patchovat jádro. Základní myšlenkou u vyjmenovaných výhod je sjednotit uživatele a vývojáře kgdb a kdb tak, aby mohli táhnout za jeden provaz, protože jak kdb, tak kgdb mají podobné potřeby, co se týče toho, jak se integrují do jádra. V minulosti proběhlo několik diskuzí o tom, které z řešení je nejlepší, ale protože obě slouží v jiných případech, mít k dispozici obě by mělo další výhodu: Lidé už nebudou muset debatovat o tom, jestli je lepší kdb nebo kgdb, proč máme jenom jedno… Prostě půjdou a použijí ten nástroj, který pro ně bude nejlepší.

Jason podotýká, že Ubuntu v nedávných jádrech kgdb povolilo, což by rád viděl i u jiných distribucí. Když bude k dispozici kdb, mělo by být povoleno i to, což by uživatelům zjednodušilo přístup k jeho funkcím:

Také doufám, že vstupní bariéra bude u kdb mnohem nižší, protože je ho snazší používat. Například někdo s laptopem, na kterém poběží jádro s povoleným kdb, může snadno udělat

echo kms,kbd > /sys/module/kgdboc/parameters/kgdboc
echo g > /proc/sysrq-trigger
dmesg
bt
go

A voila, právě jste spustili jaderný debugger.

V příkladu výše Jason ukazuje, jak povolit kdb (pro klávesnici – kbd – a fungování KMS) a pak se do něj dostat pomocí sysrq-g (když je povoleno, je kdb voláno i v případě, že dojde k panice nebo oops). Následující tři příkazy slouží k prohlédnutí výstupu logu, získání zpětného výpisu zásobníku a pokračování v běhu.

Patche jsou samy o sobě rozděleny do tří samostatných sad: První a největší přidává infrastrukturu kdb do kernel/debug a do tohoto adresáře přesouvá kgdb.c, druhá přidává podporu KMS do kdb s experimentálním patchem pro atomické nastavování režimu u grafického ovladače i915 a třetí umožňuje ladění jádra pomocí kdb a kgdb brzy během bootování – od chvíle, kdy je k dispozici earlyprintk(). Jason míří do 2.6.34 a přinejmenším zatím byly jeho patche přijaty dobře. Nejnovější verze sady patchů má číslo 3 a obsahuje dlouhý seznam změn, které byly provedeny v reakci na dřívější komentáře. Z komentářů k RFC z loňského května navíc bylo zjevné, že o kdb a jeho sloučení s kódem kgdb je zájem.

Pozorní čtenáři si všimnou několika podobností mezi tímto návrhem a nedávnou snahou o začlenění utrace. V obou případech je existující ladící nástroj přepsán tak, aby používal nové jádro, ale jsou tu i rozdíly. Na rozdíl od utrace poskytují patche kdb/kgdb přímo nějakou funkci, která uživatelskému prostoru chybí. Jestli to bude dostatečné k tomu, aby to překonalo Linusův polonepřátelský postoj k jaderným debuggerům – i když začlenění kgdb naznačuje, že ohledně toho trochu měkne – se ještě uvidí.

Jak staré je naše jádro?

Jonathan Corbet, 17. února 2010

Duben 2005 byl pro jadernou vývojovou komunitu poměrně napjaté období. Nástroj BitKeeper, který tolik zlepšil vývojový proces, najednou nebyl k dispozici a nebylo jasné, co ho nahradí. Pak se Linus objevil s novým systémem nazvaným git; současnou epochu vývoje jádra můžeme datovat od té doby. Zahájením této epochy byl commit 1da177e4, jehož changelog říká:

Počáteční verze pro repozitář git. Nebudu se obtěžovat s kompletní historií, i když ji máme. Později můžeme vytvořit oddělený „historický“ gitový archiv, pokud budeme chtít, po importu do gitu má okolo 3,2 GB – prostor, který by první dny zbytečně komplikoval, protože pro to nemáme dostatek dobré infrastruktury.

Tak hr na to!

A komunita opravdu byla hr; od té doby bylo přidáno nějakých 180 000 sad změn. Typicky je v každém tříměsíčním vývojovém cyklu změněno několik set tisíc řádek kódu. Před nějakou dobou autora napadlo, kolik z jádra bylo opravdu změněno a kolik z jádra, které bude 2.6.33, pochází z doby 2.6.12-rc2, které otevíralo éru gitu. Zbylo vůbec něco z jádra, které jsme překládali roku 2005?

Odpověď na tuto otázku lze získat naboucháním několika ošklivých skriptů a investicí mnoha hodin času k jejich zpracování. V podstatě se použije příkaz git blame, který lze použít k vytvoření označkované verze souboru, ve kterém se vypisuje poslední commit, který danou řádku kódu měnil. ID těchto commitů lze poté shrnout a spojit s verzí jádra; na konci tohoto procesu je jednoduchá tabulka, která ukazuje, jaký podíl v procentech má daná verze jádra na celkové kódové základně. Tabulka vypadá takto:

Shrnuto: Těsně nad 31 % jaderného stromu se datuje až do 2.6.12 a od té doby je beze změn. Jádro se možná rychle mění, ale některé jeho části se během pěti let nezměnily vůbec. Od té doby vidíme plynulý proud změn, přičemž novější jádra jsou zastoupena více než starší. Tato křivka je částečně důsledkem obecného nárůstu tempa změn s postupem času; 2.6.13 mělo méně než 4 000 commitů, zatímco 2.6.33 jich mělo téměř 11 000. I tak jednoho zajímá, co se stalo s 2.6.20 (5 000 commitů), že toto vydání nyní reprezentují méně 2 % ze všeho kódu.

Velká část opravdu starých věcí je v mnoha souborech proložena novějšími řádky; hlavně komentáře a poznámky o autorských právech existují beze změny poměrně dlouho. Makefile na nejvyšší úrovni v 2.6.12 obsahoval VERSION=2 a PATCHLEVEL=6, přičemž tyto řádky se od té doby nezměnily; řádek níže (SUBLEVEL=33) se změnil v prosinci.

Na horním konci lze také narazit na zajímavé závěry. Když použijeme toto měřítko, 2.6.33 je nejmenší vývojový cyklus, který jsme měli za poslední rok, i když byl určitě nahrazen nějaký kód přidaný během předchozích cyklů. 4,2 % kódu v 2.6.33 bylo naposledy změněno ve vývojovém cyklu 2.6.33, přičemž každé z předchozích čtyř jader (od 2.6.29 do 2.6.32) reprezentuje více než 5,5 % kódu, který je dodáván v 2.6.33.

Další zajímavé cvičení je podívat se na celé soubory, kterých se pět let nikdo nedotkl. Vzhledem k obecnému dění a změnám API, ke kterým během té doby došlo, je velká pravděpodobnost, že soubory, kterých se nikdo nedotkl, nikdo nepoužívá. Zde je kompletní seznam souborů, kterých se od 2.6.12 nikdo nedotkl – obsahuje všech 1062. Pár závěrů:

• Každý strom jádra si nese drivers/char/ChangeLog, který se z větší části věnuje dokumentaci snah Teda Ts'o ohledně TTY z poloviny devadesátých let. Od roku 1998 v něm byla pouze jedna změna provedená roku 2001. Takové soubory mohou být užitečné z historického úhlu pohledu, ale v současných jádrech příliš relevantní nejsou.

• Nikoho nepřekvapí, že adresář s dokumentací obsahuje spoustu materiálu, který dlouho nebyl aktualizován. Velkou část ani není potřeba měnit; způsob, jak nakonfigurovat ISA Sound Blaster je v podstatě stejný jako kdykoliv předtím – za předpokladu, že někdo najde takovou kartu a ISA sběrnici, do které ji zapojit. Podobně není velká aktivita vývoje u podpory klingonštiny (Documentation/unicode.txt), podpory Netwinder a podobných, takže dokumentace je pravděpodobně aktuální, i když nepříliš užitečná. Když to shrneme, 41 % adresáře s dokumentací se datuje zpět do 2.6.12. U práce na dokumentaci byla špička v 2.6.32; bez ní by mnohem větší procento tohoto podstromu vypadalo poměrně staře.

• Některá stará rozhraní se dlouho neměnila, což vede na spoustu statických souborů v include/. <linux/sort.h> deklaruje sort(), které se používá na mnoha místech. <include/fcdevice.h> deklaruje alloc_fcdev() a obsahuje varování, že tento soubor bude někdy opravdu brzy sloučen s ostatními. Velká část rozhraní sunrpc je také dlouho statická.

• Prastarým kódem přetéká strom ovladačů, i když pravděpodobně není překvapení, že staré hlavičkové soubory jsou k vidění častěji než staré C soubory. Strom ovladače ISDN je poměrně statický.

• Velká část sound/oss je již dlouho netknutá a pravděpodobně je již hezky protkána pavučinami; již nějakou dobu není moc důvodů sahat na kód OSS.

• net/decnet/TODO obsahuje krátký seznam věcí, které potřebují dokončit; v době gitu se ho také nikdo nedotkl. Nabízí se otázka, jak daleko jsou vývojáři DECnet s vyřizováním věcí na tomto seznamu…

Který subsystém je tedy nejstarší? Následující graf se dívá na jaderné subsystémy (definované podle adresářů na nejvyšší úrovni) a ukazuje zastoupení kódu z 2.6.12 v každém z nich:

Nejmladší subsystém je bez překvapení tools/, který před 2.6.29 neexistoval. Mezi subsystémy, které v 2.6.12 existovaly, je nejnovější vnitřní část jádra [core kernel], k verzi 2.6.12 se datuje 13 % kódu. Na opačném konci je zvukový subsystém s 45 % kódu – největší podíl v jádře. Pro ty, které zajímá rozdělení stáří v jednotlivých subsystémech, je k dispozici tato stránka.

Shrnutí: I když se základna kódu v jádře vyvíjí poměrně rychle, je spousta kódu, kterého se nikdo za posledních pět let nedotkl, a to ani opravami stylu kódu či mezer. Kód tu s námi zůstává poměrně dlouho.

(Těm, kteří by si rádi hráli s těmito daty, jsou k dispozici použité skripty v gitdb repozitáři git://git.lwn.net/gitdm.git)

       

Komentáře

[xxxx]

Ja tomu nerozumiem, moze mi niekdo do pekla konecne po 20 rokoch vysvetlit vyznam POSIX v linuxe ked to aj tak nie je unix pripada mi to ako v zlej firme mas rozhranie ktore ti vobec ale vobec nevyhovuje, napriek tomu narubujes setko aby to pasovalo k tomu API, tak tomu sa zvycajne hovori prasarna a seci co s tym maju co docinenia sa to snazia obist a zalepit dalsi bypasom ...

[CIJOML]

POSIX treba proto abys prelozil kod pro jiny unix na Linuxu a naopak (kdyz budes mit dost trpelivosti a stesti)

[Karlik]

Jak jsem to pochopil, tak spis jde o to "naopak". Treba to nove ioctl by docela jiste nebranilo prelozeni kodu puvodne napsaneho pro jiny unix.

Otazka je, jestli je nutne trvat na POSIXu tam, kde je to vylozene omezujici. A dalsi veci je, ze tyhle informace se vyuziji hlavne pri psani a odladovani programu, ke koncovemu zakazniku se vlastne ani nemusi dostat. Tak proc si neulehcit zivot?

POSIX by potreboval aktualizaci. Tech pripominek k nemu se objevuje docela dost.

[CIJOML]

Protoze Linux je certifikovany drive dokonce v ramci bootu psal "POSIX conformance testing by UNIFIX" odstraneno 3. kvetna 2004

[Milan Jurik]

Jak jsem to pochopil, tak spis jde o to "naopak". Treba to nove ioctl by docela jiste nebranilo prelozeni kodu puvodne napsaneho pro jiny unix.

To je fakt. A takovych system-specific veci je spousta (jinak by se autoconf neuzivil). Jenze v tomto pripade se jedna o dost zasadni vec a zjevne ne uplne kazdy vyvojar Linuxu je uz toho nazoru, ze na ostatni "API-kompatibilni" systemy serepes. Proto by bylo zahodno takove veci nedebatovat na LKML, ale v ramci Austin group.

POSIX by potreboval aktualizaci. Tech pripominek k nemu se objevuje docela dost.

Myslite to, co se dnes nazyva Single UNIX Specification a aktualni verze vysla pred par mesici, s pravidelnymi komentari se na ni podili take Ulrich Drepper z RH?

[mimi.vx]

kompaktibilita a orenositelnost mezi ruznymi nixy ,,,,,

[e.lisak]

nejlepší návod k použití kdb k nalezení v v článku na developerWorks,

2x "v", podle mne je v textu odkazu navíc

[Robert Krátký]

Díky, opraveno.

[Filip Jirsák]

Velká číst opravdu starých věcí

číst –> část

[Milan Jurik]

Je videt, ze ValerieA odesla ze SUNu uz docela davno

[kralyk z abclinuxu]

Bzip2 je novější možnost; chvíli trvalo, než se uchytil, protože potřebné nástroje nebyly příliš široce dodávány. I přesto nyní lidé v kernel.org zvažují změnu kompresních formátů, které používají. Diskuzi rozproudila dostupnost nástroje XZ založeného na kompresním algoritmu LZMA. XZ nabízí lepší kompresi – 53 MB u 2.6.32 – ale má obvyklý problém: Nástroje nejsou ještě široce dostupné v distribucích, obzvláště v těch podnikových.

Člověk má dojem, že žijeme v době kamenný
Tomu Xz se zas až tak nedivím, ale bzip2? Ten je už nejmíň 10 (spíš ale tak 12) let v linuxu naprosto běžný... Že by v článku mluvili o době tak archaické?

Xz, se musím přiznat, neznám, ale nakoukl jsem do výchozí repo Archlinuxu a je přítomen
Čímž nechci říct, že musí být nutně v každém distru (především enterprise mají tendence být poněkud konzervativní), nicméně Arch není znám právě obrovským počtem balíků...


Jinak ale musím říct, že dnešní JN jsou skvělým počtením. Málokdy se mi stává, že bych JN pročetl fascinovaně jedním dechem. Zvlášť ty statistiky o stáří kódu jsou velmi zajímavým počtením...
(A být tak teď na linuxovém stroji, tak si kdb hned vyzkouším... :/)

[thingie]

Nj, dneska to bylo takové okecávací, snad jenom ty debuggery, jinak to do žádného tématu moc nešlo, no.

[petr_p]

Bzip2 mě taky zaskočil. Xz ale chápu, protože teprve nedávno se pohřbily lzma-utils ve prospěch xz-utils, takže teď je taková hluchá doba, kdy se mnoho nástrojů upravuje.

[cronin]

Nemam problem najst v okoli niekolko produkcnych strojov, ktorych tar stale nevie automaticky detekovat kompresiu archivu pri dekomprimacii a potrebuje explicitne pouzitie z alebo j. Takze pre mna to az take prekvapenie nie je.

[petr_p]

Cože? Tar umí detekovat kompresi? Já všude poctivě píšu -z, -j nebo --lzma.

[Käyttäjä 11133]

Ano, dělá to podle suffixu...

marek@tebook:~> tar xvf htop-0.8.3-1.el5.rf.x86_64.tar.bz2 
bzip2: (stdin) is not a bzip2 file.
tar: Child returned status 2
tar: Exiting with failure status due to previous errors
marek@tebook:~> mv htop-0.8.3-1.el5.rf.x86_64.tar.bz2 htop-0.8.3-1.el5.rf.x86_64.tar.lzma
marek@tebook:~> tar xvf htop-0.8.3-1.el5.rf.x86_64.tar.lzma 
lzma: (stdin): File format not recognized
tar: Child returned status 1
tar: Exiting with failure status due to previous errors
marek@tebook:~> 

[Käyttäjä 11133]

Respektive pro přesnost GNU Tar to dělá :)

[stativ]

bsdtar taky.

[JoHnY2]

Nejstrasnejsi je kdyz se pak clovek logne na nejaky stary solarko nebo neco podobnyho a ten jejich userland z doby kameny si porad jen na neco stezuje .

[cronin]

Aka je to verzia tar-u? Teraz som skusil oklamat GNU tar 1.15.1, a ziadna detekcia podla pripony sa nekona; spravne detekuje typ kompresie podla obsahu.