Tomáš Chvátal: Pokud se to hýbe, zkompiluj to!
Tomáš Chvátal je už čtyři roky vývojářem Gentoo a členem Gentoo councilu. Před dvěma lety s ním vyšel rozhovor na Rootu. Ve své přednášce se věnoval samozřejmě projektu Gentoo a jeho klíčovým vlastnostem. Mezi hlavní výhody je obecně řazena možnost optimalizace pro konkrétní hardware. Podle Chvátala ale už nejde vůbec o zásadní věc. Optimalizace pro konkrétní hardware se dnes už příliš nevyplatí, protože máme výkonu na rozdávání,
řekl na úvod své přednášky. Stále to má ale smysl na pomalých platformách jako Atom či Zacate.
Na druhou stranu stále existují případy, kdy se optimalizace vyplatí. Například OpenGL je po optimalizaci o 20 % rychlejší než na Debianu,
řekl Chvátal. Výhodou pro uživatele je naopak ohromné množství různých aplikací, které jsou v hlavním stromu k dispozici. V současné době je v Gentoo asi 20 tisíc balíčků a 30 tisíc různých verzí aplikací. Tahle čísla se ale velmi často mění, proto už nemusí být platná.
Pro mnohé pokročilé uživatele je rozhodně výhodou, že jde o čistý systém s minimem vlastních distribučních přídavků. Gentoo totiž nepoužívá téměř žádné vlastní patche, protože vše, co se vyvine v Gentoo, jde zpět do upstreamu. Balíček se vám dostává vždy tak, jak ho distribuuje vývojář,
vysvětlil Chvátal.
V přednášce byly zmíněny i nevýhody distribuce Gentoo. Mezi nimi je například složitá instalace, protože distribuci je třeba instalovat zcela ručně bez jakékoliv automatizace. Kdysi existoval projekt instalátoru, ale ten po několika měsících umřel. Ukázal sice, že to jde, ale nikdy nebyl dotažen do konce.
Další nevýhodou pro někoho může být systém rolling-updates, tedy stále živé distribuce bez konkrétních zmražených verzí. Mnoha uživatelům vyhovuje mít stále nejnovější verze balíčků, ale ne pro každou situaci je to vhodné. Neustálé změny ale nemusí vyhovovat všem. Například pokud chcete postavit veřejný kiosek a nestarat se o něj, nebude vám vyhovovat stále měnící se systém.
Hovořilo se také o testing repositářích, kde jsou nejnovější verze všech balíčků přímo z upstreamu. Jejich použití je podle Chvátala „o hubu“. Dostávají se tam totiž balíky bez distribučního testování. Velmi často se tam dostane rozbitý balíček. To je naprosto běžné. Testování probíhá až zpětně,
vysvětlil Chvátal. Po vytvoření nového balíčku probíhá takzvaná stabilizace, která trvá až 30 dní. Někdy ale ani testování nemusí zaručovat správný a funkční výsledek. Teď máme třeba problém s AMD týmem, který sice balíky testuje, ale jen je zkompiluje a nezkouší spustit,
postěžoval si Chvátal.
Jakub Hrozek, Martin Košek: FreeIPA, SSSD
FreeIPA je open-source nástroj pro správu identit. Ať už uživatelů a jejich skupin, strojů nebo například map pro automounter. Integruje v sobě LDAP, Kerberos a DNS server, obalený v uživatelsky příjemném rozhraní. Přednášku začal Martin Košek, který nejprve obecně hovořil o potřebě správy identit a následně začal probírat základní vlastnosti projektu FreeIPA.
FreeIPA znamená Identity, Policy, Audit a jde o nástroj, který umožňuje centrální správu identit. Mezi hlavní výhody patří jednoduchá instalace, rozhraní pro administraci a provázanost s důležitými službami na linuxových klientech,
popsal klíčové vlastnosti Košek.
FreeIPA je postavena na stávajících open-source technologiích LDAP, Kerberos a DNS. Všechny služby si můžete samozřejmě nakonfigurovat sami ručně s LDAP a Kerberos. Ale museli byste mít podrobné znalosti obou těchto technologií, abyste to zvládli. S tím vám právě pomůže náš projekt.
IPA umí spolupracovat s DNS a můžete si tak automaticky zřizovat DNS záznamy podle nově vytvořených účtů. Velmi se tím zjednodušuje správa DNS. Jako DNS server používáme BIND, do kterého se vše automaticky replikuje.
Stejně tak je možné skrze IPA vydávat automaticky i SSL certifikáty. Zatím to umíme jen pro služby, v budoucnu chceme vydávat certifikáty i uživatelům,
řekl Košek.
FreeIPA samozřejmě především spravuje identity uživatelů. IPA přidává především automatickou tvorbu UID, což zjednodušuje správu uživatelů na více replikách.
Umí také spravovat SSH klíče, takže jakmile se uživatel jednou přihlásí, může pak používat SSH bez dalších překážek. Automatizuje se také například správa skupin pro uživatele. Pomocí regulárních výrazů můžu uživatele při vytváření rovnou zařadit do správných skupin.
Nejnovější verze 3.0 už umožňuje také spolupracovat s Active Directory. Dříve byl jedinou možností modul winsync, který umí do AD jednosměrně synchronizovat informace z IPA. Teď už umíme použít Kerberos trust, takže uživatele z IPA se umí přihlásit do Windows a obráceně,
řekl Košek.
Jakub Hrozek ve druhé polovině přednášky hovořil o klientském projektu SSSD, který dovoluje jednoduše připojit klientský počítač k LDAP, Kerberos či IPA. Původně projekt SSSD začal jako klientská část k FreeIPA, teď je to samostatný projekt, který uživatelé používají i bez návaznosti na IPA,
zahájil svou část přednášky Hrozek.
Také SSSD dokáže spolupracovat s microsoftí technologií. V nejnovějším vydání je i nativní podpora pro Active Directory.
Hlavní výhodou je kešování přihlašovacích informací na lokální disk počítače. To se hodí ve chvíli, kdy nejste připojeni k síti. Já tady na notebooku nemám vůbec unixového uživatele a přesto se můžu přihlásit. Jakmile se pak připojíte k firemní síti, počítač automaticky dostane „živý ticket“ a může okamžitě přistupovat ke službám,
vysvětlil Hrozek.
Egbert Eich: Wayland
V Linuxu už máme displej server, je to X Window System. Ten je starý třicet let a dříve se staral o všechno: vstupy z klávesnice a myši, výstup na grafickou kartu, komunikaci s X klienty a mnoho dalších věcí. Většina funkcí X serveru dnes už není využívaná, což komplikuje kód serveru samotného i aplikací, které s nim musí komunikovat,
připomněl na začátku Egbert Eich.
Dnes už ovladače vstupních zařízení nejsou součástí X serveru, ale jsou v jádře, a to je předává do X. Ten je zase správně předá jednotlivým klientům (aplikacím). Dříve aplikace na uživatelskou akci zareagovala tím, že řekla X serveru, co se má změnit na obrazovce. Dnes už žádná aplikace nepoužívá vykreslování primitiv X serveru. Všechny kreslí své prvky pomocí obrázků.
Jednotlivé plochy kreslené programy do window bufferů pak propojuje kompozitor, který teprve složí výslednou podobu obrazovky. Ta se pošle zpět do jádra, odkud přes KMS putuje do grafiky. Celý tento proces je poměrně komplikovaný a zahrnuje časté přepínání kontextu. Z jádra do X, do aplikace, do X, do kompozitoru a zase do jádra.
Výsledkem tak je, že se mnoho funkcí přesouvá mimo X server. Ovladače jsou v jádře, primitiva se nepoužívají, grafiku řeší moderní toolkity a třeba fonty řeší freetype. Mnoho funkcí z X už se tedy v praxi vůbec nepoužívá. X server funguje už jen jako jakýsi prostředník, který jen předává události a výsledky práce dalších komponent,
řekl Eich.
Wayland mění tyto zažité pořádky a komunikaci jednotlivých komponent zjednodušuje. Abychom se prostředníka v podobě X serveru zbavili, předáváme události z KMS a evdev přímo do kompozitoru. Ten pak posílá vstupní události přímo aplikacím, které zase mohou kreslit přímo do svých bufferů. Nepotřebují k tomu využívat komplikovaný X protokol. Aplikace si naalokuje vlastní window buffer, který pak předává kompozitoru.
Ten pak dokáže přímo s jednotlivými výstupy pracovat. Kompozitor přesně ví, kam má událost putovat, protože už zná pozici jednotlivých oken. Starý X server to nikdy neví.
Správná aplikace pak může zareagovat, třeba vykreslením nového objektu do vlastního window bufferu. Jeho obsah pak vrátí kompozitoru s informací, která část se změnila. Kompozitor tuto část obrazu vezme a aktualizuje správný kus obrazovky. Pokud celý tento proces porovnáte s tím starým, zjistíte, že je potřeba méně přepnutí kontextu a vše může probíhat hladčeji.
Eich se dále věnoval protokolu, který používá Wayland. Použitý protokol je velmi podobný X server protokolu. Používá unixové sockety ke komunikaci mezi aplikací, kompozitorem a displej serverem. Komunikace je zajištěna tak, že každá komponenta otevírá pro ostatní různá rozhraní (interfaces), která jsou identifikována unikátním jménem.
Wayland se ale od X serveru v mnohém liší, není už například síťové transparentní. Síťová transparentnost se často uvádí jako výhoda X, ale většina uživatelů ji už nevyužívá. Většina aplikací dnes běží lokálně.
Existují už ale snahy tuto transparentnost implementovat i do Waylandu a výhodou je, že nový kompozitor má pro to velmi dobré předpoklady. Při přesunu obrazu na vzdálený server je třeba přenášet obsah bufferů. Zatímco u X to znamená odesílat poměrně hodně dat, Wayland má už v návrhu protokolu identifikaci oblastí, které se změnily. Tím se výrazně šetří přenosové pásmo,
řekl Eich.
Uživatelé se často ptají, zda budou moci ve Waylandu spouštět své X aplikace. Wayland poslouchá i na známých socketech pro X klienty a jakmile se některá aplikace připojí, automaticky se spustí X server. Aplikace pak komunikuje s ním a pokud otevře viditelné okno, začne se X server chovat jako Wayland klient a předává kompozitoru svůj výstup. Celý tento proces je vlastně stejný jako u dnešního X serveru. X komunikuje na jedné straně s kompozitorem a na druhé s klientem.
Na konci své přednášky Egbert Eich předvedl funkční implementaci Waylandu zvanou Weston. Vysvětlil, že zatím neumí třeba klonovací režim, který je použitelný zejména při prezentacích. Neměl by ale být problém ho implementovat, protože vlastně jde jen o to, zkopírovat obsah bufferů do dvou výstupů. Zatím to není plnohodnotně použitelné pro velký desktop, ale základní věci už to umí.
Předveden byl funkční virtuální terminál, který Eich otáčel kolem osy. Tohle by například v X nebylo vůbec možné,
dokončil demonstraci Eich.
Michal Zima: WrapSix
NAT64 (čti nat šest čtyři) je metoda, která umožňuje na IPv6-only sítích komunikovat s počítači v internetu, které IPv6 konektivitou nedisponují. Pracuje ve spojení s DNS64, který do odpovědí na DNS dotaz přidává virtuální IPv6 adresy, se kterými se pak klient snaží navázat spojení. Pomocí NAT64 překladu je pak komunikace překládána z virtuální IPv6 do reálné IPv4 adresy. Podpora DNS64 existuje nativně v BIND od verze 9.8.0 a pro Unbound existuje patch,
řekl Zima.
WrapSix je svobodná implementace NAT64, která běží v userspace. Je alternativou k aplikacím Ecdysis a Tayga. WrapSix má ale výrazně větší výkon využitelný pro velké provozy s nízkou odezvou.
Není problém přes něj dostat 1Gbps tok. Ovšem není gigabit jako gigabit. Tayga tvrdí, že vytíží gigabitovou linku, ale otázkou je, při jak velkých paketech. V tomhle případě jde spíše o marketing,
řekl Zima. Při velikosti paketů 52 bajtů je třeba přenést 2,3 miliony paketů za sekundu, zatímco při velikosti 1500 bajtů je jich jen 83 tisíc.
Menší pakety kladou nároky nejen na samotnou překládající aplikaci, ale zvyšují i počet volání jádra. To vede k vyššímu vytížení procesoru při přenášení takto velkého množství dat. Většina NAT64 implementací to řeší paralelizací, která naplno využívá moderního hardware.
Zima se pak věnoval tomu, jak optimalizovat práci NAT64 tak, aby byl efektivnější a nemusel takto používat hrubou sílu.
V první řadě je třeba zbavit se neužitečného kódu. Každá instrukce se počítá a zejména skoky jsou velmi náročné. Nepředvídatelné skoky snižují efektivitu vykonávání kódu, protože nedovolují využít pipeline.
Dále je třeba optimalizovat práci s pamětí. Paměť RAM totiž není rychlá. Používat cache je mnohem výhodnější a je proto ji třeba maximálně vytížit.
Třetí možností je zlepšit alokování paměti. Dynamické alokování je velmi pomalé.
Statické je podle Zimových měření asi o čtvrtinu rychlejší. Zároveň standardní malloc není jediný dostupný alokátor, existují mnohé další a některé jsou efektivnější.
Velmi důležitá je také struktura dat. Špatná struktura může způsobit významný pokles výkonu.
NAT64 si ukládá především stavové informace, ve kterých je třeba velmi rychle vyhledávat.
Důležité je také vyladit samotné chování operačního systému, ve kterém překlad běží. Když začnete psát podobný software, rychle zjistíte, že operační systém vám moc nepomáhá.
Je třeba nastavit aplikaci co nejvyšší prioritu a zařídit distribuci jednotlivých vláken po procesorových jádrech. Více jader vám dá více než více vláken, takže vypněte Hyper-Threading.
V případě WrapSix byly tyto optimalizace naprosto zásadní pro celkový výkon aplikace. Před optimalizacemi jsem nebyl schopen obsloužit gigabit ani při MTU 1500.
Dnes to je možné, ale stále je co zlepšovat, což se projeví zejména u malých paketů. Stále ještě nejsem s optimalizacemi hotový,
řekl Zima.
Michal Zima se pak věnoval zprovoznění WrapSix. Zatím je projekt ve verzi 0.1.0, kterou stáhnete na webu WrapSix.org a musíte si ji zkompilovat. Zatím mám jiné priority než uživatelskou přívětivost, takže konfiguraci je třeba provádět ve zdrojovém kódu před kompilací.
Samotný WrapSix pak spustíte pomocí wrapsix-wrapper a DNS nastavíte tak, aby ke zjištěným IPv4 adresám přidávala prefix 64:ff9b::/96. Ještě je třeba vypnout IPv6 forwarding, jinak to nebude fungovat.
Díky WrapSix je takto možné provozovat reálně IPv6-only síť, i když zdaleka ne všechny servery dokáží na IPv6 komunikovat.
Neděle
Zítra si budete moci přečíst o tom, o čem se hovořilo v neděli.
ČLÁNKY DO MAILU