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.
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í.
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: 44
| 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