Vim Classic byl vydán ve verzi 8.3. Drew DeVault oznámil tento fork editoru Vim (verze 8.2.0148, tj. těsně před zavedením Vim9 skriptování) v březnu letošního roku. Důvodem forku bylo, že vývojáři editorů Vim a Neovim začali při vývoji využívat LLM.
Open source konference DevConf.CZ 2026 proběhne 18. a 19. června v Brně na FIT VUT. Publikován byl program a spuštěna byla registrace.
Společnost JetBrains uvolnila verzi 2 svého open-source velkého jazykového modelu (LLM) pro vývojáře Mellum.
Probíhá konference Microsoft Build 2026. Microsoft představuje své novinky: kvantový čip Majorana 2, Surface Laptop Ultra a Surface RTX Spark Dev Box s NVIDIA RTX Spark, Intelligent Terminal, Coreutils for Windows (fork Rust Coreutils), AI modely MAI, AI agenta Scout, platformu pro agent-first zařízení Project Solara, …
Google Chrome 149 byl prohlášen za stabilní. Nejnovější stabilní verze 149.0.7827.53 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Vylepšeny byly také nástroje pro vývojáře.
Pluto.jl, reaktivní notebook pro programovací jazyk Julia, dospěl do verze 1.0.
Byla vydána nová verze 12.0.0 vizuálního programovacího jazyka Snap! (Wikipedie) inspirovaného jazykem Scratch (Wikipedie). Přehled novinek na GitHubu.
Počítačovou hru Gravity Circuit (ProtonDB) lze do 14. června do 19:00 získat na Steamu zdarma. Napořád.
Nejnovější X.Org X server 21.1.23 a Xwayland 24.1.12 řeší 9 bezpečnostních chyb.
npm balíčky @redhat-cloud-services byly kompromitovány.
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: