Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
Současné vývojové jádro je 2.6.33-rc5 vydané 21. ledna. Obsahuje mnoho oprav, tempo patchů přicházejících do 2.6.33 je stále poměrně vysoké.
Ve vývojovém jádře 2.6.33-rc5 zůstává 23 nevyřešených regresí (ze 75 nahlášených).
Stabilní aktualizace: 2.6.32.5 bylo vydáno 22. ledna, následováno 2.6.32.6 z 25. ledna; obě obsahují poměrně hodně důležitých oprav. 2.6.32.7 je revidováno v době psaní tohoto článku; obsahuje 98 oprav a lze ho očekávat někdy po 28. lednu.
-- Al Viro
Normálně je jádro, které nepadá, považováno za dobré jádro. Může ale také být zdrojem opravdové frustrace pro ty, kteří chtějí vidět, jak systém letí v plamenech k zemi. Spolehlivost systému znamená, že člověk čekající na pád může při čekání zestárnout.
Simon Kagstrom zaslechl o problémech takových uživatelů; proto zaslal jaderný modul pro ty, kdo si chtějí sestřelit systém na vyžádání. Tento modul vytvoří v debugfs adresář (provoke_crash [vyprovokuj_pád]), ve kterém je několik užitečných souborů. Pro ty, kdo mají jednoduché požadavky, zápis do bugon vyústí v přímočaré volání BUG(). Uživatelé s jemněji vytříbeným vkusem mohou zapsat do null_dereference a tím způsobit dereferenci nulového ukazatele, overwrite_allocation zapíše za alokovanou haldu [heap], corrupt_stack přepíše zásobník. Opravdu výstřední uživatelé mají k dispozici i oops_interrupt_context dereferencující nulový ukazatel v režimu softirq, write_after_free, který šlápne do uvolněné paměti, či unaligned_load_store, který provede špatně zarovnané operace s pamětí.
Není potřeba říkat, že toto není modul, který by někdo chtěl nechat nahraný v jádře na produkčním systému; lepší je držet ho na tajném místě a vytáhnout, až když děti spí. Samozřejmě kromě případů, kdy pro něj máte skutečné využití; Simon ho používal k tomu, aby kmsg_dump() dělala v různých případech pádu správnou věc. U většiny vývojářů je nicméně práce řízena potřebou pádům se vyhýbat; protože pro tuto vlastnost nemají využití, není jasné, jestli se tento malý modul někdy dostane do hlavní řady.
Linux má již dlouho systémové volání mincore(), které aplikaci umožňuje zjistit, jestli je daná stránka v RAM, nebo ne. Není ale snadné zjistit, jestli je daná stránka ze souboru v cache stránek, nebo ne. Aplikace může soubor namapovat pomocí mmap() a použít mincore(), ale to může být pomalé. Christ Frost proto navrhl nové systémové volání fincore(), které by to zajistilo:
int fincore(int fd, loff_t start, loff_t len, unsigned char *vec);
Volání fincore() se podívá na stránky souboru spojené s fd v rozsahu určeném start a len. Pro každou stránku v souboru je jeden byte ve vec nastaven na nenulovou hodnotu, pokud je tato stránka v paměti. Odpověď je přirozeně pouze přibližná – situace se během běhu systémového volání může změnit.
To nicméně může být pro Chrisovy potřeby dostatečně dobré. Jeho cílem je zrychlit aplikace, které provádí mnoho nesekvenčních čtení ze souboru. Tradiční kód dopředného čtení se s takovou situací vyrovnává špatně, vzhledem k tomu, že vzor přístupů nelze předem odhadnout. Aplikace ale často dopředu zná sekvenci, ve které bude číst; pokud by bylo možné jádru říci, aby tyto stránky natáhlo předem, mohlo by řadit I/O operace optimálně a celou věc zrychlit. Když to udělal u sqlite a GIMPu, hlásil Chris významné zrychlení.
Přednačtení dat lze vyžádat systémovým voláním fadvise(). Je tu ale problém: Pro přednačítací knihovnu je těžké zjistit, kolik je k dispozici systémové paměti. Pokud je přednačteno příliš málo dat, výkonnostní zisky nebudou takové, jaké by mohly být; přednačtení příliš mnoha dat však může vést ke značnému zpomalení. A proto systémové volání fincore(): Jestliže přednačtené stránky nejsou k dispozici, když se aplikace dostane k tomu, že je chce použít, knihovna ví, že chtěla příliš a že by měla zpomalit.
Andrewu Mortonovi se patch líbí:
Jamie Lokier se ale ptal, jestli by nebylo lepší najít způsob, jak aplikace informovat o tom, že jsou jejich stránky odstraněny před použitím.
Jde o první zaslání tohoto systémového volání, takže se mu nedostalo příliš pozornosti; určitě bude nutná delší diskuze, než ho bude možné začlenit. Více informací najdete na stránce o libprefetch.
Ti z vás, kteří mají rádi prezentace Davea Airlieho plné koťátek, byli dost možná nespokojeni s jeho přednáškou na linux.conf.au, která byla nazvána "Tak jste přestěhovali grafické ovladače do jádra… a co teď? Můžu mít poníta?" Poníci ale také mohou být hezcí a shrnutí novinek ohledně stavu grafických ovladačů v jádře stálo za to si vyslechnout.
Nyní je to přibližně rok od doby, co bylo do hlavní řady začleněno jaderné nastavování režimu [kernel mode setting, KMS]. KMS ukončuje ten „nepořádek“, který vzešel z toho, že grafické ovladače byly v uživatelském prostoru; vykopat se z této jámy trvalo dobrých sedm let. Teď jsou grafické ovladače v jádře stejně jako většina ostatních.
Kromě vyklizení tohoto zmatku je několik dalších dobrých důvodů pro začlenění KMS. Jedním z nich je, že systém je nyní plně schopen využít možnosti úspory energie hardwarem; před KMS jádro nikdy nevědělo, co se s hardwarem děje. Co se týče úspory energie, ovladače od Intelu mohou nyní fungovat stejně dobře jako na Windows; 
ovladače od ATI tak daleko ještě nejsou. Další hezká vlastnost je možnost použít jaderný debugger na systému, na kterém běží grafika; nyní je možné odskočit do debuggeru a pak se vrátit do běžícího systému a vše bude fungovat.
Jediný důvod, proč tak dlouho trvalo KMS začlenit, bylo to, že od jádra vyžaduje spoustu nových věcí. Na začátku seznamu je slušný správce grafické paměti. To je složitý problém, takový, kterému se vývojáři grafiky chtěli věnovat někdy Opravdu Brzy. Nakonec se k tomu dostali vývojáři TTM, ale ti rychle narazili na mnoho problémů s API. Po nějaké snaze se vývojáři od Intelu rozhodli, že obecný přístup k API správy paměti nebude fungovat; z toho vzešel správce paměti GEM, který se pokoušel řešit problém jenom u Intelu.
Vývojáři pracující na čipových sadách ATI následně brzy zjistili, že GEM nemá možnosti, které potřebují. Proto se vrátili zpět k TTM, ale ne předtím, než na něj našroubovali něco, co vypadá jako API GEM. TTM byl nedávno začleněn, takže KMS je možné použít u čipových sad ATI.
Co nás tedy čeká? Jedna z budoucích vlastností je architektura Gallium 3D. Gallium, jak říká Dave, začíná fungovat, ale ještě bude chvíli trvat, než bude plně funkční. Úprava ovladačů pro Gallium bude nepříjemné cvičení; již teď existuje několik API, která je potřeba podporovat. Také se blíží DRI2; tato vlastnost je nutná k tomu, aby KMS fungovalo správně, obzvláště u kompozitních záležitostí. Stále jsou ale výkonnostní problémy, které je potřeba vyřešit.
Další věc, na kterou se můžeme těšit, je zobrazovací server Wayland. Wayland lze považovat za jednodušší a menší náhradu X vystavěnou nad KMS. Nyní na něm mohou běžet GTK a GL aplikace; také pro něj existuje emulátor X serveru. Zbývá několik potíží včetně toho, že Wayland není X; vzhledem k tomu, že X je v dané oblasti standard, alternativy bude obtížné prodat. Vývojáři Waylandu se také ještě nepotýkali s problémem vstupu, přičemž to je velký kus kódu X. Wayland tedy také bude ještě chvíli na cestě; možná se dostane nejprve do embedded řešení.
Dave věnoval nějaký čas současnému stavu grafických ovladačů. Intel, jak řekl, je v současnosti ve vedení. Podporuje KMS všude – dobrá, téměř všude; „čipová sada, o které nemluvíme“ (proprietární GMA500) podporu stále postrádá. Ovladač obsahuje všechny vlastnosti, ale Dave ho nechce nazývat „dokončený“; na to bude potřeba ještě jedno nebo dvě vydání. Jak zde bylo dříve zmíněno, ovladač bude muset nějakou dobu udržovat nastavování režimu z uživatelského prostoru [user mode setting, UMS], nicméně současné zdrojové kódy X.org v upstreamu již podporu UMS z X serveru vyřadily.
Ovladače ATI/AMD jsou trochu více pozadu, ale blíží se; vzhledem k mnoha variacím čipových sad je tento ovladač složitější než ovladač Intelu. V současnosti jsou podporovány čipové sady od R100 do R700; Podporu R800 lze očekávat během několika týdnů. Ovladač aktuálně funguje „skoro tak dobře jako ten starý“; uspávání a probouzení fungují lépe než dříve. Podpora úspory energie chybí, ale očekává se v 2.6.34. Ovladač Radeon je v současnosti ve stromě -staging, ale z toho se může dostat před koncem vývojového cyklu 2.6.33.
Co ovladač RadeonHD? Oddělení tohoto ovladače je primárně důsledkem neshody ohledně používání tabulek BIOSu ATI; ovladač Radeon obsahuje interpreter těchto tabulek, zatímco RadeonHD reimplementuje funkce, které tyto tabulky poskytují. Používání tabulek BIOSu značně ulehčuje práci; umožňuje to ovladači ignorovat mnoho detailů spojených s různými variantami čipových sad. Kód pro tabulky BIOSu je součástí implementace KMS, která byla začleněna do hlavní řady; to by podle Davida mělo neshody vyřešit.
„Poník“ zobrazený u zmínky o Nouveau byl ve skutečnosti Trojský kůň. Nouveau bylo samozřejmě začleněno do 2.6.33. Ovladač právě ztratil svoji podporu pro nastavování z uživatelského prostoru; umí pouze KMS. Podporovány jsou čipové sady od NV4 po G80 a poslední kousky budou brzy doplněny. Firmware „ctxprogs“ je zkoumán; verze pro NV40 byla již nahrazena přepsaným ekvivalentem se svobodnou licencí a u NV50 se na tom pracuje. Dave poznamenal, že ať už si lze o spolupráci nvidie s komunitou myslet cokoliv, jejich hardware bývá relativně dobrý a snadno se s ním pracuje.
Když byl Dave dotázán na podporu nelinuxových systémů, odpověděl, že většina z nich byla ponechána svému osudu. U Sunu se zjevně pracuje na portu pro OpenSolaris, ale tato skupina nevydala žádný kód. Další člověk z publika se zeptal na běh X bez oprávnění roota: To nyní funguje a Moblin to používá. Zbývá ale několik problémů, obzvláště co se týká rychlého přepínání uživatelů. Vzhledem k absenci systémového volání revoke() nelze nijak garantovat, že nějaký uživatel neodposlouchává jiného. Protože je revoke() obtížný problém, není jisté, jak bude tato záležitost vyřešena.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Je tu jeden překlep z poníka na poníta.Není to překlep.
Je tu jeden překlep z poníka na poníta.To není překlep.
18.2.2010 13:05
Jakub Lucký | skóre: 40
| Praha
18.2.2010 13:05
Jakub Lucký | skóre: 40
| Praha
18.2.2010 19:40
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
Jadra 2.6.27 <= verzie >= 2.6.31 hadzali deterministicky oopsy pri odmountovani fs mountovanom s -o loop. Robit na takom jadre s obrazmi diskov z VirtualBoxu je fakt radost.S loop jsem si nedávno na 2.6.31 užíval docela dost. Ani jeden oops. A stěžovat si na jádro, když do něj cpeš binární sra?ky...
18.2.2010 17:30
vlastikroot | skóre: 24
| blog: vlastikovo
| Milevsko
20.2.2010 16:06
Jendа | skóre: 78
| blog: Jenda
| JO70FB
A stěžovat si na jádro, když do něj cpeš binární sra?ky...VirtualBox má i opensource edici a ten jaderný modul je AFAIK otevřený vždy.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
18.2.2010 09:34