Byla vydána (𝕏) zářijová aktualizace aneb nová verze 1.105 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.105 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Ve Firefoxu bude lepší správa profilů (oddělené nastavení domovské stránky, nastavení lišt, instalace rozšíření, uložení hesla, přidání záložky atd.). Nový grafický správce profilů bude postupně zaváděn od 14.října.
Canonical vydal (email) Ubuntu 25.10 Questing Quokka. Přehled novinek v poznámkách k vydání. Jedná se o průběžné vydání s podporou 9 měsíců, tj. do července 2026.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzi 1.5.0.
Byla vydána nová verze 1.12.0 dynamického programovacího jazyka Julia (Wikipedie) určeného zejména pro vědecké výpočty. Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Aktualizována byla také dokumentace.
V Redisu byla nalezena a v upstreamu již opravena kritická zranitelnost CVE-2025-49844 s CVSS 10.0 (RCE, vzdálené spouštění kódu).
Ministr a vicepremiér pro digitalizaci Marian Jurečka dnes oznámil, že přijme rezignaci ředitele Digitální a informační agentury Martina Mesršmída, a to k 23. říjnu 2025. Mesršmíd nabídl svou funkci během minulého víkendu, kdy se DIA potýkala s problémy eDokladů, které některým občanům znepříjemnily využití možnosti prokázat se digitální občankou u volebních komisí při volbách do Poslanecké sněmovny.
Společnost Meta představila OpenZL. Jedná se o open source framework pro kompresi dat s ohledem na jejich formát. Zdrojové kódy jsou k dispozici na GitHubu.
Google postupně zpřístupňuje českým uživatelům Režim AI (AI Mode), tj. nový režim vyhledávání založený na umělé inteligenci. Režim AI nabízí pokročilé uvažování, multimodalitu a možnost prozkoumat jakékoliv téma do hloubky pomocí dodatečných dotazů a užitečných odkazů na weby.
Programovací jazyk Python byl vydán v nové major verzi 3.14.0. Podrobný přehled novinek v aktualizované dokumentaci.
1. Rychlost čtení a zápisu umí většinou už předinstalovaný (v prostředí Gnome) program "gnome-disk-utility".https://www.maketecheasier.com/benchmark-storage-devices-gnome-disk-utility/ To vypadá ne-moc přesně, ale zkusím když je to jediné normal-user řešení. Snad to bude měřit pokaždé stejně na stejném disku, protože jich potřebuju porovnat víc a pokud budu dostávat pokaždé jiné výsledky i jen na tom samém, nebude mi to moc platné.
z historie ale vím že takové odkazy mohou nabízet už mrtvé projekty, shit-ware apod.Tak s takým typom (shhh) programového vybavenia sa prosím odsťahujte mimo Linuxu, mladý pán.
skóre: 63?
Problém je v tom, že na rozdíl od měření HDD u nichž je na například pro sekvenční rychlost významným faktorem pouze vzdálenost stopy od vnějšího okraje (průběžné se ke středu snižující počet sektorů na stopu) u SSD/Flash je těch faktorů ovlivňující výkon daleko více.
Jednoduchý nástroj jako zmíněné HDTune může poskytnou značně zavádějící výsledky (jeho free verze 2.55 z roku 2008 je tj. prakticky z před SSD éry).
Zde je průběh rychlosti sustain zápisu na dvou odlišných SSD.
U NVMe Samsungu je vidět, že po zaplnění pseudo-SLC cache je schopen stále trvalého zápisu (přímo do TLC buněk) cca 600MB/s.
https://www.monitos.cz/tmp/samsung_evo_960_500g_nvme.png
U levného SATA Kingstonu je po vyčerpání pseudo-SLC cache dosahováno rychlosti <50MB/s (musí uvolňovat prostor pseudo-SLC cache a zapisovat finálně jako TLC).
https://www.monitos.cz/tmp/Kingston_A400_240gb_dd.png
Pokud by benchmark byl omezen na pouhých 50GB (většina benchmarkovacích nástrojů testuje na objemech ještě menších) závěr by zněl, že Samsung je v sekvečním zápisu pouze o 40% rychlejší (600MB/s versus 420MB/s).
Docela by mě zajímalo, co je to „přenosová rychlost disku“. To já když přenáším disk z domova do kanclu, někdy dosáhnu přenosové rychlosti až 5 km/h.
Záleží na tom, jak se disk používá a na které vrstvě chceme něco měřit. Dejme tomu, typická situace, že mám třeba přímo na disku /dev/sdx
nějaký LUKS kontejner /dev/mapper/luks_kontejner_x
a v kontejneru pak Btrfs namountovaný (ať nežeru) do /mnt
.
Ke všem pokusům bych si napřed spustil někde bokem v jiném terminálu něco takového (a výstup bych dle potřeby a chuti ukládal):
iostat -x 1 /dev/sdx /dev/mapper/luks_kontejner_x
Může mě zajímat, jak rychle přečtu samotný disk bez overheadu na šifrování, LBA po LBA, od začátku do konce:
pv -arb < /dev/sdx > /dev/null
(Pokud je disk už v háji a jde jen o sběr dat pro účely reklamace, přidá se klidně -E
, což skvěle ukáže nejrůznější kombinace chyb čtení + nečitelných LBA s mizerným výkonem (protože to po chybě nepřestane (zkoušet) číst). U funkčního disku, u kterého ještě záleží na datech, bych -E
nechtěl; tam je naopak správné po první chybě přestat a zamyslet se.)
Může mě zajímat, jak rychle přečtu LUKS kontejner, tj. jestli mi to šifrování správně hardwarově akceleruje a nezpůsobuje krk láhve:
pv -arb < /dev/mapper/luks_kontejner_x > /dev/null
Může mě zajímat, jak rychle přečtu nějaký veliký soubor na úrovni filesystému:
pv -arb < /mnt/veliký_soubor > /dev/null
Tohle↑ se dá nahradit taky třeba zápisem nějakých náhodných dat; na úrovni filesystému už se dá zkoušet i rychlost zápisu. Na úrovni disku nebo LUKS je to … složitější.
Může mě zajímat, jak rychle se přečte všechno v /mnt
, tedy se všemi vrstvami abstrakce (LUKS, Btrfs) — buď opravdu všechno (první příklad) nebo subvolume viditelný z /mnt
(druhý příklad):
btrfs scrub start -B /mnt btrfs scrub status /mnt # za běhu výše uvedeného
tar --one-file-system -c /mnt | pv -arb > /dev/null
Tak takovou situaci (taky) řeší moje odpověď výše.
Tiskni
Sdílej: