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.
Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Byl představen nový Xserver Phoenix, kompletně od nuly vyvíjený v programovacím jazyce Zig. Projekt Phoenix si klade za cíl být moderní alternativou k X.Org serveru.
XLibre Xserver byl 21. prosince vydán ve verzi 25.1.0, 'winter solstice release'. Od založení tohoto forku X.Org serveru se jedná o vůbec první novou minor verzi (inkrementovalo se to druhé číslo v číselném kódu verze).
Wayback byl vydán ve verzi 0.3. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
HW myslím že mám dostatečně výkonný. S diskem to má společné to, že když se mi ty programy spustí v návaznosti těsně po sobě, nebude tolik seekovat a ve vysledku se to spustí rychleji...A na to jsi přišel jak? To si jenom myslíš, že? Ono myslet, znamená ho..o vědět.
Předpokládám, že programy mají běžet současně a jako problém se ti jeví úvodní část jejich běhu, ukončená například naběhnutím hlavního okna v případě GUI aplikace, zahájením akceptování spojení serverem apod. OS přechod do takového stav neidentifikuje a ani nemůže, neboť jde o vnitřní stav aplikace.Konečně mě někdo pochopil a nehledal v mé otázce, do čeho si rýpnout. Díky, tahle odpověď mi stačí
Konečně mě někdo pochopil a nehledal v mé otázce, do čeho si rýpnout.a ty, co se vám snažily naznačit, že paralelní přístup k disku by měl řídit plánovač IO, jste nepochopil vy
&&. A kdyz jim chces dat oddech, tak tam nasazel sleepy
& mene
Nejak jsem to z uvodniho dotazu nepochopil. Jinak pokud bys to chtel uplne presne nadefinovat, ze az se "dokonci spousteni" tehle aplikace, tak "zacni spoustet" dalsi, tak na to me zadne reseni nenapada. Jedine to spoustet s nejakym stracem s vystupem "nekam", a ted vystup checkovat, jestli se porad zvetsuje, nebo uz ma stabilni velikost. Doufam, ze jsem to napsal srozumitelne.
Jestli jo, tak man strace
stracem to nepůjde, protože to by se proces programu musel okamžitě uspat, aby strace už nic nevypisoval. Stačí jediný pohyb paměti a tenhle způsob půjde do háje. Zelenýho.
Popravdě mě přijde celý dotaz jako naprostá kravina. Prostě použij ; (a když už, tak i nějaký sleep). Jinou možnost ani nemáš, protože jak už tu někdo psal by program musel posílat nějaký signál, že už je spuštěný. A to že to zrovna tyhle programy budou dělat je hoodně nepravděpodobné.
Pocit, že se programy takhle spustí rychleji je podle mně zcela mimo. Hlavičky hard disku musí tu cesto projít stejně v každém případě. Fragmentace souborů v systému bude přítomná vždy a lítání hlav tedy taky. Máš tedy v podstatě na výběr jestli hlavičky budou překmitávat rychle nebo pomalu (a to takřka stejným způsobem). To že to dělá větší kravál opravdu neznamená, že je to pomalejší.
Samozřejmě existuje teoretická možnost, že tvůj způsob bude rychlejší. A to v případě, že všechna data budou uložená na disku za sebou přesně v tom pořadí, v jakém se čtou (včetně všech knihoven). S tím se prakticky nesetkáte (existuje patch pro kernel, který dělá něco takového, ale jen po dobu bootu). Ovšem to by se program musel začít spouštět okamžitě po načtení dat předchozího (tedy i před jeho kompletním spuštěním) aby se hlavičky nestihly zaparkovat nebo tak něco.
PS: Navíc firmware disku si může dělat co chce, takže na OS bych v tomhle zrovna moc nespoléhal.
#!/usr/bin/python
from __future__ import division
import time
def sumsys_iowait():
statline = file('/proc/stat').readline().split()[1:8]
ints = [int(x) for x in statline]
sumsys = sum(ints)
iowait = ints[4] #IOWAIT
return sumsys, iowait
s_old, i_old = sumsys_iowait()
while True:
time.sleep(0.2)
s, i = sumsys_iowait()
iowait = (i-i_old)/(s-s_old)
print iowait
if iowait > 0.5:
break
s_old = s
i_old = i
Schválně jsem obrátil podmínku a nastavil, ať program skončí až se aktivita disku _zvýší_ nad 0.5 - ať je to zajímavější. Pětkrát za sekundu kontroluju IOWAIT což většinou odpovídá aktivitě disku (ale nemusí).
Tiskni
Sdílej: