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.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »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