Jaderné noviny - 24. 9. 2008

6. 11. 2008 | Jirka Bourek | Jaderné noviny | 4206×

Aktuální verze jádra: 2.6.27-rc7. Citáty týdne: Linus Torvalds, Bill Nottingham, Paul McKenney. e1000e a radost z vyvíjení jádra. LPC: Budoucnost grafiky v Linuxu. Novější jádra a starší SELinux politiky. 2.6.27-rc8, "tohle by mělo být poslední".

Tento článek je překladem z anglického originálu, a proto vychází se zpožděním.

Obsah

• Aktuální verze jádra: 2.6.27-rc7
• Citáty týdne: Linus Torvalds, Bill Nottingham, Paul McKenney
• e1000e a radost z vyvíjení jádra
• LPC: Budoucnost grafiky v Linuxu
• Novější jádra a starší SELinux politiky
• 2.6.27-rc8, "tohle by mělo být poslední"

Aktuální verze jádra: 2.6.27-rc7

Současné vývojové jádro 2.6 je 2.6.27-rc7 vydané 21. září. Všechny změny jsou malé - největší jsou věci jako pár změn v defconfigu m68k a triviální pročištění v souboru MAINTAINERS. Detaily lze nalézt v kompletním changelogu.

Od vydání 2.6.27-rc7 bylo do gitového repozitáře hlavní řady začleněno několik tuctů oprav.

Strom linux-next si dal znenadání pauzu; jeho návrat se očekává 13. října.

Citáty týdne: Linus Torvalds, Bill Nottingham, Paul McKenney

A stejně jako u teorie relativity se dva lidé s různými CPU mohou skutečně oprávněně neshodnout na řazení stejné události. Jsou zde věci, které se chovají jako "světelné kužely", neboli hranice toho, na čem se mohou shodnout všichni. Ale v základu je při nepřítomnosti explicitních zámků dost možné, že nic takového jako "řazení" nemusí existovat.

-- Linus Torvalds

-	early_printk("Jádro skutečně žije\n");
+	early_printk("Jádro skutečně žije! Žije! ŽIIIIIJEEEEEE!\n");

-- Bill Nottingham

Kód je stále experimentální, není k začlenění, ale vzhledem k tomu, že v něm momentálně nalézám méně chyb než ve zbytku Linuxu, mám dojem, že se k začlenění blíží.

-- Paul McKenney (Díky Stevenu Rostedtovi)

e1000e a radost z vyvíjení jádra

Seznam regresí 2.6.27-rc zaslaný 21. září obsahuje - hluboko - položku "e1000e: 2.6.27-rc1 poškozuje EEPROM/NVM". Její přehlédnutí je odpustitelné; seznam regresí je (bohužel) stále dlouhý a nic v jejím popisu nenaznačuje, že se jedná o významnější problém. Ale je: tato konkrétní chyba znamená víc než jen chybu v síťování; když kousne, poškodí EEPROM na zařízení, které potom přestane fungovat (přinejmenším dokud se uživateli nepodaří nahrát do EEPROM fungující kód). To je problém, který stojí za to opravit.

V době psaní tohoto článku se nicméně nezdá, že by někdo zjistil, kde problém spočívá. Došlo k určitému zmatku kvůli faktu, že příbuzný ovladač e1000 také trpěl problémem s poškozením EEPROM - ukazuje se ale, že šlo o jinou chybu. Problém v e1000 byl opraven přidáním zámku k přístupu k EEPROM, čímž se zabránilo jejímu poškození způsobenému paralelním přístupem. V e1000e se ale děje něco jiného.

Zdá se, že zjistit, co to "něco jiného" je, je výzva. Problém nelze snadno zreprodukovat a menší problém také je, že vyvolat chybu víc než jednou vyžaduje výměnu postiženého hardwaru. Není dokonce ani jasné, které verze jádra jsou postiženy, i když se zdá, že se chyba projevuje jenom ve vývojové sérii 2.6.27. Existuje nějaká korelace mezi poškozením e1000e a pádem grafického ovladače, což Davida Millera vedlo ke zkoumání hypotézy, že skutečným viníkem jsou změny X serveru, ale tuto verzi se ještě nepodařilo prokázat. Další vývojáři mají podezření, že jde o problém spojený se souběhem podobně jako u e1000.

V době psaní tohoto článku je většina toho, co je známo, k nalezení v doporučení od Mandrivy. Jaderní vývojáři přidávají informace, které zjistí, do záznamu v jaderné bugzille (v době vydání je přinejmenším dostupná oprava od Intelu).

Padlo doporučení, že každý, kdo provozuje 2.6.27 na potenciálně postižitelném systému, by měl zazálohovat kopii současného obsahu EEPROM příkazem:

ethtool -e eth0 > eth0.eeprom

(To samozřejmě předpokládá, že je příslušné zařízení ve vašem systému eth0.) S uloženými daty by mělo být možné zařízení opravit, když dojde k nejhoršímu; bez nich je pravděpodobné, že budou oběti muset svůj systém vrátit prodejci.

V jistém smyslu tato chyba ukazuje, že systém (vývoje jádra) funguje. Byla odchycena ještě v době, kdy je jádro ve stabilizační fázi; můžeme si být jisti, že bude nějakým způsobem zlikvidována předtím, než vyjde stabilní verze 2.6.27. Na druhou stranu první hlášení o tomto problému se na síti objevilo 8. srpna; problém byl znám déle než měsíc předtím, než na něj distributoři začali reagovat, a začal skutečný hon na příčinu. To je, co se trvání regrese týče, dlouhá doba, ale obzvlášť dlouhá je v situaci, kdy se jedná o regresi, která může hardware vrátit do doby kamenné.

Distributoři nyní zareagovali; většina z nich stáhla jádra s postiženými ovladači. Zatím nikdo nezaslal nástroj, který by pomohl uživatelům hardware opravit (návrhy použít ibautil by měly být ignorovány a zapomenuty tak rychle, jak to bude možné). Takový nástroj se chystá, ale těžko obviňovat odpovědné techniky z toho, že se předtím zaměřují na opravení problému. Pokud se poštěstí, základní příčina bude nalezena již v době, kdy toto budete číst.

Je tu ale jedna věc, která se nezměnila. Testeři nestabilního softwaru - obzvláště jádra - jsou často varováni, že zmíněný software může s jejich systémem udělat otřesné věci. Tato varování je snadné ignorovat; i -rc1 jádra většinou většině lidí fungují. Nicméně, jak jsme viděli v tomto případě, potenciál pro katastrofické chyby je skutečný. Vývojový kód může zničit váš síťový adaptér, přeházet souborový systém, otevřít vážné bezpečnostní díry nebo uložit vaše dokumenty v OOXML. Když experimentujete s nestabilním kódem - i když vám ho distributor poskytl v hezkém balíčku - je vždy moudré mít dobré zálohy a ještě lepší smysl pro humor.

LPC: Budoucnost grafiky v Linuxu

V poslední den Linux Plumbers Conference (Konference linuxových instalatérů) vedl Keith Packard mikrokonferenci věnovanou budoucím displejům. Bylo diskutováno mnoho témat, ale v klíčové diskuzi se jednalo o blízké budoucnosti linuxových video ovladačů. Dlouhodobí čtenáři Jaderných novin toto téma znají lépe: Linux má několik subsystémů pověřených správou grafického hardwaru, model ovladačů v uživatelském prostoru přijatý XFree86 vede k různým problémům, podpora pro 3D grafiku není taková, jaká by mohla být atd. Celé toto téma bylo v dané diskuzi probráno, nicméně s významným rozdílem: Řešení jsou v posledních fázích stabilizace a tyto problémy se brzy stanou historií.

Jsou dvě hlavní komponenty, na kterých se pracuje: Správa grafické paměti [graphics memory management] a jaderné nastavování režimu [kernel-based mode setting] (vizte Plymouth). Současné grafické procesory (GPU) jsou skutečná CPU ve všech ohledech, včetně integrované jednotky správy paměti. Zvládání sdílení paměti mezi uživatelským prostorem, jádrem a GPU je pro implementaci korektní a na výkon náročné grafiky nezbytné. Před rokem se řešením problému správy paměti zdál být TTM subsystém, ale jak se zlepšilo porozumění problému, s TTM se dalo čím dál tím hůře pracovat. Jako cesta kupředu nyní vypadá kód Správce grafického zpracování [Graphics Execution Manager, GEM]; v současnosti se připravuje k začlenění do hlavní řady jádra.

Keith Packard, Dave Airlie a Jesse Barnes

Jaderné nastavování režimu je míněno jako způsob, pomocí kterého je možné se zbavit nutnosti umožnit kódu v uživatelském prostoru hrabat se přímo v hardwaru. Převést nastavení konfigurace videoadaptéru na jádro má spoustu výhod. Například je mnohem větší šance, že bude fungovat uspávání a probouzení. Jakmile X server přestane k hardwaru přistupovat přímo, nebude již muset běžet pod rootem; muset provozovat tolik nedůvěryhodného kódu se všemi oprávněními lidi už mnoho let znervózňuje. V současném schématu jádro nemůže změnit grafický režim, když potřebuje; to například znamená, že když systém zpanikaří, uživatel v grafickém prostředí si zprávu nikdy neprohlédne. S jaderným nastavováním režimu jádro může režim přepnout a umožnit uživateli zběsile se pokoušet přečíst zprávu dřív, než z obrazovky odroluje. Také s ním bude mnohem lépe fungovat rychlé přepínání uživatelů, zmizí potřeba použít pro každé uživatelské sezení oddělený virtuální terminál.

Jedním z prvních témat diskuze bylo: jak jádro rozhodne o tom, kdy přepnout na obrazovku paniky [panic screen], aby uživateli ukázalo důležitou zprávu? Je poměrně mnoho cest, kterými může jádro signalizovat nouzový stav; měla by se jaderná zpráva ukázat pokaždé, když nastane stav WARN_ON()? Zdá se, že bude potřeba sjednotit chybové cesty v jádře, aby se toto rozhodnutí zjednodušilo. Jesse Barnes navrhl, že jádro by mohlo jednoduše přepnout při každé zprávě, kterou vypisuje printk(), s tím, že taková politika by vedla k rychlé a vítané redukci upovídanosti jádra.

Skutečná debata na tomto sezení se však týkala vývojového procesu. Jak bylo dříve diskutováno v LWN, mnoho z práce na zobrazování se dělá mimo strom hlavní řady jádra. Nyní vidíme, jak se velký kus této práce připravuje na začlenění. Nové rozhraní pro nastavování režimu je ale velká změna API, která bude vyžadovat úpravy v uživatelském prostoru; nové jádro, od kterého se očekává správa nastavení, nemusí podávat nejlepší výsledky, když poběží se starším X serverem v uživatelském prostoru. Dojde tedy na nějaký slavnostní den, kdy se všechno změní a všechen nový kód se poprvé spustí.

Linus není nápadem slavnostního dne nadšen; dlouze apeloval na inkrementálnější přístup k opravě fungování video ovladačů. Z jeho pohledu slavnostní den znamená, že se aktivuje velký kus netestovaného kódu naráz; určitě v něm budou návrhové chyby, které se projeví, a celá ta věc nebude fungovat správně. V tom okamžiku bude zapotřebí další slavnostní den. Linus nebyl ohromen tvrzením, že uživatelé Fedory tento kód nesobecky testovali pro všechny; podle něj je podstatné, že toto testování nedělají jaderní vývojáři. Celou věc vidí jako cestu ke katastrofě.

Skutečný problém - a důvod pro vývoj mimo strom - je, že všechna tato práce vyžaduje vytvoření nových, komplexních ABI pro uživatelský prostor. To platí jak pro nastavování režimu, tak pro správu paměti a tyto dva od sebe nelze snadno oddělit. Dokud kombinace jako celek nebude fungovat, vývojáři videoovladačů se jednoduše nemohou zavázat ke stabilnímu rozhraní do uživatelského prostoru - a to znamená, že jejich kód nelze začlenit.

Jako příklad bylo zmíněno TTM. Kdyby kód byl začleněn, když se zdál být tím pravým řešením, bylo by nyní potřeba řešit ještě větší problémy.

Grafičtí vývojáři v podstatě věří, že jejich přístup je tak inkrementální, jak jenom může být. Jestli o tomto faktu přesvědčili Linuse, není jasné, ale ke konci se zdálo, že plán přijímá. Žádal je, aby do upstreamu tlačili nejprve kód pro nastavování režimu, ale ten nemůže fungovat bez podpory správy paměti, takže GEM se do hlavní řady dostane první. Jakmile bude v jádře všechno, bude možné nabootovat systém s nastavováním režimu buď v jádře, nebo v uživatelském prostoru, takže budou podporovány nové i staré distribuce. Časem, ve vzdálené budoucnosti, bude možné podporu pro nastavování režimu z uživatelského prostoru vyjmout. Mnohem dříve, než se tak stane, bychom nicméně všichni měli provozovat značně vylepšený grafický kód a již si nepamatovat, jak věci vypadaly dříve.

Novější jádra a starší SELinux politiky

Malá změna v 2.6.25 nedávno způsobila, že Andrew Mortonovi nefungoval systém zcela správně, ale také demonstrovala uživatelské rozhraní, které může být občas přehlédnuto: SELinux. Problém vznikl ze změny, která měla pomoci kontejnerům tak, že se z /proc/net udělal symbolický odkaz, což podrazilo nohy SELinuxovým politikám, které byly napsány pro starší jádra. Jádro se řídí principem přenechání nastavení politik uživatelskému prostoru, ale to může někdy vést k neočekávané synchronizaci, která je mezi těmito politikami a jádrem zapotřebí.

Změna samotná byla vcelku malá, z /proc/net se stal symbolický odkaz na /proc/self/net tak, aby kontejnery viděly jenom svá síťová zařízení místo těch, které jsou v systému, v němž jsou uzavřeny. Nicméně když Andrew spustil nové jádro na svém systému Fedora Core 5 a 6, dostal:

sony:/home/akpm> ifconfig -a
Warning: cannot open /proc/net/dev (Permission denied). Limited output.

Další průzkum odhalil, že i ls dostane chybu o oprávněních, když se dívá do /proc/net. Jak je obvyklé u záhadných "přístup odepřen" chyb, příčinou byl SELinux.

Když byla změna v březnu provedena, byla revidována vývojáři SELinuxu, ale nikdo z nich si nevšiml, že způsobí jeden test oprávnění navíc - pro samotný odkaz. Takže když se rozhoduje o věcech jako /proc/net/dev nebo dalších záznamech v tomto adresáři, testují se i "štítky" [label] symbolického odkazu. /proc je samozřejmě syntetický souborový systém, takže štítky jsou generovány z kódu SELinuxu, nikoliv získávány z rozšířených atributů (xattrs).

Distribuce aktualizovaly své politiky, aby se k symbolickému odkazu umožnil přístup - pravděpodobně si všimly zamítnutí od SELinuxu ve zprávách v logu - takže většina lidí na problém nikdy nenarazila. Jak ale Andrew zjistil, existující soubory distribucí (například ty dodané v FC5 a FC6) stále přístup nepovolí. Andrew pravidelně spouští novější jádra na starších distribucích ve snaze zachytit přesně tento druh chyb; je pravděpodobně jeden z mála, možná jediný, kdo to dělá.

Protože bylo změněno jádro dodané distribucí, někteří argumentovali, že potřeba uživatele aktualizovat politiky SELinuxu není tak obtížný požadavek. Paul Moore to řekl takto:

Možná jsem zde v menšině, ale podle mě jakmile přestaneš používat distrem dodané jádro (platí i pro další balíky, i když u těch je to pravděpodobně méně kritické), měl bys také nést zodpovědnost za to, že upgraduješ/vyladíš/nainstaluješ další kousky, které je potřeba opravit.

Andrew s tímto argumentem nesouhlasil a řekl:

Ne. Vydání kernel.org jádra, které není zpětně kompatibilní, je velký problém.

Občas to děláme, oznamujeme to dlouho dopředu, velmi opatrně a po dlouhém rozhodování.

Tentokrát jsme to udělali naprosto náhodou. V tomhle oboru se to chápe jako "chyba".

Vývojář SELinuxu Stephen Smalley nicméně upozornil na to, že testování oprávnění není běžně považováno za součást rozhraní mezi jádrem a uživatelským prostorem. Je to ale poněkud šedá oblast. Standardní UNIXová testování oprávnění jsou součástí tohoto rozhraní alespoň částečně, protože jádro řeší politiku těchto testů. Vzhledem k tomu, že politiky, které určují rozhodnutí o zamítnutí přístupu SELinuxem, přicházejí z uživatelského prostoru, je poněkud obtížné přít se o tom, že změny v jádře nevyplavou na povrch. Stephen problém popsal:

Měl bych zde poznamenat, že co se změn SELinuxu týče, doteď jsme se vždy snažili vyhnout takovému narušení kompatibility zaváděním přepínačů a příznaků politiky, které nové testy povolují atd. (přestože cenou je zvýšená komplexita a rozlézající se kód pro kompatibilitu). Změny ve zbytku jádra ale mohou stejně tak snadno změnit sadu testů oprávnění, které jsou na danou operaci aplikovány, a nemyslím si, že budeme někdy schopni garantovat, že nové jádro + stará politika bude Prostě Fungovat.

Jedním možným řešením současného problému, které Stephen naznačil, bylo, že by SELinux mohl změnit štítek, který vrací pro symbolické odkazy v /proc. Není jasné, jestli někdo tuto změnu požaduje, a neobjevila se žádná snaha ji přidat. Jak řekl Andrew, lidé, kteří dodávají distribuce založené na 2.6.25 a 2.6.26, by pravděpodobně ve svých jádrech takový patch stejně nechtěli.

Co se delšího časového úseku týče, Eric Biederman se ptal na podporu xattrs pro /proc. To by uživatelskému prostoru umožnilo štítkovat souborový systém proc správně, čímž by se odstranil jeden ze speciálních případů. Bohužel by to vytvořilo další nekompatibilitu mezi novějšími jádry a starým uživatelským prostorem.

Protože chybu zpozoroval jenom Andrew mnoho měsíců poté, co byla zavedena, nakonec bude pravděpodobně prostě ignorována. Časem se nicméně může objevit větší problém ohledně toho, jak se testy oprávnění vejdou do rozhraní mezi jádrem a uživatelským prostorem.

Následující obsah je © KernelTrap.

2.6.27-rc8, "tohle by mělo být poslední"

30. září, originál

Takže zase další týden, další -rc, začal Linus Torvalds oznámení jádra 2.6.27-rc8. Toto -rc by mělo být poslední: rozhodně nám nedošly regrese, ale na druhou stranu musím někdy vybrat nějaký okamžik a regrese jako celek nevypadají příliš děsivě. A -rc8 zjevně opravuje další. Linus pokračoval poznámkou, že většina změn od -rc7 je malá a nebylo jich tolik.

Jiří Kosina upozornil, že je zde stále neznámá chyba, která postihuje ovladač e1000e v jádře 2.6.27 a kvůli které jsou karty nadále nepoužitelné pro většinu nejsem-hacker uživatelů (a vzpomeňte si, že dokonce i Dave Airlie úplně usmrtil svůj notebook, když se snažil obsah eeprom obnovit). Když byl tázán, jak tuto chybu reprodukovat, Jiří poznamenal, že neschopnost spolehlivě chybu reprodukovat zvýšilo obtížnost ladění problému, zjevně jde o nějaký druh souběhu, protože obvykle trvá několik cyklů ji vyvolat.

       

Komentáře

[DNA]

pravděpodobně se všimly

[Robert Krátký]

Díky, opraveno.

[Michal Ludvig]

Proč vývojáři jádra tak zarputile trvají na udržování zpětné kompatibility skoro všech rozhraní? Chápal bych to u aplikací - může být potřeba upgradovat HW + OS a přenést na něj existující dejme tomu databázi nebo nějaký na zakázku napsaný program, takže je fajn že i 10 let staré aplikace můžou běžet na novém jádře. Ale i to je, řekl bych, zbytné.

Proč se ale zabývat nízkoúrovňovými záležitostmi typu SElinux, ovladače, atd? To nechápu. Dávat do staré distribuce nejnovější jádro je krajně neobvyklé cvičení, stejně tak dávat nové distro na starý HW. Že mnohdy nefunguje staré distro na novém HW, nebo starý kernel s novým distrem nikoho nepřekvapí, tak proč by to nemělo platit i naopak?

[petr_p]

Proč vývojáři jádra tak zarputile trvají na udržování zpětné kompatibility skoro všech rozhraní? Chápal bych to u aplikací

Proč se ale zabývat nízkoúrovňovými záležitostmi typu SElinux

Protože z hlediska jádra je všechno kromě jádra aplikace (uživatelský prostor). Ať už se jedná o 10 let starou databázi nebo o sadu politik SELinuxu.

Že mnohdy nefunguje staré distro na novém HW, nebo starý kernel s novým distrem nikoho nepřekvapí, tak proč by to nemělo platit i naopak?

Protože jde o zpětnou kompatibilitu, nikoliv dopřednou.

[Michal Ludvig]

Protože z hlediska jádra je všechno kromě jádra aplikace (uživatelský prostor). Ať už se jedná o 10 let starou databázi nebo o sadu politik SELinuxu.

Technicky jistě. Ale "logicky" nikoliv. Zatímco stará databáze na novém jádře je celkem představitelný scénář, tak staré distro včetně všech low-level hejblátek s novým jádrem je v podstatě nesmysl. Některé části user space jsou prostě s konkrétním jádrem svázány víc než jiné, tak proč v jádře nechávat překonaná nebo nedostatečná rozhraní?

Protože jde o zpětnou kompatibilitu, nikoliv dopřednou.

To ovšem není odpověď na otázku proč tuto kompatibilitu tak odhodlaně zachovávat.

[Ondrej 'SanTiago' Zajicek]

tak staré distro včetně všech low-level hejblátek s novým jádrem je v podstatě nesmysl

Tak zrovna ja to takhle pouzivam. Distribuci mam obvykle stable Debian (a vetsinou upgraduju nikoliv ihned po vydani noveho stable), zatimco jadro si casto kompiluju aktualni.

[CIJOML]

Protoze to, co funguje uz roky ma fungovat nadale - to nas odlisuje od silencu s woknama, kteri po par letech prodavaji na aukcich zcela funkcni hw jen proto, ze ve Vistach (XP, 2000...a tak stale dozadu) nefunguje. V linuxu mam 100% jistotu, ze to, co fungovalo bude fungovat i nadale nez to umre na opotrebeni/vyrobni vadu. A kdyz ne, ze je to povazovano za chybu a bude opraveno.

[YYY]

Pokud neni regrese, ale to se preci jen u bezneho hardware snad moc nedeje (doufam)

[CIJOML]

A kdyz ne, ze je to povazovano za chybu a bude opraveno.

[trekker.dk]

Pokud se najde někdo, kdo to udělá...

[CIJOML]

Pokud si to ten postizeny bisektuje, neni s tim problem

[Mandarinka]

Právě. Všimněte si, jak často se z jádra vyhzuje nějaký rozbitý/nefunkční/neudržovaný ovladač. Když se neozvete hned, máte pech. Taky asi když se nenajde nikdo kdo by chtěl váš problém řešit. Navěky HW nechodí, to je utopie.

[stybla]

pod to bych se klidne podepsal. take to bude tim, ze ne vsude je nasazeny high-end, ale vetsinou low-end. je to asi jako tvrdit, ze DOS se uz nikde nepouziva.

[Prcek]

Jedním z prvních témat diskuze bylo: jak jádro rozhodne o tom, kdy přepnout na obrazovku paniky [panic screen]

Huraaa budeme mit bsod

Omlouvam se, ale nemohl jsem si pomoci. Jinak predstava, ze mi X nepobezi s uid 0, se mi pochopitelne zamlouva.

[JoHnY2]

No nakonec se ukazuje, ze graficky rozhrani a akcelerace je tak komplexni zalezitost, ze bez castecny integrace do jadra to poradne resit nejde. Za rozumny vyreseni grafiky v linuxu bych byl vdecnej. Dnesni stav je v ty nizkourovnovy casti vasne dost neutesenej.

Jsem docela zvedavej na casovej ramec, jestli mame uvazovat v desitkach mesicu nebo jednotkach let . Vyvoj okolo X serveru se v poslednim roce hodne ozivil, ale stejne to este neni ono. (narocnejsi prace nez klasicky kodeni kernelu, takze neni divu)

[rtfm]

Jo jo, okolo X.Org serveru se deje hodne zla. Staci si precist nektere ze zapisku v "not-a-blogu" Tuomo Valkonena (vyvojar naprosto jedinecneho window manageru Ion)... Ale jinak Vam iluze brat nehodlam. Osobne jsem obrecel stary dobry XFree86 server a co je tu X.Org, veci jdou evidentne spatnym smerem...

A uplne do haje jde vyvoj aplikaci pro X. Napriklad naprosta ignorance ICCCM a o tech ostatnich vecech radeji ani nemluve... Je to k vzteku! Snazim se vyvinout novy WM a tretina aplikaci ho klidne ignoruje, druha tretina si mysli, ze je chytrejsi nez ja a dela si co chce a posledni tretina jaksi zapomina manageru signalizovat co ze to vlastne dela... O trochu lepe je na tom Qt nez GTK(+-*/), ale stejne jsou oba ty molochy peknej shit, takze clovek aby pak nedelal nic jineho nez psal workaroundy aby tyhlety bastly fungovaly alespon trosicku v mezich zdraveho rozumu...

Naprostym vrcholem jsou pak aplikace jako Acroread (i Ion pro nej ma specialni hack), ktere ignoruji prakticky cokoli, co se ignorovat da a pak jeste aplikace, ktere si mysli, ze nejaky window manager je tu jen pro srandu kralikum a delaji si dokonce vlastni dekorace! V takovem prostredi se ani nemuzeme divit, ze jsou vyvojari window manageru opravdu "rare breed", jak se "kdesi" pise...

K originalni krase UNIXu to opravdu neprispiva, ale pokud nekomu ten bordel vyhovuje... IMHO tim trpime uplne vsichni. Jeste stesti, ze osobne pouzivam vicemene jenom XTerm (nebo spis XVT) a terminalove aplikace...

[thingie]

Originální kráse Unixu? Nic takového nikdy nebylo

Rozbitosti je všude kolem mnoho, ale většina toho co se děje, děje se celkem k lepšímu. Pokud to někomu připadá jako zhoršení, pak je to spíš, že dřív to bylo tak zlé, že kdyby si na to člověk násilně nezvyk a nezačal to milovat, musel by utéct kilometry daleko.

[walley walleyovic]

miluju optimisty:) clovek se aspon obcas zasmeje:)

[thingie]

Například už se zdá, že lidi pochopili jaká strašná kravina byly ty XML zvrácenosti všude

[Zdeněk Štěpánek]

Ale pobezi, jenomze ne v user-space, ale ze znacne casti v kernel-space a v uzivatelskym prostoru zustane jen to co roota nevyzaduje.

Coz je reklbych z blata do louze. Ovladani grafiky primo v jadre uz tady jeden OS ma, jenze BSOD neni vyhoda z toho vyplivajici, ale spis nasledek. Ale asi tomu prdlajs rozumim.

Zdenek

[trekker.dk]

To je dost možný. Nastavování grafiky v jádře znamená, že jádro bude poskytovat API, kterým bude možné s tou grafikou manipulovat. V současnosti je to tak, že když X server chce nějak změnit nastavení grafiky, tak si to udělá sám, což je v podstatě pěkná prasárna.

Ten jeden OS má nejenom ovládání grafiky v jádře, ale celou grafiku...

[Foo Bar]

Ehm, nevím jestli si toho všiml ještě někdo další... ale stala se chyba v časoprostorovém kontinuu a tyhle Jaderné noviny jsou ze září...

[Robert Krátký]

Je až s podivem, jak často se kvůli tomuto někdo ozve, i když se to vysvětluje snad pod každými druhými JN.

Jediná chyba je v tom, že vydávání překladů JN má většinou nějaké zpoždění. V současné době je to zpoždění lehce přes měsíc. Vím, není to ideální a snažíme se to zpoždění dohnat, aby nebylo větší než dva týdny. Na překladatelovu obranu musím podotknout, že chyba není u něj - překlady dodává velmi brzy; jen se nedaří JN optimálně zařazovat do vydávacího plánu.

[Peppa1]

tak se vykašlete na plán a hoďte to na web rovnou!

[Foo Bar]

Třeba by pomohla taková jednoduchá věc. Nahoru dát menším šedým písmem poznámku o tom, že JN vycházejí se zpožděním...

[Michal Vyskočil]

Podle mých zkušeností takové tabulky stejně nikdo nečte.

[Robert Krátký]

Přesto jsem tam tu větu na začátek přidal...

[Zomp]

A já už si říkal, že to tam bylo vždycky, akorát jsem si toho nikdy nevšiml... :)

[YYY]

Jak to vlastne ted momentalne vypada s e1000e?

[trekker.dk]

Chybu už našli, v 2.6.27.1 je opravená.

[YYY]

Diky za info, bohuzel se mne to tyka, takze ted jsem se par tydnu bal davat nova jadra ;)

[Heron]

Týká? Tzn. máš danou síťovku a používáš -rc jádra?

[YYY]

Ano. Mam danou sitovku a obcas rc jadro zkusim...

[Heron]

Chyba už je opravená a největší "sranda" je, že to vůbec nebyla chyba v e1000e ale úplně jinde.

[YYY]

Diky za info. Nu, to je docela pruser... A vyresili to nejakym hackem, nebo tak nejak principialne?

[Heron]

No opravili tu chybu co našli jinde (která toto způsobovala). Nevím, zda je to hack nebo princip. Ale mnoho o té chybě nevím a týká se to testovací verse jádra, takže všechno ok.

[trekker.dk]

Tu chybu v podstatě neopravili. Chybu způsobil sledovací kód (ftrace), oprava by byla v rámci stable jádra přílši složitá, takže to vyřešili tak, že celé ftrace zakázali.

Skutečná oprava bude až v 2.6.28.

[Heron]

Taky způsob.

[YYY]

Takze je to hack

[clayman]

Spíš hotfix.

[petr_p]

Celá pravda je, že trasovací kód byl natolik špatný, že jej zahodili a napsali nový, který shodou okolností tímto problémem (xcmp nad do paměti mapovaným IO prostorem) netrpí. Protože se ale nový kód nestihlo zařadit do 2.6.27, tak prostě vyjde v další verzi.

[donny]

zprávička zmiňující opravu problému: http://www.abclinuxu.cz/zpravicky/linux-2.6.27.1