Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
Intel vydal 41 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20240514 mikrokódů pro své procesory řešící INTEL-SA-01051, INTEL-SA-01052 a INTEL-SA-01036.
Společnost Raspberry Pi patřící nadaci Raspberry Pi chystá IPO a vstup na Londýnskou burzu.
Google na své vývojářské konferenci Google I/O 2024 představil řadu novinek. Keynote byl věnován umělé inteligenci (DeepMind, Gemini, Responsible AI).
=== START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0 2 Throughput_Performance 0x0005 133 133 054 Pre-fail Offline - 93 3 Spin_Up_Time 0x0007 158 158 024 Pre-fail Always - 417 (Average 416) 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 13 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 128 128 020 Pre-fail Offline - 18 9 Power_On_Hours 0x0012 097 097 000 Old_age Always - 24132 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 13 22 Helium_Level 0x0023 100 100 025 Pre-fail Always - 100 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 1009 193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 1009 194 Temperature_Celsius 0x0002 153 153 000 Old_age Always - 39 (Min/Max 25/46) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0A jsou rozhodne chladnejsi, nez klasicke disky.
Ten EPYC patří mezi nejlevnější CPU, není to žádný megaboost CPU. Jinak zapomínáš na online kompresy a šifrování přenášených dat + musí unést nějakou tu VM a zvládnout topku v podobě 15Gbit trafficu. Velikost záloh je cca podobná jako v předchozím zápisku. Tj. denně cca 2TB a jednou týdně dump 10TB databáze + pár věcí okolo. K tomu mám část vyhrazenou pro obnovu VM, takže částečně přes den to bude sloužít jako úložiště pro testovací VM (testování update/upgrade apod.). Třeba teď tam mám obnovený 6TB emailový systém a dalších 6 VM okolo, který to potřebuje k životu a budu na tom testovat upgrade na novější verze.
Pokud se podívám na aktuální stav těch dvou NVMe, tak už mají za tu chvilku pěkně naběháno:
Critical Warning: 0x00 Temperature: 41 Celsius Available Spare: 100% Available Spare Threshold: 0% Percentage Used: 0% Data Units Read: 20,959 [10.7 GB] Data Units Written: 118,014,644 [60.4 TB] Host Read Commands: 386,604 Host Write Commands: 477,363,227 Controller Busy Time: 432 Power Cycles: 11 Power On Hours: 2,667 Unsafe Shutdowns: 2 Media and Data Integrity Errors: 0 Error Information Log Entries: 0
Pokud bych se měl vyjádřit k tomu JBODu, tak uvidíme. Teď je tam 42ks disků, teplota nejstudenějšího disku je 28C, teplota nejteplejšího je 45C a větráky JBODu běží snad na nejnižší otáčky.
ato jakoby zustane takle ležet nebo seto strčí do racku nebo pověsí nazeď?? :O :O v těch točicích discích sou mechanický součástky těm je jako jedno když se disky takle třeba natočej vo 90 strupňů?? :O :O
storcli /c0 show all |grep -i temperature ROC temperature(Degree Celcius) = 53 storcli /c1 show all |grep -i temperature ROC temperature(Degree Celcius) = 54V místnosti chladíme na 18C. volně ložený temp sensor v racku ukazuje 21C.
a co tak slýchám, tak bezproblémový.Za mě si udělejte čárku k "problémový" LSI3008 a LSI3108 (provozovaný jako HBA). Musel jsem na discích vypnout zápisovou cache (cache_type = "write through") a NCQ (queue_depth = 1), jinak ten řadič tuhl. Sice ne trvale, ale dost dlouho na to, aby třeba vypadl disk z RAIDu
aspoň 3 servery, spíše 4Ten čtvrtý je IMO navíc, pokud ho nepotřebujete kvůli kapacitě. Jinak pár let zpátky jsem byl na nějaké konferenci o úložištích - o Cephu tam mluvili nejvíc - a někdo z přednášejících měl spočítáno, že pokud z Cephu stavíte úložiště za účelem, který vám pokryje blackbox za půl milionu, tak se ten Ceph finančně nevyplatí. Zlom byl někde okolo 750 tisíc a nad to už Ceph vyšel cenově lépe. (Snad si ta čísla pamatuju dobře.)
výkon z toho nepůjde vyždímat takový jako u toho ZFSAFAIK Ceph nemá nic jako SLOG. (Teď jsem našel, že je to ve vývoji.) Má tiering, ale v dokumentaci je u toho hromada varování, že to s ním bude spíš horší, pokud zátěž není přesně taková, na jaké to bude fungovat
sent 91,362,212 bytes received 385,674 bytes 423,777.76 bytes/sec
Oproti tomu ten samý rsync z jednoho adresáře pracovního stroje do jiného:
sent 91,362,533 bytes received 385,716 bytes 425,745.94 bytes/sec
Docela dobrá náhoda, že to vychází skoro stejně, ale je potřeba vzít do úvahy, že v tom druhém případě se na tom pracovním stroji zároveň zapisuje i čte, takže výkon RBD cca poloviční
Používám tedy nativní šifrování a online kompresy.Vizte poslední odstavec v https://www.abclinuxu.cz/blog/Max_Devaine/2019/9/zfs-stavba-zkusenosti-se-zfs-storage#2
Tiskni Sdílej: