Byly publikovány informace (technické detaily) o bezpečnostním problému Snapu. Jedná se o CVE-2026-3888. Neprivilegovaný lokální uživatel může s využitím snap-confine a systemd-tmpfiles získat práva roota.
Nightingale je open-source karaoke aplikace, která z jakékoliv písničky lokálního alba (včetně videí) dokáže oddělit vokály, získat text a vše přehrát se synchronizací na úrovni jednotlivých slov a hodnocením intonace. Pro separaci vokálů využívá UVR Karaoke model s Demucs od Mety, texty písní stahuje z lrclib.net (LRCLIB), případně extrahuje pomocí whisperX, který rovněž využívá k načasování slov. V případě audiosouborů aplikace na
… více »Po půl roce vývoje od vydání verze 49 bylo vydáno GNOME 50 s kódovým názvem Tokyo (Mastodon). Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Článek na stránkách Fedora Magazinu informuje o vydání Fedora Asahi Remixu 43, tj. linuxové distribuce pro Apple Silicon vycházející z Fedora Linuxu 43.
Byl zveřejněn program konference Installfest 2026. Konference proběhne o víkendu 28. a 29. března v Praze na Karlově náměstí 13. Vstup zdarma.
Byla vydána Java 26 / JDK 26. Nových vlastností (JEP - JDK Enhancement Proposal) je 10. Odstraněno bylo Applet API.
Byla vydána nová verze 260 správce systému a služeb systemd (Wikipedie, GitHub). Odstraněna byla podpora skriptů System V. Aktualizovány byly závislosti. Minimální verze Linuxu z 5.4 na 5.10, OpenSSL z 1.1.0 na 3.0.0, Pythonu z 3.7.0 na 3.9.0…
Byla vydána nová verze 5.1 svobodného 3D softwaru Blender. Přehled novinek i s náhledy a videi v poznámkách k vydání. Videopředstavení na YouTube.
Bylo oznámeno vydání nové verze 8.1 "Hoare" kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie). Doprovodný příspěvek na blogu Khronosu rozebírá kódování a dekódování videa pomocí Vulkan Compute Shaders v FFmpeg.
Byl představen open-source a open-hardware prototyp nízkonákladového raketometu kategorie MANPADS, který byl sestaven z běžně dostupné elektroniky a komponent vytištěných na 3D tiskárně. Raketa využívá skládací stabilizační křidélka a canardovou stabilizaci aktivně řízenou palubním letovým počítačem ESP32, vybaveným inerciální měřicí jednotkou MPU6050 (gyroskop a akcelerometr). Přenosné odpalovací zařízení obsahuje GPS,
… více »Zdravím,
tento dotaz je primárně směřován na ženy/muže orientující se v problematice programovaní a kompilace ve fortranu ale ani ostatní se nemusí cítit odstrčeni.
Popis problému:
Program na řešení soustavy parabolických PDE (trubkový reaktor s axiální disperzí), napsaný ve fortran90 (z důvodu dynamické alokace polí) a FORTRAN77 (rutiny na řešeni PDE), byl zkompilován Intel Fortran Compiler For Linux verze 10.1 20080312. Pokud je program zkompilován v debug modu (s parametry -g -debug all) běží vše v pořádku, resp. je dosažen smysluplný výsledek*. Pokud ale je použita při kompilaci optimalizace (-O2 a výše) solver DDASPK, který má za úkol numerické řešení prostorových derivací, se ukončí z důvodu neschopnosti vypočíst YPRIME (první derivace funkce y - definované uživatelem).
Nejde zde ani tak o problém fyzikální (věřím že fyzikální podstata problému je naprogramována správně), ale spíše programátorský. Jak může obecně optimalizace zdrojového kódu kompilátorem ovlivnit numerickou stabilitu výpočtu? Dočetl jsem se, že během optimalizace dochází k vektorizaci vybraných smyček-cyklů není zde podstata výše uvedeného problému? Setkali jste se už někdy s rozdílným chováním programu zkompilovaného v debug modu a optimalizovaného (jedno v jakém programovacím jazyku)?
Dík za Vaše zamyšlení nad problémem,
Milan
* Smysluplným výsledkem je myšlen ten, který splňuje zadání úlohy a poskytuje reálné (fyzikální) hodnoty, jako třeba kladné absolutní teploty, respektuje zákon zachování hybnosti, hmoty a energie.
HA! Tak formulace problému zde nafóru mi pomohla najít vhodnou formu dotazu pro google!:
computation result differs with Optimize/Debug versions
A výsledky se začaly hrnout. Třeba hned jeden z prvních odkazů:
http://www.flounder.com/debug_release.htm
se zdá být nanejvýš relevantní.
No budu pokračovat v samomluvě. Našel jsem to co je nejspíše příčinou mého problému. Níže uvedený odkaz obsahuje sice obecnou přednášku, ale na stránce 7 je přesně popsáno, co způsobuje "horlivá" optimalizace za bordel.
www.cs.berkeley.edu/~wkahan/Mind1ess.pdf
Dík za napad s paralelním výpisem z neoptimalizovaného a optimalizovaného programu a sledovat kde dochází ke změně. Jinak optimalizace začne produkovat jiné výsledky když použiju -O2. Když přidám -fltconsitency tak problém zmizí.
Tiskni
Sdílej: