Balík nástrojů Rust Coreutils / uutils coreutils, tj. nástrojů z GNU Coreutils napsaných v programovacím jazyce Rust, byl vydán ve verzi 0.3.0. Z 634 testů kompatibility Rust Coreutils s GNU Coreutils bylo úspěšných 532, tj. 83,91 %. V Ubuntu 25.10 se již používá Rust Coreutils místo GNU Coreutils, což může přinášet problémy, viz například nefunkční automatická aktualizace.
Od 3. listopadu 2025 budou muset nová rozšíření Firefoxu specifikovat, zda shromažďují nebo sdílejí osobní údaje. Po všech rozšířeních to bude vyžadováno někdy v první polovině roku 2026. Tyto informace se zobrazí uživateli, když začne instalovat rozšíření, spolu s veškerými oprávněními, která rozšíření požaduje.
Jste nuceni pracovat s Linuxem? Chybí vám pohodlí, které vám poskytoval Microsoft, když vás špehoval a sledoval všechno, co děláte? Nebojte se. Recall for Linux vám vrátí všechny skvělé funkce Windows Recall, které vám chyběly.
Společnost Fre(i)e Software oznámila, že má budget na práci na Debianu pro tablety s cílem jeho vyžívání pro vzdělávací účely. Jako uživatelské prostředí bude použito Lomiri.
Proběhla hackerská soutěž Pwn2Own Ireland 2025. Celkově bylo vyplaceno 1 024 750 dolarů za 73 unikátních zranitelností nultého dne (0-day). Vítězný Summoning Team si odnesl 187 500 dolarů. Shrnutí po jednotlivých dnech na blogu Zero Day Initiative (1. den, 2. den a 3. den) a na YouTube.
Byl publikován říjnový přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Pracuje se na podpoře M3. Zanedlouho vyjde Fedora Asahi Remix 43. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Iniciativa Open Device Partnership (ODP) nedávno představila projekt Patina. Jedná se o implementaci UEFI firmwaru v Rustu. Vývoj probíhá na GitHubu. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0. Nejnovější verze Patiny je 13.0.0.
Obrovská poptávka po plynových turbínách zapříčinila, že datová centra začala používat v generátorech dodávajících energii pro provoz AI staré dobré proudové letecké motory, konvertované na plyn. Jejich výhodou je, že jsou menší, lehčí a lépe udržovatelné než jejich průmyslové protějšky. Proto jsou ideální pro dočasné nebo mobilní použití.
Typst byl vydán ve verzi 0.14. Jedná se o rozšiřitelný značkovací jazyk a překladač pro vytváření dokumentů včetně odborných textů s matematickými vzorci, diagramy či bibliografií.
Specialisté společnosti ESET zaznamenali útočnou kampaň, která cílí na uživatele a uživatelky v Česku a na Slovensku. Útočníci po telefonu zmanipulují oběť ke stažení falešné aplikace údajně od České národní banky (ČNB) nebo Národní banky Slovenska (NBS), přiložení platební karty k telefonu a zadání PINu. Malware poté v reálném čase přenese data z karty útočníkovi, který je bezkontaktně zneužije u bankomatu nebo na platebním terminálu.
To já fakt nevím, co dělá linux když něco nemůže přečíst. Že by posílal požadavek disku pořád dokola? Nebo že by disku opravdu tak dlouho trvalo, než to skutečně vzdá? Pole samozřejmě nemá důvod čekat, dávno si data dopočítá o odešle.
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x0008 083 082 000 Old_age Offline - 115001966 3 Spin_Up_Time 0x0006 098 098 000 Old_age Always - 0 4 Start_Stop_Count 0x0013 098 098 020 Pre-fail Always - 2370 5 Reallocated_Sector_Ct 0x0013 100 100 036 Pre-fail Always - 23 7 Seek_Error_Rate 0x0009 052 048 030 Pre-fail Offline - 1374444414102 9 Power_On_Hours 0x0012 092 092 000 Old_age Always - 7678 10 Spin_Retry_Count 0x0013 100 100 090 Pre-fail Always - 0 12 Power_Cycle_Count 0x0013 096 096 000 Pre-fail Always - 4978 197 Current_Pending_Sector 0x0030 100 100 000 Old_age Offline - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 12A moje nastavení:
/dev/hda: multcount = 32 (on) IO_support = 3 (32-bit w/sync) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 19846/16/63, sectors = 20005650, start = 0Staré Seagaty doporučuji, jsou levné a opravdu kvalitní například oproti WD, nebo IBM (ale to jsou jenom moje zkušenosti)...
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 3270 9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 3435ale prednedavnom som si uz vsimol nejake divne zvuky, ako keby nemazali loziska (keby tam ovsem nejake boli - tipujem, ze uz na vacsine/vsetkych (aspon 2.5'') diskov su fluidne :))
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 4 4 Start_Stop_Count 0x0032 097 097 000 Old_age Always - 4035 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0024 253 253 000 Old_age Offline - 0 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 882820 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1773 194 Temperature_Celsius 0x0022 133 100 000 Old_age Always - 35 197 Current_Pending_Sector 0x0033 253 253 010 Pre-fail Always - 0 198 Offline_Uncorrectable 0x0031 253 253 010 Pre-fail Offline - 0 199 UDMA_CRC_Error_Count 0x000a 100 100 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0 201 Soft_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0To vypadá celkem dobře, ne? zvlášť když na začátku mám
SMART overall-health self-assessment test result: PASSED
Power_On_Hours 0x0032 099 099 000 Old_age Always - 882820se mi nejak nezda...
pokud je to v hodinach, tak to odpovida dobe nejakych 100let
Pro ilustraci jeden 3 roky stary Seagate:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 758 9 Power_On_Hours 0x0032 074 074 000 Old_age Always - 23465 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 433(jsou uvedeny jen nektere polozky)
...podivejte se na teplotuHm, 35°C se mi nezdá jako nereálná hodota.
Doporučuju ve smartctl -a koukat i na error log. Pokud obsahuje nějaké chyby, je to nejlepší indikátor, že se něco děje a co se přesně děje.
Když disk při pokusu o čtení zjistí, že narazil na vadný sektor, tak to může dopadnout několika způsoby:
1) čtení trvá o něco déle, ale proběhne, a disk provede transparentní relokaci sektoru (nedojde ke ztrátě dat)
2) disk po pár pokusech vrátí OS chybovou hlášku, že "DriveReady SeekComplete Error". A pak sektor realokuje bez záchrany dat, tj. netransparentně. Takže při novém pokusu o čtení sektor přečte z náhradního umístění, ale jsou v něm halušky. Tato chyba by se měla správně objevit ve SMART logu.
3) disk se odmlčí, OS nahlásí timeout ATA/SCSI příkazu. Po rebootu se disk buď sebere a tváří se jako že nic (správně by mu měla přibýt chyba ve SMART error logu resp. "Grown defects listu"), nebo už to nerozchodí.
Obdobně to může dopadnout při zápisu, i když tady mi není jasné, nakolik disk může při zápisu odhalit vadný sektor, zda dělá validaci zapsaných dat, nebo zda prostě v některých případech nedokáže zaseekovat na stopu (nalézt pod hlavou naváděcí režijní značky)... - domnívám se, že B je správně.
Obvyklé chyby při čtení hlášené samotným diskem jsou dvou druhů: buď disk přečte ze sektoru data, která mají vadný checksum, nebo ani nedokáže zaseekovat na stopu. V Linuxu se tohle dá rozlišit z chybového kódu, případně ze SMART error logu (obsahuje tytéž informace). Interpretace ATA příkazů a chyb se dá dohledat na internetu.
No a pak jsou odchylky od očekávaného chování. Typický příklad: chyba se nedostane do SMART logu / grown defects listu, disk se při čtení tváří hrozně spokojeně, SMART error log je čistý, ale při pokusu o zápis padne disk na hubu (a po rebootu opět to samé). On totiž SMART ukládá svoje data taky jenom do nějakého režijního "SMART" sektoru na plotně (doslova 512 B), který není přímo adresovatelný. No a když má fatální problém se zápisem, tak už nezapíše ani ten SMART sektor. Taky se vyskytují bugy ve firmwaru disků. Přijde mi, že některé disky třeba na error log vysloveně kašlou.
Některé disky mají SMART "vypnutý". To se pozná ve chvíli, kdy se pokusíte o smartctl -a. Dá se pomocí této utility zapnout. Není mi ale jasné, zda ve vypnutém stavu disk vede statistiky (a je pouze vypnuté vnější rozhraní SMARTu), nebo zda při vypnutém SMARTu disk prostě nic nesleduje.
V RAIDu může být jistě problém s nějakým vaklem v hot-swap rámečku, nebo s přehříváním elektroniky disku - pak se chyba "opraví" vytažením a zasunutím disku. Podobně se ale chová disk při netranspaentní realokaci sektoru - ta by měla být vidět ve SMARTu, nejlépe jak ve statistice tak v error logu. Ostatně by měla být vidět taky jako událost v logu RAIDu, pokud RAID takovou věc má.
S RAIDy obecně je ten problém, že není vidět přímo na disk, takže nelze použít smartctl/scsiinfo - ledaže vypnete RAID a disky si připojíte na prostý HBA nebo onboard SATA kanál. Různé RAIDy poskytují různou úroveň podrobností ze SMART statistiky jednotlivých disků. Docela dobře je na tom Areca, z ní lze například vyrazit kompletní statistiky (surový SMART sektor) na dálku pomocí ovládací knihovny přes TCP/IP, inband přes SCSI nebo u interních PCI karet přímo přes PCI. (Něco se dá taky zjistit pollingem přes SNMP.) Bohužel ale nejde získat SMART error log - v hlavičkovém souboru knihovny je poznámka, že "tento SMART příkaz není implementován", patrně ani ve firmwaru. Nejedná se o prosté passthrough ATA SMART příkazů, číselné kódy příkazů jsou jiné.
Periodickou kontrolu povrchu disků umí tuším jakýkoli Adaptec AACRAID (SCSI, SATA, SAS), údajně má něco na ten způsob Areca apod. Externí Accusys umí dokonce nastavit den a hodinu, kdy se má scrubbing spustit (ale má zase jiné mouchy).
SMART sledují i ty nejlevnější externí RAIDové řadiče od Arecy a Accusysu. U interních RAIDů do PCI nemám přehled (kromě Arecy). U dražších a větších storage mrazáků taky nemám tušení.
Na vícečetné výpadky disků je dobrý RAID6 - přežije výpadek libovolných dvou disků.
Tiskni
Sdílej: