Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,742 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější český počítač C24 klesl na 165 místo. Karolina, GPU partition klesla na 195. místo a Karolina, CPU partition na 421. místo. Další přehledy a statistiky na stránkách projektu.
Oficiálně byl vydán Android 16. Detaily na blogu a stránkách věnovaných vývojářům.
Byla vydána nová verze 14.3 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
CSIRT.CZ upozorňuje, že na základě rozhodnutí federálního soudu ve Spojených státech budou veškeré konverzace uživatelů s ChatGPT uchovávány. Včetně těch smazaných.
Ač semestr ve škole právě končí, bastlíři ze studentského klubu Silicon Hill neodpočívají a opět se jako každý měsíc hlásí s pravidelným bastlířským setkáním Virtuální Bastlírna, kde si můžete s ostatními techniky popovídat jako u piva o novinkách, o elektronice, softwaru, vědě, technice obecně, ale také o bizarních tématech, která se za poslední měsíc na internetu vyskytla.
Z novinek za zmínku stojí Maker Faire, kde Pájeníčko předvedlo … více »Na WWDC25 byl představen balíček Containerization a nástroj container pro spouštění linuxových kontejnerů na macOS. Jedná se o open source software pod licencí Apache 2.0 napsaný v programovacím jazyce Swift.
Do 16. června do 19:00 běží na Steamu přehlídka nadcházejících her Festival Steam Next | červen 2025 doplněná demoverzemi, přenosy a dalšími aktivitami. Demoverze lze hrát zdarma.
Apple na své vývojářské konferenci WWDC25 (Worldwide Developers Conference, keynote) představil řadu novinek: designový materiál Liquid Glass, iOS 26, iPadOS 26, macOS Tahoe 26, watchOS 26, visionOS 26, tvOS 26, nové funkce Apple Intelligence, …
Organizátoři konference LinuxDays 2025, jež proběhne o víkendu 4. a 5. října 2025 v Praze na FIT ČVUT, spustili přihlašování přednášek (do 31. srpna) a sběr námětů na zlepšení.
Po roce byla vydána nová stabilní verze 25.6.0 svobodného multiplatformního multimediálního přehrávače SMPlayer (Wikipedie).
Vývojové jádro 3.17-rc4 vyšlo dne 7. září (oznámení). po týdnu, který byl, alespoň ke konci, podle Linuse „celkem normální“. Linus k tomu řekl:
Celkem normální docela ujde a já si nestěžuju. Neděje se nic zvlášť velkého ani hrozného – na chvíli nás vyděsila hloupá chyba ve vrstvě kompatibility, ale zdá se, že šlo jen o planý poplach, který vyústil spíš v přidání nějakého komentáře než ve změny ve zdrojovém kódu.
Stabilní aktualizace: 5. září byly vydány verze 3.16.2 (oznámení), 3.14.18 (oznámení) a 3.10.54 (oznámení). Nedodělky v implementaci oprav jsou momentálně údajně velké, v dohledné době tedy čekejte víc (větších) aktualizací.
- .set_mux = pcs_sex_mux,
+ .set_mux = pcs_set_mux,
Linus Walleij (odkaz) opravil „freudovské přeřeknutí“ (díky Jonu Mastersovi)
Před pár lety se vývojáři jádra krátce pokoušeli převést veškeré zjišťování zařízení na asynchronní činnost. To vedlo ke komplikacím, které byly natolik obtížně řešitelné, aby byly tyto snahy označeny za neperspektivní a všechny změny byly vráceny. Nyní se asynchronní zjišťování vrátilo na pořad jednání. Tato myšlenka se nesetkává s obecně pozitivním přijetím, ale problém, který se snaží řešit, je skutečný. A poněkud podivný.
Všechno začalo v listopadu 2013, kdy Tetsuo Handa napsal opravu, která umožňuje násilně ukončit funkci jádra kthread_create(), která vytváří a spouští vlákno jádra (tedy, že je ukončena signálem SIGKILL). Před touto změnou byl jakýkoli proces spuštěný ve funkci kthread_create() dočasně imunní k signálu SIGKILL, konkrétně nereagoval, pokud ukončovací proces OOM (vyčerpání paměti) vyhodnotil, že je toto ukončení nutné. I když se dá nesouhlasit s heuristikou, podle které tento proces vybírá své oběti, jen málo vývojářů se domnívá, že by tyto oběti, když už jsou vybrané, měly v systému zůstávat po libovolnou dobu. S Tetsuovou změnou není proces, který způsobil vytvoření vlákna jádra, dále imunní před výpady ukončovacího procesu OOM.
Tato oprava způsobila, že některé systému nebylo možné spustit. Spousta ovladačů úložných systémů vyžaduje k dokončení procesu zjišťování polí úložišť vlákna jádra. Tento postup zjišťování si může vyžádat velký objem práce, takže může běžet třeba i minutu. Podle všeho nemá systemd-udev neomezenou trpělivost; při načítání modulu zařízení spustí 30sekundový časovač (zkrácený z loňských 3 minut) a při překročení tohoto limitu proces načítání ukončí (signálem SIGKILL). Proces zjišťující pole úložišť je tedy ukončen, sestavení pole selže a systém se nespustí. Před Tetsuovou změnou byl tento signál při zjišťování ignorován; po ní se stal fatální. Tento problém se může dotknout i dalších typů ovladačů, které musejí stahoval velké firmwary.
Výsledná diskuse se rozprostřela v několika diskusních fórech a systémech sledování chyb, takže ji bylo obtížné sledovat. Vývojáři jádra podle všeho sdíleli názor, že napevno nastavený 30sekundový limit v systemd-udev není dobrý nápad a že problém by se měl řešit zde. Vývojáři systemd se domnívají, že modul, který se načítá déle než 30 sekund, je zkrátka chybný a měl by se opravit. Tetsuo navrhl, že funkce kthread_create() by měla na signál SIGKILL reagovat se zpožděním 10 sekund, pokud příslušný signál pochází odjinud než ze správy OOM. Ani jeden z těchto návrhů nebyl obecně přijat ani nevedl k řešení problému.
Existuje samozřejmě možnost prostého prodloužení časového limitu v konfiguračních souborech, jak to udělali vývojáři mapovače zařízení v reakci na obdobný problém. Tento přístup ale nikdo nepovažuje za příliš elegantní.
Tento problém lze řešit ještě jinak – ovladače zařízení by se při spouštění mohly prostě registrovat a provádět činnosti, které lze rychle dokončit. Všechny časově náročné úlohy by se předávaly do samostatného vlákna spuštěného asynchronně, po načtení modulů a ukončení aktivity systemd-udev. Tento způsob asynchronní inicializace by navíc zlepšil dobu spouštění, protože by během pomalého zjišťování mohly probíhat další činnosti.
V tom ohledu zveřejnil Luis Rodriguez sadu oprav, které do jádra ovladačů přidávají asynchronní zjišťování. Tyto opravy přidávají pole (async_probe) do struktury struct device_driver; pokud má toto pole hodnotu true, zjišťování zařízení bude probíhat asynchronně prostřednictvím pracovní fronty. Byly upraveny tři ovladače (pata_marvell, cxgb4 a mptsas) tak, aby požadovaly nový asynchronní přístup. Existuje také varianta Tetsuovy opravy s 10sekundovým zpožděním, která je primárně určena k zápisu upozornění do systémového žurnálu v případě, že správa OOM vydá signál SIGKILL funkci kthread_create(); má pomoci identifikovat další ovladače, které je nutné převést na asynchronní režim.
Tejun Heo, který také spravuje vrstvu ATA, pro tento přístup není. Nakonec má námitky ke dvěma problémům:
Druhý problém je kontroverznější. Moderní distribuce časovou posloupnost připojování zařízení k systému neřeší, proto někteří vývojáři namítají, že v téhle oblasti by už k žádným problémům docházet nemělo. Ale staré správcovské skripty se mohou zablokovat i na delší čas. Takže riziko narušení reálně fungujících systémů takovou změnou je skutečné, i když není jasné, kola systémů se může dotknout.
Některé reálně používané systémy už jsou samozřejmě narušené nyní, proto by se s tím mělo něco dělat. Nejpravděpodobnějším výsledkem bude nějaké asynchronní zjišťování prováděné v uživatelském prostoru; pokud to uživatelský prostor nebude explicitně vyžadovat, toto chování by se nemělo měnit. Pravděpodobným uplatněním tohoto přístupu je globální příznak, který asynchronní zjišťování zapne, s jednou výjimkou. Existuje velká pravděpodobnost, že libovolný kód v jádru volající funkci request_module() očekává, že zařízení požadovaného modulu bude k dispozici po dokončení volání. Proto moduly načítané tímto způsobem by se – alespoň prozatím – měly načítat synchronně.
U distribucí, kde správu polí úložišť řeší skripty dodané v distribuci, by měl být přepínač „použít asynchronní zjišťování“ standardně vždycky zapnutý. Ostatní budou vyžadovat nějaký manuální zásah. Není to nejlepší možné řešení, ale mohlo by být nejvhodnější v nejbližší budoucnosti.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Výsledná diskuse se rozprostřela po několika seznamech a sledování chyb
Ty "seznamy" mají být mailing listy? A nemohlo by to být aspoň něco jako "systémy (pro) sledování chyb", aby k pochopení věty nebyl potřeba překlad zpátky do angličtiny?
.set_mux = pcs_sex_mux,
A tohle šlo zkompilovat?
Podle všeho nemá systemd-udev neomezenou trpělivost; při načítání modulu zařízení spustí 30sekundový časovač (zkrácený z loňských 3 minut)...
V zásadě dneska spousta servisek (třeba Samba) při svém startu (init skriptem) považuje za samozřejmé, že jsou v okamžiku startu servisky mountnuté všechny svazky, které serviska potřebuje ke své práci.Zrovna tohle je v systemd světě řešitelné velmi jednoduše: přidáš do unit souboru dotyčné služby tvrdou závislost na daném zařízení a je to.
Zrovna tohle je v systemd světě řešitelné velmi jednodušeTakze, az si to precita Lenart, bude uz len otazkou casu, kedy systemd integruje kernel. (Nakolko je velmi nepravdepodobne, ze by kernel integroval systemd.) A naschval sa nevyjadrujem, ci to bude dobre, alebo zle... Zacinat so systemd v jadernych novinach je zaruceny flamewar. Skoda, ze sa nepocitaju komentar "hits"
Celkem normální docela ujde