Byl vydán Debian 13.6, tj. šestá opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.15, tj. poslední patnáctá opravná verze Debianu 12 s kódovým názvem Bookworm, k dispozici je LTS. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
V jádře Linux byla nalezena a v upstreamu již byla opravena kritická zranitelnost GhostLock aneb CVE-2026-43499. Lokálnímu uživateli umožňuje získat práva roota a také obejít kontejnerovou izolaci. Zranitelnost existovala v Linuxu 15 let, tj. od roku 2011, od Linuxu verze 2.6.39.
Evropská komise předběžně shledala, že návykový design aplikací Instagram a Facebook od americké společnosti Meta porušuje unijní nařízení o digitálních službách (DSA). Návykový design zahrnuje například takzvané nekonečné posouvání, automatické přehrávání videí, tzv. push notifikace, kdy aplikace uživatele vybízí k návratu do jejího prostředí, či vysoce personalizovaný algoritmus, který rychle pozná, co uživatele baví a snaží
… více »Byla vydána verze 1.97.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Švýcarská společnost Punkt. má nově v nabídce telefon Punkt. MC03. Telefon byl navržen ve Švýcarsku s důrazem na soukromí a digitální suverenitu a vyroben v Německu. V telefonu běží operační systém AphyOS (Apostrophy OS) založený na AOSP (Android Open Source Project) 15. Cena telefonu je 745 eur.
TypeScript (Wikipedie), tj. JavaScript rozšířený o statické typování a další atributy, byl vydán v nové verzi 7.0. Kompilátor byl kvůli výkonu přepsán z TypeScriptu do Go.
Europarlament podpořil pozměněnou verzi výjimky známé jako „chat control 1.0“ umožňující firmám skenovat soukromou komunikaci na internetu kvůli ochraně dětí před zneužitím. Pozměňovací návrhy přijaté europoslanci však počítají s tím, že z výjimky bude vyřazena šifrovaná komunikace. Výjimka přestala platit začátkem dubna poté, co se Evropský parlament a Rada EU nedokázaly shodnout na jejím prodloužení. Rada následně přijala
… více »Nejnovější X.Org X server 21.1.24 a Xwayland 24.1.13 řeší 2 bezpečnostní chyby.
Clement "Clem" Lefebvre publikoval souhrn dění v Linux Mintu za červen 2026. Vypíchnuta je vylepšená podpora Waylandu. Už není považována za experimentální. V příští verzi Linux Mintu, plánována je na Vánoce, bude běh Cinnamonu plně podporován na X11 i Waylandu. V květnu na vývoj Linux Mintu přispělo 611 dárců celkovou částkou 19 612 dolarů. Dalších 2 326 patronů přispělo na Patreonu celkovou částkou 5 334 dolarů.
V Linuxu v KVM byla nalezena a v upstreamu již byla opravena kritická zranitelnost Januscape aneb CVE-2026-53359. Root na hostovaném počítači (virtuální stroj) může obejít izolaci a získat plnou kontrolu nad hostitelským systémem (DoS útok nebo vzdálené spuštění kódu s právy roota). Na obou hlavních architekturách – Intel i AMD. Zranitelnost v Linuxu existovala téměř 16 let (od srpna 2010 do června 2026).
Pokud chcete RAID1 ze dvou disků, je otázka, co vám přinese řešit to pomocí btrfs. Myslím, že stejnou službu jako btrfs vám v takovém případě udělá i mdadm a teprve nad ním můžete mít btrfs.Třeba možnost řešení některých případů silent-data-corruption? Když mi jeden disk vrátí blok jako OK, ale btrfs nesouhlasí checksum, nemůže v případě mdadm dělat nic. V případě RAID1 na úrovni btrfs může zkusit týž blok přečíst z druhého disku a opravit ho na prvním. Takový ZFS to umí, a je to jeden z důvodů proč pod něj nedávat jiný RAID (mdadm, HW).
To, že pole pokračuje v provozu dál, už je popis nějakého chování, které je ve skutečnosti v rozporu s tou definicí.Jo, ale za předpokladu, že si tu definici nejdřív vhodně roztrhnete a nepohodlný kus odstraníte. Jinak jako vždycky melete ptákoviny. Mít možnost to jednou připojit v degradovaném režimu a pak už to bude read-only, znamenalo dodatečnou práci na straně vývojářů a tedy nic, co by tam bylo pro další vývoj v rámci vylepšování uživatelské stránky. Další vývoj už tam byl, někdo přidal čítač/flag a dodatečné chování. Chování, které naprosto jednoznačně popírá účel RAIDu: umožnit nepřerušené poskytování služby v případě havárie hardware.
Chování, které naprosto jednoznačně popírá účel RAIDu: umožnit nepřerušené poskytování služby v případě havárie hardware.Jenže to je nepochopení RAIDu (bohužel časté nepochopení). RAID neslouží k nepřerušenému poskytování služby v případě havárie, RAID slouží k předcházení škodám způsobených havárií – tedy k minimalizaci ztrát dat a ke zkrácení doby výpadku. Když vám z dvoudiskového RAID 1 vypadne jeden disk, máte dvě možnosti – buď pokračovat dál s jedním diskem a modlit se, aby nevypadl ani ten, a nebo systém zastavit, zreplikovat data na druhý disk a spustit ho znovu v režimu RAID 1. Oba případy jsou legitimní, a správce musí vědět, která varianta platí. Někdy je totiž opravdu mnohem levnější na chvíli zastavit systém a opravit ho, než riskovat ztrátu dat. Třeba banka radši bude chvíli sypat požadavky na příkazy k úhradě do fronty a neprovádět je, než aby je dál potvrzovala a zapisovala do systému, který může selhat – a banka pak bude mít den starou zálohu a k tomu hromadu potvrzených transakcí, o kterých nic neví.
Disk se naprosto bezne vymenuje za chodu, bez jakyhokoli vypadku systemu.Jenže tohle není jediný způsob, jak docílit bezvýpadkovosti. Vlastně je to ten nejhorší způsob. Komu nikdy nekleklo pole nebo řadič při výměně disku, ať hodí ... zálohovací páskou. A tenhle zastaralý způsob přemýšlení nad storage mě vlastně na celé věci vadí nejvíc. Sám používám BTRFS od roku 2010, v 2011 jsem napsal články a od té doby to jenom používám k maximální spokojenosti. A v roce 2020 vyjde článek, který se na btrfs dívá optikou starých storage někdy z 80 let. Prostě storage se nedělá tak, že to závisí na jednom stroji. U normálně navrženého storage (a nejen to, libovolného systému) nelze spoléhat na stabilitu jednoho stroje, ale je potřeba to mít distribuované. A potom je úplně jedno, jestli k výměně disku ten FS musím odmountovat nebo ne. Data pro klienty budou dostupná. A pokud změním myšlení tímto směrem, tak se současně odlehčí nároky na ten daný FS. Je fakt úplně jedno, jak se to zachová pouze s jedním diskem. Data jsou jinde. Na místo takových kravin ten fs může řešit podstatnější věci, jako atomické snapshoty, nezávislé subvolume apod. Ne, místo toho se hromada lidí zasekla v době někdy před 20 lety a požadují nejdřív funkční RAID podle jejich zkreslených představ, včetně nesmyslných R5/6 a až potom si možná přečtou něco navíc. Kdy ty vyšší funkcionality začnou používat fakt nevím. Ale což, tohle myšlení se projevuje i v jiných oblastech. Dneska každý může mít 10 emailových účtů, ale jsou lidé, kteří si hýčkají jen ten jeden a rozčilují se při sebemenším výpadku. Takže jo, klidně si stavte jedno 50 diskový pole, které když z libovolných důvodů vypadne, tak musíte poslat zaměstnance domů, protože to přece nejde vyřešit nijak jinak...
degraded, a jádro už si samo domyslí, jestli tím myslíte RW nebo RO.
Je mozne, ze nad tim proste nikdo ani vterinu nepremyslel a proste to tam jen tak placnul. Mimochodem MS ma podobny system (umi redundanci na zarizenich, nemusi mit stejnou velikost proste to jen garantuje, ze tam jsou 2 kopie na 2 discich (nebo vic dle nastaveni)) jmenuje se storage spaces. Svete div se- RAID1 tomu rezimu nerikaji.
man mkfs.btrfs (starej debian 9 - old stable). Názornější už to snad být nemůže.
RAID
a block group profile type that utilizes RAID-like features on multiple devices: striping, mirroring, parity
PROFILES
There are the following block group types available:
┌────────┬────────────────────────────────────┬────────────────────┐
│ │ │ │
│Profile │ Redundancy │ Min/max devices │
│ ├──────────────┬────────┬────────────┤ │
│ │ │ │ │ │
│ │ Copies │ Parity │ Striping │ │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│single │ 1 │ │ │ 1/any │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│ DUP │ 2 / 1 device │ │ │ 1/any (see note 1) │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│ RAID0 │ │ │ 1 to N │ 2/any │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│ RAID1 │ 2 │ │ │ 2/any │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│RAID10 │ 2 │ │ 1 to N │ 4/any │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│ RAID5 │ 1 │ 1 │ 2 to N - 1 │ 2/any (see note 2) │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│ RAID6 │ 1 │ 2 │ 3 to N - 2 │ 3/any (see note 3) │
└────────┴──────────────┴────────┴────────────┴────────────────────┘
Jelikoz to neni zdaleka prvni pripad, ktery vidim, ze se na tohle nekdo nachytal tak to vidim jako problem. Pritom to stacilo projevit trochu empatie, predvidavosti ze na druhe strane bude chybujici zaneprazdneny clovek a naznacit mu, ze je neco jinak... treba nazvem BTRFS REDUNDANCY1 nebo tak neco. Nic tezkeho.Chápu jak to myslíš, ale nesouhlasím se závěrem. Pokud si někdo při nasazení nové technologie nepřečte ani manuálovou stránku, tak mu ani jiné pojmenování příliš nepomůže, jen zkrátka narazí někde jinde. Obvykle o něco později, kdy bude ještě složitější to vyřešit. Zkrátka každá profese vyžaduje pokoru v určitých místech a k běžné práci admina patří i to, že čte dokumentaci a zkouší si různé scénáře provozu dané technologie. To je alespoň můj pohled na svět a moje zkušenost, ještě jsem nenarazil na žádnou technologii, který by neměla nějaké vedlejší efekty, které by mi bez čtení dokumentace / testů byly dopředu zřejmé.
Ne najednou, ale pokud se mezi smrti tech jednotlivcu stihne prepocitat pole, tak muzou umrit.Jasně a toto je dost silná podmínka. V nějaké diskusi vedle někdo radil použít co nejvíc do nejmenších disků. Jenže i to narazí na pravděpodobnost úmrtí dalšího disku během rebalance. Pokud do btrfs raid-1 dám 50 disků (jak se někdo ptal), tak pravděpodobnost výpadku dalšího disku během rebalance po výpadku prvního už není zrovna malá. A když se to stane, tak se 100% přišlo o část dat. Jednoduše proto, že btrfs ty bloky rozhazuje více méně náhodně, takže lze tvrdit, že kopie bloků z libovolného jednoho disku jsou rozprostřeny na zbývajících 49 diskách. A když po výpadku jednoho disku vypadne i další, tak se 100% přišlo o nějaká data. A vzhledem k tomu, že stačí, aby vypadl libovolný náhodný disk, tak šance na ztrátu dat s větším počtem zařízení dost rychle roste. Proto bych ocenil (a už to má být v 5.5) zvolit vyšší míru redundance. 3 pro větší počet disků se zdá být velmi rozumné.
Tiskni
Sdílej: