Jaderné noviny - 20. 6. 2007

16. 7. 2007 | Robert Krátký | Jaderné noviny | 5511×

Aktuální verze jádra: 2.6.22-rc5. Citáty týdne: Con Kolivas, Bartlomiej Zolnierkiewicz. Další citáty týdne - obrazy z války (slov). btrfs a NILFS. Jak získat zprávy z jádra.

Obsah

• Aktuální verze jádra: 2.6.22-rc5
• Citáty týdne: Con Kolivas, Bartlomiej Zolnierkiewicz
• Další citáty týdne - obrazy z války (slov)
• btrfs a NILFS
• Jak získat zprávy z jádra

Aktuální verze jádra: 2.6.22-rc5

Aktuální předverze je 2.6.22-rc5, vydaná 16. června. Obsahuje hodně oprav - takže si Linus trochu postěžoval, že je i takto pozdě ve vývojovém cyklu začleňováno tolik věcí. Vizte podrobnosti v dlouhém changelogu.

Od vydání -rc5 bylo do hlavního git repozitáře přidáno jen několik patchů.

Během minulého týdne nevyšla žádná nová verze stromu -mm ani starších jader. Všichni měli zjevně plné ruce práce s "diskuzí" o GPLv3.

Citáty týdne: Con Kolivas, Bartlomiej Zolnierkiewicz

Takže mám dost. Končím tady provždycky. Chci odsud vypadnout dřív, než mě to natolik otráví, že bych nakonec začal používat Windows. Občas si možná trochu pohraju s kódem v uživatelském prostoru, ale jádro je pro mě černá díra, do jejíhož horizontu událostí už nechci nikdy vstoupit.

-- Con Kolivas

Z toho příběhu plyne poučení, že se v současné době prostě nevyplatí kontrolovat cizí kód [code review]. Z osobního hlediska je výhodnější počkat, až se do jádra dostane patch plný chyb, a pak ty problémy opravit (aspoň si vás někdo všimne). Aby se to změnilo, měli bychom klást větší důraz na důležitost kontroly kódu tím, že budeme "odměňovat" lidi, kteří tomu věnují svůj čas, a "odměňovat" vývojáře/správce, kteří budou brát kontroly kódu vážně.

-- Bartlomiej Zolnierkiewicz

Další citáty týdne - obrazy z války (slov)

Jak je vidět, v nedávném GPLv3 flamewaru o 1000 zprávách je jen málo věcí, které by ospravedlnily tak velké plýtvání bity. Tady je pár ukázek.

Myslím, že Open Source komunita (a FSF také) by udělala mnohem lépe, kdyby se *nezaměřovala* na "právní pravidla" ohledně toho, co se smí a nesmí dělat, a raději vynaložila větší úsilí na ukazování lidem, že celá ta "Open Source" věc vlastně funguje. A já jsem přesvědčen, že právě to Linux posledních deset let dělá!

-- Linus Torvalds

Ale pokud tou otázkou myslíš "řekl bys, že je GPLv3 v pohodě bez toho nového povídání v sekci 6 o 'spotřebitelských zařízeních'?", pak by odpověď byla ano, myslím, že současný návrh GPLv3 vypadá, až na tu drobnost, dobře.

-- Linus Torvalds

Nerozumím tomu, jak můžeš tvrdit, že výrobce omezuje tvoje svobody. _Ty_ jsi se rozhodl, že půjdeš a produkt si koupíš, i když jsi věděl, že se výrobce nepřetrhne, aby ti usnadnil zařízení hacknout. V mnoha případech ani výrobce nemá na vybranou (napadají mě třeba kanály a certifikace 802.11b, GSM atd.), jestli věci uživatelům otevřít. A změna licence s tím nic nevykouzlí.

-- Paul Mundt

V tom, co dělá TiVo, vidím daleko více zákazů než svobod. Je důležitější umožnit jediné firmě kvůli jejímu obchodnímu modelu vydávat zákazy, nebo zachovat ducha hackování a sdílení, díky kterému se daří svobodnému softwaru a Linuxu? Copak myslíš, že by byl Linux úspěšný, kdyby měly počítače zámky, které by lidem bránily, aby na nich Linux upravovali?

-- Alexandre Oliva

Takže místo abych TiVo považoval za "zlo", beru ho jako včelu dělnici, která sice nikdy nikomu své geny nepředá, ale stejně pomůže lidem, kteří ty geny předají: jádru (do jisté míry - ani ne kvůli samotným patchům, ale kvůli rozšíření obzorů v oblasti PVR) a projektům jako MythTV (opět ne kvůli patchům, ale protože lidem pomohl lépe chápat dané problémy).

-- Linus Torvalds

Myslím, že RMS by měl akceptovat skutečnost, že většina kódu byla napsána, aniž by lidé souhlasili s jeho ideologií. A měl by přijmout _zodpovědnost_, kterou svým géniem nebo náhodou (vyberte si) získal, a pokusit se _pochopit_, jak ti lidé uvažují - místo aby se snažil prosadit vlastní plány.

-- Ingo Molnar

Dovolím si nesouhlasit. Přijetím _jeho_ licence jsi přijal i jeho postoj. Pokud se ti to nelíbí, vyber si jinou licenci (což samozřejmě můžeš).

-- Michael Gerdau

GPLv2 neříká, že se máš stát otrokem RMS a ve všem jej následovat a se vším souhlasit. Fakt. Musel jsi číst nějakou jinou verzi (třeba nějaký počáteční nevydaný návrh?).

-- Linus Torvalds

Co je tady, kruci? Konference linux-kernel nebo Nikajský koncil?

-- Al Viro

btrfs a NILFS

Skoro přesně před rokem, zatímco vývojáři diskutovali o změnách souborového systému ext3, napsal Andrew Morton:

Přesto je pravda, že linuxové souborové systémy začínají být trošku rozvrzané a blížíme se k okamžiku, kdy bychom mohli těžit z nového, který začne na zelené louce. Mohl by být založen třeba na reiser4 - nedíval se na něj někdo? Už tu leží pár let.

Reiser4 asi ještě bude nějakou dobu ležet bude. Ale to neznamená, že by nebyl zájem o vytváření zajímavých nových souborových systémů. V květnu jsme mluvili o LogFS, ale není to jediný nováček na scéně.

Asi nejzajímavější účastník je btrfs, který Chris Mason oznámil 12. června. Jde o úplně nový souborový systém určený pro standardní rotační ukládání s několika zajímavými funkcemi:

• Btrfs je plně založen na rozsazích [extents], což znamená, že může velké soubory ukládat daleko efektivněji než ext3 (vyvíjený souborový systém ext4 podporu rozsahů má). Souborový systém založený na rozsazích nepotřebuje ty dlouhé seznamy ukazatelů na jednotlivé bloky obsažené v souboru; místo toho jsou dohromady sledovány skupiny po sobě jdoucích bloků ("rozsahů"). U velmi malých souborů uloží btrfs přímo obsah souboru v rámci struktury rozsahů, takže není nutné samostatně alokovat blok.


• Souborové systémy mohou být rozděleny na "podsvazky" [subvolumes], z nichž každý má vlastní adresářovou strukturu a diskovou kvótu. Podsvazky lze použít k členění oddílu s btrfs, ale mají ještě jedno zajímavé využití...


• Btrfs umí pořizovat snímky [snapshotting] - zmrazení stavu souborového systému v daný okamžik. Snímky jsou podsvazky; může z nich být vytvořena samostatná a nezávislá adresářová struktura, kterou lze procházet nezávisle na "živém" souborovém systému. Zajímavé je, že i snímky jsou živé - mohou být upravovány a lze z nich vytvářet další snímky.


• Podpora podsvazků a snímků si v btrfs vynucuje strukturu copy-on-write [kopie při zápisu]. Je-li do daného rozsahu zapisováno, bude zkopírován a nová data budou zapsána do kopie. Rozsahy mají referenční čísla; například vytvoření snímku způsobí navýšení referenčního čísla. Když je upraven rozsah, který je jak ve snímku, tak v "opravdovém" souborovém systému, bude zkopírován pro měněný podsvazek, ale pro ten druhý zůstane na místě a nezměněn. Pokud je rozsah nakonec odstraněn, dojde ke snížení všech příslušných referenčních čísel a nevyužité rozsahy budou vzaty zpět.


• Díky mechanismu podsvazků a snímků není potřeba samostatná žurnálovací funkce. Změny souborového systému lze změnit na transakční pouhým vytvořením snímku, který existuje jen do chvíle, kdy je transakce dokončena.


• Tento souborový systém provádí kontrolní součty úplně všeho - dat i metadat. Může tedy za běhu odhalit mnoho druhů poškození.

Rychlá kontrola souborového systému je pro btrfs důležitým designovým cílem. Data a metadata jsou uspořádána způsobem, který offline checkeru [kontrolnímu programu] umožňuje číst disk téměř sekvenčním způsobem. To by mělo proces výrazně urychlit; kontrola souborového systému obvykle znamená velké množství vyhledávacích operací. V plánu je i online kontrola, která však zatím nebyla implementována; jakmile bude fungovat, mohlo by se úplně zrušit kontrolování při připojování.

Tento souborový systém je zatím v rané fázi vývoje - nedoporučuje se pro data, která byste si chtěli ponechat. Zatím nebylo provedeno moc výkonnostních testů a je pravděpodobné, že ještě dojde k mnoha optimalizacím. Celý souborový systém je například v tuto chvíli chráněn jediným mutexem, což je řešení, které by si pravděpodobně na moderních systémech se 4096 procesory moc dobře nevedlo. Také je potřeba se postarat o několik detailů - třeba by neměl "oopsovat", když dojde místo, je potřeba přidat podporu přímého I/O, zápisu přes mmap(), rozšířených atributů atd. Ale btrfs se podařilo upoutat pozornost, takže pokud dostojí nadějím, které jsou do něj vkládány, mohli bychom v budoucnu používat btrfs systémy.

(Další informace na stránce projektu btrfs.)

Druhý nedávno představený souborový systém je NILFS, který je teď ve druhé verzi. NILFS (New Implementation of a Log-structured Filesystem) je souborový systém strukturovaný jako log - úložné médium je bráno jako kruhový buffer a nové bloky jsou vždy zapisovány na konec. Tyto souborové systémy obvykle dosahují dobrých výsledků v testech, které měří výkon při zápisu, protože všechny zápisy jsou prováděny na souvislé bloky; výkon při čtení už tak dobrý není. Souborové systémy strukturované jako log se často používají na flash zařízeních, protože přirozeně zajišťují rovnoměrné opotřebení. Vypadá to však, že NILFS není určen pro flash.

Místo toho klade NILFS důraz na snímky. Přístup, který využívá strukturu jako log, je specifickou formou copy-on-write, takže se nabízí vytváření snímků. Vývojáři NILFS mluví o vytváření "souvislých snímků", které lze použít pro záchranu při problémech způsobených uživatelem - typu "rm -r". NILFS je prý škálovatelný díky 64bitovým datovým strukturám, ale podpora architektury x86_64 je kupodivu na seznamu zatím nesplněných úkolů. Zatím také nepodporuje rozsahy.

(Další informace na nilfs.org.)

Jak získat zprávy z jádra

Obecně platí, že uživatelé Linuxu o jádře spíše nechtějí vědět. Pokud je všechno v pořádku, tak fungují připojená zařízení, běží programy a jádro to všechno potichu zařídí. Když se však vyskytne problém, bývá nutné pročítat zprávy, které jádro posílá. Tyto zprávy dávají smysl vývojářům, kteří je napsali, ale pro zbytek světa už tak zřejmé nebývají. Neal Stephenson ve svém příběhu Na počátku byla příkazová řádka říká, že jaderné zprávy jsou stejně "zlověstně nečitelné jako graffiti tagy". Pro vývojáře jádra je nejčastěji hodnota jaderné zprávy v tom, že může určit, která část kódu si stěžuje - a z toho lze odvodit samotný problém.

Pro běžné uživatele je však těžší jaderné zprávy takto používat - a ti, kteří nemluví anglicky, to mají ještě horší. Není tedy překvapivé, že se čas od času objeví diskuze na téma vylepšení zpráv.

Reformátoři zpráv mají většinou dva cíle:

• Chtěli by, aby měla každá zpráva přiřazen unikátní identifikátor. Připomíná to VMS nebo operační systémy IBM, které identifikátory zpráv používaly desítky let. Hlavním smyslem identifikátorů zpráv je to, že administrátor systému (nebo člověk z podpory, kterému zavolal) může identifikátor vyhledat v manuálu a zjistit, co ta zpráva doopravdy znamená. Různé starší operační systémy byly dodávány s příručkami o zprávách, které na polici zabíraly pořádný kus místa; obsahovaly (poměrně) podrobná vysvětlení problémů a návrhy řešení.


• Je mnohem jednodušší spravovat překlady zpráv, které mají unikátní identifikátory. Linuxový systém, který by uměl podávat zprávy v různých jazycích, by byl pro potenciální uživatele přístupnější.

Potíž je samozřejmě v tom, že přiřazení identifikátorů ke zprávám je pořádný kus práce. V jádře jsou desítky tisíc volání printk(); každému z nich je potřeba přiřadit identifikátor a změnit kód. S každou novou verzí jádra přibývají - ve velkých počtech - nové zprávy. Snadno si lze představit, jak rychle by vývojáře začalo otravovat přiřazování identifikátorů. Z těchto důvodů Linus dříve návrhy na vylepšení zpráv odmítal.

Ale je to stejně zpátky. Japonští uživatelé, kteří mají potíže s podporou Linuxu, navrhli nový přístup. Každá jaderná zpráva by měla přiřazeno jméno komponenty a číslo. Komponenta by byla určena definicí v souboru:

    #define KMSG_COMPONENT "railgun"

Volání printk by pak byla upravena tak, aby obsahovala číslo zprávy:

    printk(KMSG_ERR(100) "Railgun omylem vystřelila - pardón\n")

Výsledkem by byla zpráva, které by předcházel řetězec railgun.100:, což by umožnilo přeložení zprávy a také vyhledání v manuálu. Aby se zaručilo, že bude nějaká dokumentace opravdu k dispozici, vyžaduje návrh dokumentaci přímo ve zdrojovém kódu; asi takto:

    /**
     * message
     * @100: 
     *
     * Popis:
     * Railgun omylem vystřelila, protože uživatel
     * nespecifikoval žádnou akci.
     *
     * Uživatelská reakce:
     * Obsluha by si měla dávat pozor, aby stála bokem.
     */

Skripty kerneldoc by byly aktualizovány, aby posbíraly všechny tyto zprávy a vyrobily z nich tisknutelnou příručku. Další nástroj by kontroloval zdrojové soubory a upozorňoval na zprávy, u kterých by chyběl popis.

Podobná schémata byla již v minulosti kritizována a totéž se stalo i tentokrát. Přidaná práce, která vyplývá z takového dokumentování zpráv, je pro některé vývojáře příliš; David Miller to vyjádřil trefně:

Řekl bych, že moje reakce na něco takového, pokud by se to do jádra dostalo, by byla asi taková, že bych přestal psát kód, který podává užitečné zprávy, protože muset ho ještě takto dokumentovat je příliš práce, takže by mi to ani nestálo za to.

Obtížné by bylo také aktualizování zpráv - kód se často mění, aniž by byly změněny i okolní komentáře; není důvod se domnívat, že by jaderné zprávy byly výjimkou.

Andrew Morton místo toho navrhl řešení, které by vývojáři mohli spíše akceptovat. Přidala by se nová podoba printk(), která by pracovala s ID zpráv (v zatím neurčeném formátu). ID by bylo vypsáno společně se zprávou, ale všechno ostatní - překlady, popisy, upřímné soustrasti atp. - by bylo v databázi mimo jádro.

Klíčové je, že by se od vývojářů neočekávala jakákoliv práce s touto databází - dokonce ani s jadernými zprávami. Místo toho by byl "tým pro jaderné zprávy", který by měl za úkol tyto informace udržovat. Čas od času by se někdo z týmu podíval na nový kód, přidal potřebná ID a poslal správci patch. Pokud by o to sami neměli zájem, nemuseli by se tohoto procesu vývojáři vůbec účastnit.

I tento návrh má své nedostatky; jedním z nich je to, jak by byl tým starající se o zprávy financován (nebo jinak motivován). Dopad by však mohl být tak malý, že by to komunita mohla přijmout. Jednoho dne si možná i uživatelé Linuxu budou muset na poličkách vyhradit místo na pořádné manuály o zprávách.

       

Komentáře

[freshmouse]

A já mám jsem přesvědčen, že právě to Linux posledních deset dělá!

[freshmouse]

... tím jsem jen chtěl říct, že tam je asi něco špatně (v té větě).

[Robert Krátký]

Díky, dovtípil jsem se (a hned také opravil).

[Prcek]

Tak nevim... A já mám jsem přesvědčen, že právě to Linux posledních deset let dělá! Tam je ted

[Robert Krátký]

Nedaj pokoj a nedaj pokoj

Koho by napadlo, že tam jedno slovo chybělo a druhé přebývalo...

[8an]

Railgun není žádné "železniční dělo": http://en.wikipedia.org/wiki/Railgun

Ale nenapadá mě jak to přeložit, myslím že jsem to nikdy přeložené neviděl.

[Michal Kubeček]

Taky mne ten překlad natolik překvapil, že jsem raději zapátral ve slovníku i po webu, jetli to náhodou není pravda. Ale vypadá to spíš na další příklad zrádnosti překladů odborných termínů za každou cenu…

[Robert Krátký]

Abyste se nepicli, pánové

Zas tak moc odlišné od http://en.wikipedia.org/wiki/Railway_gun to není.

[Michal Kubeček]

Uznávám, kdybych nehrál Quake2, asi by mi to tolik nápadné nebylo… :-)

[trekker.dk]

Když už jsme u toho, v Enemy Territory je Railgun název mapy s Railway gun, takže pro někoho jsou tyto pojmy volně zaměnitelné

[Robert Krátký]

Quake neznám, takže jsem si okamžitě vybavil obrovské kanóny z 2. světové války. A i když mě mohlo napadnout, že "rail" není "železnice", tak protože jsem nečul žádnou zradu, blíže jsem to nezkoumal.

[Martin]

A. Schwarzenegger ve filmu Likvidátor:

hrdinka: ... pulzní magnetická zbraň. likvidátor: To je vlaková puška! Nejmenší co znám, montují do bitevních lodí!

[Creator of Myths]

Ja byl vzdycky presvedceny, ze rika "tlakova".

[hydrandt]

[trekker.dk]

Když se ve filmu objeví něco takového, většinou jdu pryč.

Nicméně bych se chtěl živit jako překladatel pro televizi. Skoro každej den má člověk možnost vidět, že není potřeba umět jazyk, stačí si dobře vymýšlet.

[Gilhad]

Ja zas videl nadherny preklad: " ... ty dnesni ultrafialove hry ..." (v anglictine ultraviolent - super nasilne) ...co jen dokaze jedine pismenko

[Zdenek Sl]

Hned jak jsem uvidel ten obrazek na Wikipedii, tak se mi okamzite vybavil preklad "Elektromagneticke delo". (Cauldron Spellcross) Popis teto zbrane je naprosto presny .

[zelial]

ja nekde cetl o kolejkove a kolejnicove pusce. teda ne ze bych tu tyhle preklady prosazoval. zlaty railgun!

[llib]

Já měl zato že se to překládá jako řetězové/á dělo/puška.

[Cubic]

to je zase chain gun pravdepodobne kanon s revolverovym zaverem

[trekker.dk]

Obvyklejší překlad pro chain gun je rotační kulomet.

[nonsense]

joj, pánové, všem děkuji za osvětu, doteď jsem si myslel, že se jedná o novou, lekařské vědě zatím neznámou, venerickou chorobu...

[Cubic]

obvykly preklad mozna ano, ale kdyz uz jsem se ted podival do wikipedie tak tam pisou:

It is a common misnomer to refer to Gatling guns (rotary cannons) as chain guns; even in some video games, such as Wolfenstein 3D and Doom, the player carries a minigun referred to as a chain gun. In fact, most Gatling-type guns—weapons such as the M61 Vulcan, the M197, the GShG-7.62, the M134, and the XM214—are externally-powered but are not chain guns.

ikdyz wikipedia taky neni vsevedouci a neomylna

[Jan Olšan]

No, já nevím, ale pod chaingun se myslí spíš to, že automatická střelba funguje nikoliv na principu energie zpětného rázu nebo tlaku spalin, nýbrž je ten nabíjeví/vybíjecí mechanismus poháněn speciálním motorem - třeba pomocí řetězu. Čili jde o věci jako je minigun a vulcan.

Podle wikipedie: "Chain gun" is a registered trademark of McDonnell Douglas for a chain-powered weapon.

[Cubic]

kdyz se podivate na zminenou stranku wikipedie mezi

The most commonly produced and used chain gun...

zjistite ze tam neni ani vulkan ani zadny minigun ale treba kanon z AH-64 Apache coz je prave mnou zminena zbran, ale samozrejme s pouzitou definici principu stralby pomoci externiho pohonu souhlasim

[Jan Olšan]

Kdyby byly v jádře celé zprávy a návrhy řešení, nedejbože ještě s překlady, tak by narostly jeho nároky na paměť.

BTW, má tu někdo představu, kolik místa v paměti jádor zabírá? Vím, kolik má binárka, ale čert ví, kolik si pak naalokuje navíc...

[Milan Jurik]

Prave, ze by tam byly jen identifikatory zprav a dokumentace v komentarich (tedy nezakompilovana do binarky jadra)...

[Robert Krátký]

Mně ten japonský návrh připadá výborný - tu vývojářskou vzpouru proti němu moc nechápu. Je jasné, že doplňování komentářů k již existujícím hláškám by byla otročina, ale to by šlo dělat postupně. A připojit vysvětlení k novým zprávám, to se mi nezdá jako nějak šíleně nehorázný požadavek.

[cronin]

+1

[Leoš Literák]

Vyvojari vetsinou povazuji dokumentaci za nudny ukol, ktery je zdrzuje od zabavy - hackovani. Ve firme muzes programatory vyhruzkami prinutit, aby ji psali (stejne ji ale odflaknou), ale co u FOSS projektu? Tam jsou vyvojari dobrovolnici a neni na ne zadna paka, jak je primet, aby dodrzovali dana pravidla.

[Michal Vyskočil]

Navíc, jak jsem pochopil je hlavním problémem angličtina*, takže popis chybových hlášení mimo jádro umožní případný překlad hlášení.

* neumím si sice představit, že existuje člověk, který musí jít na tak nízkou úroveň a přitom neumí ani tu primitivní počítačnickou angličtinu, ale asi mám pouze malou představivost

[Milan Jurik]

Takovych jsou miliony a ten pocitac, za kterym sedite, vyrobili oni Pokud je starsi, tak Japonci a Taiwanci, ty novejsi pak nejspise Cinani. Pro ne je anglictina zcela nezajimavy jazyk casto.

[Michal Vyskočil]

All your base are belong to us?

[hwsoft]

Nerekl bych, s cinany musim obcas (na muj vkus az moc casto) komunikovat a anglictina opravdu problem neni :). Spise odlisny pohled na pracovni nasazeni.

[Milan Jurik]

Nejspise komunikujete s velmi uzkou skupinkou lidi Par Cinanu na svem konte take mam.

[hwsoft]

Komunikuji s cinany z provincie Guang Dong, je to prumyslova cast Ciny a IMHO se tam clovek anglicky domluvi. Zase netreba cekat, ze zemedelec z jine oblasti Ciny bude prispivat do vyvoje jadra :).

[Milan Jurik]

Vetsina z nich jsou puvodem zemedelci I ti prispevatele do jadra. Zrovna jeden takovy mi tu po ranu dela kulisu na praci na telefonu. Ze zemedelske oblasti zvane Beijing

A prekvapive, ty "hlasky" nepotrebuje jen vyvojar jadra, ovsem to nekteri vyvojari jadra jaksi ignoruji

[trekker.dk]

Na druhou stranu by pro ně neměl být problém k chybovému hlášení napsat něco jako "railgun.100". A když existuje tolik dobrovolníku pro psaní kódu, určitě by se našel nějaký dobrovolník, který by napsal dokumentaci - jediné, co by vývojář musel udělat, je říct, že je to správně.

[Milan Jurik]

Japonce k tomu vede to, ze systemy, ktere znaji, tohle delaji a take proto, ze jejich anglictina je mizerna. Oba duvody jsou dostatecne zasadni a uvedene vymluvy jen potvrzuji nazory nekterych na zpusob vyvoje Linuxu. Ovsem co uz, drive ci pozdeji se misto toho zavede switcher, bud pred kompilaci nebo on-line, pro urcovani jazyka a hutnosti chybove hlasky

[Milan Jurik]

Vyborny dil, diky za nej. Al Viro opet bodoval, asi ho zahy budu citovat v opensolaris-discuss, az si tam zase budeme uzivat GPLv3 diskuze

[Leoš Literák]

Osobne nepovazuji zpravy ala IBM za dobry priklad. Kdyz delam SQL dotazy nad Oraclem, vzdy se dozvim, jakou chybu jsem udelal (aspon priblizne). Pak je spustim pod DB2 a vyskoci na mne krypticky kod a ja stravim deset minut googlovanim, nez pochopim, v cem je problem. Nesnasim DB2.

[tommy]

hmmm, a co infromix databaza a hlaska "Not implemented yet".

[s0]

muhehe, já miluju ORA-00600. A že jich na kontě pár mám. Ale to sem vlastně moc nepatří...

[Libor Chocholaty]

Pokud me pamet neklame (uz par let si s Oraclem netykam), ze Oracle ma utilitu, ktera ten krypticky kod prelozi do vicemene smysluplne hlasky, takze IMHO Google netreba.

[Leoš Literák]

Jenze ja jsem psal, ze DB2 ma priserne chybove hlasky, oracle je celkem v pohode.

[b*d]

ne nema. Podivej se do napovedy. Uz jsem s ni dlouho nedelal, ale vraci kod a kratkou zpravu (aby si nehledal, kdyz ses treba uklepl). Podle kodu se vyhleda chybova hlaska, ovsem podle jazyka klienta. Tj. kdyz bezi klient (db2) v ceske locale popis bude taky cesky. A krome toho - chybova hlaska ma byt hratka, kdezto tady ziskas nekdy 20 stranek napovedy.

Zrovna tohle jsem na db2 miloval. Tuny tuny dokumentace a taky neni spatny http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp

V linuxu to kdysi takhle fungovalo - dostal si kod chyby a perror dalo vysvetleni. Ted uz nejak ne.

[Michal Kubeček]

V linuxu to kdysi takhle fungovalo - dostal si kod chyby a perror dalo vysvetleni. Ted uz nejak ne.

AFAIK to tak pořád funguje. Musíte rozlišovat mezi signalizací chyby syscallu pro volající proces a chybovým hlášením, které jádro zapisuje do logu (prostřednictvím syslogu).

[JS]

ID zprav z kernelu je vyborna vec. Umozni to lepsi nastroje, co budou moci reagovat na nejruznejsi udalosti v logu. Nejen kernel, ale kazdy seriozni demon by to tak mel delat.

[happy barney]

jj, to je pravda, až sa na to dajaká libka pýta

[andree]

CK-ovi sa fakt necudujem, tolko prace a slusna ignoracia od vyvojarov mainlineu jadra.. tiez by som odisiel, a asi este kus menej noblesne ako fakt nechapem, ze v jadre je tolko experimentalnych veci, niektore ktore vobec nik nepouziva a pritom perfomance patche od CK tam nedaju, lebo..? pochybujem ze jeho kod je taky hrozny, ze by nevyhoval standardom alebo co... to je jadro skostnatene natolko ze tam je dolezitejsie ze je tam (?)prehladny kod, miesto aby bol vykonny/lepsi?

tiez to mohli vyriesit pomocou konfiguracie jadra - v pripade ze by si clovek zaskrtol "CKs improvements", skompilovalo by sa to s jeho patchami - a bolo by po probleme... a casom by mozno zistili podla ohlasov pouzivatelov, ze niektore tie patche su fakt dobre...

no co uz, tak je o jedneho skveleho vyvojara menej asi ich uz je privela, ze si ich linux nemusi drzat...

[eee]

To že je přehledný kód důležitější než optimalizace na výkon je snad každému zřejmé, ne? Přehledný kód je nutný pro údržbu a má také vliv na množství chyb v kódu. Chtěl bys snad o trochu rychlejší jádro za cenu, že za dva, tři roky bude neudržovatelné a plné bugů?

[andree]

neviem, konkretne patche CK som nevidel, ale celkom pochybujem ze su typu nahradenie for cyklu za switch a podobne.. v kazdom pripade je to skoda...

[DNA]

bug - takže by mi to ani stálo za to.

[paranoiq]

větu "chtěl bych psát u Microsoftu chybové hlášky." jsem dodnes používal jako vtip. teď vidím, že jde o krutou realitu

[Michal Ludvig]

Jsem jedinej komu btrfs tak napadne pripomina ZFS? Hlavne aby panove nenarazili do patentu...

[Milan Jurik]

Je a neni. Je tam spousta podobnych veci, je tam spousta rozdilnych. A pochybuji, ze by Sun nekoho zaloval za vyuziti softwarovych patentu. Gor Oracle

[zelial]

jednoznacne identifikatory chybovych hlaseni jsou urcite dobra vec. a ze to pomaha pri lokalizaci je pravda. je to 20 mminut, co jsem na cz win vista pri pripojovani sitovych disku narazil na dve chyby.

prvni znela: "Nastala systémová chyba 53"

druha: "Nastala systémová chyba 1326"

strucne, jasne, nezamenitelne. preklad vsech takovych chybovych hlaseni byl urcite jednoduchy. proste sama pozitiva a socialni vyhody.

[Michal Vyskočil]

Překlad hlášení snad ani ne, jako překlad jejich popisu