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 2.6.34-rc1; během minulého týdne nebyly vydány žádné nové předverze.
Stabilní aktualizace: 15. března byla vydána jádra 2.6.32.10 a 2.6.33.1, se 145 a 123 patchi jsou obě obrovská.
-- Ingo Molnár
-- Eric Sandeen
napsal Jonathan Corbet, 16. března 2010
Na konci vývojového cyklu 2.6.33 Linus naznačil, že příští začleňovací okno bude o něco kratší než obvykle. A 2.6.34-rc1 opravdu vyšlo 8. března, dvanáct dní po vydání 2.6.33. Mnoho stromů zůstalo kvůli této změně na mraze a zdá se, že to Linusovi vyhovuje.
I tak byly některé stromy přetaženy po vydání -rc1. Mezi ně patří strom trivial s obvyklým nákladem oprav pravopisu a dalšími malými změnami. Také se objevila velká sada změn v ARM, včetně podpory pro mnoho nových desek a zařízení. Řadič využívání paměti získal novou vlastnost pro práh [threshold], což umožňuje jemnější řízení a získávání informací o využívání paměti. A tak dál, celkem bylo (v době psaní tohoto článku) od vydání 2.6.34-rc1 začleněno 1000 změn.
Když se ale objevil poslední požadavek na přetažení SCSI, Linus v ten okamžik nakreslil čáru do písku. Linuse, jak se zdá, trochu unavuje to, co u některých správců subsystémů považuje za jednání na poslední chvíli.
Linus tedy říká, že má v plánu být v budoucnu ještě méně předvídatelný. Determinismus v této fázi vývojového procesu evidentně vede k chování, které nemá rád, takže v budoucnu vývojáři nebudou schopni říci, jak dlouhé začleňovací okno bude. V takovém prostředí většina správců subsystémů bude pracovat tak, jako by začleňovací okno bylo zkráceno na jediný týden – což byl nápad, který byl diskutován a odmítnut na Jaderném summitu 2009.
napsal Jonathan Corbet, 16. března 2010
Na patchích škálovatelnosti VFS Nick Piggin už pracuje nějaký ten pátek – což je pro nízkoúrovňovou práci zaměřenou na výkon běžné. Nedávno Nick začal patch dělit na menší části, přičemž každá z nich řeší jednu část problému a každou z nich lze zvažovat samostatně. Jeden z těchto kousků zavádí zajímavý mechanismus pro vzájemné vyloučení nazvaný velký čtenářský zámek [big reader lock] či „brzámek“ [brlock].
Těm, kteří si patch přečtou, budiž odpuštěno, když nebudou chápat, o co jde; cokoliv, co kombinuje záludné zamykání a třicetiřádková makra pro preprocessor, způsobuje vrásky na čele. Základní koncept je ale jednoduchý: Brzámek se snaží zajistit, aby zamykání pouze pro čtení bylo tak rychlé, jak to jenom jde, tak, že vytvoří pole spinlocků, pro každé CPU jeden. Kdykoliv CPU potřebuje získat zámek pouze pro čtení, zabere vlastní zámek. Zamykání pro čtení je tedy lokální pro CPU a neobjevuje se žádné odrážení řádku cache [cache line bouncing]. A vzhledem k tomu, že soupeření o spinlock specifický pro CPU by ve skutečnosti mělo být nulové, tento zámek bude rychlý.
Život je o trochu ošklivější, když je potřeba získat zámek pro přístup pro zápis. Ve zkratce: Nešťastné CPU musí projít celé pole a získat spinlock všech CPU. Na 64procesorovém systému je tedy potřeba získat 64 zámků. To rychlé nebude ani v případě, že se o žádný zámek nebude soupeřit. Tento typ zámku by se tedy měl používat zřídka a jenom v případech, kdy téměř zcela převažuje přístup pro čtení.
Jeden takový případ – cíl tohoto zámku – je vfsmount_lock, který je vyžadován (pro čtení) při vyhledávání cest [pathname lookup]. Tato vyhledávání jsou častá a zjevně kritická pro výkonnost. Na druhou stranu je přístup pro zápis potřeba pouze v případě, kdy se připojuje nebo odpojuje souborový systém – což se děje mnohem méně často. Brzámek se sem tedy velmi dobře hodí a jeden (z mnoha) malých kousků puzzle škálovatelnosti VFS je na místě.
napsal Jonathan Corbet, 16. března 2010
Mezi běžná pravidla jádra patří to, že se snaží vyhnout spotřebování většího množství zdrojů, než je nezbytně nutné; systémový čas je lépe využíván programy v uživatelském prostoru. Patch pro zabrání CPU Tejuna Heo je tedy možná trochu překvapující; vytváří mechanismus, kterým si jádro může vyhradit monopol na jedno či více CPU a spustit na něm nicnedělající proces o vysoké prioritě. Tato sada patchů má ale dobré odůvodnění; a dokonce může v některých situacích vylepšit výkonnost.
Předpokládejme, že chceme zabrat jedno nebo více CPU v systému. První krok je vytvoření zabírací [hogging] funkce:
#include <linux/cpuhog.h> typedef int (*cpuhog_fn_t)(void *arg);
Když přijde čas na zabírání, je tato funkce zavolána s nejvyšší možnou prioritou. Jestliže je cílem opravdu CPU zabrat, tato funkce by pravděpodobně měla běžet v těsné smyčce. Je ale potřeba zajistit, aby tato smyčka mohla někdy skončit; nikdo pravděpodobně nebude chtít vyřadit CPU navždy.
Zabrání procesoru se provádí jednou z funkcí:
int hog_one_cpu(unsigned int cpu, cpuhog_fn_t fn, void *arg); void hog_one_cpu_nowait(unsigned int cpu, cpuhog_fn_t fn, void *arg, struct cpuhog_work *work_buf); int hog_cpus(const struct cpumask *cpumask, cpuhog_fn_t fn, void *arg); int try_hog_cpus(const struct cpumask *cpumask, cpuhog_fn_t fn, void *arg);
Volání hog_one_cpu() způsobí, že se daná fn() spustí na cpu v režimu kompletního zabrání; volající proces bude čekat, než se fn() vrátí; v tu chvíli je předána návratová hodnota fn(). Pokud je potřeba zároveň s tím dělat nějakou užitečnou práci (na jiném CPU), je potřeba použít hog_one_cpu_nowait(); vrátí se okamžitě, přičemž fn() může v tom okamžiku ještě běžet. Strukturu work_buf musí alokovat volající a nepoužívat ji, o víc se ale volající starat nemusí.
Někdy není úplná kontrola nad jedním CPU dostačující; v takovém případě lze volat hog_cpus(), která spustí fn() naráz na všech CPU stanovených cpumask. Varianta try_hog_cpus() je podobná, ale na rozdíl od hog_cpus() nečeká, pokud někdo zabral CPU před ní.
K čemu by tento mechanismus tedy mohl být? Jedna možnost je stop_machine(), která se volá, aby se zajistilo, že se v systému chvíli nebude vůbec nic dít. stop_machine() se obvykle volá, když v systému probíhají zásadní změny – například jsou vkládány dynamické sondy, nahrávány jaderné moduly nebo odstraňována CPU. To vždy fungovalo stejným způsobem jako funkce pro zabrání CPU – spuštěním vlákna o vysoké prioritě na každém procesoru.
Nová implementace stop_machine() přirozeně používá hog_cpus(). Na rozdíl od předchozí implementace (která využívala pracovní fronty) nový kód využívá vlákna pro zabírání CPU, která již existují. To odstraňuje výkonnostní bug, který nahlásil Dimitri Sivanich, kde je množství času potřebného pro boot systému zdvojnásobeno kvůli režii různých volání stop_machine().
Další využití je vynucení toho, aby každé CPU rychle prošlo plánovačem; to může být užitečné, pokud chce systém vynutit přechod do nového ochranného období [grace period] při čtení-kopírování-zápisu. Dříve byla tato úloha poněkud podivným způsobem zabudována do vlákna migration, které již nyní běží na každém CPU jedno; nyní se používá přímočaré volání pro zabrání CPU.
Vlákno migration je samo o sobě také uživatelem funkce pro zabrání jednoho CPU. Toto vlákno přichází ke slovu, když chce systém přestěhovat proces běžící na daném CPU. První věc, kterou je potřeba udělat, je vysídlit tento proces z CPU – úkol, pro který se zabírání CPU dobře hodí. Jakmile zabírací funkce CPU převezme, právě vystěhovaný proces lze přestěhovat do nového domova.
Konečným výsledkem je odstranění slušného množství kódu, pročištění implementace vlákna migration a zlepšení výkonnosti stop_machine(). Objevily se obavy, že pokud by jako zabírající funkce byla předána funkce, která blokuje, mohlo by to v některých situacích způsobit problémy. Blokování při zabírání CPU se ale zdá být z principu kontradikce; lze očekávat, že obvyklá reakce bude „to nedělej“. A druhá verze patche dokonce zakazuje v zabíracích funkcích spát. Reakce „to nedělej“ bude samozřejmě i odpověď na většinu použití zabírání CPU obecně; zabírání procesorů v jádře je stále ve většině případů považováno za nespolečenské.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: