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.
Aktuální vývojová verze jádra je 3.15-rc3 vydaná 27. dubna. Máme za sebou další týden a další rc. Zatím nic hrozivého a rc3 je odpovídajícím způsobem menší než rc2, takže se to odvíjí správně.
Stabilní aktualizace: verze 3.14.2, 3.10.38 a 3.4.88 vyšly 26. dubna.
Nutnost restartovat systém kvůli instalaci opravy jádra je otravné. V mnoha případech je to dokonce ještě horší: systém(y), o které jde, mohou mít omezení týkající se dostupnosti, která znemožňují restartování dle potřeby. Uživatelé, kteří takovým nesnázím čelí, by často rádi měli způsob, jak dostat do jádra kritický patch bez nutnosti systém vypnout. Jako odpověď na toto se už v roce 2008 objevila první verze sady patchů Ksplice. Ksplice se nikdy ale nedostalo do hlavní řady jádra a po odkoupení Oraclem pravděpodobně z linuxového světa zmizelo. V poslední době bylo oznámeno několik alternativních patchů nabízejících podobnou funkčnost; jeden z nich – kGraft – byl nyní zaslán ke zvážení.
KGraft je prací Jiřího Kosiny a Jiřího Slabého ze SUSE. Přístup, který použili, je snazší než v případdě Ksplice a scházejí mu některé schopnosti, které Ksplice nabízí. Na druhou stranu má základní patch s kódem kGrafu jen 600 řádek a proces aplikace patchů je o dost jednodušší a s menším dopadem na systém.
KGraft funguje tak, že v jádře nahrazuje celé funkce. Za použití nástrojů dodaných s kGraftem může na základě patche jádra vytvořit seznam změněných funkcí; nové verze těchto funkcí jsou pak zkompilovány do odděleného jaderného modulu. Jakmile je tento modul nahrán do jádra, kGraft se postará o nahrazení stávajících porouchaných funkcí jejich novými opravenými verzemi.
Toto nahrazování je poněkud zrádná věc; operování jádra za živa skýtá spousty nebezpečí. Dobrou zprávou pro vývojáře kGraftu je to, že tento problém už byl za ně z větší části vyřešen. Subsystém trasování funkcí (ftrace) potřebuje dělat právě tento typ patchování za běhu, takže se vývojáři ftrace už postarali o napsání kódu, který to zajistí, odladili všechny podivné vady a také to náležitě odnesli, když něco nefungovalo tak, jak by mělo. Vývojáři kGraftu zkrátka jen musí použít nástroje ftrace – které už umí zachytit volání funkcí v běžícím jádře – a použít je k nahrazení volání vadných funkcí za volání nového kódu.
Jsou tu samozřejmě ještě nějaká rizika. Tím největším z nich je: co se stane, když proces běží při aplikování patche zrovna v jaderném prostoru? Tento proces může jednou zavolat starou verzi funkce a krátce na to zavolat novou verzi; v závislosti na tom, co se mezitím změnilo, by to mohlo vést ke zmatení a k výpadkům, kterým se právě takto snažíme předejít. Při pohledu na tento problém dospěli vývojáři kGraftu k tomu závěru, že se dá problémům předejít, pokud žádný proces neuvidí dvě verze té samé funkce při jediném průchodu do jaderného prostoru a zpátky.
Proto patch přidává do struktury thread_info v každém procesu příznak, zda tento proces opustil nebo se vrátil do uživatelského prostoru od začátku aplikování patche. Jakmile je zachyceno volání staré funkce, „pomalý pahýl“ zkontroluje zmiňovaný příznak pro běžící proces; pokud proces vstoupil do prostoru jádra nebo jej opustil, tak se má za to, že běží ve „starém světě“ a dostane starou verzi této funkce. Jinak se řízení předává nové verzi. Jakmile každý proces v systému přešel do nového světa, pak může být pomalý pahýl odstraněn a nová funkce může být volána nepodmínečně.
A co s procesy, které tento přechod neprovedou v rozumném čase? Například proces zaseklý při čekání na I/O na síťovém socketu by mohl v jádře zůstat velmi dlouho a bránil by tak pročištění po operaci graft. Když Vojtěch Pavlík hovořil o této práci na březnovém Linux Foundation Collaboration Summitu, zmínil mechanismus, který by pomalým procesům poslal signál, aby byl přechod vynucen. Tento mechanismus ale není v zaslaném patchi přítomen. Na druhou stranu je pod /proc k dispozici příznak umožňující administrátorům identifikovat procesy, které brání dokončení operace.
Další otázka: co s jadernými vlákny, která nejsou spuštěna z uživatelského prostoru? Většina jaderných vláken, jakmile doběhnou do vhodného místa, zavolá kthread_should_stop(), aby zjistila, jestli se mají ukončit. Kód kgraft upravuje kthread_should_stop() tak, aby resetovalo příznak „starého světa“. Pro vlákna, která taková volání nedělají, vložili vývojáři kGraftu volání kgr_task_safe(), která na vhodných místech značí přechod do nového světa.
Nakonec tu máme otázku přerušení. Kód kgraftu může blokovat přerušení na lokálním CPU, zatímco provádí změny, ale nemůže je zablokovat globálně. Aby si kGraft byl jistý, že při běhu obsluhy přerušení nedojde k žádným překvapením, tak přidává pole specifické pro každé CPU, aby bylo možné sledovat, zda každý procesor běžel v kontextu procesu (mimo přerušení). Tento příznak je ze začátku nastavený na false a následně je zavoláno schedule_on_each_cpu(), aby došlo ke spuštění funkce kGraftu v kontextu procesu na každém z procesorů. Tato funkce, která nemůže být spuštěna, dokud jsou obsluhována přerušení na daném CPU, nastaví pro dané CPU příznak. Pahýl umístěný při nahrazování funkce mezitím vynutí to, aby kód z obsluhy přerušení používal kód ze starého světa, dokud nemá dané CPU nastavení příznak pro „nový svět“.
Tento článek byl napsán jen krátce po zaslání patche kGraft, proto doposud není moc co psát o reakcích, jaké vyvolal. Zatím se ale neobjevily žádné námitky k tomu, jak vývojáři celou věc pojali. Tato funkčnost má zjevný přínos, takže můžeme očekávat, že něco někdy bude začleněno. Nejistotu do rovnice vnáší další soupěřící patche, jež čekají na svou příležitost. V jádře není místo pro dva nebo více mechanismů pro patchování za běhu, takže tyto patche buď budou muset být sjednoceny, nebo bude někdo muset učinit rozhodnutí.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
operování jádra za živa
Pahýl je znám z české Wikipedie. Pomalý je běžný překlad běžného přívlastku. Navíc autor sousloví změkčil uvozovkami, jak pravidla žádají. Jinak řečeno tohle byl záměr a já jsem se dobře pobavil.
Oproti tomu pro termíny jako "directory", "mail folder" atp. je závěr přesně opačný, protože je přesně opačná i situace lidí, kteří je používají: jsou to už dnes laici žijící normálně v ČR, mluvící česky a používající tyto termíny v běžné mluvě i psané formě … Proto naopak považuji myšlenku národního obrození, samozřejmě moderně chápanou (bez nacionalistických extrémů), za nejen stále živou, ale zrovna v naší branži extrémně potřebnou.
Vytváření vlastních překladů (nebo někdy jen přepisů) termínů používaných v běžném životě je ale proces, který se děje v každé době a v každé zemi - a děje se i u národů, které byly vždy natolik svébytné, že hnutí odpovídající našemu národnímu obrození nikdy nepotřebovaly. Tím (ne)pokračováním v národním obrození jsem myslel právě to, že dnes už nejsme v situaci, kdy by bylo potřeba povzbuzovat umírajícího národního ducha tím, že bychom za každou cenu počešťovali úplně všechno.
Smysl live kernel patching není vyhnout se odstávkám úplně. Jde o to, aby v případě kritické chyby v jádře (např. remote root exploit) bylo možné odložit tu odstávku na reboot do doby, kdy se to bude hodit (až update projde interní QA zákazníka, až bude maintanance window, až doběhne měsíc trvající simulace, …).
Rozhodně je tedy mylná představa, že se budou live patche generovat pro všechny opravy (to obecně ani nejde) a rebootovat se nebude nikdy. Jde o to, aby když přijde kritický problém, s jehož opravou nelze čekat dny až týdny, opatchovalo se živé jádro a s rebootem na nový update se mohlo počkat na vhodný okamžik.
Ono uplne klidne staci aby se muslimove a zide mezi sebou dohodli jestli vypadek bude v patek, sobotu anebo v nedeli.Jo, ten byl dobrej, diky
S tim RACem to ale moc nechapu. Zrovna tehle SW taky umi hot-patching.Sam sebe jiste opatchovat umi, ale kdyz je chyba v externi knihovne, treba OpenSSL nebo v GLibc tak ti to nepomuze.
Kdyz uz mas tendle napad... muzes zkusit napsat vlastni nastroj pro patchovani userspace-u a udelat hype kolem nehoJdu na to. Pojmenuju to usplice a pak to zkusim prodat Oraclu za mega penez ;)
zatím to vypadá na hybrid, který se blíží ideálu mikrojádra s tunou modulů pro každý úkol včetně uprdnutí si
To si vůbec nemyslím. I kernel thready běží pořád ve stejném paměťovém prostoru a se stejnou úrovní oprávnění jako "core" jádro. Navíc když si vezmu typický driver zařízení, třeba síťové karty, tak mám sice oddělenou hardirq a softirq část, ale nejen že IRQ handler je součástí jádra, ale ani ta softirq část neběží zdaleka vždy v rámci kernel threadu. Takže ideálu mikrokernelu, kde by byly drivery zařízení striktně odděleny od "core" jádra, nejsme o moc blíž než na začátku.
I kernel thready běží pořád ve stejném paměťovém prostoru a se stejnou úrovní oprávnění jako "core" jádroTo je vlastně fakt. Jenže díky tomu taky hodně stoupá složitost samotného monolitického blobu. Ono už z názvů funkcí lze vytušit, že provést nějaký jednoduchý úkol v jádře nemusí být jenom tak. Tohleto on-line patchování tomu jen nasazuje korunku (přitom by stačilo zabít příslušný proces a spustit ho znova).
Ten nárůst komplexity je zjevný, ale ona není samoúčelná. Ve starých jádrech sice byla spousta věcí jednodušší, ale tehdejší jádra nemusela být schopna běhat na 4096 procesorech a obsluhovat 6 TB paměti nebo čtyřicetigigabitové ethernetové karty, život vývojářů nekomplikovaly věci jako namespaces nebo cgroups atd.
Pokud si dobře vzpomínám na někdejší debaty na téma monolitické jádro vs. mikrokernel, tak hlavní problém byl právě v tom, že úplně čistý mikrokernel měl sice spoustu designových předností, ale nikdo ho nedokázal implementovat tak, aby to bylo neprůstřelné a efektivitou se to vyrovnalo monolitickým jádrům. A za jeden z hlavních důvodů toho, proč se z mnoha různých systémů prosadil právě Linux, považuji to, že Linus je pragmatik, neopájí se tolik vznešenými idejemi a má čich na výběr toho řešení, které bude rozumně fungovat. Což ve výsledku znamená, že v Linuxu je sice spousta designových kompromisů a nouzových řešení, nad kterými srdce neplesá, ale na druhou stranu se moc často nestává, že by se prosadilo řešení, které je sice teoreticky dokonalé, ale v praxi buď pořádně nefunguje nebo je zoufale neefektivní.
Ve starých jádrech sice byla spousta věcí jednodušší, ale tehdejší jádra nemusela být schopna běhat na 4096 procesorech a obsluhovat 6 TB paměti nebo čtyřicetigigabitové ethernetové karty, život vývojářů nekomplikovaly věci jako namespaces nebo cgroups atd.Pravda. Jen by nebyly složité samotné subsystémy a ovladače, nýbrž servery v uživatelském prostoru.
Pokud si dobře vzpomínám na někdejší debaty na téma monolitické jádro vs. mikrokernel, tak hlavní problém byl právě v tom, že úplně čistý mikrokernel měl sice spoustu designových předností, ale nikdo ho nedokázal implementovat tak, aby to bylo neprůstřelné a efektivitou se to vyrovnalo monolitickým jádrům. A za jeden z hlavních důvodů toho, proč se z mnoha různých systémů prosadil právě Linux, považuji to, že Linus je pragmatik, neopájí se tolik vznešenými idejemi a má čich na výběr toho řešení, které bude rozumně fungovat. Což ve výsledku znamená, že v Linuxu je sice spousta designových kompromisů a nouzových řešení, nad kterými srdce neplesá, ale na druhou stranu se moc často nestává, že by se prosadilo řešení, které je sice teoreticky dokonalé, ale v praxi buď pořádně nefunguje nebo je zoufale neefektivní.Moje pozorování? Ten pragmatismus se k tomu idealismu vždycky pragmatickou cestou stejně propracuje. Dle mého názoru prostě složitost jádra furt poroste až jednoho dle prostě Linus prohlásí „Tenhle bloatware já udržovat nebudu. Smazat a znovu přepsat!“ a stejně se to k něčemu jako je GNU/Hurd jednou propracuje. Akorát to bude dýl trvat.
…a stejně se to k něčemu jako je GNU/Hurd jednou propracuje. Akorát to bude dýl trvat.
Dokud neuvidím, neuvěřím. :-)
Připomíná mi to, jak jsem se někdy v roce 1993 nebo 1994 začal zajímat o to, jak dostat na PC nějaký unixový systém, a kamarád mi zasvěceně vysvětloval, že unix, to už je odepsaná záležitost, že teď je skvělý nový systém plan9, který je navržen mnohem lépe a že to je budoucnost…
plan9, který je navržen mnohem lépe a že to je budoucnost…To je v podstatě to, o čem Grunt mluví. Vždyť linux k tomu už skoro dospěl, jen je podstatně ošklivější a táhne si s sebou některé opravdu nepěkné dedictví (tty například).
tty napříkladHuh? Co je špatně na tty?
Vždyť linux k tomu už skoro dospěl
Jak se to projevuje?
Opravdu myslíte, že takhle nějak si to lidé, kteří navrhovali plan9, představovali?Ne, to si nemyslím. Na druhou stranu spousta z technologií, které tam uvedli byla portována v nějaké alternativě do linuxu.
/proc
, používání UTF a FUSE jsou takové hlavní příklady, které nemusí být nutně tak elegantní, jak byly navrženy v plan9, ale funkčně jsou na tom dost podobně. Tím nechci hanit plan9, ani nějak vyzdvihovat linux.
Osobně by se mi líbilo, kdyby se plan9 pohnul k větší praktické použitelnosti a z dlouhodobého hlediska se mu chci věnovat víc, až na to někdy budu mít čas.
/proc, používání UTF a FUSE jsou takové hlavní příklady, které nemusí být nutně tak elegantní, jak byly navrženy v plan9, ale funkčně jsou na tom dost podobně
Tomu se tuším říká post hoc ergo propter hoc. Unicode se vyvíjel nezávisle na plan9 a postupný příklon k němu měl pramálo společného s tím, že si ho vybrali (i) v plan9. K FUSE už jsem se vyjádřil. A procfs existoval i v řadě jiných systémů, a to dokonce i před plan9. Stránka na wikipedii sice tvrdí, že implementace v Linuxu vznikla jako klon té z plan9, ovšem s poznámkou "citation needed". Ale i kdyby to byla pravda, stejně je to moc málo na to, aby se dalo tvrdit "Vždyť linux k tomu už skoro dospěl."
Unicode se vyvíjel nezávisle na plan9 a postupný příklon k němu měl pramálo společného s tím, že si ho vybrali (i) v plan9.Unicode vs UTF. Afaik UTF-8 vzniklo právě pro plan9, ale můžu se mýlit.
Ale i kdyby to byla pravda, stejně je to moc málo na to, aby se dalo tvrdit "Vždyť linux k tomu už skoro dospěl."Mě to stačí :)
Unicode vs UTF.
V tom případě ale také UTF vs. UTF-8.
Afaik UTF-8 vzniklo právě pro plan9, ale můžu se mýlit.
Podle wikipedie sice s poslední úpravou oproti předchozím kódováním přišel Ken Thompson, který v té době pracoval na plan9, a plan9 byl prvním systémem, který UTF-8 začal používat, ale přesto bych to nepovažoval za nějakou featuru převzatou z plan9.
Moje pozorování? Ten pragmatismus se k tomu idealismu vždycky pragmatickou cestou stejně propracuje.Tohle je docela dobré pozorování, které platí i v programovacích jazycích. Za pár (desítek) let bude vše hybrid mezi erlangem, smalltalkem a lispem :)
Co je ale důležitější Linuz umí vést projekt tak, aby jeho vývoj byl trvale udržitelný. Prostě žádné nakupení featur (včetně návrhových featur) s tím, že se to vyčistí později (na což nedojde a další vývojář v pořadí provede refaktor, protože není v jeho silách porozumět kódu, který napsal předchozí vývojář). A to není jen o pragmatismu.
+1