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.
Obrovská poptávka po plynových turbínách zapříčinila, že datová centra začala používat v generátorech dodávajících energii pro provoz AI staré dobré proudové letecké motory, konvertované na plyn. Jejich výhodou je, že jsou menší, lehčí a lépe udržovatelné než jejich průmyslové protějšky. Proto jsou ideální pro dočasné nebo mobilní použití.
Typst byl vydán ve verzi 0.14. Jedná se o rozšiřitelný značkovací jazyk a překladač pro vytváření dokumentů včetně odborných textů s matematickými vzorci, diagramy či bibliografií.
Do konference přišlo celkem 1537 emailů, nejvíce jich poslali Andrew Morton, William Lee Irwin III a Adrian Bunk.
29. črv - 8. črc
Linas Vepstas napsal:
Firmware může hlásit chyby kdykoliv a není to neobvyklé ani při bootu. Jenže tyto zprávy nejsou k ničemu do chvíle, kdy naběhne rtasd, což je poměrně pozdě. V důsledku toho jsou chyby firmawaru během bootu tiše ignorovány.
Tenhle patch je alespoň vypíše pomocí printk, takže se objeví v boot.msg/syslog. Existují ještě dva logovací mechanismy, které jsem radši nechal na pokoji, protože nerozumím jejich chování. Především nvram není povoleno až do pozdní fáze bootu... Ale jaký má pak nvram logování smysl, jestli ne zachytávat zprávy, které se objevily časně během bootu?
Paul Mackerras odpověděl: Printk vypisující chyby je otravné a nezdá se mi to příliš přínosné vzhledem k tomu, že jde jen o nečitelná hexová čísla, kterých může být opravdu moc. Musí existovat lepší způsob. Dát to do nvram se mi zdá jako lepší možnost. Neznám důvod, proč bychom nemohli nvram používat hned zkraje.
Jake Moilanen poznamenal: nvram můžeme inicializovat velmi brzy, ale události v nvram uložené bychom neměli zahazovat, dokud neběží rtasd a ty události si nevytáhne, protože by mohlo jít o tu chybu, která minule při bootu systém shodila. Mohli bychom asi rtasd nastartovat o trochu dříve, ale nepřipadá mi, že by nás to mělo tolik trápit.
Greg KH celou záležitost považoval za diskutabilní, protože Linas by měl prostě použít syslog nebo netlink jako celý zbytek kernelu. Nevynalézejte znovu kolo.
Paul také Linasovi řekl: Tento typ problému se obyčejně řeší pomoci netlinku. Myslím, že by dávalo smysl vypisovat pomocí printk RTAS chybové události se závažností "fatal" a možná i "error". Varování a události by však měly být poslány na rtasd.
Hollis Blanchard napsal: Už jsem se na to ptal dříve a bylo mi řečeno, že neexistuje způsob, jak zjistit závažnost události bez předchozího úplného zpracování binárních dat. Byl bych nadšen, kdybych se mýlil...
Nathan Fontenot odpověděl:
Zjistit závažnost RTAS události lze a ani to není moc náročné. Podívej se na asm-ppc64/rtas.h, kde najdeš definici hlavičky RTAS události (struct rtas_error_log). Všechny RTAS události mají počáteční hlavičku obsahující závažnost dané události.
Dekódování RTAS událostí za hranicemi hlavičky je po chvilce pěkně nechutné a doufejme, že to v jádře nikdy nebude potřeba dělat.
4. črc - 14. črc
Norberto Bensa si všiml, že XFS vynuluje soubory po nekorektním vypnutí. Zeptal se, jestli existuje způsob, jak se tomu vyhnout. L. A. Walsh odpověděla, že jde o starý problém, který byl již dříve hlášen v XFS konferenci; ale dodala:
Zjevně to nelze snadno reprodukovat, nikdo nemá tušení, proč se tak děje. Prostě to dělá. I po několika synchronizacích jsou někdy soubory editované během posledních několika dní vynulovány. Dobrý důvod pro pořizování denních záložních kopií, protože ty většinou obsahují bezchybné soubory...
Kdybych jen mohla přijít na to, jak to reprodukovat... když se o to
pokusím, nic se nestane. Grrr... ví, že kontroluji! 
Chris Wedgwood během diskuze řekl:
XFS soubory nevynulovává, pouze vrací nuly místo nezapsaných úseků. Otevřete-li existující soubor a celý jej popíšete, možná během spadnutí uvidíte stará data, nebo nová data, pokud byla zapsána [flush]. Neměli byste však vidět nuly.
Hádám, že u jiných filesystémů (když se žurnálují pouze metadata) jsou bloky alokované pro nově zapsaná data většinou stejné jako nedávno uvolněné bloky, takže to vypadá, že všechno funguje, ale ve skutečnosti je to pravděpodobně pouze náhoda. XFS by se mohlo chovat podobně, ale dříve nebo později byste na to stejně doplatili, když byste dostali nesmysly místo starých dat.
Některé aplikace je prostě potřeba opravit.
L. A. odpověděla:
Nevím, jestli to nějak pomůže (pochybuji, mě to mate)... Soubory, které jsem zapsala ve vimu, a které vrátily "nuly", byly soubory napsané před 2 - 3 DNY -- přičemž čerstvější zápisy byly často uloženy bez problémů.
Kdyby to byl soubor, který jsem právě editovala, a v tu chvíli to spadlo, to bych to chápala lépe než soubory, kterých jsem se pár dní nedotkla.
Chris řekl, že podobné chování skutečně nikdy neviděl, rozhodně pak ne u souborů, které byly upraveny před několika dny. Byl si jistý, že na jeho systému by checksum skripty, které kontrolují všechny jeho soubory, něco takového zachytily. Jeho odhad v odpovědi na popis od L. A. byl, že soubory jsou skutečně nějak měněny, ale nedělá to XFS.
5. črc - 8. črc
Andrew Morton oznámil Linux 2.6.7-mm6:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/pat ches/2.6/2.6.7/2.6.7-mm6/
8. črc - 14. črc
Erik Rigtorp napsal: Tento patch do swsusp přidává podporu pro bootsplash. Na kódu, který je rozhraním k bootsplash, je ještě nutné pracovat, v této chvíli je víceméně ukradený ze swsusp2. Nějaký další kód by šlo místo toho pravděpodobně přesunout do console.c.
Christoph Hellwig poukázal na to, že CONFIG_BOOTSPALSH není v současné době v oficiálním stromu jádra; takže podporovat to u software suspend je předčasné. Christoph rovněž naznačil, že CONFIG_BOOTSPALSH v hlavním stromu vítáno není. Pavel Machek odpověděl:
Ten patch nebyl určen pro hlavní strom... Ale i tak se bude hodit, protože velká distra tenhle druh věcí chtějí...
Možná by CONFIG_BOOTSPLASH nakonec v hlavní stromu být mělo. Vůbec se mi nelíbí představa dvou nekompatibilních sad háčků do swsusp....
Ale Christoph řekl: Ne. Tyhle věci nemají v kernelu co dělat. Malujte si své pěkné obrázky přes fbdev. A ten bootsplash patch od SUSE je totální humus - vždyť co musíš hulit, abys dal JPEG dekodér do jádra?
Stefana Reinauera se to dotklo a napsal:
Souhlasím, že v případě jádra 2.6 by to šlo udělat lépe díky pořádné podpoře initramfs, ale v 2.4 nebyl žádný rozumný způsob, jak vložit uživatelský kód dost brzy na to, aby byl spuštěn před inicializací framebufferu.
Na druhou stranu, ten JPEG dekodér má 8k - méně než desítky gzip/gunzip algoritmů v kernelu. Takže stěžování mi přijde trochu hloupé. Jestli chceš jen držkovat, pak běž kritizovat to, že s rozlišením 1024x768 sežere bootsplash nadobro 1.5MB paměti. Pokud něco, tak TO by dávalo smysl.
A jestli chceš retro textové hlášky nebo grafický boot, to je dozajista filosofická otázka. Dle mého skromného názoru není možné tak brzy startovat X.
Pavel pak také Christophovi řekl:
SUSE verzi bootsplashe jsem neviděl... Ani nechci vidět. Ale takhle má SUSE svůj mizerný bootsplash, RedHat pravděpodobně také, Mandrake asi také, atd.
A teď bude chtít SUSE splash u swsusp, RedHat pravděpodobně také, Madrake asi také, atd. Nechce se mi trápit se třemi různými sadami háčků do swsusp.
Takže... kdyby si pročištěný bootsplash našel cestu do jádra, mohlo by to zmírnit množství humusu v distribucích. Aspoň by existoval jednotný způsob, jak tu věc vypnout...
Christoph odpověděl: Red Hat to dělá správně, protože používá program, který využívá fbdev. Zároveň také nemají žádnou podporu pro swsusp, což dává docela smysl, když vezmeme v potaz, jakým tempem se ten kód i nadále mění.
V originálu Kernel Traffic 270 vyšla navíc ještě tato témata:
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz