Devatenáctý ročník konference OpenAlt se opět konala na FIT VUT v Brně. Akce vznikla sloučením konferencí LinuxAlt a OpenMobility. Dříve jsme dělali pravidelné srazy, ale to se nám v poslední době nedaří. Pokud se s námi budete chtít potkat, napište nám do telegramové skupiny a zamluvte hospodu,
zval k další aktivitě při zahájení konference Jozef Mlích. OpenAlt kromě toho také zastřešuje různé otevřené projekty, provozuje řadu webů a různých služeb.
Na konferenci samotné se podílí asi 50 přednášejících, zhruba 10 dobrovolníků na místě a asi pětičlenný tým, který na akci pracuje několik měsíců předem. Děláme to úplně zadarmo, protože si myslíme, že taková akce by měla existovat.
Organizátoři rozhodně uvítají do svého týmu další lidi, kteří převezmou část úkolů. Témata konference zůstávají tradiční, mluví se o otevřeném software, hardware i společnosti.
Letos se podařilo zajistit studentský track, na kterém své projekty předváděli středoškolští studenti. Jde o různé maturitní a další práce, myslím, že to bude velmi zajímavé a těším se na to.
Ondřej Profant: Jak to bylo se stavebním řízením
Proč potřebujeme digitalizaci stavebních řízení? Česko trápí krize bydlení, zároveň jsou byrokratické postupy velmi zkostnatělé a i velmi jednoduchá řízení mohou trvat roky. I velcí developeři jsou nervózní z toho, že je celý systém nepředvídatelný a chová se náhodně.
Jednou z příčin je, že sice jde o státní stavební řízení, ale je v přenesené působnosti samospráv. Je to roztříštěné napříč obcemi, kterých je 6500.
Musíme s tím tedy něco dělat a posunout se dál.
Jedním z řešení je procesní změna, tedy úprava zákona, který věci odblokuje. Už nejsme ve stavu, kdy bychom chtěli vyvinout dokonalé řešení, ale potřebujeme alespoň věcí nezhoršovat.
Dalším krokem je zjednodušení prováděcí části řízení, aby vše běželo hladce.
Cílem změny je zkrátit stavební řízení, zvýšit pohodlí pro občana a úředníka. Řízení by také mělo být v každém případě spravedlivé. Kvůli té roztříštěnosti se může ve vaší obci stát, že jsou všichni nemocní a máte smůlu. Soused o obec vedle může za měsíc stavět.
Příjemné by také bylo, kdyby nový systém byl moderní.
Příprava probíhala mezi lety 2017 a 2021, kdy ministerstvo vyjednalo finanční zdroje. Vytvořilo také nějaká pracovní místa, ale ta zůstala z většiny neobsazená.
S přípravou také pomáhalo sdružení dodavatelů ICT a zakázka byla rozdělena na čtyři části. Což začne dávat smysl, když k tomu začnete dávat jména firem, které by to mohly dělat.
Vše mělo také proběhnout formou soutěžního dialogu, což je metoda velmi náročná na kvalitu práce zadavatele.
S novým vedením ministerstva vznikl nový tým o patnácti lidech. Stále to není ideální, jsou to stále úředníci s tabulkovými platy. Alespoň je to nějaká realistická snaha.
Tři ze čtyř zakázek přestaly běžet formou soutěžního dialogu a proběhlo klasické zadání pomocí 200stránkové dokumentace. Je tam přesně popsáno, co má systém dělat, kdy má doplňovat jaké podpisy, kdy se má co stát a podobně.
Soutěž byla vypsána v březnu 2023.
Vítěz byl skutečně vybrán, byla jím firma InQool. Poté byla zakázka napadena drobnou firmou nesplňující kvalifikační kritéria pro účast na zakázce. Na základě této stížnosti pak ÚOHS zakázku v listopadu 2023 zrušil.
V tu chvíli zbývalo osm měsíců do spuštění nového systému. Přes všechny průtahy ale systém vznikal na základě nové zakázky s velmi osekaným zadáním v rámci jednacího řízení bez uveřejnění. Jako první v takové situaci zjednodušíte zadání o pohodlné UX rozhraní.
Základní architektura zahrnuje portál stavebníka pro žadatele, spisovou službu pro řádnou práci s dokumenty na pozadí a konečně klíčový informační systém stavebního řízení (ISSŘ) pro práci úředníka. Projekt byl pod neustálým tlakem a čas na přípravu byl necelých osm měsíců, ale to ještě není vše.
Do celé věci musí vstoupit také stavební úřady na obcích a v krajích.
Stavební úřady byly pod tlakem a někteří lidé si ještě v červnu mysleli, že se systém spouštět nebude. V té době na úřadech většinu techniky zajišťoval jeden dlouhodobý dodavatel, který vyvíjel decentralizovaný systém.
U něj je problém s audity a prověřováním práce jednotlivých úřadů. S tím systémem byly ale úřady spokojeny, protože dělal, co po něm úředníci chtěli.
Výsledkem bylo sabotování školení na nový systém, kdy se do testovacího prostředí přihlásila zhruba polovina úředníků. Na školení jich přišlo ještě méně a ptali se například na to, proč je nastavení schováno pod ozubeným kolečkem a filtry pod trychtýřem.
Tohle bylo podceněno na úrovni ministerstva, které komunikovalo přes oficiální kanály – primárně přes kraj. Kraje se ale bavily primárně o tom, co samy potřebují a nereprezentovaly obce a jejich uživatele.
V době spuštění pak nastal největší problém s nastavením práv pro uživatele na jednotlivých úřadech. Samosprávy dostaly instrukce už v květnu, ale ministerstvo nemělo přesnou představu o počtu úředníků.
Nebylo tedy možné jednoduše zjistit, které obce mají práva správně připravená. Další problém představovala už zmíněná slabá proškolenost úředníků, přes možnost zúčastnit se online nebo si později pustit záznamy. Musím přiznat, že byl i velký problém s UX a návodností průchodu celým systémem.
Ne vše bylo přehledné a nedostatečné bylo i informování o věcech, které není možno udělat.
Přišly také další drobnější problémy zahrnující komunikaci mezi jednotlivými částmi systému nebo limity v hybridní poště. Někteří účastníci řízení totiž nemají datovou schránku, takže je třeba spisy tisknout a posílat poštou. Někdy má ale spis i tisíc stran a často velkoformátových, na což občas pošta na některých pobočkách narážela.
Tyto problémy se ale podařilo postupně vyřešit a bude jich ubývat, jak přibývá počet datovek.
Výsledkem byl ale moderní webový centrální systém, který je postavený na moderních otevřených technologiích jako Docker, PostgreSQL a dalších. Poprvé jde o dílo kompletně v majetku ministerstva a poprvé v historii máme k dispozici také reálná data o stavebním řízení.
Do té doby byly k dispozici jen obecné statistiky z malých vzorků. Nový systém umožňuje detekovat centrálně různé problémy.
Jsou například úřady, na kterých je jen jeden zaměstnanec – když je nemocný, tak úřad nepracuje.
Systém byl sice nedokonalý a bylo na něj málo času, ale znamenal posun a přinášel nové možnosti do budoucna. Čas spuštění ale nebylo možné posunout jednak kvůli zákonu a také kvůli milníkům v evropském financování. Jednotlivé kroky musejí navazovat a když jeden plán selže, nedodržíme předepsaná pravidla.
Tyhle věci bylo možné posunout, ale bylo by to náročné a možná by to nakonec skončilo stejným výsledkem.
Ministerstvo se nakonec rozhodlo celý systém zahodit a začít na něm pracovat znovu. Jelikož je ale celý software v majetku ministerstva, bylo by možné jej případně i zveřejnit pod otevřenou licencí.
Petr Hodač: GCC – překladač, optimalizace, měření, CPU
GCC je zkratka pro GNU Compiler Collection a jde o nástroj pro překlad různých jazyků: C, C++, Objective-C, Objective-C++, Fortran, Ada, D a Go. Mnoho kódu, který není v C a C++ a běží na velkých superpočítačích, je napsáno ve Fortranu, protože mnoho nejen fyzikálních simulací je napsáno v něm.
Běžní linuxoví vývojáři se nejčastěji zabývají jazyky C a C++ a mohou z toolchainu využít nástroje jako gcc, gdb, glibc, debuginfod, valgrind a binutils. Celá komunita kolem těchto nástrojů se pravidelně schází na konferenci GNU Tools Cauldron.
GCC má vývojový cyklus o několika krocích. Ten první trvá asi čtyři měsíce a přibývají během ní nejrůznější změny. Poté se přibližně dva měsíce ladí chyby a pak vyjde nová verze. GCC vychází, až je hotové.
I samotný překladač je potřeba něčím přeložit a nestačí přitom vzít starou verzi a přeložit s ní nový kód. Dalším krokem je vzít takto zkompilovaný nový překladač, přeložit s ním nový kód znovu a pak to udělat ještě jednou. Obě výsledné binárky se porovnají a pokud jsou stejné, máme připravenou novou verzi. Na dnešních počítačích to trvá jen 30 minut, dřív to ale byla mnohem delší doba.
Moderní překladač se skládá z několika částí. Frontend se věnuje gramatice konkrétního jazyka, poté probíhá ve střední části optimalizace a nakonec se v backendu připravuje kód pro danou architekturu. Když přidáváte podporu pro nový jazyk, pracujete téměř výhradně na frontendu, naopak když přidáváte podporu pro nový procesor, upravujete naopak backend.
Všechny průběžné kroky při zpracování je možné si uložit do samostatných souborů a zkoumat je.
Když už máme procesor a dokážeme na něm spouštět svůj kód, můžeme na něm začít něco měřit. Jak ale získat porovnatelná data z různých architektur? Chcete mít co nejvíc různých platforem, abyste věděli, jak se to na různých systémech chová.
Je třeba zajistit stejné prostředí a stejné nastavení. Je vhodné také zakázat randomizaci paměťového prostoru a vypnout limit pro stack.
Pro měření se používají komerční benchmarky s názvem SPEC, které se staly standardem pro celý trh. Když Intel a AMD vydají nový procesor nebo nějaký výrobce postaví nový server, vždycky uvádí výsledky benchmarku i podle SPEC.
Vývojáři GCC hlídají problémy pomocí dlouhé řady kompilačních benchmarků, které běží neustále dokola a s různými parametry. Když nějaký vývojář něco vylepší, je potřeba pohlídat, že to nerozbilo něco jiného.
Proto je připravena spousta testů, které se neustále dokola kompilují a vykreslují do grafů. Koukáme, jestli se něco nezlepšuje nebo nezhoršuje, když nemá.
Tohle testování tedy funguje jako pojistka, navíc probíhá na mnoha různých platformách: Zen2, Zen3, Zen4, Arm a Intel. Hlídáme i výsledek běhu, takže když nějaký test vrátí jinou hodnotu, víme o tom.
GCC má obrovskou spoustu různých optimalizačních voleb, které je možné použít. Optimalizace jsou bezpečné, ale existují speciální případy, kdy je třeba vědět, jestli si vývojář může danou optimalizaci dovolit – například se zaokrouhlováním v plovoucí čárce a ofast.
I tyhle optimalizace se tedy ověřují, jestli dělají, co mají.
Záleží i na cílové architektuře, která musí být správně zvolená. Když si při kompilaci žádnou nevyberete, použije se nějaká obecná, která je málo optimalizovaná a měla by běžet všude.
V praxi je ale výhodné vybrat správnou architekturu a využít jejich specifických vlastností. Tohle taky hlídáme pro všechny optimalizace, abychom věděli, že vše dopadlo správně.
Uživatelé se často ptají, jestli má smysl aktualizovat GCC na novější verze. Novější překladač toho umí víc a trvá mu to déle, ale výsledkem je rychlejší kód. Musíme si uvědomit, že nám roste i výkon procesoru, takže nás čas kompilace tolik netrápí.
Přesto ji vývojáři sledují a dávají si na případné změny pozor. Cím víc toho ale GCC umí, tím to o maličko déle trvá.
Výsledky benchmarků napříč verzemi GCC je možné studovat na webu lnt.opensuse.org.
Michal Hrušecký: Novinky v Turrisu
Pro Turris Omnia je k dispozici nový 5G Kit, který není kompatibilní s Omnií Wi-Fi 6, protože se do ní už nevejdou antény. Uvažujeme, že do budoucna zvětšíme krabičku, abychom mohli přidat antény.
Součástí sady je nový horní kryt, antény, pigtaily, chladicí kostka, adaptér na M.2 a samotná karta. Ta využívá modem Quectel RM500U-EA, který byl vybrán pro relativně příznivou cenu. Konečně 5G modem nestojí víc než celá Omnia.
Přes 5G je možné v centru Prahy dostat 400 Mbit download a 200 Mbit upload. V současné době je 5G nastaveno jako záložní konektivita, když není do rozhraní WAN připojen kabel nebo za ním není připojení k internetu. Na LTE ještě bylo přepnutí někdy poznat, na 5G si toho obvykle nevšimnete.
Vývojáři pracovali na velkém zařízení Turris Omnia Enterprise, které bylo plánováno už na konec roku 2022. Nyní vývojáři intenzivně pracují na novém prototypu. Hledali jsme hardwarový problém, ale všechny dílčí testy dopadaly dobře.
Nakonec se ukázalo, že je problém v paměťové sběrnici. Nyní se pracuje na nové verzi, která by měla stát přibližně 1000 dolarů. Uvnitř poběží osmijádro Cortex A-72 na 1,8 GHz, až 64 GB RAM v modulech a šest 10Gbps SFP+ modulů. Ne každý ale něco tak výkonného upotřebí.
Paralelně proto vznikala nová verze Turris Omnia NG, která by na trhu měla nahradit stávající Omnie. Práce na prototypu jsou v hodně pokročilém stádiu.
Uvnitř poběží čtyřjádrový Cortex A-73 na 2,2 GHz, 2 GB RAM, čtyři 2,5Gbps a dvě 10Gbps SFP+, na bezdrátové straně bude k dispozici Wi-Fi 7. Zase půjde o výkonné zařízení, které vydrží dlouhé roky.
Na trh by se NG měla dostat v příštím roce a měla by stát výrazně méně než Omnia Enterprise.
Vývojáři pracují na TurrisOS 7.1, který je v současné době ve stádiu RC. Systém přejde z IPtables na Nftables, což zjednoduší konfiguraci firewallu pro IPv4 a IPv6 a zjednoduší integraci nástroje Turris Sentinel. Znamená to, že vám přestanou fungovat vaše skripty pro IPtables. Pokud jste si ale poctivě vše napsali do UCI, nic se vám nerozbije.
Turris Sentinel se teď více zaměří na IPv6, v době jeho psaní byl počet útoků po šestce zanedbatelný. Teď ale vše přepisujeme, takže jsme se rozhodli do toho pořádně šlápnout.
V první fázi bude v plánu blokovat útočný provoz z celých bloků /64, v budoucnu se podle situace vývojáři mohou rozhodnout pro /56 nebo dokonce /48.
Další na řadě je přechod na Turris OS 8, který je postavený na OpenWrt 23.05. Už nyní je systém použitelný, ale řeší se problémy s neobvyklou architekturou v prvním modrém Turrisu. Ten používá architekturu PowerPC, ale má nestandardní hardwarovou floating point jednotku.
Tu už nepodporují nejnovější kompilátory a systémové knihovny. Nechceme ale podporu modrého Turrisu ukončit, přestaneme jen podporovat tu hardwarovou akceleraci.
Z původní sady dvou tisíc kusů je jich ještě více než tisícovka v provozu.
OpenWrt pracuje na verzi 24.xx s jádrem 6.6, která by měla vyjít pravděpodobně ještě letos. Příští rok na něj proto naváže také Turris OS 9. Naše nová připravovaná zařízení budou vyžadovat podporu v jádře a už vyjdou pravděpodobně s devítkou.
Jiří Eischmann: Nerozbitný Linux pro celou rodinu
Když chcete běžnému uživateli nainstalovat linuxový systém, je to dnes mnohem jednodušší, protože se spousta věcí přesunula na web. Řada uživatelů dnes otevře webový prohlížeč a to jim stačí.
Na druhé straně je dnes výrazně vyšší konkurence, protože tu máme Android, ChromeOS, macOS a další systémy.
Stále platí, že by výsledné řešení mělo plnit požadavky uživatelů a nevyžaduje pokud možno žádné servisní zásahy. Uživatelé jsou dnes do značné míry schopni si systém spravovat sami.
Na začátku je potřeba zvolit linuxovou distribuci. Já používám Fedoru, protože ji znám nejlíp a dobře se mi s ním pracuje. Můžete ale zvolit něco jiného.
Doba neměnného LTS systému je zřejmě pryč, uživatelé jsou zvyklí na průběžné změny a vlastně je očekávají. Udržovat LTS je také pro distributora velmi drahé a naopak systémy sledující průběžné změny mají více opravených chyb.
Uživatelé jsou dnes také ochotni akceptovat různá uživatelská rozhraní. Dříve jsme museli imitovat prostředí Windows a dát správnou ikonu na správné místo.
Uživatelé jsou dnes mnohem flexibilnější, běžně přecházejí mezi různými operačními systémy, které se mohou používat velmi odlišně.
Ze světa mobilních platforem byl do takzvaných „neměnných“ linuxových distribucí převeden princip, kdy základ systému přichází jako jeden obraz aktualizovaný atomicky. Fedora Silverblue je obsahově běžná Fedora Workstation, která je ovšem spravovaná pomocí OSTree. Nejlépe se to vysvětluje jako operační systém uložený v Gitu.
Každá aktualizace je vlastně přechodem na další commit, přičemž si systém stáhne jen změny a po restartu nabootuje nová verze. V případě problémů je možné se kdykoliv vrátit k libovolnému snapshotu v libovolné větvi.
Běžní uživatelé zásadně neaktualizují, pokud aktualizace závisí na jakékoliv jejich aktivitě. Klasická Fedora jednou týdně zobrazí oznámení, které je potřeba potvrdit a nainstalovat nové verze balíčků. Stejně to ti uživatelé nedělají. Proč by aktualizovali, když jim všechno funguje?
OSTree umožňuje na pozadí všechno připravit a pak při příštím restartu nasadit.
V případě Fedory Silverblue došlo ke stoprocentnímu oddělení systémové a aplikační vrstvy, o kterou se stará Flatpak. Výbornou vlastností je, že se Flatpaky průběžně automaticky aktualizují na pozadí.
Jakmile aplikaci restartujeme, automaticky naběhne nová verze. Uživatelé nad tím nemusejí přemýšlet, stejně jednou za čas aplikace vypínají.
Nakonec tedy stačí jednou za čas počítač restartovat a tím se všechny aktualizace vyřeší bez dalšího zásahu. Pokud nastane po restartu problém, stačí v zavaděči vybrat druhou položku a vrátit se k předchozí funkční verzi.
Pro vzdálenou správu je možné použít vlastní VPN třeba na WireGuardu, kterou poučení uživatelé umějí zapnout a pustit správce do systému. Používám SSH nebo vzdálenou plochu pomocí RDP, nic složitějšího není třeba vymýšlet.
Ondřej Caletka: Pohled do zákulisí sítě pro RIPE Meeting
RIPE Meeting je setkání, na kterém se dvakrát ročně setkávají lidé z evropského regionu. Přibližně 600 lidí se tam baví o tom, jak by se měl internet v našem regionu rozvíjet.
Účastníci jsou síťoví odborníci, kteří jsou nároční na připojení k internetu. Vozíme si sebou vlastně svého poskytovatele připojení, který má k dispozici /21 IPv4 adres a /48 IPv6 adres.
Organizátoři řeší například problémy s geolokací, protože obvykle služby nepočítají s tím, že se celý poskytovatel pohybuje napříč Evropou. Pro geolokaci pomocí IP adres existuje mnoho různých služeb, které provozuje mnoho různých poskytovatelů. Neexistuje žádná jednotná databáze ani zdroj pravdy ohledně umístění jednotlivých adres.
Vznikl standard RFC 8805, kterému se dnes říká „geofeed“ a jde vlastně o jednoduchý soubor CSV, ve kterém je uložena vazba IP adresy její lokalizace. Je to čím dál populárnější, jak se adresní prostor drobí na menší a menší sítě.
Pořád je potřeba čísti poskytovatelů geo dat posílat mailem informace o tom, že si mají znovu zpracovat soubor s daty po nějaké změně. Někteří už to naštěstí umějí automaticky.
Fyzická síť je pak realizována na malých serverech SuperMicro, na kterém je vše virtualizováno na 25 virtuálních serverech: směrovače firewaly, DHCP servery, DNS resolvery a Wi-Fi controller. Pro ethernet se používají přepínače Juniper, Zyxel a MikroTik. Pro bezdrátovou síť se používají Wi-Fi přístupové body Unify UAP AC (S)HD. Jsme s nimi celkem spokojení, ale jsou už docela staré a mají jen Wi-Fi 5, což ale na konferenci pořád stačí.
Vše je uloženo do beden, které se pak na místo dopraví pomocí přepravní společnosti. K dispozici je v nich také spousta podpůrného materiálu jako prodlužovačky, kabely různých délek a podobně.
Celá síť běží na open-source software: hraniční směrovače používají BIRD, firewall využívá Nftables, jako resolvery jsou nasazeny Knot Resolver a BIND9, DHCP zajišťuje Kea, NAT64 běží na Jool a statistiky sbírají CollectDB a Grafana. Celé to orchestrujeme pomocí Ansible.
Celkem je poskytováno sedm různých sítí: veřejná sít v režimu IPv6-mostly, experimentální síť IPv6-only bez podpory IPv4 a nejobyčejnější síť s dual-stackem. Pak jsou tu privátní sítě pro správu síťových prvků a třeba také oddělená síť pro A/V prvky.
Konektivita přichází přes směrovače postavené na Oracle Linuxu 9, na kterém se od nadřazeného poskytovatele BIRD přebírá plnou BGP tabulku. Chceme totiž jít příkladem a provádět RPKI Route Origin Validation.
To je bezpečnostní mechanismus, který brání unesení IP rozsahů v internetu.
Sítě nabízí režim IPv6-only, kdy je možné přistupovat ke starému IPv4 světu pomocí NAT64 implementovaném nástrojem Jool. Tohle všechno funguje krásně, kromě některých video platforem, třeba iVysílání.
Ty fungují tak, že nejprve komunikují s token serverem a se získaným tokenem pak uživatel jde za video serverem. Pokud se ale v průběhu komunikace změní vaše vnější IPv4 adresa, dostanete od video serveru chybu.
Jool totiž negarantuje, že budete pro různé dotazy používat stále stejnou adresu na vnějším rozhraní. Ve výchozím stavu je totiž adresa vybírána pomocí hašů, do kterých ve výchozího stavu vstupuje zdrojová IPv6 adresa, cílová IPv6 adresa a cílový port. To je možné přepnout pomocí parametru f-code do režimu hašování jen zdrojové IPv6 adresy. Tohle není specifické pro NAT64, ale narážejí na to i provozovatelé CG-NAT.
Obvykle je v nich také možné přepnout se do režimu IP-stickyness, kdy je vždy stejná vnitřní adresa mapována na stejnou vnější adresu.
Pokud provozujete veřejnou síť s IPv4 adresou, neustále vám do ní chodí síťové skeny. Ty vytvářejí uvnitř sítě dotazy pomocí protokolu ARP a pokud jsou dané adresy neobsazené, dotazy se neustále opakují. V linuxovém jádře není negativní keš, takže se dotazy neustále opakují a vytvářejí neustálý tok broadcastů.
Řešením je spustit na rozhraní démona arpd, který má 30sekundovou negativní keš, což vede k řádovému snížení počtu dotazů v síti.
Většina bezdrátové sítě dnes běží na 5 GHz, jen asi jedno procento klientů se připojí k 2,4 GHz. To je statistická chyba, máme to jen na každém desátém AP.
Provozovatelé se snaží „vyhánět“ uživatele z těchto sítí tím, že u nich na každém setkání mění eSSID. Nestane se vám, že se na příštím setkání omylem připojíte k legacy síti. U těch standardních sítí jméno neměníme.
Do budoucna je v plánu nasadit redundantní firewall s VRRP, redundantní NAT64 a aktualizace hardwre pro Wi-Fi, který využije 10GBE přípojku.
(Autorem fotografií je Petr Krčmář.)
ČLÁNKY DO MAILU