Bylo oznámeno vydání Fedora Linuxu 43. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách Fedora Magazinu: Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Silverblue a Fedora Atomic Desktops.
Elon Musk oznámil (𝕏) spuštění internetové encyklopedie Grokipedia (Wikipedia). Zatím ve verzi 0.1. Verze 1.0 prý bude 10x lepší, ale i ve verzi 0.1 je podle Elona Muska již lepší než Wikipedia.
PSF (Python Software Foundation) po mnoha měsících práce získala grant ve výši 1,5 milionu dolarů od americké vládní NSF (National Science Foundation) v rámci programu "Bezpečnost, ochrana a soukromí open source ekosystémů" na zvýšení bezpečnosti Pythonu a PyPI. PSF ale nesouhlasí s předloženou podmínkou grantu, že během trvání finanční podpory nebude žádným způsobem podporovat diverzitu, rovnost a inkluzi (DEI). PSF má diverzitu přímo ve svém poslání (Mission) a proto grant odmítla.
Balík nástrojů Rust Coreutils / uutils coreutils, tj. nástrojů z GNU Coreutils napsaných v programovacím jazyce Rust, byl vydán ve verzi 0.3.0. Z 634 testů kompatibility Rust Coreutils s GNU Coreutils bylo úspěšných 532, tj. 83,91 %. V Ubuntu 25.10 se již používá Rust Coreutils místo GNU Coreutils, což může přinášet problémy, viz například nefunkční automatická aktualizace.
Od 3. listopadu 2025 budou muset nová rozšíření Firefoxu specifikovat, zda shromažďují nebo sdílejí osobní údaje. Po všech rozšířeních to bude vyžadováno někdy v první polovině roku 2026. Tyto informace se zobrazí uživateli, když začne instalovat rozšíření, spolu s veškerými oprávněními, která rozšíření požaduje.
Jste nuceni pracovat s Linuxem? Chybí vám pohodlí, které vám poskytoval Microsoft, když vás špehoval a sledoval všechno, co děláte? Nebojte se. Recall for Linux vám vrátí všechny skvělé funkce Windows Recall, které vám chyběly.
Společnost Fre(i)e Software oznámila, že má budget na práci na Debianu pro tablety s cílem jeho vyžívání pro vzdělávací účely. Jako uživatelské prostředí bude použito Lomiri.
Proběhla hackerská soutěž Pwn2Own Ireland 2025. Celkově bylo vyplaceno 1 024 750 dolarů za 73 unikátních zranitelností nultého dne (0-day). Vítězný Summoning Team si odnesl 187 500 dolarů. Shrnutí po jednotlivých dnech na blogu Zero Day Initiative (1. den, 2. den a 3. den) a na YouTube.
Byl publikován říjnový přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Pracuje se na podpoře M3. Zanedlouho vyjde Fedora Asahi Remix 43. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Iniciativa Open Device Partnership (ODP) nedávno představila projekt Patina. Jedná se o implementaci UEFI firmwaru v Rustu. Vývoj probíhá na GitHubu. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0. Nejnovější verze Patiny je 13.0.0.
Aktuální vývojová verze jádra je 3.10-rc6 vydaná 15. června. V oznámení Linus Torvalds zmínil, že počty patchů (226 od -rc5) se lehce snižují. Ale i pokud jste luddita a ještě jste se neseznámili s rozkošemi práce s gitem, pak byste jistě měli mít zájem používat poslední jádro. Tak se na to vrhněte a odhalte případné regrese. Protože oprav tam máme všude hodně...
Stabilní aktualizace: Greg Kroah-Hartman dne 13. června vydal stabilní jádra 3.9.6, 3.4.49 a 3.0.82. Stabilní jádro 3.2.47 vydal Ben Hutchings dne 19. června.
Jádra 3.9.4, 3.4.50 a 3.0.83 se aktuálně revidují a jejich vydání lze očekávat 20. června nebo krátce poté.
OK, ještě jsem tu nenašel žádnou chybu, ale ty tvé bývají zákeřnouškééé. My neradi zákeřnoušké a musíme najít miláška!
Kvůli tomuhle kódu začínám vypadat jako Glum.
Můj názor je ten, že se vším, co má co do činění s NetWarem, je nejlepší, když zacházejí fajn lidé z Miskatonické univerzity, a to se všemi náležitostmi, když se pracuje se zárodky po dávných bozích.
-- Al Viro
Když už jsme u toho, tak křečci jsou opravdu zlá stvoření.
Samozřejmě, že můžete svého malého chlupatého křečka Ferdíka mít rádi, ale pod roztomilým a skromným zevnějškem se skrývá vypočítavé a černé malé srdce.
Takže za zaklínání křečků není potřeba se omlouvat. Můžou si za to sami.
No jasně, rád se spokojím s „Můžu to udělat později“, pokud dotyčnému nebude zase vadit mé „Začlením to později“ :)
Nedávno se na LWN psalo o prvotním návrhu od Inga Molnara týkajícího se plánovače ohleduplného ke spotřebě energie. Fragmentace zodpovědnosti za správu výkonu CPU mezi plánovačem, frequency governorem a subsystémem CPUidle musí podle něho být nahrazena jednotným řešením, které umístí rozhodování týkající se správy výkonu na místo, kde je vždy nejvíce informací: do plánovače. Po tomto prohlášení následovala velmi živá diskuze a postupně se začíná rýsovat možné řešení. I nadále jde ale o složitý problém.
Převelení zodpovědnosti za rozhodnutí týkající se správy výkonu CPU na plánovač CPU má určitý šmrnc, plánovač je snad v dobrém postavení na to, aby věděl, zda systém bude v nejbližší době potřebovat výpočetní výkon. Ale tato myšlenka hned naráží na probém kvůli jinému trendu v jádře: rozhodnutí týkající se správy výkonu se přesouvají z plánovače do nízkoúrovňového kódu ovladačů. Jak Arjan van de Ven poznamenal už v květnu v diskuzi na Google+, politika správy výkonu u procesorů značky Intel se v posledních jádrech řeší v kódu specifickém pro tato CPU:
Ačkoliv si uvědomuji, že toto může být kontroverzní, tak říkám, že kombinujeme řídící algoritmus s ovladačem CPU na jediném místě. Pravdou je, že takové řídící algoritmy jsou specifické pro konkrétní CPU, idea obecných governorů „pro všechna CPU“ je už od začátku mylná; chování hardwaru je pro algoritmy klíčové.
Arjan upozorňuje, že debaty kolem řízení frekvencí a napětí CPU se nedotýkají jedné důležité věci: současné procesory mají komplikovanější správu výkonu a mezi jednotlivými generacemi hardwaru se značně liší. Plánovač není správným místem pro veškeré nízkoúrovňové informace; místo toho patří do nízkoúrovňového kódu specifického pro daný hardware.
Obecně ale lidé souhlasí, že předávání více informací mezi plánovačem a nízkoúrovňovým kódem pro správu výkonu by bylo ku pomoci. Zejména je velký zájem o lepší integraci mezi vyvažováním zátěže v plánovači (který rozhoduje o tom, jak rozdělit procesy mezi dostupnými procesory) a logikou správy výkonu. Při vyvažování zátěže se ví, jaké jsou aktuální potřeby a je možné dělat nějaké odhady týkající se blízké budoucnosti; proto dává smysl, že by se ten samý kód účastnil rozhodování, jaké procesorové prostředky by pro danou zátěž měly být k dispozici.
Na základě těchto myšlenek a dalších postřehů Morten Rasmussen zaslal návrh přepracovaného plánovače, ohleduplného ke spotřebe energie. Současný plánovač by byl rozdělen do dvou oddělených modulů:
Plánovač CPU bude řešit plánování jako doposud. Plánovač výkonu si zase bude brát informace o zátěži od plánovače CPU a podle potřeb bude měnit nastavení výkonu systému tak, aby to lépe odpovídalo této zátěži. Mezi tyto změny může patřit přesun CPU mezi stavy výkonu [power state] nebo uspání (nebo probuzení) CPU. Plánovač výkonu by komunikoval se současnými ovladači pro správu frekvence, ale tyto ovladače by nadále byly oddělené a specifické pro konkrétní hardware. Při tomto návrhu by vyvažování zátěže zůstalo pod kontrolou plánovače CPU; k přesunu do plánovače výkonu by nedošlo.
Zajisté je tu spousta problémů, které je nutné vyřešit mimo jednoduchou implementaci plánovače výkonu a definice rozhraní k plánovači CPU. Plánovač CPU nadále musí získat schopnost používat procesory s různými výpočetními schopnostmi; je to nutné pro architekturu big.LITTLE, ale i pro pokročilejší správu stavů výkonu. Aktuálně se procesům započítává, kolik času stráví během na CPU; to jednoznačně není fér vůči procesům spouštěným na pomalejším procesoru. Proto bude nutné používat jinou jednotku než čas, například počet instrukcí. Plánovač CPU si bude muset být vědom uplatňované politiky správy výkonu. Plánování procesů tak, aby byl využit režim „turbo boost“ (kdy je možné přetaktovat jediné CPU za předpokladu, že ostatní CPU jsou nečinná), zůstává otevřenou otázkou. Teplotní omezení přidávají do rovnice další proměnné. A tak dále.
Je také možné, že se oddělení plánování CPU a výkonů nepovede; Morten to popsal takto:
Jsem si vědom, že rozhodování plánovače a plánovače výkonu nemusí být oddělitelné, takže se možná rozhodneme je sloučit. I tak si myslím, že stojí za to snažit se oddělit rozhodování o výkonu od plánovače, leda by se ukázalo, že to jinak nejde.
I s těmito nejistotami se zdá přístup používající „plánovač výkonu“ jako dobrý začátek; Morten a jeho kolegové mají v plánu v brzké budoucnosti zaslat prvotní implementaci plánovače výkonu. Pak se snad od Inga dozvíme, jak dobře tento návrh splňuje požadavky; on (stejně jako ostatní vývojáři plánovače) se od posledních debat drželi stranou. Tak či tak to vypadá, že komunita bude na novém plánovači pracovat docela dlouho.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Jenže tady je to zcela určitě špatně:
… dne 13. června vydal stabilní jádra 3.9.6, … Jádra 3.9.4, … se aktuálně revidují a jejich vydání lze očekávat 20. června nebo krátce poté …
Reality check: 3.9.4 vyšlo 24. května, 3.9.6 13. června a 3.9.7 20. června. Takže místo 3.9.4 má být 3.9.7.