SystemTap, linuxová odpověď na DTrace

4. 3. 2009 | Jirka Bourek | Jaderné noviny | 4378×

Cílem SystemTap je poskytnout kompletní sledování produkčních systémů způsobem, který je bezpečný, neintruzivní, má (téměř) nulovou režii a umožňuje pro jakoukoliv zajímavou událost, ke které může dojít, všudypřítomné sbírání dat v celém systému.

Originál tohoto článku napsal Mark Wielaard, vyšel na LWN.net.

SystemTap byl aktivně vyvíjen několik let. Během posledního roku více než 35 lidí přispělo nějakým vylepšením. Novější změny, jako například dynamické sledování programů v uživatelském prostoru, byly, zdá se, uvedeny velmi potichu a kvůli tomu si jich uživatelé, kteří SystemTap nevyužívají extenzivně, ne vždy všimli. Tento článek se tedy dívá na to, co funguje bez nastavování, co je potřeba mít, aby věci fungovaly, na čem se pracuje a na výzvy, kterým SystemTap čelí, aby byl výkonnější a byl šířeji přijímán.

Úvod

SystemTap definuje jazyk stap, kterým uživatel definuje sondy [probe], akce a sběr dat. Překladatel SystemTap zajišťuje, že sondy jsou umístěny pouze na bezpečná místa a sondující funkce nemohou způsobit příliš mnoho režie při sběru dat. Pro dynamické sondy adres v jádře používá SystemTap kprobes. Pro dynamické sledování programů v uživatelském prostoru používá jejich bratrance uprobes [PDF]. Tím poskytuje jednotný způsob sledování a sběru dat pro pozorování celého systému. Dynamické vyhledávání pozic pro sledovací body, argumenty sledovaných funkcí a proměnných v rozsahu sledovaného bodu SystemTap řeší pomocí ladících informací [debuginfo] standardu (Dwarf), které generuje překladač.

Aby tedy distribuce GNU/Linuxu poskytly ideální prostředí pro používání SystemTapu, měly by poskytnout snadný přístup k ladícím informacím pro jádro a programy v uživatelském prostoru. To dělají téměř všechny distribuce. Jádro podporuje kprobes, které byly v jádře již několik let, a uprobes, které jsou dodávány (a automaticky nahrávány) se SystemTapem, ale které závisí na kompletním frameworku utrace, který ještě v hlavní řadě není. (Několik nejnovějších vydání v rodině Fedory včetně Red Hat Enterprise Linuxu a CentOS obsahuje ve výchozím nastavení kompletní podporu utrace.) SystemTap funguje bez ladících informací, ale rozsah sond a množství dat, které lze sbírat, jsou velmi omezené. Funguje bez podpory utrace, ale pak není možné podrobně sledovat uživatelský prostor, pouze interakce mezi ním a jádrem.

Sondy

Se SystemTapem lze použít několik variant sond [probes], ale nejzajímavější jsou sondy jádra založené na ladících informacích jaderných modulů a aplikací v uživatelském prostoru. Tyto mohou používat varianty pro funkce, výrazy nebo návratové hodnoty a zástupné znaky, například:

• kernel.function("rpc_new_task"): pojmenovaná jaderná funkce,
• process("/bin/ls")-function("*"): jakýkoliv vstup do funkce ve specifickém procesu,
• module("usb*").function("*sync*").return: každý návrat z funkce, které obsahuje slovo sync v jakémkoliv modulu, který začíná usb,
• kernel.statement("bio_init@fs/bio.c+3"): pro specifický výraz v konkrétním souboru

V závislosti na typu sondy lze přistupovat ke specifikům sledovaného bodu. Pro sondy založené na ladících informacích jsou to:

• $var pro viditelné proměnné nebo argumenty funkcí,
• $var->field pro přístup k polím struktur,
• $var[N] pro prvky v poli,
• $return pro návratovou hodnotu funkce při sledování návratu z funkce a
• metaproměnné jako $$vars, které obsahují řetězcovou reprezentaci viditelných proměnných v konkrétním sledovacím bodě.

Všechny přístupy k těmto konstrukcím jsou chráněny SystemTapem, aby se zajistilo, že nedojde k žádnému nepovolenému přístupu.

Za předpokladu, že jsou k dispozici ladící informace instalovaného programu, lze snadno získat jednoduché sledování volání [call trace] konkrétního programu, včetně všech parametrů funkcí a návratových hodnot následujícím stap skriptem:

probe process("/bin/ls").function("*").call
{
  printf("=>%s(%s)\n", probefunc(), $$parms);
}

probe process("/bin/ls").function("*").return
{
  printf("<=%s:%s\n", probefunc(), $$return);
}

Příklady dodávané se SystemTapem obsahují mnohem silnější verze, které ukazují časované grafy volání specifické pro vlákna, volitelně se zobrazením pouze potomků konkrétního volání funkce.

I když jsou konstrukce pro sledování a získávání dat mocné, vyžadují nějaké znalosti kódové základny jádra nebo programu. Vzhledem k tomu, že nás často zajímá, co se děje, a ne přesně jak, je SystemTap dodáván se "sadami sond" [tapset], což jsou pomocné funkce a aliasy pro skupiny zajímavých sond v konkrétním subsystému. Příklady zahrnují systémová volání, operace NFS, signály, sockety atd. V současnosti jsou tyto sady sond distribuovány se samotným SystemTapem, ale ideálně by každý program či subsystém měl pro zajímavé události obsahovat vlastní sadu sond, které by poskytoval správce subsystému.

Proměnné

Pouhé vypisování událostí, když se objeví, není vždy ideální. Za prvé proto, že byste mohli být zaplaveni výstupními informacemi; zadruhé vás možná zajímá jenom část daných událostí (pouze určité parametry, pouze volání, která trvají déle, než je zadaný čas, jenom pro procesy, které v daném časovém rámci provádí většinu volání, atd.). A nakonec by se zpracování všech událostí na vašem produkčním systému mohlo ovlivnit pozorování sledovaného jevu. Obzvláště když s průzkumem začínáte, nemusíte si ještě být jisti, jaké jsou zajímavé události, a můžete sledovat velmi zeširoka, abyste zjistili, co se děje.

Z tohoto důvodu jazyk stap podporuje proměnné, které lze použít jako asociativní pole, jednoduché řídící struktury a data spojující funkce. Během sledování je jimi možné získávat jednoduché statistiky s minimální režií a bez potřeby volat externí programy, které by mohly interferovat se systémem, který je sledován.

Následující skript by mohl ukazovat způsob, jakým začít pátrat po problému, kdy systém, zdá se, provádí příliš velký počet čtení. Používá sadu sond "vfs" a asociativní pole, do kterého se ukládá počet čtení, které provádí konkrétní proces se specifickým ID:

global totals;
probe vfs.read
{
  totals[execname(), pid()]++
}

probe end
{
  printf("== totals ==\n")
  foreach ([name,pid] in totals-)
    printf("%s (%d): %d \n", name, pid, totals[name,pid])
}

Toto poskytne seznam spuštěných programů a jejich PID řazený podle celkového počtu čtení vfs, ke kterým došlo, když skript běžel. Tyto nástroje v jazyce stap značně pomáhají minimalizovat režii sledovacího frameworku. Pokud byste chtěli dělat to samé prostým vypsáním každé události vfs a zpracováním výsledků Perlem, mohli byste skončit s tím, že Perl sám o sobě bude tím procesem, který provádí nejvíce volání vfs, nebo ještě hůře může Perl při zpracování megabajtů dat narušit chod systému ještě víc, čímž se ztíží určení původní příčiny problému.

Statické značky

SystemTap nyní také podporuje statické značky [static markers]. Ty umožňují správcům subsystémů označit specifické události jako zajímavé a poskytnout formátovací řetězec argumentů události tak, aby je bylo možné snadno analyzovat sledovacími nástroji. Výhoda statických značek oproti sadám sond spočívá v tom, že jsou v kódu, a tak je jednodušší je udržovat, i když pravděpodobně budete i tak chtít s nimi spojené sady sond pro nástroje, které hezky zformátují argumenty či spojí různé značky mezi sebou. Značky také mohou fungovat bez ladících informací DWARF, ztratíte nicméně možnost prohlížet lokální proměnné či parametry funkce, které značce nejsou předávány. Použít značku je možné příkazem jako tento:

probe kernel.mark("kernel_sched_wakeup")

Sada sond může k argumentům přistoupit přes $argnN a k formátovacímu řetězci argumentů značky přes $format.

Alternativní způsob, jak vložit do jádra statické značky, sledovací body [tracepoints], není zatím SystemTapem podporován. Sledovací body mají nevýhodu v tom, že vyžadují ladící informace DWARF, protože v současnosti kromě prototypů funkcí nespecifikují typy svých argumentů. SystemTap tedy v současnosti může sledovací body používat pouze s pomocí ručně psaného zprostředkujícího kódu, který je mapuje na značky.

Vývojová verze SystemTapu nedávno získala podporu pro statické značky v uživatelském prostoru. Ačkoliv SystemTap definuje svá vlastní makra STAP_PROBE pro použití v aplikacích, které chtějí přidat statické značky, je zde také alternativní sledovací nástroj Dtrace, který má pro programy vlastní způsob, jak vložit statické značky. SystemTap konvenci, kterou používá Dtrace, podporuje poskytnutím alternativního hlavičkového souboru a překladového preprocesoru, takže programy používající makra DTRACE_PROBE mohou být přeloženy tak jako pro Dtrace a jejich statické značky se objeví v SystemTapu.

Štěstí je, že různé programy mají tyto značky již definované. Například PostgreSQL obsahuje statické značky ke sledování událostí na vyšší úrovni, jako jsou transakce a zamykání databáze. V současnosti je proces překladu takových programů nutné ručně upravit, ale další verze SystemTapu bude obsahovat skripty, které tento proces zautomatizují.

Podpora

I když SystemTap funguje na distribucích GNU/Linuxu, které ho podporují, dobře, je potřeba překonat několik záležitostí, aby se více rozšířil a mohlo ho používat více uživatelů. Tyto záležitosti přitom překračují práci na samotném SystemTapu - vzhledem k tomu, že cílem je poskytnout možnost sledování celého systému, je potřeba udělat nějakou práci na celém GNU/Linuxu. Také je potřeba lepší integrace do více distribucí poskytující výchozí instalaci SystemTapu a sad sond, snadného přístupu k ladícím informacím pro hloubkové zkoumání, binárky překládané s podporou značek pro události na vyšší úrovni atd. Dvě hlavní záležitosti, které musí SystemTap vyřešit, aby byl silnější a snadněji použitelný na jakékoliv distribuci, jsou ladící informace a lepší podpora v jádře.

Velká část schopností SystemTapu pochází z faktu, že umí použít ladící informace DWARF z jádra a aplikací a tak provádět velmi detailní průzkum. Tyto schopnosti ale přichází za určitou cenu, protože ladící informace jsou často rozsáhlé - například u Fedory je balíček s ladícími informacemi jádra mnohem větší než samotný balíček s jádrem. Jedno jednoduché řešení by bylo rozdělit balíček s ladícími informacemi na DWARF soubory a soubory se zdrojovým kódem, které jsou potřeba pro debugger, ale ne přímo pro sledovací nástroj, jako je SystemTap. Fedora to plánuje udělat v příštím vydání. Tým elfutils také pracuje na frameworku pro transformaci a kompresi Dwarf, který by šlo použít pro postprocesor výstupu překladače.

SystemTap má občas stejné problémy, které se mohou objevit u debuggeru: překladač optimalizoval kód, ale zapomněl, kam po optimalizaci vložil určitou proměnnou. A samozřejmě jde vždy o proměnnou, která vás nejvíce zajímá. Alexandre Olive pracuje na vylepšení ladících informací o lokálních proměnných v GCC. Jeho větev GCC sledování proměnných přes přiřazení [PDF] má za cíl vylepšit ladící informace označením přiřazení v počátečních fázích procesu překladu a udržováním těchto značek přes všechny optimalizační průchody, takže je vždy možné přesně sledovat proměnné i v optimalizovaném kódu.

A nakonec, pracuje se na SystemTap "klient a server", který by bylo možné použít na produkčních systémech, na kterých nemusíte chtít instalovat ladící informace ani nástroje. Pak můžete nastavit vývojového klienta, který bude mít stejnou konfiguraci jako produkční systém, ale navíc překladač SystemTap a všechny ladící informace. Na tomto klientovi potom můžete vytvořit a testovat své skripty. Konečný výsledek této práce potom lze použít na barebone produkčním serveru.

Utrace

Většina SystemTapu, jako je podpora kprobes, je udržována v linuxovém jádře v upstreamu, ale některé věci stále chybí. To vede k tomu, že distribuce musí přidávat patche do jádra, obzvláště když chtějí podporovat sledování v uživatelském prostoru. Konkrétně v upstreamu stále chybí framework utrace. Během několika posledních vydání jádra byly začleněny jeho různé části, včetně utrace frameworku user_regset, který vytváří rozhraní pro kód přistupující k pohledu uživatelského prostoru na jakýkoliv stav specifický pro stroj. Také byla začleněna práce na sledovacích háčcích [tracehook], která poskytuje framework pro sledování celého uživatelského procesu. Současný framework utrace sedí nad těmito komponentami; rozhraní ptrace() je implementováno jako klient utrace. Cokoliv, co mění implementaci ptrace, je záludná záležitost, takže existuje rozsáhlá sbírka testů ptrace, která zajišťuje, aby se nic nerozbilo. Jeden nápad, který je zvažován, je začlenit utrace do upstreamu ve dvou fázích: nejprve by se použití utrace a ptrace na jednom procesu vzájemně vylučovalo. To by následně vydláždilo cestu, aby se do upstreamu nejprve dostalo čisté utrace a správná kooperace s ptrace by přišla jako druhá.

Tento přístup by také poskytl uprobes, které závisí na frameworku utrace, cestu k zaslání do upstreamu. Komponenty uprobes, jako je vkládání a odstraňování breakpointů či infrastruktura pro krokování, jsou taktéž potenciálně použitelné pro další sledovací nástroje a debuggery v uživatelském prostoru. Jako u utrace je jednou z možností rozdělit tyto části uprobes tak, aby je mohlo používat několik klientů pomocí sdílené vrstvy breakpointů v uživatelském prostoru (ubs). S několika klienty používajícími stejnou vrstvu by akceptování upstreamem mohlo být snadnější.

Jedním kandidátem využívajícím jak utrace, tak vrstvu uprobes je kromě SystemTapu Froggy, který poskytuje alternativní ladící rozhraní pro ptrace. Projekt GDB Archer by rád sloužil jako testovací lavice pro Froggy, přičemž jeho autoři doufají, že tím dosáhnou větší robustnosti GDB, když bude spojen s libpython, který se používá pro GDB skriptování.

Začlenění do jádra

V minulosti byli správci jádra ke sledování skeptičtí, což vyústilo v to, že byly sledovací frameworky jako dprobes, LTT a části SystemTapu udržovány mimo hlavní strom jádra. Nyní, když v jádře skutečně není nedostatek možností sledování, lidé jako Ted Ts'o urgovali programátory SystemTapu, aby co nejvíce své práce tlačili do upstreamu. Ted také povzbudil vývojáře, aby se na programátory jádra více zaměřili jako na prvořadé zákazníky, místo aby se zabývali výhradně použitím na celém systému v produkčním nasazení. Vývojáři SystemTapu uspěli v tom, že jejich podpora modulů "prostě funguje" s jakýmkoliv jádrem. V současnosti funguje s verzemi jádra mezi 2.6.9 a nejnovějším 2.6.28; také je pravidelně testován oproti nejnovějším -rc jádrům. Možná ale byli úspěšní až příliš, protože být tato aktivita viditelnější, znamenalo by to větší publicitu. Jako reakce se nyní objevila chyba SystemTapu nazvaná "zajistit, aby byli jaderní vývojáři byli spokojení", která žádá častější zasílání zpráv do hlavní jaderné mailové konference, vylepšení používání ladících informací, jak je popsáno výše, a priorita v tlačení utrace a uprobes do upstreamu.

Stále zbývá nějaká práce, ale během několika posledních pár let se zkušenosti se sledováním a laděním v GNU/Linuxu stále zlepšují. Doufejme, že brzy všechny tyto části zapadnou na místo a poskytnou vývojářům dostatečně příjemné prostředí nejenom pro ladění na vývojových systémech, ale také pro neinvazivní sledování na produkčních systémech.

---

O autorovi: Mark Wielaard je Senior Software engineer v Red Hatu pracující ve skupině pracovních nástrojů [Engineering Tools], která pracuje na SystemTapu.

       

Komentáře

[finn]

Obávám se, že článek je pro nezasvěceného člověka nečitelný a zasvěcenec ho buď nebude potřebovat číst, nebo si přečte originál.

1. Chybí nějaký obecnější úvod. Obyčejní uživatelé linuxu, kterých je na tomto serveru myslím drtivá většina, a na které je asi článek zaměřen, nejspíš netuší, co je to DTrace. Takže přirovnávat hned v nadpisu SystemTap k DTrace se mi zdá nevhodné.
   Článek (aby byl čitelný publikem, které se na tomto serveru schází), by např. mohl začít příkladem z praxe — k čemu se třeba dá SystemTap použít. Stačil by jeden odstavec a hned bych měl jasno, jestli stojí za to, číst celý článek.
   Pozn: ano, hned v úvodu je věta „Cílem SystemTap je poskytnout…“, ale ta mi – jako laikovi – problém vůbec neosvětlila.
   Příkladem budiž věta „Překladatel SystemTap zajišťuje, že sondy jsou umístěny pouze na bezpečná místa a sondující funkce nemohou způsobit příliš mnoho režie při sběru dat.“ – jaký překladatel? Není to překladač? Ta věta je v úvodu (sic!), ale ani po několikerém jejím přečtení nevím, která bije. Úvod má obsahovat jemný úvod do problematiky, ne chrlení dosud nevysvětlených pojmů (překladatel, sondy, …).
2. Obecnou vlastností překladů na tomto serveru je jejich určitá „neučesanost“. To je pochopitelné např. u Zpravodaje o víně nebo u Jaderných novin, ty jinak než překladem řešit nejdou, ale u tohoto článku by prospělo, kdyby nebyl pouhým překladem, ale autor jej napsal svými slovy, tak jak mu zobák narostl.
   • „Pro dynamické sondy adres v jádře používá SystemTap kprobes.“ Kdo používá koho?
   • „lze snadno získat jednoduché sledování volání [call trace] konkrétního programu“ vs. „lze snadno jednoduše sledovat volání konkrétního programu“
   • „…systém, zdá se, provádí příliš velký počet čtení.“ – příliš doslovný překlad z anglického originálu. Tuším že to byl pan Pavel Eisner, který vtipně kdesi napsal, že provádět můžete turisty po Karlštejně. Nezní věta „…se zdá , že systém příliš často čte.“ přeci jen líp?
   • „…nazvaná "zajistit, aby byli jaderní vývojáři byli spokojení"“ V originále se píše Make upstream kernel developers happy, což bych chápal spíše jako výzvu, tedy „Dělejte jaderným vývojářům radost.“
   Nemá cenu zabíhat do dalších a dalších detailů, chtěl jsem uvést jen pár příkladů. Překladateli zkrátka nestačí umět se domluvit dvěma jazyky, v tomto případě česky a anglicky. Překladatel musí mít cit pro jazyk a to hlavně (!) pro ten, do nějž je překládáno. A to je dar, kterým jsou obdařeni jen někteří (a já se mezi ně nepočítám).

Závěrem: nechci aby můj příspěvek vyzněl jako hanobení práce, kterou si s překladem jeho autor dal, z vlastní zkušenosti vím, že to není práce na půl hodiny. Ale pokud by autor napsal článek na stejné téma z vlastní hlavy, věřím, že výsledek by byl mnohem lepší.

Poznámka pro korektora: informace jsou ladicí, nikoliv ladící (tj. jsou to informace určené pro ladění, ne informace, které by aktivně něco ladily). Stejná poznámka se vztahuje k řídícím strukturám, které jsou ve skutečnosti řídicí.

[trekker.dk]

Příkladem budiž věta „Překladatel SystemTap zajišťuje, že sondy jsou umístěny pouze na bezpečná místa a sondující funkce nemohou způsobit příliš mnoho režie při sběru dat.“ – jaký překladatel? Není to překladač?

Translator je podle mě překladatel. (A nebo ještě jinak - translator není compiler, takže jsem nechtěl použít slovo překladač.)

[jan]

-el je zivotna koncovka. Sice ji muzou mit i nezive veci, ale neni to moc bezne a spise v ustalenych spojenich. Takze jestli ten preklad neprovadal trpaslik zavreny v pocitaci, tak je to IMHO prelozeno nevhodne.

[dad]

to vsechno co pisete je pravda a ja mohu potvrdit, ze jsem toho moc nepochopil. Samozrejme, ze me nachytalo to DTrace, kazdy o tom mluvi, nekteri kvuli tomu dokonce kupuji Solaris, takze je vitana kazda prilezitost se neco dovedet.

Presto si ale myslim, ze vase opravnena kritika je zbytecna. Nemluvite o nicem jinem, nez o kvalite. A na tu dnes sere pes. Proto je ten preklad v duchu doby a jinak to ani nelze, globalizace pohrbila kvalitu a proto ji nikdo nemuze dodavat - ekonomicky to proste nelze, kdo by to platil?

Ale to neznamena, ze je zivot horsi.

[RoJ]

Solaris nikdo nekupuje - je zdarma . Az podpora je za penize.

[bodlinka]

Solaris je zadarmo?

Od kedy? Nieco som zaspal?

Doteraz som mal dojem, ze zadarmo je len OpenSolaris.

[Radek Hladik]

Já se musím článku a autora zastat. Popisuje zajimavé funkce systemtapu a prostě jde o článek pro pokročilé. Všechny články na abíčku nemusí být ve stylu LVM pro začátečníky po patnácté (bez urážky). Pokud někdo chce vědět přesně, co to ten system tap je, tak stačí kliknout na odkaz v prvním odstavci:

SystemTap provides free software (GPL) infrastructure to simplify the gathering of information about the running Linux system. This assists diagnosis of a performance or functional problem. SystemTap eliminates the need for the developer to go through the tedious and disruptive instrument, recompile, install, and reboot sequence that may be otherwise required to collect data.

SystemTap provides a simple command line interface and scripting language for writing instrumentation for a live running kernel...

Naopak místo úvodu, postupu instalace a pár pěkných "screenshotů s výstupem" článek popisuje obecnější principy fungování a nějaké podpokličkoidní věci. Koneckonců dokument Beginner's  Guide jsem na odkazovaném webu našel na asi 4té kliknutí. O systemtapu stejně jako o Dtrace jsem měl poměrně povrchní povědomí (= jde o systémy na analýzu toho co a jak a jak dlouho systém/program dělá) a po přečtení článku jsem získal lepší představu o tom, co to asi umí a jak se to dá použít. Teď už jen zbývá přečíst ten Begginer's guide a zkusit si to na vlastní kůži. Ale představa, že pomocí zmíněných věcí budu schopen kouknout, co zrovna dělá PostgreSQL, co zpracovává a proč sakra zase žere 100% na čtyřech procesorech, když dotazy mají být poměrně jednoduché, a to bez bez úpravy apliakce, která databázi používá, se mi docela zamlouvá...

[finn]

Obávám se, že polemizuješ s věcmi, které jsem nenapsal.

1. Nikde nepíšu, že mi vadí, že jde o článek pro pokročilejší uživatele. To naopak vítám. Ale každý slohový útvar musí nějak plynout – od úvodu až k závěru. A tady mi úvod chybí.
2. Pokud kliknu na odkaz v prvním odstavci, dostanu se na anglicky psanou stránku. Pak jsou možné dvě varianty: buď anglicky neumím a je mi to k ničemu, nebo anglicky umím a nepotřebuji tu mít přeložený tento článek, stačí zprávička o tom, že na LWN vyšel článek o ST.
3. O postupu instalace a screenshotech jsem se nikde ani náznakem nezmínil. Takže ještě jednou: článek rovnou od začátku předpokládá, že máte nějaké povědomí o tom, co ST je, ale obsah článku tomu neodpovídá – ten je naopak určen lidem, kteří se ST nemají žádné zkušenosti.
4. Také jsem psal o těžkopádnosti překladu. S tím souvisí zhoršená čitelnost článku, příklady jsem uvedl.

Takže souhrnem: jsem rád, že vyšel článek o ST, ale kritizuji to, jakým způsobem byl napsán (což z mého pohledu snížilo jeho kvalitu).

[Radek Hladik]

Nepolemizuju přímo s tím, co jsi napsal, spíše jsem psal vlastní názor opačného vyznění (i komentář jsem psal jako samostantý, ne jako odpověď). Protože se mi článek líbil, tak bych byl rád aby, pod ním byly i pozitivní komentáře.

Shodnem se na tom, ze nekteré překaldy jsou těžkopádné. Asi i na tom, že se "jen" jedná o překlad z angličtiny, ale nesouhlasím s tím, že by článek měl mít velký úvod a tak. Máme přeci hypertext, linků je v článku poměrně dost a není potřeba ho jako v tištěném médiu přečíst odshora dolů. Prostě čtu, pokud narazím na něco, co neznám, tak buď je tam odkaz nebo mám po ruce wikipedii, google,... Prostě článek obsahuje sesumírované nějaké informace a ostatní buď znám nebo si je musím dohledat. A pokud někdo neumí alespoň na tolik anglicky, aby nepřečetl onen zmiňovaný popis, tak je to spíš jeho problém. Článek je zaměřen na programátory a systémové administrátory a řekl bych, že takováhle úroveň angličtiny je téměř nutností. Ale i tak mám pocit, že pokud takový člověk místo kliknutí na odkaz použije vyhledávání tady na abíčku, tak docela něco najde. Sice s větší námahou, ale najde.

Podle mně se jedná o poměrně novou technologii a zajímavých informací o ní je poskrovnu, takže je potřeba zpracovávat všechny informace, ikdyž nejsou třeba krásně předpřipravené. Na VŠ jsem vystudoval předmět o XML, který se zaobíral tak novými technologiemi, že na to nebyla skripta, přednáška vypadala jak seznam odkazů na internet+debata na všemožná témata a člověk strávil nejvíc času pročítáním všeho možného. Ale člověk se naučil pracovat s informacemi tak, aby si dal dohromady různé informace z různých zdrojů. Dalo to sice práci, ale človek nemusel čekat, až/jestli to někdo udělá za něj a vydá článek, který to všechno sesumíruje.

[vencour]

Info o dtrace jsem našel na wiki. Ok, časem se k tomu rád vrátim. Zajímalo by mne, kolik lidí s tim pracuje, koho to zajímá, vývojáře? Správce?

[Dtrace]

Nejsem proti vlastní implementaci System tab ale lepší by bylo a v to doufám že Opensolaris -> GPL3, Linux -> GPL3 a potom by nebranilo nic v portaci Dtrace a ZFS na linux

[geebranz]

approved!

www.storageshedschattanoogatn.com