Singularity je rootkit ve formě jaderného modulu (Linux Kernel Module), s otevřeným zdrojovým kódem dostupným pod licencí MIT. Tento rootkit je určený pro moderní linuxová jádra 6.x a poskytuje své 'komplexní skryté funkce' prostřednictvím hookingu systémových volání pomocí ftrace. Pro nadšence je k dispozici podrobnější popis rootkitu na blogu autora, případně v článku na LWN.net. Projekt je zamýšlen jako pomůcka pro bezpečnostní experty a výzkumníky, takže instalujte pouze na vlastní nebezpečí a raději pouze do vlastních strojů 😉.
Iconify je seznam a galerie kolekcí vektorových open-source ikon, ke stažení je přes 275000 ikon z více jak dvou set sad. Tento rovněž open-source projekt dává vývojářům k dispozici i API pro snadnou integraci svobodných ikon do jejich projektů.
Dle plánu certifikační autorita Let's Encrypt nově vydává také certifikáty s šestidenní platností (160 hodin) s možností vystavit je na IP adresu.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 14.0 (Mastodon). Forgejo je fork Gitei.
Just the Browser je projekt, 'který vám pomůže v internetovém prohlížeči deaktivovat funkce umělé inteligence, telemetrii, sponzorovaný obsah, integraci produktů a další nepříjemnosti' (repozitář na GitHubu). Využívá k tomu skrytá nastavení ve webových prohlížečích, určená původně pro firmy a organizace ('enterprise policies'). Pod linuxem je skriptem pro automatickou úpravu nastavení prozatím podporován pouze prohlížeč Firefox.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.18. Díky 174 přispěvatelům.
Miliardy korun na digitalizaci služeb státu nestačily. Stát do ní v letech 2020 až 2024 vložil víc než 50 miliard korun, ale původní cíl se nepodařilo splnit. Od loňského února měly být služby státu plně digitalizované a občané měli mít právo komunikovat se státem digitálně. Do tohoto data se povedlo plně digitalizovat 18 procent agendových služeb státu. Dnes to uvedl Nejvyšší kontrolní úřad (NKÚ) v souhrnné zprávě o stavu digitalizace v Česku. Zpráva vychází z výsledků víc než 50 kontrol, které NKÚ v posledních pěti letech v tomto oboru uskutečnil.
Nadace Wikimedia, která je provozovatelem internetové encyklopedie Wikipedia, oznámila u příležitosti 25. výročí vzniku encyklopedie nové licenční dohody s firmami vyvíjejícími umělou inteligenci (AI). Mezi partnery encyklopedie tak nově patří Microsoft, Amazon a Meta Platforms, ale také start-up Perplexity a francouzská společnost Mistral AI. Wikimedia má podobnou dohodu od roku 2022 také se společností Google ze skupiny
… více »D7VK byl vydán ve verzi 1.2. Jedná se o fork DXVK implementující překlad volání Direct3D 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána verze 12.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Současně byl ve verzi 12.0.0 vydán související modul pro Python libvirt-python. Přehled novinek v poznámkách k vydání.
Současné vývojové jádro je stále 2.6.37-rc5; minulý týden nevyšly žádné předverze. Linus se vrátil z cest a začal znovu začleňovat patche, takže novou verzi lze očekávat v blízké budoucnosti.
Stabilní aktualizace: 9. prosince vyšly aktualizace 2.6.27.57, 2.6.32.27 a 2.6.36.2. Greg Kroah-Hartman poznamenává, že to je poslední jádro 2.6.27, které vydal, a že jej k dlouhodobé údržbě předává Willymu Tareauovi (ve shodě se změnami ve stabilních stromech, které oznámil 3. prosince.) 57 verzí za 791 dní, obsahovalo 1596 patchů (což není nejvíce pro stabilní řady, .32 to již překonalo.) [...] Když mluvíme o .32, silně doporučuji všem uživatelům .27 přechod ke stromu .32.
Aktualizace 2.6.35.10 byla svým novým správcem Andi Kleenem vydána - s více než 200 patchi - 15. prosince. Andi říká: Tato verze obsahuje bezpečnostní opravy a všem uživatelům je doporučeno aktualizovat.
-- Linus Torvalds potřebuje port gitu na Android
napsal Jonathan Corbet, 15 prosince 2010
Současná CPU mají zajímavou vlastnost: dokáží poznat, že virtualizovaný host čeká ve smyčce na zámek, a předat tuto informaci jádru hostitele. Účelem je zajistit, aby hostitel mohl najít něco lepšího, co by procesor mohl dělat. KVM na to v současnosti zareaguje tím, že se na chvíli uspí, což umožňuje běh procesů mimo virtualizovaný systém. Jak ale upozornil Rik van Riel, to nemusí být správně.
Jestliže jedno vlákno ve virtualizovaném systému čeká na zámek, pak jiné vlákno v tomto systému musí ten zámek držet. Místo pozastavení celého hosta je lepší spustit vlákno, které drží zámek, aby ho bylo možné uvolnit. Pozastavení hosta jenom zpozdí uvolnění zámku, takže virtuální stroj jako celek je penalizován; to, jak říká Rik, vede k situaci, kdy hostu s Windows a 64 VCPU trvá věčnost a ještě něco k tomu, než nabootuje. Můžeme být v pokušení prostě obvinit Windows, ale pravděpodobně bude lepší problém opravit.
Rik mění to, jak se obsluha zachycené události [trap handler] chová; místo toho, aby se CPU vzdala úplně, vezme časový podíl vlákna čekajícího v cyklu a předá ho procesu na jiném CPU. Doufá se, že příjemce tohoto daru (efektivně se jedná o zvýšení priority) bude ten, kdo drží zámek, ale v současnosti to není nijak garantováno. Tato funkce je implementována novou funkcí yield_to(), o které Rik říká, že by ji bylo možné změnit na systémové volání, pokud by se ukázalo, že to bude užitečné.
Patch prošel několika koly revizí a možná si najde cestu do 2.6.38.
napsal Jonathan Corbet, 13 prosince 2010
Virtualizace na hostitelský systém přináší nějaké zajímavé požadavky, mnoho z nich se týká správy paměti. Když dva prvky na stejném systému věří, že mají paměť na povel, musí nastat zajímavé konflikty. Nedávný patch, jehož autorem je Balbir Singh, ukazuje snahu na tyto konflikty reagovat, ale také naznačuje mnohem ambicióznější snahu o to, jak problém vyřešit.
Cache stránek v Linuxu udržuje v hlavní paměti kopie stránek a doufá, že se vyhne I/O operacím, když se k těmto stránkám přistupuje. Ve většině situací si cache stránek může snadno vzít více než polovinu z celkové paměti systému. Skutečná velikost cache stránek se postupem času mění; když narůstá objem paměti využité jinak (paměť jádra, anonymní stránky), cache stránek se zmenší, aby udělala místo. Balancování mezi požadavky cache stránek a ostatními uživateli paměti může být náročné, ale Linux to většinou dělá skoro správně.
Balbirův patch má správci systému dát o něco větší kontrolu nad využíváním cache stránek; za tímto účelem poskytuje nový parametr předávaný při bootu (unmapped_page_control), který nastavuje horní hranici počtu odmapovaných stránek v cache. „Odmapované“ [unmapped] stránky jsou takové, které nejsou namapovány do adresového prostoru žádného procesu – neobjevují se v žádné tabulce stránek [page table]. Odmapované stránky mají menší šanci, že je někdo bude v nejbližší budoucnosti potřebovat; systém se jich také může snáze zbavit. Tento patch tedy správci systému umožňuje relativně snadno minimalizovat spotřebu paměti cachí stránek.
Zjevná otázka: proč? Když systém bude potřebovat paměť jinde, stránky z cache stránek se uklidí i tak, takže se nezdá, že by mělo smysl ji zmenšovat předčasně. Problém je, zdá se, virtualizace. Když proces na virtualizovaném systému načte stránku ze souboru, operační systém hosta uloží kopii ve své cache stránek. Skutečné čtení nicméně bude předáno (a vykonáno) hostitelem, který si také uloží kopii do cache stránek. Jedna stránka se tedy cachuje dvakrát – nebo také vícekrát, pokud ji používá více virtuálních strojů. Cachovat stránku může být dobré, ale cachovat několik kopií je dobré až moc.
To, co dělá Balbirův patch, by se dalo vysvětlit takto: vynutí vyklizení kopií stránek z cache stránek hosta, aby se minimalizovaly duplikátní kopie. Paměť, která se takto uvolní, může být zabrána balónovým ovladačem a vrácena hostiteli k produktivnějšímu použití někde jinde.
Taková technika by situaci mohla zjevně zlepšit. Menší duplikace je dobrá a když host bude některé z uvolněných stránek potřebovat, pravděpodobně se najdou v cache stránek hostitele. Nelze se nicméně nepozastavit nad tím, jestli tento přístup není až příliš nepřímý. Než vynuceně uvolňovat stránky z cachí hostitelů, nebylo by lepší, kdyby všechny systémy sdílely stejnou cache stránek? Jednu unifikovanou cache by bylo možné spravovat tak, aby se maximalizovala výkonnost celého systému; to by mělo vést k lepšímu výsledkům, než spravovat několik zdánlivě nezávislých cachí stránek.
Virtualizace založená na kontejnerech má přesně takový typ sjednocené cache, protože všechny kontejnery běží na stejném jádře. To může být jeden z důvodů, proč se kontejnery považují za výkonnější než plně virtualizované systémy. Dostat sdílenou cache do světa virtualizace by nicméně mohlo být poněkud náročné, což je pravděpodobně hlavní důvod, proč to nikdo ještě neudělal.
Pro začátek jsou tu jasné záležitosti spojené s bezpečností. Virtualizovaný systém by neměl mít možnost přistupovat ke zdrojům, které mu nebyly přiřazeny. Jakákoliv sdílená cache stránek by se musela navrhnout tak, aby hostitel měl kontrolu nad tím, které stránky který host vidí. Prakticky by to znamenalo používat virtualizované blokové oladače, které nyní virtualizovaným hostům zpřístupňují souborové systémy. Místo „načtení“ stránky do stránky pod kontrolou hosta by ovladač mohl nějak namapovat kopii hostitele do adresového prostoru hosta.
Aby to fungovalo správně, muselo by se přidat nové, linuxové API mezi hostem a hostitelem. Bylo by těžké udělat to tak, aby se udržovala iluze, že host běží na vlastním hardwaru. Takovéto schéma by zkomplikovalo správu paměti hosta – hardware je sice čím dál tím dynamičtější, ale jednotlivé stránky ještě pořád nepřicházejí a nemizí spontánně. Sdílená cache stránek by také překážela pokusům používat pro paměť hosta obrovské stránky.
Jinými slovy potíže spojené se sdílením cache stránek mezi hostem a hostitelem rozhodně nevypadají triviálně. Není překvapením, že stále žijeme ve světě, kde se vzácné stránky v paměti plní duplikovanými kopiemi dat. Dokud se tato situace nezmění, bude tu místo pro patche, díky kterým se hosté budou chovat přátelštěji k systému jako celku.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
3.1.2011 11:04
Pavel Stárek | skóre: 43
| blog: Tady bloguju já :-)
| Kolín
.
5.1.2011 18:41
Gilhad | skóre: 20
| blog: gilhadoviny
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz