DuckDuckGo AI Chat umožňuje "pokecat si" s GPT-3.5 Turbo od OpenAI nebo Claude 1.2 Instant od Anthropic. Bez vytváření účtu. Všechny chaty jsou soukromé. DuckDuckGo je neukládá ani nepoužívá k trénování modelů umělé inteligence.
VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
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 verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
/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 iotop
u) 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
iotop
u 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ý.
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ý.