Jaderné noviny - 24. 9. 2008 (diskuse)

[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