Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Jádro 4.2 bylo vydáno 30. srpna. Linus poznamenal, že ono týdenní zpoždění pravděpodobně nebylo nutné. "Soudě podle toho, jak málo se minulý týden stalo, by zřejmě nebylo chybou vydat 4.2 minulý týden. Ale i tak se podařilo přidat několik oprav, navíc nejde o to, že by zpožděním 4.2 měly vzniknout nějaké problémy." Hlavní funkce tohoto vydání zahrnují patche pro zásobníky bezpečnostních modulů, algoritmus pro řízení zahlcení metodou gradientu zpoždění, vylepšení pro writeback management v kontrolních skupinách a mnoho vylepšení pro infrastrukturu perzistentní paměti a další.
Vývojové jádro 4.3-rc1, bylo vydáno 12. září. "Rozhodl jsem se, že mě nezajímá nic, co se objeví zítra, a mohl bych tedy klidně zavřít začleňovací okno a udělat -rc1 vydání." I tak již bylo během tohoto začleňovacího okna začleněno na 10 756 neslučovacích sad změn.
Vývojové jádro 4.3-rc2 bylo vydáno 20. září. Linus k tomu řekl: "Jak bývá poslední dobou zvykem, rc2 je relativně malá, zřejmě proto, že chvíli trvá, než se začnou objevovat regresní reporty (a někteří aktivně čekají, až se rc2 začne testovat - vy strašpytlové)."
Stabilní aktualizace: 4.1.7, 3.14.52 a 3.10.88 byly vydány 13. září.
Stabilní aktualizace: 4.2.1, 4.1.8, 3.14.53 a 3.10.89 byly vydány 21. září.
Začleňovací okno 4.3 je otevřené, pro podrobnosti o začleněných součástech viz článek níže.
Přinutit dodavatele, aby si uvědomil, že má dobré obchodní důvody se vzdát, je specializovaná dovednost, obvykle praktikovaná po dlouhou dobu a úspěšně jen několika lidmi v oboru. Nestává se to samo od sebe, a určitě ne protože máte vztek na někoho, kdo si vzal něco, co prezentujete jako "zdarma", a navíc má tu drzost očekávat, že vám nebude muset platit."
Jako vážně. Kdy jste naposledy slyšeli někoho si stěžovat, že "napsal číslo 9223372036854775809, a počítač si myslel, že jsem myslel ´1´ - Jsem opravdu naštvaný."
K vydání 4.3-rc1 byly projednány všechny bezpečnostní problémy v uživatelském jmenném prostoru, kterých jsem si vědom.
Nakonec jsem si náhodou všiml, že v průběhu low-level testování se chování velmi viditelně změnilo, když jeden z mých psů proběhl kolem racku.
Linux Test Project (LTP) se dočkal stabilního vydání v září 2015. Předchozí vydání bylo v září. Toto vydání obsahuje řadu nových testovacích případů, včetně jednoho pro uživatelské jmenné prostory, virtuální síťová rozhraní, unmount2(), getrandom() a další. Navíc byly přepsány testovací případy pro síťové uživatelské prostory, přidány byly regresní testy pro inotyfy, cpuset, futex_wake()recvmsg(). O psaní LTP testovacích případů se na LWN psalo v lednu letošního roku.
Celý článek zde.
První týden po otevření začleňovacího okna 4.3 bylo začleněno 4000 neslučovacích sad změn. Mezi ty nejdůležitější patří:
V druhém týdnu bylo začleněno 6200 sad změn, za oba týdny celkem to dělá 10 200 neslučovacích sad změn. Do hlavního repozitáře se dostaly celkem zajímavé věci:
Třetí týden otevřeného začleňovacího okna přinesl mimo jiné tyto novinky:
Trvalá (perzistentní) paměť nabízí perspektivu velkých kusů (např. terabajtů) přímo připojené paměti, která si uchovává svůj obsah i po restartu nebo vypnutí systému. Nabízí také řadu zajímavých designových problémů, které se týkají toto, jak by měla být řízena; perzistentní paměť vypadá téměř jako obyčejná paměť, ale liší se v několika důležitých aspektech. Výsledkem je dlouhá diskuze o tom, jak se s touto pamětí vypořádat, a zejména, zda by jádro mělo používat struktury stránek k jejímu popisování či nikoli. Jak se ukazuje z několika posledních patchů, diskuze na toto téma se stále vyvíjí a vypadá to, na zajímavý výsledek problému se struct page.
Pro ty, kdo potřebuji rychlou rekapitulaci: struct page je základní datovou strukturou řízení paměti jádra. Pro každou stránku paměti systému existuje struct page. V současných jádrech postrádá perzistentní paměť doprovodné struktury stránek z jednoho prostého důvodu: množství paměti, které by drželo všechny tyto struktury, by bylo příliš vysoké. Jejich ukládání v matici trvalé paměti je možné (viz níže), ale struktury stránek se často mění, takže se nehodí pro ukládání trvalé paměti, která (1) bývá pomalá při zápisu, (2) se rychleji opotřebuje, je-li vystavena pravidelným zápisům.
Celý článek zde.
Společnosti, které využívají velká datová centra, mají zřejmou motivaci dostat z každého z velkého počtu jednotlivých strojů co nejvyšší možný výkon. Virtualizace a live migrace pomáhají tak, že povolují jednotlivým úkolům, aby byly přesunuty mezi jednotlivými stroji, takže každý může běžet při maximálním využití. Problém je, jakým způsobem se mají jednotlivé spolupracující úlohy při přesouvání datovým centrem najít. K řešení tohoto problému existuje několik řešení a jádro 4.3 nabídne další ve formě technologie, která se jmenuje identifikátor adresního vyhledávání nebo ILA.
ILA, která bude fungovat pouze na IPv6, je postavena na jednoduché myšlence: Každému úkolu datového centra je přidělen unikátní identifikátor, který není vázán na žádné konkrétní místo na síti. Identifikátor je součástí síťové IPv6 adresy úkolu, takže síťový subsystém může jednoduše směrovat pakety mezi sebou a měnit směrování (routing) podle toho, jak se úlohy pohybují mezi stroji.
Celý článek zde.
Rozhraní mezi jádrem a uživatelským prostorem je, v některých místech, překvapivě složité. Četné úkoly zahrnující předávání podrobných informací o hardwarových konfiguracích, stavech procesu a dalších - v obou směrech. Když se něco pokazí, zúží se komunikační kanál do kódu jednoho celého čísla, takže je pro vývojáře často těžké, zjistit co se vlastně děje. V minulosti bylo pro rozšíření rozhraní o hlášení chyb navrženo několik řešení, posledním je návrh Alexandra Šiškina, který se bohužel možná také nedostane dál než jeho předchůdci, ale ukazuje, že stále je zájem toto řešit.
Jako příklad může posloužit volání VIDIOC_S_FMT ioctl() ze subsystému médií. Jeho úkolem je nastavit formát obrázků ze zařízení (třeba fotoaparátu) do uživatelského prostoru. Vzhledem k obrovskému počtu různých formátů, obsahuje popis tohoto formátu, předaný z uživatelského prostoru do jádra, velké množství vzájemně souvisejících parametrů. Existuje mnoho způsobů, jak se může takový popis pokazit – a to ještě předtím, než do hry vstoupí vliv konkrétního ovladače. Pokud ovšem skutečně dojde k problému, jediné, co bude v uživatelském prostoru vidět bude, že volání VIDIOC_S_FMT vrátilo EIVAL. Jádro samozřejmě ví, kde se stala chyba, ale neexistuje způsob, jak tuto informaci komunikovat do uživatelského prostoru.
Celý článek zde.
Alokátor paměti jádra musí pracovat i při velkém souboru různých omezení, má-li při většině zatížení pracovat správně. V průběhu času vedla tato omezení k tomu, že se kód pro nízkoúrovňovou alokaci stal velmi složitý. Problém ovšem přetrvává a někdy se jako nejlepší řešení jeví odstranění části této komplexnosti v zájmu jednoduššího řešení. Patchset Mela Gormana koluje již nějakou dobu a vypadá to, že brzy dosáhne stádia zralosti. Určitě stojí za to se podívat jak je náročné, aby patchset správně fungoval na současných jádrech.
Alokátor, kterého se to týká, je stránkový low-level alokátor ("buddy allocator"). Nejmenší jednotka paměti, se kterou pracuje, je plná stránka (na většině systému je to 4096 bajtů). Slab alokátory (včetně kmalloc()) jsou postaveny na stránkových alokátorech, mají své zákonitosti, kterými se zde nebudeme zabývat.
Stránkový alokátor je hlavním zdrojem paměti systému, jestliže nemůže splnit požadavek, není paměť dostupná. Dostupnosti paměti se tedy věnuje značné úsilí, zvláště pro volání s vysokou prioritou, která nemohou počkat, až se paměť uvolní někde jinde. Alokace vyššího řádu (takové, které vyžadují více než jednu stránku fyzicky souvislé paměti) tento problém ještě více komplikují. Paměť má tendenci se v průběhu času fragmentovat, takže je těžké souvislé kusy najít. Vyvažování paměti na systémech NUMA přidává další zvrat. Všechna tato omezení (a další) se musí vyřešit bez toho, aniž by došlo ke zpomalení procesu v alokátoru samotném. Řešení tohoto problému vyžaduje značné množství složitého kódu, strašidelné heuristiky, atd. Není tedy překvapením, že začlenit do hlavního repozitáře změny správy paměti, může být dost složité.
Celý článek zde.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: