Daniel Gultsch: Jabber/XMPP: 25 let digitální nezávislosti
Co se dozvíte v článku
Digitální nezávislost byla před dvaceti lety jen buzzwordem a vlastně ještě nedávno o tom nikdo nepřemýšlel, dokud se nestaly ve světě některé nedávné změny. Open source je pro digitální suverenitu nutná podmínka, ale ne jediná.
Nabízí nám ochranu proti spyware, ověřitelnou kryptografii a kód, který můžeme zkoumat a pochopit.
Naopak nám open-source nezajistí ochrany proti vypnutí služby, sankcím, regionálnímu blokování a svévolným rozhodnutím operátorů. Suverenitu nám zajistí jen široká zaměnitelnost.
Znamená to možnost kdykoliv změnit poskytovatele služeb i software na straně serveru či klienta. Kterýkoliv z dodavatelů může být kdykoliv vyměněn, ale stále musíme být schopni se domluvit s ostatními.
Proto potřebujeme otevřené standardy. Otevřené API ale automaticky neznamená standard.
Ke standardizaci slouží různé organizace (SDO, Standards Developing Organisations) jako ISO, IETF, W3C a podobně. Mezi známe standardy patří DNS, HTTP, JSON, TLS nebo SSH. Naopak standardem není třeba S3 (Simple Storage Service), což je jen široce přijímaná volná shoda mezi mnoha nezávislými stranami.
XMPP je zkratka pro Extensible Messaging and Presence Protocol, který byl v prvních verzích standardizován už v roce 2004 a později rozšiřován. O standardizaci rozšíření se stará XMPP Standards Foundation (XSF), která má pravidla pro ochrany před tím, kdyby některá firma chtěla převzít kontrolu nad celým prostředím. Žádný člen se nesmí stát dominantním, aby byl schopen sám věci ovlivňovat.
Zhruba před deseti lety došlo k velkému přechodu uživatelů komunikačních aplikací k mobilním telefonům. Tahle doba byla důležitá, protože v té době ztratilo XMPP spoustu uživatelů.
Kvůli vylepšení provozu na mobilních sítích vzniklo rozšíření XEP-0198, které zajišťuje správu toku, potvrzování paketů a zotavení při změně sítě. Další rozšíření pak umožňuje například sledovat na serveru stav klientů, posílat zprávy na více zařízení, ukládat zprávy pro pozdější odeslání a distribuovat soubory několika odpojeným zařízením.
Rozšíření XEP-0384 pak zavedlo end-to-end šifrování pomocí OMEMO, což je stejné šifrování, které používají aplikace jako WhatsApp a Signal. Řeší se tam i možnost posílat šifrované zprávy na více zařízení najednou.
Vylepšen byl také šifrovaný transportní protokol používaný mezi klienty a servery, který má teď velmi širokou podporu mezi klienty.
Byl zaznamenán útok na největší ruský server pro XMPP, který proběhl na serverech poskytovatelů Hetzner a Linode. Šlo o útok na úrovni poskytovatele, kdy byla unesena žádost pomocí protokolu ACME.
Útočníkovi se tak podařilo získat platný certifikát od Let's Encrypt a mohl se tak vydávat za původní server. Stále není jasné, kdo za útokem stál, ale předpokládá se, že to byla nějaká státní organizace.
XMPP se vylepšuje dále, nabízí například možnost synchronizace mezi několika klienty. Umožňuje to odesílateli oznámit, že zpráva byla přečtena.
Kvůli soukromí je možné to vypnout, ve velkých skupinách to bývá často vypnuté. Další zmíněné rozšíření umí třeba informovat pisatele o časové zóně jeho kontaktu. Na některých klientech tak vidím, jestli ten člověk spí, protože je u něj zrovna noc.
Do budoucna se připravuje šifrování pomocí Stanza v XEP-0420, které by mělo být výrazně robustnější. Už máme deset let zkušeností s provozem OMEMO.
Chystají se také odpovědi na zprávy, které známe z jiných platforem. Podobně se pracuje na možnosti poslat více fotografií najednou, což jsou takové malé galerie v konverzacích. Pracujeme také na podpoře OAuth, aby bylo možné XMPP nasadit jednoduše v organizacích.
Posun by měl proběhnout na XMPP Sprintu, který proběhle v listopadu v Londýně.
Velkým plánem je XMPP 2.0, což je nový pokus dostat standard do IETF. Chceme aktualizovat základní sadu RFC a zkombinovat nejpopulárnější rozšíření do dalšího RFC.
Základ byl už představen a diskutován na IETF 126 ve Vídni, další práce se připravují pro IETF 128 v Kuala Lumpur.
Vyzkoušejte XMPP, stačí si vybrat vhodného klienta. V Linuxu to může být Dino, ve Windows Gajim, na Androidu Conversations a na iPhone třeba Monal. Poté musíte zvolit poskytovatele služby, což může být Conversations.im, providers.xmpp.net nebo nějaký místní třeba na univerzitě nebo v hackerspace. Pokud si chcete server provozovat sami, můžete nasadit Prosody nebo ejabberd. Většina distribucí je má zabalíčkované.
Jan Kára: Ext4 – nové triky starého psa
Souborový systém Ext2 vznikl v roce 1993 a byl inspirovaný souborovými systémy Minix a FFS z BSD. Diskový formát byl dobře navržený jako rozšiřitelný. Dodnes jsou formáty kompatibilní, dnešním jádrem si můžete připojit souborový systém z roku 1993.
Na začátku souborového systému leží bitmapy, které ukazují právě používané vlastnosti.
Jak rostly velikosti disků, zpomalovala se kontrola souborových systémů po nekorektním odpojení. Stalo se to neúnosným a začaly se implementovat vlastnosti jako žurnály.
V roce 2001 vznikl souborový systém Ext3, který toho na disku změnil málo, ale došlo k velkému přepsání celé implementace v jádře.
V roce 2006 pak vznikl Ext4, který přišel s novým formátem inodů. Protože to byla velká změna, vznikla kopie kódu na které se pracovalo, aby se nepoškodila data uživatelů.
Jakmile pak byl nový kód ověřený a stabilní, mohl se kolem roku 2015 původní kód ext3 z jádra smazat.
Souborový systém je rozdělen na alokační grupy, ve které je tabulka inodů pevné velikosti, bitmapa použitých bloků a bitmapa použitých inodů. Tabulka inodů a bitmapy nemusejí ležet nutně uvnitř grupy.
Velikost blokové bitmapy omezuje velikost grupy – typické alokační grupy mají 128 MB.
Inode je oblast velká obvykle 256 bajtů, která popisuje jeden objekt: adresář, soubor, link a podobně. Obsahuje informace jako velikost, práva, časy přístupu a modifikace a hlavně odkazy na datové bloky obsahující data příslušného objektu. Ve zbylém místě rezervovaném pro inode se ukládají rozšířené atributy.
Ext4 přišel s novým způsobem uložení informací o datových blocích do B-stromu, kterému se říká extenty.
Souborový systém Ext4 podporuje některé méně známé vlastnosti, které byly v přednášce představeny. V roce 2011 byla implementována vlastnosti bigalloc, která dovoluje alokovat místo na souborovém systému po velkých blocích. To umožňuje mít větší grupy a alokovat rychleji s menší režií.
Naopak se více plýtvá místem pro malé soubory.
Obvyklá velikost bloků je 4 KB na x86, protože jádro dlouho nepodporovalo jinou velikost bloku než jaká je velikost paměťové stránky. Na jiné architektuře si to můžete nakonfigurovat jinak, ale kvůli kompatibilitě se to příliš nepoužívalo.
Od roku 2025 je podporována libovolná velikost bloku bez ohledu na velikost stránky. Oproti velkým alokačním clusterům to neplýtvá místem pro metadata. Nevýhodou ale je, že malé soubory zabírají více místa v keši a je zvýšená režie při malých čteních a zápisech.
Moderní disky podporují atomický zápis delší než jeden sektor. Při výpadku napájení tak na disku uvidíte buď starý obsah nebo už nový obsah a nic mezi tím.
Je možné tímto způsobem ukládat větší množství dat, od 4 KB až třeba pro 1 MB. Výhodné je to zejména pro databáze, které se snaží tímto způsobem také pracovat.
Pokud databázi zaručíte atomické zápisy na úrovni disku, je možné odstranit dvojité zápisy a to vede až ke 30% navýšení výkonu. Pro direct IO přibyla podpora v roce 2025, ale jen do velikosti jednoho clusteru.
Ext4 obvykle používá žurnál, aby se zajistila konzistence souborového systému i při nekorektním odpojení třeba při pádu systému. Každá logická operace se skládá z řady kroků, kterým se dohromady říká transakce. Do žurnálu se zapíše informace o blocích, které se budou měnit a jejich obsah.
Po uložení všech změn se zapíše takzvaný „commit“, který říká, že transakce je úplná. Na pozadí pak začnete přepisovat změny ze žurnálu na správné pozice v souborovém systému.
Při připojování souborového systému se žurnál projde a od nejstarších se data zapíší na svá místa, čímž získáme jistotu, že je souborový systém v konzistentním stavu.
Souborový systém Ext4 může fungovat i v režimu bez žurnálu, podobně jako to dělal Ext2. Práce se žurnálem je náročná, pokud intenzivně pracujeme s metadaty, což nás stojí výkon disku.
Vždy totiž musíme zapisovat dvakrát, nejdřív do žurnálu a pak znovu na finální pozici. Jsou ale situace, kdy o konzistenci nestojíme, například pokud je na disku uložená třeba jen keš. Souborový systém můžeme po výpadku zahodit a vytvořit ho znovu prázdný.
Získáme tím asi 20 % výkonu při zápisech, což pro nás může být výhodnější varianta.
Jádro nabízí volání fsync, které zajistí uložení dat na disk, aby byla skutečně dostupná po výpadku. Je nutné při tom zapsat všechna data pro soubor, zapsat do žurnálu transakci s novým obsahem metadatových bloků. Vždy je ale aktivní jen jedna transakce a fsync čeká na zápis i nesouvisejících dat. Pro některé typy zátěže spotřebuje zápis do žurnálu až dvě třetiny výkonu disku.
Proto v roce 2020 vznikla nová vlastnost žurnálu fastcommit, která dovoluje při fsync zapsat jen zkrácenou transakci. Ta neobsahuje metadata, ale jen seznam logických operací, které proběhly od posledního commitu. Tím se výrazně snižuje množství dat, která je třeba zapsat do žurnálu.
V roce 2017 byla implementována podpora velkých rozšířených atributů, které se využívají například při ACL, SELinuxu a dalších aplikacích. Obvykle je velikost dat omezena na malý kousek zbývajících dat v inode, případně vám souborový systém alokuje jeden blok. Jsou to maximálně čtyři kilobajty, kam se musí vše vejít. To je docela málo místa.
Vlastnost ea_inode dovoluje alokovat skrytý inode a data uložit pomocí něj jako v souboru. Velikost atributu je pak omezena na 64 KB.
V současné době dochází k přechodu implementace na VFS infrastrukturu iomap. V ideálním případě bude jediným pozorovatelným efektem snížení nároků na CPU pro některé druhy zátěže.
Některé operace jsou už převedené, nejvíce práce bude se standardním bufferovým IO.
Mluví se také o přepisu alokace bloků, které se v současnosti nejprve označí jako zabrané a v inodu se označí jako nezapsané. Po bezpečném zápisu dat se bloky v B-stromě označí jako zapsané. Potřebujete tím pádem dvě modifikace pro jeden zápis.
Nová implementace by měla označit bloky jako zabrané jen v pamětí, čímž jsou vám vyhrazené. Poté se modifikace provede najednou v jednom kroku, což je výrazně efektivnější.
Přestože je souborovému systému přes 30 let, stále se rozvíjí a je široce používaný. V průběhu let do něj přidáno množství nových funkcí. Pravděpodobně tu s námi bude ještě nějaké to desetiletí.
Časem ale můžeme narazit na limity, které bude těžké v původním souborovém systému změnit. Pak bude jednodušší napsat vše znovu, ale pravděpodobně to nebude brzy.
Petr Kajzar: Když AI vrací medicíně lidskost
Když jste byli před lety v ordinaci, byli jste tam dva: lékař a pacient. Dnes je tam navíc informační systém, který neustále něco chce a je třeba se mu také věnovat. Zatímco pacient je v submisivní pozici a čeká, počítač často dostane víc pozornosti než člověk.
Datlováním se pak z lékaře stává necitlivý algoritmus. Proto v poslední době vznikají technologie, které mají lékaři vrátit lidskost.
AI není jedna věc, je to parťák, který má pomoci se zpracováním strukturovaných dat, obrazu, zvuku nebo textu. Všechny tyto systémy vytvářejí nějaký hezký výstup, který vypadá důvěryhodně, ale není to důkaz, že programu udělal, co měl.
Proto je AI ve zdravotnictví pod pečlivým drobnohledem a nedá se používat cokoliv.
Nový pacient si může přinést tlustou složku s neuspořádanými zprávami za 20 let, kde jsou různé obchodní názvy léků, spousta duplicit, zanořené alergie a rizika a další problémy. Nikdo nemá sílu se v tom zorientovat, ztrácí se kontinuita péče.
Můžeme si to naskenovat, ale to není digitálně zpracovatelná informace. AI tu může sloužit jako překlenovací most, který sken přepíše do textu, sémanticky analyzuje a připraví podklady ke kontrole. To už je něco, co člověk dokáže prolétnout očima a zjistit vše podstatné.
Spousta informací přichází také v podobě rozhovoru s pacientem, který lékaři sděluje řadu důležitých podrobností. Existují systémy, které poslouchají a vytvoří návrh zápisu pro lékaře.
Osvobozuje to ruce u klávesnice a nabízí to zestručnění dlouhého rozhovoru nebo to redukuje chyby v akutních provozech.
Tyto nástroje umožňují obnovení plynulého toku pozornosti. Můžu se dívat do očí a dostanu více prostoru pro klinickou rozvahu.
AI tedy dává lékaři čas, aby mohl přemýšlet o dalším postupu.
Různé nástroje dokáží analyzovat také obraz, kdy je možné automaticky analyzovat rentgenové snímky, oční pozadí či detekovat vzácné choroby. Je možné analyzovat i zvuk a hlas, nebo třeba filtrovat hluk v audiologii. Máme naslouchátka, která dokáží upozadit třeba cinkání lžiček v kavárně a zdůraznit rozhovor.
Na hlasu je možné provádět také diagnostickou analýzu, protože je možné takto poznat například počínající demenci.
Protože máme málo lékařů a specialistů, je dobré mít už v regionech dostupnou triáž. Praktický lékař může například vyfotit sítnici a analýza ukáže, jestli je potřeba další vyšetření nebo je vše v pořádku. Tím se neřeší jen diagnostika, ale i čekací doby, náklady na dopravu a nedostatek kapacit specialistů.
AI se také na rozdíl od lékaře neunaví.
Automatizované systémy by měly zajistit, že lékař nebude zbytečně plýtvat svou pozorností. Proto je možné, aby si data nejprve prohlédla AI a vybrala jen podezřelé úkazy. Data se mohou uložit do databáze a při příští kontrole je možné je porovnat a hledat změny.
Volně dostupné modely nemohou bezpečně stanovovat diagnózu ani léčbu. Hodí se nám modely, které jsou nasazené nad databázemi odborných publikací.
Riziko halucinací je nižší, než kdybychom použili běžné obecné jazykové modely.
Obecné modely dávají běžným uživatelům nejhorší scénáře, protože jsou kalibrované na riziko. Chatbot ví, že potřebujete ujistit a přitakává vám. Kdy se zeptáte, zda nemáte něco vážného, jen vás v tom utvrdí.
Chatbot také nemá kontext a nemůže vás doopravdy vyšetřit. Často rád padá do extrému, buď vás uklidňuje nebo naopak děsí.
Mnohem lepší je, když pacient používá chatboty jako překladače z „doktorštiny“ do běžného srozumitelného jazyka. Lékaři často používají zkratky a slova, která ani ostatní doktoři nedokáží přečíst.
Dobře také fungují jako zdravotní kouč a příprava na návštěvu lékaře.
To, že model něco tvrdí, ještě není medicínský argument. Mělo by být zřejmé, z čeho výchozí a v jakém kontextu se pohybuje. Klinické jazykové modely vyžadují RAG architekturu, kdy čerpají data z ověřených databází a uvádějí přesné citace.
AI je jen chytře aplikovaná statistika, která výstupy generuje na základě trénovacích dat. Je tu tedy riziko zkreslení a je potřeba vždy vědět, zda je daná odpověď relevantní pro daného pacienta. Zkreslení může v trénovacích datech způsobit třeba pravítko, které lékař přikládá kvůli fotografii jen u už podezřelých jevů.
Cílem AI by mělo být minimalizovat matematickou chybu, ale to se nemusí krýt s cíli lékaře, pacientů ani zdravotnictví. Musíme vždy přemýšlet nad tím, jaký bude mít výsledek dopad na pacienta, abychom jen slepě neaplikovali výsledky na všechny.
Je nutné například také při trénování chránit citlivá data pacientů.
AI pomáhá diagnostikovat, léčit a nalézt třeba lékové interakce. Lékař ale má přinést klinickou odbornost a odvahu věci zjednodušovat. Lékař by měl získat čas, pozornost a kognitivní kapacitu zaměřit se na pacienta.
Nejlepší technologie je ta, která je nakonec úplně neviditelná.
Radek Zajíc: GNU/Linux a Segment Routing over IPv6 (SRv6)
Tunelovat potřebujeme kvůli segmentaci provozu či virtualizaci sítě nebo chceme dělat traffic engineering, tedy přesně řídit cestu při přenášení paketů. Obvykle nic takového neděláte, v internetu se hledá nejkratší cesta, což ale vždy nemusí být cesta nejlepší.
K tunelování je možné použít IPSec, kdy tranzitní síť neví, jaká data se přenášejí. Má dva režimy: v tunelovacím se šifruje celý paket, v transportním se šifruje jen obsah paketu. Druhou populární technologií je WireGuard, který je moderní, jednoduchý, ale nemá rozumnou orchestraci. Pro transport se používá UDP a šifruje se vždy celá komunikace, takže při přenosu není vidět skutečný zdroj a cíl.
EVPN/VXLAN je způsob, jak přenášet ethernetové rámce na už existující IP infrastruktuře. Vše je virtualizované, takže například každý klient může mít svou vlastní L2 nebo L3 síť.
Jako control plane se používá protokol MP-BGP, který distribuuje informace o MAC a IP adresách. Jako identifikátor segmentu se tu používá VNI, což je obdoba VLAN, ale škálující do milionů. V podstatě je to virtualizovaný ethernet.
Všechny tyto technologie mají společné to, že nejprve zajistí enkapsulaci paketů z místa A do B. Tranzitní síť pak neřeší obsah paketu, ale jen ho přenese. SRv6 pak k tomu přidává informace o tom, kudy se mají data posílat.
V klasickém směrování se každý síťový uzel rozhoduje o dalším vysílání sám podle svojí směrovací tabulky. V případě source routingu pak odesílatel může určit celou cestu předem. Každý paket si může nést takzvaný Segment list (SL), což je seznam uzlů označených SID (Segment IDentifier), kterými má paket projít.
Tradičním předchůdcem SRv6 je MPLS, kdy zákaznický směrovač nic o MPLS neví. Teprve operátorský hraniční směrovač paket označí a pošle do jádra sítě, kudy projde a na konci se z něj zase stane běžný paket. MPLS label říká, kam s paketem dál. SRv6 tuto myšlenku přebírá a směrovače na cestě pak vědí, co s daným paketem udělat.
SRv6 nevyžaduje žádné speciální rozšíření paketu, ale používá se při něm jen obrovský adresní prostor IPv6. SRv6 dává význam konkrétní IPv6 adrese.
Použitá adresa má vnitřní strukturu, kdy se adresa dělí na lokátor, funkci a případně argumenty. První část ukazuje, kam se má paket doručit a poté co se má s jakými parametry s paketem udělat. Hodnota funkce není univerzálně daná a je vždy na správci sítě. Z adresy není možné poznat, co se s paketem v cíli stane.
Volitelnou hlavičkou je SRH (Segment Routing Header), která může nést informaci o tom, kolik segmentů ještě zbývá navštívit. Také se v ní nachází Segment List, což je seznam segmentů v obráceném pozadí. Velikost hlavičky je 8 bajtů na hlavičku a 16 na každý segment IPv6 adresy. SRH může chybět, pokud je cílovou hlavičkou jediný segment a hlavička by nic dalšího nepřidala.
V linuxovém jádře se objevovala podpora postupně, první část je v něm od roku 2017. Na rozhraních je potřeba nastavit volbu net.ipv6.conf.<iface>.seg6_enabled=1, což povolí SRv6 na konkrétním rozhraní. Konfigurace pak probíhá pomocí standardního nástroje ip.
SRv6 je stále ještě novinka, která není proti tradičním technologiím dostatečně prozkoumaná a spousta zařízení ji ještě nepodporuje. Přesto je to zajímavá možnost, kterou stojí za to sledovat.
Pozor na to, že SRv6 data nešifruje, pro šifrování je potřeba přidat například IPSec v transportním režimu.
Pro dynamické směrování je potřeba použít routovacího démona. Zatím je základní podpora jen součástí FRR, ale ani tam ještě není úplně dospělá. Podpora v démonu BIRD v tuto chvíli úplně chybí, takže je možné jej použít jen k zajištění dostupnosti přenosové sítě a zbytek je třeba stejně nakonfigurovat ručně.
ČLÁNKY DO MAILU