Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Tento článek je překladem z anglického originálu, a proto vychází se zpožděním.
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.
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.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
- early_printk("Jádro skutečně žije\n");
+ early_printk("Jádro skutečně žije! Žije! ŽIIIIIJEEEEEE!\n");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)
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.
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.
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.
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.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
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.
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.
tak staré distro včetně všech low-level hejblátek s novým jádrem je v podstatě nesmyslTak 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.
(doufam)
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.
. 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)
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... 
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.
6.11.2008 14:58
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
6.11.2008 14:24
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
6.11.2008 14:53
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Ale mnoho o té chybě nevím a týká se to testovací verse jádra, takže všechno ok.
6.11.2008 17:15
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
7.11.2008 08:40
clayman | skóre: 13
| Praha 6
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 13:20
6.11.2008 16:44
6.11.2008 23:56