Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Na porovnání výsledky z desktopu "AMD Ryzen 5 5600X" + Crucial P5 1TB. Vše za běžné práce, žádný idle.
7z b
7-Zip [64] 17.04 : Copyright (c) 1999-2021 Igor Pavlov : 2017-08-28
p7zip Version 17.04 (locale=cs_CZ.UTF8,Utf16=on,HugeFiles=on,64 bits,12 CPUs x64)
x64
CPU Freq: 64000000 64000000 64000000 64000000 128000000 128000000 256000000 1024000000 2048000000
RAM size: 32025 MB, # CPU hardware threads: 12
RAM usage: 2647 MB, # Benchmark threads: 12
Compressing | Decompressing
Dict Speed Usage R/U Rating | Speed Usage R/U Rating
KiB/s % MIPS MIPS | KiB/s % MIPS MIPS
22: 50808 1068 4627 49427 | 560651 1112 4301 47819
23: 47521 1061 4565 48418 | 544867 1088 4332 47142
24: 45919 1074 4598 49373 | 541085 1101 4314 47491
25: 42847 1046 4677 48922 | 515679 1091 4208 45893
---------------------------------- | ------------------------------
Avr: 1062 4616 49035 | 1098 4288 47086
Tot: 1080 4452 48061
hdparm -Tt /dev/nvme0n1
/dev/nvme0n1: Timing cached reads: 50364 MB in 1.97 seconds = 25543.54 MB/sec Timing buffered disk reads: 5188 MB in 3.00 seconds = 1729.07 MB/sec
cd linux-5.16.10
make clean make defconfig time make -j 12 real 2m20,218s user 22m23,353s sys 2m3,030s
Dbench nezkusím, páč mi nejde zkompilovat.
Zdar Maxtime 7z b
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=cs_CZ.UTF-8,Utf16=on,HugeFiles=on,64 bits,128 CPUs AMD Ryzen Threadripper 3990X 64-Core Processor (830F10),ASM,AES-NI)
AMD Ryzen Threadripper 3990X 64-Core Processor (830F10)
CPU Freq: - - - - - - - - -
RAM size: 257663 MB, # CPU hardware threads: 128
RAM usage: 28240 MB, # Benchmark threads: 128
Compressing | Decompressing
Dict Speed Usage R/U Rating | Speed Usage R/U Rating
KiB/s % MIPS MIPS | KiB/s % MIPS MIPS
22: 272323 11632 2278 264917 | 4791965 12457 3282 408612
23: 163844 11795 1415 166938 | 4677220 12380 3271 404706
24: 117936 12069 1051 126806 | 4630251 12499 3253 406331
25: 99903 12169 938 114066 | 4544769 12600 3212 404416
---------------------------------- | ------------------------------
Avr: 11916 1421 168182 | 12484 3254 406016
Tot: 12200 2337 287099
Disky mam tedy pomalejsi podle udaju, co jsem videl.
LibreOffice build - asi 5 minut. 47GB RAM max na 128t. Zde hodne vyvojari vylepsili beh buildu.
Chromium build - 16 minut. Pamet taky nekde pres 55GB na 128t. Asi nejlepsi C/C++-ckovy benchmark, co znam.
openhab-addons (Java) po stazeni dependencies - asi 6 minut. Vcelku to brutalne vytezuje hardware pri mvn -T 1C a load 900 neni problem. openhab-code se mi nepodarilo ani sestavit vcetne testu. Zde to pada na vyssi nez povoleny pocet threadu na yetty nebo na nejakem webserveru. Vice jsem se v tom nechtel hrabat. Pokud je build spusten s nejnizsi prioritou, tak lze porad na masine delat.
Asi nejlepsi benchmark na Java buildy, co jsem videl.
OcrMinion - hlidac statu - docker+dotnet klient + tesseract 4 OCR.
Aby stihaly servery dodavat data, tak ma smysl dat pocet instanci dockeru na 40 kusu maximalne. Pak se da tezit asi 5000 scanu za hodinu. Load mezi 15-85, jak jsou data - asi 15 GB RAM obsazene. Pri 400 instancich je masina vcelku lina, OCR se hodne zpomaluje a vice ping-a server nez tezi data- load asi 430. Mozna, ze by to slo vyladit lepe.
gf
load 133 max time (make clean && make -j128 allmodconfig && time make -j128) real 4m19,319s user 323m13,731s sys 130m7,617sffmpeg
time (make clean && time make -j128) real 0m17,721s user 14m8,082s sys 1m36,861sKdyz jsem testoval build kernelu, tak jsem zapomel na pocitaci bezet antivirovy program na pozadi jako daemon. Bylo mi divne, ze maximalni load 17 a doba kompilace hodne pomala. Po vypnuti load pres 130. Mozna to vite, ale antivirove programy nejsou nejspise moc optimalizovane pro vykonnejsi CPU. Navic bezi na 1 vlakne a nestihaji zasobovat CPU daty. Vykonove ztraty bezne 25%, ale v pripade prekladu na C/C++ jsou o dost vetsi. U kernelu to odhaduju minimalne 50-70%. gf
/dev/nvme0n1:
Timing O_DIRECT disk reads: 6980 MB in 3.00 seconds = 2326.66 MB/sec
Tiskni
Sdílej: