Vláda USA nařídila společnosti Anthropic pozastavit přístup k modelům Fable 5 a Mythos 5 pro všechny cizince, včetně zaměstnanců Anthropicu.
Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.
V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.
Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.
Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Řešení dotazu:
Btrfs. Ostatní jmenované formáty jsou vhodné spíš pro Národní technické muzeum.
Podle mě skvěle, protože jako jeden z mála souborových systémů má mount parametry specifické pro SSD a několik alokačních mechanismů speciálně určených pro SSD.
Jiná otázka je, jak jsou na tom SSD disky samotné...
Já osobně bych takovému zařízení svá data nesvěřil. Je to ubohá flashka, která vydrží asi tak pět přepsání, jen je to nesrovnatelně dražší.
Takový FUD by byl třeba tak v roce 2009 namístě, ale dnes nemáme rok 2009.
Zajímavé je, že ext4, který měl během existence Btrfs nesrovnatelně víc kritických bugů než Btrfs, včetně takových, které vedly ke ztrátě dat, nikdo za loterii neoznačuje.
Btrfs je pro lidi, kteří mají rádi rozumné přidělování místa na disku (bez předchozího rozdělení na předpotopní oddíly), kteří rádi zálohují z konzistentních snapshotů, kteří rádi upgradují svůj systém atomicky bez jakéhokoliv rizika selhání (kdo zná Illumos či znal OpenSolaris, ten ví, o čem je řeč) a konečně pro ty, kteří vědí, že cp --reflink prostě rulezzz.
Když chci redundanci (tj. mít něco fyzicky zapsáno dvakrát), může mi to zajistit automaticky samotný souborový systém (Btrfs), aniž bych musel používat nějaký tupý cp a sám ručně udržovat kopie aktuální. Další důvod pro Btrfs. Naopak cp --reflink je super třeba pro takový jednoduchý use-case jako třídění a zpracování fotek. Celý adresář s fotkami si napřed zkopíruju pomocí cp -a --reflink. Overhead na kopii metadat nestojí příliš za řeč. Pak můžu zkopírované fotografie upravovat, některé smazat, některé ponechat beze změn a tak dále. Narozdíl od hardlinků mi původní neroztříděné fotografie zůstanou v původním stavu a beze změn, což zpravidla chci. Narozdíl od symlinků se nic zlého nestane, když původní fotografie později smažu a nechám si jen ty protříděné a upravené. A konečně narozdíl od tupých kopií tam nemám ta data dvakrát. (I když například u ZFS by to vyřešila časem deduplikace. U Btrfs zatím není, pokud vím.)
To by mě zajímalo, co by takové „studie“ řekly například na Ext3 a Ext4. Třeba něco ve stylu „vždycky to bylo trochu buggy, ale co už, když je to staré, musí to být dobré“? Závěry o spolehlivosti by měly být dokumentované například na počtu selhání (výkonnosti, dostupnosti, konzistence dat) v hodně velkém datovém centru. Samozřejmě by byl Btrfs lehce v nevýhodě, protože dovede odhalit „silent data corruption“, zatímco ostatní scheisse-filesystémy vesele servírují poškozená data a nic neřeknou. I toto hledisko by se muselo správně zahrnout do srovnávacích metrik. Aby došlo k statisticky významnému počtu selhání hardware i filesystému, chtělo by to aspoň roční studii v pořádně velkém datovém centru, a to pokud možno s aktuálními systémy, ne s nějakým RedHatem, ve kterém je kernel 2.6.něco a podobné vykopávky. Takové studie ovšem nikde nevidím.
Na externím disku mám samozřejmě Btrfs. Kromě už jmenovaných killer features má navíc ještě (nepřímo) zmíněný checksumming dat, což dává RAIDu 1 v Btrfs i replikování dat a metadat jednotlivých souborů konečně hlubší smysl, protože když už něco selže, Btrfs aspoň dovede zjistit, která z duplicitních kopií se zdá být v pořádku a která vlastně selhala. Tedy se umí vypořádat korektně i s celou škálou selhání jiných typů než nedostupnost disku či nečitelné bloky.
Jirka Paroubek by se všech ostatních souborových systémů zeptal: Kdo z vás to má?!
Tiskni
Sdílej: