Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
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.
Současné vývojové jádro je 2.6.28-rc5 vydané 15. listopadu. Obsahuje obvyklou hromádku oprav; detaily vizte v kompletním changelogu.
Současné stabilní jádro 2.6 je 2.6.27.6 vydané 13. listopadu. Obsahuje slušné množství oprav, z nichž jedna má přiřazené CVE číslo. V době psaní tohoto článku je pro začlenění do 2.6.27.7 revidováno 46 patchů, verze bude pravděpodobně vydána brzy.
-- Alan Cox se přidává k exkrementální náladě
Linux Foundation zaslala sadu fotografií z Kernel Summitu 2008. Pokud se těmto obrázkům dá věřit, Summit zahrnoval spoustu času stráveného konzumací alkoholických nápojů. Ve skutečnosti to ale byla mnohem vážnější událost, čestně.
Arjan van de Ven hlásí, že kerneloops.org zaznamenal oops č. 100 000 těsně před svými prvními narozeninami. Tato stránka sbírá výstupy z jaderných oops zpráv, což jsou popisy pádů jádra. Záměrem je najít ty nejběžnější ve snaze najít a opravit chyby, které je způsobují. Kromě prvních dvou položek, na které existují patche, jsme docela slušně pracovali na opravování nejčastěji se objevujících chyb (kromě těch v binárních ovladačích, které samozřejmě opravit nemůžeme). Arjanova celá zpráva.
PCI express (PCIe) se normálně nepovažuje za něco, přes co by se daly propojovat počítače mezi sebou, je to sběrnice pro připojování periférií, ale použít ji jako způsob propojení má své výhody. Jaderný hacker Arnd Bergmann poskytl na nedávné UKUUG konferenci Linux 2008 prezentaci o práci, kterou udělal na používání PCIe u IBM. Načrtl současný stav podpory v Linuxu stejně jako plány pro budoucnost.
Dostupnost PCIe sběrnice v mnohém hardwaru, který se dnes používá, je jednou velkou výhodou. Použitím PCIe místo jiných propojení jako InfiniBand lze dosáhnout stejné propustnosti s nižší latencí a spotřebou energie. Arnd poznamenal, že nepoužití samostatného InfiniBand čipu ušetří 10-30 wattů, což se na 30 000uzlovém superpočítači rychle nasčítá.
PCIe má také nějaké nevýhody. Není zde žádný bezpečnostní model, takže proces s právy roota na jednom stroji může shodit ostatní připojené stroje. Je zde také bod selhání [single point of failure], protože pokud spadne kořenový port PCIe, vezme s sebou celou síť. Nebo, jak to řekl Arnd: Jestliže se něco pokazí, celý systém padne. PCIe postrádá standardní vysokoúrovňové rozhraní pro Linux a mezi ovladači není sdílen žádný obecný kód - alespoň zatím.
Jako příklad systému, který používá PCIe, Arnd popsal superpočítač "Roadrunner", jenž je v současnosti nejrychlejší existující. Je to cluster hybridních uzlů nazvaných "Triblade", každý z nich má jeden Opteron blade společně s dvěma Cell blady. Uzly jsou spojeny pomocí InfiniBand, ale mezi procesory v každém uzlu se pro komunikaci používá PCIe, ve kterém Opteron slouží jako kořenový port a Celly jsou koncové body.
Existuje i další hardware, který tímto způsobem používá PCIe, včetně akcelerátorové desky Fixstars GigaAccel 180 a desky systému na čipu [System on Chip, SoC] embedded PowerPC 440/460, obě používají stejné PCIe zařízení Axon. Arnd také mluvil o PCIe přepínačích [switch] a netransparentních mostech [bridge], které zajišťují stejné funkce jako síťové přepínače a mosty. Mosty jsou nazývány "netransparentní", protože mají tabulky pro remapování I/O - občas IOMMU - které lze adresovat dvěma kořenovými porty, jež jsou mostem spojeny. Tyto mosty mohou mít také DMA enginy zajišťující přenos dat bez řízení hostitelským procesorem.
Arnd pak přešel k softwarové straně tématu, kde se díval na dostupné ovladače - a plánované ovladače - podporující spojení přes PCIe. První ovladač byl napsán firmou Mercury Computers roku 2006 pro akcelerační desku Cell a nyní je to "opuštěný software" [abandonware]. Má mnoho nedostatků a zabralo by hodně práce dostat ho do stavu vhodného pro hlavní řadu.
Další volbou je ovladač použitý pro Roadrunner Triblade a GigaAccel zařízení, které jsou přibližně modelovány podle InfiniBand. Má rozhraní, které používá speciální ioctl() příkazy, jež implementují pouhých osm operací oproti stovkám u InfiniBandu. Na poměry linuxových ovladačů zařízení je obrovský, protože má 13 000 řádek kódu.
Ovladač Triblade není tak portovatelný, jak by mohl být, a je velmi specifický pro architektury Opteron a Cell. Na straně Cellu je implementován jako ovladač Open Firmware, na straně s Opteronem je to PCIe ovladač. Je zde namícháno hodně kódu virtuálního ethernetu. Celkově vzato není považován za nejlepší cestu, jak tato zařízení v Linuxu podporovat.
Další přístup zvolila skupina studentů sponzorovaná IBM, která vyvinula prototyp virtuálního ethernetu pro komunikaci s IBM BladeCenterem z pracovní stanice pomocí netransparentního mostu. Každá strana mohla přistupovat k paměti použitím ioremap() na jedné straně a dma_map_single() na straně druhé. Implementací ovladače virtio se vyhnuli psaní ethernetového ovladače, protože tuto funkci poskytla abstrakce virtio. Ovladač byl poněkud pomalý, protože nepoužíval DMA, ale byl to začátek na cestě, kterou Arnd považuje za správnou.
Arnd pokračoval popisem "koncepčního ovladače" pro koncové body PCIe, který je založen na práci studentů, ale přidává věci jako DMA, stejně jako dodatečné ovladače virtio. Přidání blokového zařízení virtio by mohlo embedded zařízením umožnit používání pevných disků přes PCIe nebo, v případě implementace ovladače virtio pro souborový systém Plan9 (9pfs), by se přes PCIe zajistil přístup přímo k jednotlivým souborům. To vše závisí na abstrakci virtio.
Virtio je v ovladači považováno za užitečnou vrstvu, protože je to standardní abstrakce pro dělání něčeho, když nejste omezeni hardwarem. Nad ovladači virtio jsou implementovány "hostitelé" síťování, blokových zařízení a souborových systémů, což je poměrně jednoduše zpřístupňuje. Jednou problémovou oblastí je však kousek zajišťující konfiguraci za běhu. Problém spočívá ne v nalezení něčeho, co funguje, ale něčeho, co bude fungovat i v budoucnu.
Plánuje se nahrazení rozhraní ioctl() rozhraním InfiniBand sloves (ibverb). Toto rozhraní nemusí být tou nejlepší volbou v abstraktním smyslu, ale existuje a podporuje OpenMPI, takže by ho nový ovladač měl implementovat také.
Jsou navrhovány dva typy implementace virtqueue, jedna pro paměťově mapované I/O (MMIO) a druhá pro virtqueue založené na DMA. MMIO by byla nejzákladnější implementace virtqueue s lokálním čtením a vzdáleným zápisem. Čtecí přístupy na PCIe jsou mnohem pomalejší než zápisy, protože před čtením se musí dokončit veškeré zápisy a poté čekat na přijetí dat. Data a signalizační informace by měly oddělené oblasti, takže garance řazení dat by mohly být v datové oblasti uvolněnější kvůli zvýšení výkonnosti, zatímco v signalizační oblasti by se udržovalo striktní řazení.
Implementace virtqueue založená na DMA enginu by byla značně hardwarově závislá, aby se zahrnuly výkonnostní a jiné limity pod ní ležícího enginu. V některých případech například nemá cenu nastavovat DMA pro přenosy menší než 2k, místo toho by se tedy použilo kopírování přes MMIO. DMA by se používalo pro přenášení užitečných dat, ale signalizace by se stále řešila přes MMIO. Arnd poznamenal, že jaderná DMA abstrakce nemusí poskytovat vše, co je potřeba, takže možná bude nutné vylepšit i toto rozhraní.
Arnd neposkytl žádný časový rámec, ve kterém se má tato práce dostat do jádra, protože na všem se teprve pracuje. Je toho potřeba hodně udělat, ale prezentace načrtla plán, kam se budou věci ubírat.
V e-mailovém rozhovoru po prezentaci Arnd poukázal na svoji větev triblade-2.6.27, kam se mohou podívat ti, které zajímá současný stav věcí, a poznamenal k ní, že je jen trochu spojená s tím, o čem si myslím, že je potřeba udělat. Také zmínil patch Iry Snydera, který implementuje virtuální ethernet přes PCI, u kterého je mnohem pravděpodobnější začlenění do jádra v blízké budoucnosti. Arnd a Ira se dohodli na spojení svých sil za účelem přidání více funkcí v rámci toho, co bylo na přednášce zmiňováno.
V Jaderných novinách se nedávno psalo o obavách z pomalu klesající výkonnosti linuxových systémů v benchmarku tbench zaměřeném na síťování a plánování úloh. Výsledky tbench se zhoršovaly přibližně od 2.6.22. Na konci minulé epizody byla pozornost namířena na plánovač CFS, který se zdál být pravděpodobným viníkem. Článek končil předpovědí, že teď, když je pozornost obrácena na roli plánovače v této regresi, přijdou opravy relativně rychle. O měsíc později se zdá, že opravy se opravdu objevily a vývojáři, kteří se snaží o lepší výsledky tbench, budou svůj pohled muset upřít někam mimo plánovač.
Diskuze pokračovala po rutinním týdenním zaslání seznamu regresí po 2.6.26; jeden záznam na seznamu je záležitost výkonnosti tbench. Ingo Molnár odpověděl odkazem na rozsáhlou sadu benchmarků, které provedl Mike Galbraith. Z jejich výsledků Ingo vyvozuje závěr, že plánovač CFS je nyní rychlejší než starý O(1) plánovač a že veškerý podíl plánovače na této regresi byl zlikvidován. Kromě toho:
Toto zlepšení není něco, k čemu by došlo jen tak; je to výsledek cílené snahy na straně vývojářů plánovače. Bylo začleněno docela dost změn; všechny vypadají jako malá poladění, ale dohromady dávají významné zlepšení výkonu. Jedna změna opravuje místo, kde kód plánovače zakazoval přerušení tam, kde to nebylo potřeba. Nějaké další (zde a zde) upravují chování mechanismu "probouzecí kamarád" [wakeup buddy], což je funkce, která z pohledu plánovače pojí procesy dohromady. Jako příklad zde vezměme proces, který probudí jiný proces a poté vypotřebuje svůj procesorový čas. Systém probouzení kamaráda způsobí, že plánovač přenastaví svůj mechanismus výběru tak, aby byl právě probuzený proces zvýhodněn s tím, že pravděpodobně bude používat data, která vytvořil probouzející proces a která jsou již nahraná v cache. Tím, že je spolupracujícím procesům umožněno běžet o něco málo dříve, než by jim umožnil striktně férový plánující mechanismus, dostane plánovač větší výkon ze systému jako celku.
Nedávné změny přidávají koncept "zpětného kamaráda" [backward buddy]. Jestliže není k mání žádný nedávno probuzený proces, na který by se mohlo přepnout, plánovač bude místo toho zvýhodňovat proces, který byl přerušen, aby procesu, kterému předal data, umožnil běžet. Je relativně dobrá šance, že by přerušený proces mohl (1) s tímto procesem spolupracovat nebo (2) mít stále nějaká data v cache - nebo obojí. Spustit tento proces jako další tedy pravděpodobně umožní celkové zlepšení výkonu.
Bylo začleněno mnoho dalších malých změn, takže vývojáři plánovače si nyní myslí, že regrese v tbench již nejsou jejich problém. Správce síťování David Miller nicméně s tímto hodnocením nesouhlasí s tím, že v plánovači stále existují problémy s výkonností. Ingo reagoval několika způsoby, z nichž první bylo zaslání několika výsledků profilování, které ukazují velmi nízkou režii plánovače. Zajímavé je, že se ukázalo, že vývojáři síťování ze svého profilování mají jiné výsledky než vývojáři plánovače. A následně, že to je důsledkem různosti hardwaru, který používají ke své práci. Ingo si hraje s bleeding-edge procesorem od Intelu; lidé od síťování mají procesory, které nejsou až tak nové. David Miller většinou pracuje na SPARC procesorech, které mohou přidávat jedinečné problémy samy o sobě.
Další věc, kterou Ingo udělal, bylo, z čistě praktických důvodů, profilování celé cesty jaderného kódu, která je v běhu tbench zahrnuta. Poté spustitelný soubor disassembloval a zkoumal výsledky profilování na úrovni jednotlivých instrukcí. Výsledky (příklad) ukazují na mnoho potenciálních problémových míst, většina z nich je v kódu síťování. Některé z nich již byly opraveny, zatímco o jiných probíhají dohady. Konec konců jde o velké množství surových dat, která budou po nějaký čas diskuzi živit.
Někomu z vnějšku by toto celé mohlo připadat jako cvičení v ukazování prstem. A možná tomu tak skutečně je. Nicméně jde o vysoce technické ukazování prstem, které rozšířilo náhled na to, jak jádro reaguje na specifický typ zátěže, a zároveň demonstrovalo omezení některých měřících nástrojů a výkonnostních rozdílů, které se projevují na různých typech hardwaru. Výsledkem nakonec bude rychlejší a vyladěnější jádro - a také lepší čísla u tbench.
Arnd Bergmann si na nedávné UKUUG konferenci Linux 2008 vzal dvojitou směnu a přednášel každý den. Jeho sobotní přednáška nazvaná "Portování Linuxu na nové architektury, správným způsobem", se dívala na různé problémy s nedávnými porty na nové architektury a také na projekt, na kterém pracuje, aby se tento proces zjednodušil. Vytvořením obecné šablony pro architektury se lze některým chybám z minulosti vyhnout.
Tento projekt je jedním z Arndových dítek, na kterých pracuje pro zábavu, když hackuje jádro, ale ne pro IBM. Projekt a přednáška byly inspirovány několika novými architekturami, které byly začleněny - nebo byly zaslány k začlenění - v posledních několika letech. Konkrétně byly inspirací architektury Blackfin a MicroBlaze, kde ta druhá v pořadí stále není začleněna, možná kvůli Arndovým připomínkám. Arnd doufá, že pomůže, aby se věci zlepšily.
Největší problém s portem architektury bývá duplikování kódu, protože lidé začínají kopírováním všech existujících souborů z existující architektury. Navíc většina lidí, kteří neví, co dělají, kopírují z x86, což je podle mě velká chyba. Podle Arnda ti, kteří portují na novou architekturu, nejdříve zkopírují hlavičkové soubory a pak změní bílé znaky, což ztíží okamžité nalezení duplikovaného kódu.
Ukazuje na termbits.h jako na příklad hlavičkového souboru, který je v mnoha architekturách zbytečně duplikován, protože kód je ve většině případů stejný. Také poznamenává, že se objevuje špatná duplikace kódu, s poukazem na nové architektury, které implementují systémové volání sys_ipc(), což vede k tomu, že zcela nové architektury podporují rozbité rozhraní pro x86 unix z 80. let. Toto volání je demultiplexer pro IPC volání System V, které má komentář - svědomitě duplikovaný na jiné architektury - "Tohle je skutečně otřesně strašné".
Potom jsou zde problémy s duplikováním kódu lidmi, kteří nevědí, co mají dělat, což zahrnuje implementaci sembuf.h, která kvůli zmatení 64 vs. 32 bit umisťuje vycpávky na špatné místo. Navíc, protože je kód duplikován na mnoha místech, tak se opravy chyb, které jsou udělány na jedné architektuře, nešíří na všechna místa, která je potřeba opravit. Jako příklad ukázal opravu chyby, kterou vložil správce Sparc David Miller do x86 stromu, ale do Sparc stromu se nedostala. Nakonec je zde ABI, které je zbytečně šířeno do portů na nové architektury: systémová volání, která jsou implementována novějšími systémovými voláními, jsou v nových portech stále přítomna, i když je všechny lze vyřešit pomocí libc.
"Jasným" řešením je vytvořit implementaci obecné architektury, kterou by bylo možné použít jako výchozí bod pro nové porty. Arnd na tom pracuje, což vede na 3000řádkový patch, který by měl lidem velmi ulehčit portování na nové architektury. Pro začátek definuje kanonické ABI, které je seznamem systémových volání, jež je nutné na nové architektuře implementovat. Všechny potřebné hlavičkové soubory vkládá do adresáře asm-generic, který mohou nové porty jednoduše začlenit [include] - nebo kopírovat, pokud potřebují soubory změnit.
Věci bohužel samozřejmě nejsou tak jednoduché, je mnoho problémových oblastí. Je spousta věcí, které prostě nemůžete udělat obecně. Většina z těchto věcí je v hardwarově hodně specifických oblastech, jako je podpora MMU, atomické záležitosti, přerušení, přepínání úloh, pořadí bytů, kontexty signálů, testování hardwaru a podobných.
Arnd se rozhodl pokračovat definováním některých z těchto problémů ve své architektuře example (příklad). V příslušně upravených hlavičkových souborech asm-generic/atomic.h a asm-generic/mmu_context.h není žádná podpora pro SMP či MMU. Mnoho pro architektury specifických funkcí bylo v arch/example/kernel/dummy.c ořezáno, aby bylo možné šablonu přeložit.
Architektura example používá strom zařízení Open Firmware k popisu hardwaru, který je k dispozici v čase bootu. Open Firmware je trochu jako to, co máte v novém EFI firmwaru od Intelu, ale je o hodně hezčí. Datová struktura zploštěného stromu zařízení je v čase bootu předána jádru zavaděčem, takže Arnd bude schopen přejít k dalšímu kroku: donutit ji nabootovat.
Jak by se dalo hádat, zbývá spousta práce. Je osm hlavičkových souborů, které jsou potřeba z adresáře asm-example, ale Arnd doufá, že se mu počet podaří zmenšit. Poznamenává, že jsou další pro architektury specifické oblasti, které potřebují, aby na nich někdo pracoval. Každá architektura má například svou vlastní implementaci kontrolních součtů TCP v assembleru, což nemusí být optimální.
Arnd dal účastníkům odkaz na větev ukuug2008 svého pískoviště - gitového stromu na kernel.org: git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git, aby se mohli podívat na současný stav jeho příkladové architektury. Vypadá jako hezký přírůstek do jádra, který pravděpodobně povede k lepším portům na další architektury.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Díky, jako vždy zajímavé čtení.
31.12.2008 15:55
multi | skóre: 38
| blog: JaNejsemOdsut
by mezajimalo jak vypada ta propojka na PCIe a jak dlouha muze byt
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz