Byla vydána nová verze 10.2 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Vypíchnout lze nové balíčky Immich, Immich Machine Learning, uv a RustDesk Client.
TypeScript (Wikipedie), tj. JavaScript rozšířený o statické typování a další atributy, byl vydán v nové verzi 6.0. Příští verze 7.0 je kvůli výkonu přepisována do programovacího jazyka Go.
Christian Schaller z Red Hatu na svém blogu popsal své zkušenosti s používáním AI při vývoji open source aplikací pro Linux. Pomocí různých AI aktualizoval nebo vytvořil aplikace Elgato Light GNOME Shell extension, Dell Ultrasharp Webcam 4K, Red Hat Planet, WMDock, XMMS resuscitated (aktualizace z GTK 2 a Esound na GTK 4, GStreamer a PipeWire) a Monkey Bubble. SANE ovladač pro skener Plustek OpticFilm 8200i se mu zatím nepovedl.
Americké firmy Tesla a SpaceX postaví v texaském Austinu moderní komplex na výrobu čipů pro umělou inteligenci (AI). Součástí projektu s názvem Terafab budou dvě moderní továrny na výrobu čipů – jedna se zaměří na automobily a humanoidní roboty, druhá na datová centra ve vesmíru. Uvedl to generální ředitel těchto firem Elon Musk. Projekt by podle odhadů měl stát 20 miliard USD (zhruba 425 miliard Kč).
Byla vydána nová stabilní verze 6.11 (YouTube) multiplatformního frameworku a GUI toolkitu Qt. Podrobný přehled novinek v poznámkách k vydání.
Ubuntu 26.04 patrně bude ve výchozím nastavení zobrazovat hvězdičky při zadávání hesla příkazu sudo, změna vychází z nové verze sudo-rs. Ta sice zlepší použitelnost systému pro nové uživatele, na které mohlo 'tiché sudo' působit dojmem, že systém 'zamrzl' a nijak nereaguje na stisky kláves, na druhou stranu se jedná o možnou bezpečnostní slabinu, neboť zobrazování hvězdiček v terminálu odhaluje délku hesla. Původní chování příkazu sudo
… více »Projekt systemd schválil kontroverzní pull request, který do JSON záznamů uživatelů přidává nové pole 'birthDate', datum narození, tedy údaj vyžadovaný zákony o ověřování věku v Kalifornii, Coloradu a Brazílii. Jiný pull request, který tuto změnu napravoval, byl správcem projektu Lennartem Poetteringem zamítnut s následujícím zdůvodněním:
… více »Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 163 (pdf).
Eric Lengyel dobrovolně uvolnil jako volné dílo svůj patentovaný algoritmus Slug. Algoritmus vykresluje text a vektorovou grafiku na GPU přímo z dat Bézierových křivek, aniž by využíval texturové mapy obsahující jakékoli předem vypočítané nebo uložené obrázky a počítá přesné pokrytí pro ostré a škálovatelné zobrazení písma, referenční ukázka implementace v HLSL shaderech je na GitHubu. Slug je volným dílem od 17. března letošního
… více »Sashiko (GitHub) je open source automatizovaný systém pro revizi kódu linuxového jádra. Monitoruje veřejné mailing listy a hodnotí navrhované změny pomocí umělé inteligence. Výpočetní zdroje a LLM tokeny poskytuje Google.
/dev/sda: WDC WD15EADS-00P8B0: – WesternDigital /dev/sdb: ST31500341AS: – SeagateVypadá to, že čtení brzdí WesternDigital.
# dd if=/dev/md0 bs=1M count=1024 | pv > /dev/null 1024+0 vstoupivších záznamů 1024+0 vystoupivších záznamů 1 073 741 824 bajtů (1,1 GB) zkopírováno, 10,3183 s, 104 MB/s 1GB 0:00:10 [99,2MB/s] # dd if=/dev/sda1 bs=1M count=1024 | pv > /dev/null 1024+0 vstoupivších záznamů 1024+0 vystoupivších záznamů 1 073 741 824 bajtů (1,1 GB) zkopírováno, 158,554 s, 6,8 MB/s 1GB 0:02:38 [6,46MB/s] # dd if=/dev/sdb1 bs=1M count=1024 | pv > /dev/null 1024+0 vstoupivších záznamů 1024+0 vystoupivších záznamů 1 073 741 824 bajtů (1,1 GB) zkopírováno, 9,09674 s, 118 MB/s 1GB 0:00:09 [ 113MB/s]Vím, že to není žádné úžasné měření, ale pro představu snad postačí. Použil jsem
pv, abych sledoval průtok průběžně – u sda se často rychlost dostávala na nulu, přenos se úplně zastavil. A průměrná rychlost tohoto disku byla nakonec horší než rychlost kdejaké flešky.
Předtím jsem prováděl několik opakovaných měření pomocí hdparm -t a ty tak špatně nedopadly (buffered disk reads):
/dev/md0: Timing buffered disk reads: 362 MB in 3.00 seconds = 120.55 MB/sec Timing buffered disk reads: 268 MB in 3.01 seconds = 89.16 MB/sec Timing buffered disk reads: 272 MB in 3.00 seconds = 90.59 MB/sec Timing buffered disk reads: 368 MB in 3.00 seconds = 122.50 MB/sec Timing buffered disk reads: 240 MB in 3.01 seconds = 79.80 MB/sec /dev/sda1: Timing buffered disk reads: 266 MB in 3.01 seconds = 88.30 MB/sec Timing buffered disk reads: 266 MB in 3.02 seconds = 87.97 MB/sec Timing buffered disk reads: 248 MB in 3.01 seconds = 82.26 MB/sec Timing buffered disk reads: 274 MB in 3.01 seconds = 90.99 MB/sec Timing buffered disk reads: 274 MB in 3.01 seconds = 91.01 MB/sec /dev/sdb1: Timing buffered disk reads: 366 MB in 3.01 seconds = 121.72 MB/sec Timing buffered disk reads: 362 MB in 3.00 seconds = 120.57 MB/sec Timing buffered disk reads: 368 MB in 3.01 seconds = 122.43 MB/sec Timing buffered disk reads: 362 MB in 3.00 seconds = 120.48 MB/sec Timing buffered disk reads: 366 MB in 3.01 seconds = 121.54 MB/secPo chvíli jsem pustil čtení znova, tentokrát 10 GB a dopadlo to úplně jinak:
# dd if=/dev/sda1 bs=1M count=10240 | pv > /dev/null 10GB 0:01:39 [ 102MB/s] 10240+0 vstoupivších záznamů 10240+0 vystoupivších záznamů 10 737 418 240 bajtů (11 GB) zkopírováno, 99,9046 s, 107 MB/s # dd if=/dev/md0 bs=1M count=10240 | pv > /dev/null 10240+0 vstoupivších záznamů 10240+0 vystoupivších záznamů 10 737 418 240 bajtů (11 GB) zkopírováno, 92,5676 s, 116 MB/s 10GB 0:01:32 [ 111MB/s] # dd if=/dev/sdb1 bs=1M count=10240 | pv > /dev/null 10240+0 vstoupivších záznamů 10240+0 vystoupivších záznamů 10 737 418 240 bajtů (11 GB) zkopírováno, 88,7582 s, 121 MB/s 10GB 0:01:28 [ 115MB/s]Najednou to vypadá OK. Občas zkouším systém sledovat pomocí iotopu, ale nevšiml jsem si žádného procesu, který by nějak výrazně zatěžoval disk. Pak jsem ale pustil čtení ještě jednou, tentokrát 20 GB a opět špatné:
# dd if=/dev/sda1 bs=2M count=10240 | pv > /dev/null 10240+0 vstoupivších záznamů 10240+0 vystoupivších záznamů 21 474 836 480 bajtů (21 GB) zkopírováno, 1 205,7 s, 17,8 MB/s 20GB 0:20:05 [ 17MB/s]Průběžně jsem sledoval
iotop a proces dd byl většinou na prvním místě – nikdo ho nepředbíhal, leda výjimečně načítala něco databáze nebo webový server. Rychlost, kterou dd četl, byla ale velice často nulová (bez zjevné příčiny – disk nezatěžoval nikdo jiný). Hned nato jsem spustil stejné čtení z druhého disku.
# dd if=/dev/sdb1 bs=2M count=10240 | pv > /dev/null 10240+0 vstoupivších záznamů 10240+0 vystoupivších záznamů 21 474 836 480 bajtů (21 GB) zkopírováno, 174,596 s, 123 MB/s 20GB 0:02:54 [ 117MB/s]Proces
dd četl z tohoto disku (podle pv i iotopu) rychlostí kolem 100 MB/s – ale hlavně plynule, rychlost nekolísala ani nepadala na 0 MB/s.
Jelikož věštecké koule jsou celkem drahá věc, zkouším to nejdřív tady, třeba vás něco napadne. Řešením samozřejmě může být ten WD vyhodit a dát tam nějaký jiný, ale třeba se najde ekonomičtější řešení.
Tiskni
Sdílej:
Když jsem vydělil údaje ve specifikaci (kapacita ÷ počet sektorů), tak mi vychází 512.
A ukazuje mi to i hdparm -I /dev/sda:
Logical/Physical Sector size: 512 bytes
A v popisu jumperů ten Advanced Format chybí (u jiných disků je).
Už mi pomalu to WD (a celé Green IT) začíná lézt krkem, nejdřív problémy s Load_Cycle_Count a teď tohle.
dd if=/dev/sda bs=1M count=10240 skip=10240 | pv > /dev/nullNejdřív to šlo docela dobře (normální rychlost), ale kolem šestého GB se to nějak pokazilo a rychlost čtení je 0 B/s – jen občas tam blikne 1 nebo 8 MB/s. Čtení prakticky stojí. Ale podle
iotopu mu nikdo nebrání.
-H, ale před nějakým časem i testy a vypadalo to OK (pomalé to bylo už tehdy).
Tomu disku všechno moc trvá – jak ten smartctl -H, tak třeba i zjištění teploty přes hddtemp – zatímco ten Seagate odpovídá okamžitě.
# ./seeker /dev/sda Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html Benchmarking /dev/sda [1430799MB], wait 30 seconds............... Results: 0 seeks/second, 2142.86 ms random access time # ./seeker /dev/sdb Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html Benchmarking /dev/sdb [1430799MB], wait 30 seconds............................. Results: 63 seeks/second, 15.63 ms random access timeTak mi připadá, že mám v počítači místo jednoho disku kus šrotu (WD).
Tady si stáhni utilitku Data Lifeguard Diagnostic. Tam se mrkni, jak to s tou velikostí sektoru opravdu je.
Podle všeho WD ignoruje problém s WD15EADS-00P8B0.
Hoď ten disk prodejci na hlavu a vezmi si něco jinýho. Nevypadá to totiž, že by WD chtěl tenhle problém nějak řešit.
Za svůj život jsem pravda měl jenom dva pevný disky značky WD, ale oba dva dost rychle umřely.
Na druhou stranu s disky od Seagate mám dobrou zkušenost.
zero, ale náhodná data. Beztak je potřeba ten disk přepsat několikrát (7x?), aby z něj zaručeně nešlo nic obnovit. Hlavně, že jsem tu o tom nedávno psal. A teď si to „užívám“ prakticky.
No reklamovat i tak, že se tam udělá jeden oddíl NTFS/FAT32, a další 3 Linux XFS/EXT4 a spolehlivě z toho žádný chytrák nic nedostane.Komiku.. Viz wikibooks - Jak postupovat při záchraně dat. Postupy lze uplatnit na libovolný souborový systém, pokud není šifrovaný.
A mimochodem: jen za poslední rok jsem řešil 11 vadných disků (úplně k.o. nebo těsně před kolapsam dle S.M.A.R.T.) a kupodivu jen JEDEN z nich byl WD (starší 320GB), zbytek všechno Seagate. Aktuálně třeba reklamuju 6 z 8 ks 750GB disků Seagate ES, které jsem pořídil před necelými třemi lety do jednoho storage serveru. Odešly v rozmezí dvou měsíců (ještě že mají pětiletou záruku). S disky WD mám jen ty nejlepší zkušenosti. Možná proto, že se vyhýbám levným ošizeným shitům (je jedno od kterého výrobce, shit je shit).
Jsem smířený s tím, že disk může čas od času odejít, proto jsem použil RAID 1, nemusím mít v domácím serveru extra spolehlivý disk, stačí, když neodejdou oba ve stejnou dobu (proto jsem taky kupoval jeden Seagate a jeden WD). Ale že si koupím takový „shit“ že bude fungovat víc než 10x pomalejší rychlostí, než by měl, to jsem nečekal – ani u levných disků.
Hardware_ECC_Recovered a Raw_Read_Error_Rate (musí se shodovat). Kdežto u WD musí být hodnota Raw_Read_Error_Rate nulová!
Moje zkušenost je taková, že obecně jsou disky Seagate spolehlivější bez ohledu na řadu, zatímco u WD opravdu velmi záleží na tom o jakou řadu jde. A jelikož v tom jejich značkování se prase vyzná, preferuji disky od Seagate.
md0 nebo sda. Na dvou dalších počítačích mám stejnou konfiguraci (LVM nad SW RAIDem) a tam jsem s výkonem spokojený.