Crown je multiplatformní open source herní engine. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT a GPLv3+. Byla vydána nová verze 0.60. Vyzkoušet lze online demo.
Daniel Stenberg na svém blogu informuje, že po strncpy() byla ze zdrojových kódů curlu odstraněna také všechna volání funkce strcpy(). Funkci strcpy() nahradili vlastní funkcí curlx_strcopy().
Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
Debilníček sklerotického linuxáka...
Před nedávnem jsem dostal nový služební počítač, se čtyřjádrem od AMD. Osadil jsem jej velmi čerstvou openSUSE 11.2 (kernel 2.6.31.5), nainstaloval aplikace a vše běželo jako po másle. Až na BOINC...
S programem BOINC, respektive s prací, kterou přijímal (v mém případě: rosetta@home, Einstein@home, lhc@home) jsem nikdy neměl problémy - vše se vždy na předchozím PC (dvojjádro AMD, openSUSE 10.3, kernel 2.6.22.19) spočetlo, jak mělo, a to i když jsem počítači dával kouř jak se patří (týdenní výpočty MKP a podobně). Nyní se ale začaly objevovat chyby ve výpočtech, které Einstein@home kvalifikoval jako Client Errors.
První problémy začaly s využíváním GPU pro výpočty BOINCu. Vzhledem k tomu, že BOINC není schopen používat pro výpočty GPU ATI s proprietárními ovladači (tehdy jsem měl Catalyst 9.11), nehodlal se mi nastartovat BOINC client, což vyřešilo explicitní vypnutí GPU v konfiguračním souboru (celý postup je zde). Pak se mi již podařilo BOINC bez problémů zprovoznit a začaly se objevovat ony Client Errors.
Vrcholem všeho byla chvíle, kdy jsem byl na víkend pryč a při pohledu na statistiky jsem viděl ve výsledcích pouze Client Error, a to asi u třiceti workunit. Po návratu do práce jsem zjistil, že došlo k pádu plasmy a kwin4 a ve chvíli, kdy jsem hnul s myší má Xka spadla. Po restartu vše naběhlo OK, jen se prostě čas od času objeví naprosto zbytečná Client Error.
Rozhodl jsem se tedy napsat do fóra Einstein@home, zda někdo nemá podobné problémy. (Celý thread je zde.) Po všech možných úvahách (chyba CPU, problémy s GPU a podobně) vše ukazuje na chybu jádra. tato chyba by se měla projevovat pouze ve chvílích, kdy větší počet aplikací, nežli je počet fyzických jader, chce využívat CPU na 100%.
Důvodem k tomuto podezření (symptomy chyby) je:
)A nyní můj dotaz: je možné, aby chyba vznikala tímto mechanizmem? Oficiálně se tvrdí, že tato chyba byla odstraněna v jádře 2.6.27 (její příčinou je nastavení CONFIG_PREEMPT), nicméně, jak zjistili někteří diskutující, právě tato nastavení umožňuje chybovost workunit ovlivnit. A ještě jeden dotaz: máte někdo podobné zkušenosti s touto chybou, a to ať už v rámci BOINC nebo v rámci jiné aplikace?
Ok, vím, že jde vlastně o dotaz, ale jednak je úvod k němu docela dlouhý a jednak bych rád vyvolal širší diskuzi o této chybě, včetně toho, zda a jak ji hlásit.
Díky moc,
Pushkin
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
void main(void) {
while(1) {
}
}
Z toho, že jedna aplikace blbne, nota bene uzavřená binárka, a která místo rozumného vysvětlení vrátí akorát nic neříkající číselný kód, věštit, že je chyba v jádře, je opravdu odvážné.
Aha, autoři BOINC otevřeli. Tak to je jiná.
Zmiňovaný src/protocols/ProteinInterfaceDesign/read_patchdock.cc jste už prohlížel, že si myslíte, že je chyba v jádře? Je totiž dost možné, že mají v aplikaci chybu souběhu nebo zapomněli ošetřit nepřidělení paměti nebo cokoliv jiného, co může způsobit změněné chování jádra, které přesto je zcela v souladu s API/ABI.
Pro overeni sosnout prime95 http://www.mersenne.org/freesoft/ (pokud mas 64bit distro tak 64bit vezi) a spustit v torture rezimu.
11.1.2010 12:46
kotyz | skóre: 25
| blog: kotyzblog
| Plzeň
11.1.2010 10:14