abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
dnes 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 1
dnes 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 0
dnes 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 1
dnes 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 1
včera 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 9
včera 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
včera 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
16.10. 23:44 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2017-15265 zneužitelná k lokální eskalaci práv. Jedná se o chybu v části ALSA (Advanced Linux Sound Architecture).

Ladislav Hagara | Komentářů: 1
16.10. 22:44 | Komunita

Greg Kroah-Hartman informuje na svém blogu, že do zdrojových kódu linuxového jádra bylo přidáno (commit) prohlášení Linux Kernel Enforcement Statement. Zdrojové kódy Linuxu jsou k dispozici pod licencí GPL-2.0. Prohlášení přidává ustanovení z GPL-3.0. Cílem je chránit Linux před patentovými trolly, viz například problém s bývalým vedoucím týmu Netfilter Patrickem McHardym. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 4
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (18%)
 (0%)
 (0%)
 (3%)
 (71%)
 (8%)
Celkem 38 hlasů
 Komentářů: 1, poslední dnes 11:21
    Rozcestník

    Jaderné noviny - 24. 9. 2008

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

    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

    link

    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

    link

    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

    link

    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

    link

    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.

    lpc2008 display session
    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

    link

    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í"

    link

    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.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    6.11.2008 03:53 DNA
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    pravděpodobně se všimly

    6.11.2008 08:54 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Díky, opraveno.
    6.11.2008 05:58 Michal Ludvig | skóre: 16
    Rozbalit Rozbalit vše Zpětná kompatibilita
    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?
    6.11.2008 11:21 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Zpětná kompatibilita
    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.

    6.11.2008 11:57 Michal Ludvig | skóre: 16
    Rozbalit Rozbalit vše Re: Zpětná kompatibilita
    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.
    6.11.2008 16:42 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Zpětná kompatibilita
    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 avatar 6.11.2008 13:20 CIJOML | skóre: 58 | Praha
    Rozbalit Rozbalit vše Re: Zpětná kompatibilita
    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.
    6.11.2008 14:15 maertien | skóre: 29 | blog: martinek
    Rozbalit Rozbalit vše Re: Zpětná kompatibilita
    Pokud neni regrese, ale to se preci jen u bezneho hardware snad moc nedeje :-) (doufam)
    CIJOML avatar 6.11.2008 18:17 CIJOML | skóre: 58 | Praha
    Rozbalit Rozbalit vše Re: Zpětná kompatibilita
    A kdyz ne, ze je to povazovano za chybu a bude opraveno.
    6.11.2008 19:49 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Zpětná kompatibilita
    Pokud se najde někdo, kdo to udělá...
    Quando omni flunkus moritati
    CIJOML avatar 7.11.2008 00:48 CIJOML | skóre: 58 | Praha
    Rozbalit Rozbalit vše Re: Zpětná kompatibilita
    Pokud si to ten postizeny bisektuje, neni s tim problem
    8.11.2008 03:33 Mandarinka
    Rozbalit Rozbalit vše Re: Zpětná kompatibilita
    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 avatar 6.11.2008 16:44 stybla | skóre: 28 | Praha
    Rozbalit Rozbalit vše Re: Zpětná kompatibilita
    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.
    6.11.2008 07:37 Prcek
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    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.
    6.11.2008 10:37 JoHnY2
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    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)
    6.11.2008 22:49 rtfm
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    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 avatar 6.11.2008 23:56 thingie | skóre: 8
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    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.
    Růžové lži.
    7.11.2008 17:04 walley walleyovic | skóre: 4 | blog: walley
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    miluju optimisty:) clovek se aspon obcas zasmeje:)
    thingie avatar 7.11.2008 18:34 thingie | skóre: 8
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Například už se zdá, že lidi pochopili jaká strašná kravina byly ty XML zvrácenosti všude :-)
    Růžové lži.
    6.11.2008 12:11 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    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
    www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
    6.11.2008 13:47 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    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...
    Quando omni flunkus moritati
    6.11.2008 08:38 Ondřej Surý | skóre: 14
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    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áří...
    Nehledejte zlý úmysl tam, kde je dostatečným vysvětlením hloupost.
    6.11.2008 08:53 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    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.
    6.11.2008 09:10 Peppa1
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    tak se vykašlete na plán a hoďte to na web rovnou!
    6.11.2008 09:44 Ondřej Surý | skóre: 14
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    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...
    Nehledejte zlý úmysl tam, kde je dostatečným vysvětlením hloupost.
    6.11.2008 10:00 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Podle mých zkušeností takové tabulky stejně nikdo nečte.
    When your hammer is C++, everything begins to look like a thumb.
    6.11.2008 10:12 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Přesto jsem tam tu větu na začátek přidal...
    6.11.2008 10:56 Zomp | skóre: 1
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    A já už si říkal, že to tam bylo vždycky, akorát jsem si toho nikdy nevšiml... :)
    6.11.2008 14:14 maertien | skóre: 29 | blog: martinek
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Jak to vlastne ted momentalne vypada s e1000e? :-)
    6.11.2008 14:19 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Chybu už našli, v 2.6.27.1 je opravená.
    Quando omni flunkus moritati
    6.11.2008 14:35 maertien | skóre: 29 | blog: martinek
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Diky za info, bohuzel se mne to tyka, takze ted jsem se par tydnu bal davat nova jadra ;)
    Heron avatar 6.11.2008 14:58 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Týká? Tzn. máš danou síťovku a používáš -rc jádra?
    6.11.2008 15:14 maertien | skóre: 29 | blog: martinek
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Ano. Mam danou sitovku a obcas rc jadro zkusim...
    Heron avatar 6.11.2008 14:24 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Chyba už je opravená a největší "sranda" je, že to vůbec nebyla chyba v e1000e ale úplně jinde. :-(
    6.11.2008 14:35 maertien | skóre: 29 | blog: martinek
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Diky za info. Nu, to je docela pruser... A vyresili to nejakym hackem, nebo tak nejak principialne? :-)
    Heron avatar 6.11.2008 14:53 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    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.
    6.11.2008 16:25 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    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.

    Quando omni flunkus moritati
    Heron avatar 6.11.2008 17:15 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Taky způsob.
    7.11.2008 08:15 maertien | skóre: 29 | blog: martinek
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Takze je to hack :-)
    clayman avatar 7.11.2008 08:40 clayman | skóre: 13 | Praha 6
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    Spíš hotfix.
    7.11.2008 09:28 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008

    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.

    6.11.2008 15:18 donny
    Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 9. 2008
    zprávička zmiňující opravu problému: http://www.abclinuxu.cz/zpravicky/linux-2.6.27.1

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.