Hlavní navigace

InstallFest 2013, neděle: real-time web, hry v Linuxu a Fedora

21. 3. 2013
Doba čtení: 12 minut

Sdílet

Letos se už popáté konal obnovený InstallFest. Ve školícím středisku na strahovských kolejích se opět sešli linuxáci, síťaři, studenti, nadšenci a hardwaráři. Jaké přednášky jste si mohli poslechnout a co zajímavého na konferenci zaznělo? V neděli se hovořilo o VPN, Fedoře a robotovi postaveném na Arduinu.

Ondřej Caletka: OpenVPN

První nedělní přednáška se zabývala tvorbou privátní sítě nad veřejnou infrastrukturou. Nejčastějším použitím je bezpečné propojení několika sítí skrz veřejnou síť internet. Pořízení vlastní linky totiž bývá řádově stokrát dražší než pořízení dvou běžných připojení k internetu.

Pro bezpečné propojení počítačů skrz internet byl navržen protokol IPsec. Ten byl původně vyvinut pro IPv6 a později portován do IPv4. Bohužel později do věci zasáhly NATy a různé firewally, které mohou do komunikace zasahovat, měnit IP adresy a dělat další nepříjemné zásahy. Tím se dříve čistý návrh IPsec výrazně zkomplikoval. Výsledkem je, že se obtížně používá a lidé k němu mají odpor, vysvětlil Caletka. Čas IPsec podle Caletky teprve přijde.

Snadněji používanou variantou je OpenVPN. Používá léty prověřenou mezivrstvu TLS namísto IPsec. Používá TCP nebo UDP proud a je přátelská k NATu a firewallu. Navíc nevyžaduje žádné změny v jádře, protože používá tap a tun zařízení. Jde o virtuální síťové rozhraní, které umožňuje propojit TCP/IP stack s uživatelským prostorem.

Při konfiguraci OpenVPN je nutné zvolit, zda chceme použít UDP nebo TCP. Vždycky, vždycky, vždycky používejte UDP, varoval Caletka. Problém je, že aby TCP fungovalo, vyžaduje nižší vrstvu, která neřeší ztráty paketů. Pokud zabalíme TCP do TCP, můžou nastat problémy. Ono to vypadá, že to funguje. Ale když saturujete linku, začnou vypadávat pakety a spojení přestane fungovat správně. Nižší TCP vrstva začne pakety opakovat, což ale ta horní nezjistí. Pro ni se pakety jen zdržují, rychlost klesne k pěti procentům rychlosti linky a spojení se rozbije. Trvá pak dlouho, než se to samo opraví. S UDP se vám to nestane.

Další volba umožňuje volit mezi tun a tap zařízeními. Tap představuje virtuální Ethernet, tun běží na síťové vrstvě. Tun je efektivnější, ale umí jen IPv4 nebo IPv6. Tap se víc hodí, když chcete nad VPN provozovat například dynamické směrování. Pokud se ale chcete připojovat z Androidu, musíte použít tun. Můžete si ale spustit obě varianty na různých portech a používat obě.

VPN tedy může běžet v bridged či routed režimu. V režimu bridge budou fungovat všechny služby sítě, můžete hrát staré hry po protokolu IPX nebo si nechat autokonfigurací přidělit IPv6 pakety. Ovšem budou vám také procházet všechny broadcasty, které vám budou zbytečně zabírat pásmo. Podle mě je lepší použít routed režim.

Následovaly příklady konfigurace VPN serveru včetně generování certifikátů pomocí vlastní certifikační autority. Ondřej Caletka upozornil na problém, ke kterému obvykle dojde, pokud nám spadne rozhraní, přes které běží VPN. Odstraní se routa do internetu a tím začne celý provoz padat zpět do VPN rozhraní. Kladná zpětná vazba pak způsobí plné vytížení rozhraní i procesoru počítače. Řešení naštěstí není nijak složité, v konfiguraci je možné zapnout testování (ping) protistrany a odpojení VPN v případě výpadku.

Vladimír Jarý: Konstrukce a použití Arduino robota

Arduino je vývojová platforma postavená na otevřeném hardware a software. Hardwarově je postavena na osmibitovém jednočipovém počítače Atmel AVR a programování probíhá v jazyce podobném C++. Arduino má rozsáhlou komunitu, která se stará o jeho vývoj a využití.

Ke stavbě robota byl využit mikrokontroller Atmel ATmega 328 s 32 kB flash pro kód a 2 kB RAM a 1 kB EEPROM pro data. Deska především nabízí 14 digitálních a 6 analogových pinů, ke kterým je možné připojit různá čidla. Velkou výhodou jsou takzvané shieldy, což jsou další desky, kterými je možné základní Arduino rozšířit například o WiFi, Ethernet a další hardware. Vývoj probíhá ve zjednodušeném C++ pomocí Arduino IDE, které je napsané v Javě a je poměrně spartánské.

Robot postavený na Arduinu, o kterém Vladimír Jarý hovořil, používá podvozek ze stavebnice Hobbyrobot TANK-02 a jeho kostra je postavena ze stavebnice Merkur. Napájení provádíme pomocí šesti AA akumulátorů. Robot používá infračervené a ultrazvukové senzory, které slouží k orientaci v prostoru a detekci překážek. Samozřejmě můžeme časem přidat další, zatím ale používáme jen tyto.

Robot je na ČVUT využíván především ve výuce, a to v několika oblastech – výuce základů programování, testování algoritmů umělé inteligence či programování v C++. Robota využíváme jako jakousi hardwarovou verzi robota Karla. V plánu je také návštěva středních škol a získávání nových studentů pro studium na ČVUT.

Adam Hořčica: Real-time web

Na začátku své přednášky Adam Hořčica vysvětlil, co to vlastně real-time web je a jak ho můžeme využít. Často se koukáme na nějakou stránku a přemýšlíme, jestli už se mezi tím nezměnila. Mačkáme proto F5, abychom zjistili, jestli nám někdo neodpověděl ve fóru. Právě tady by se hodil real-time web, který by s námi komunikoval sám. Příkladů použití je dnes velké množství, interaktivní real-time web využívají například Twitter, Facebook, GMail a další weby. Ty samy mění aktivně podobu své stránky, aby ji aktualizovaly.

Web běžně funguje na HTTP protokolu, který používá architekturu klient-server a generuje odpovědi na dotazy zaslané klientem. Komunikaci vždy začíná klient, neexistuje možnost, jak by mohl server aktivně poslat data klientovi. Jde také o bezestavový protokol a jakmile server ukončí komunikaci, zapomene všechny informace o klientovi. Existují způsoby, jak informace o sezení udržel, ale ty nejsou součástí HTTP.

Na real-time webu ale potřebujeme, aby věci fungovaly jinak. Dejme tomu, že jeden klient chce odeslat zprávu ostatním. Poslat zprávu na server není problém, ale jak pak může server dát vědět klientům, že jim přišla nová zpráva? Způsobů existuje velké množství, například polling, long polling, streaming a WebSockets. Při vývoji aplikací ale narazíte na rozdíly v prohlížečích. Jelikož jde o nestandardní využití HTTP, většinou narazíte docela tvrdě. Nejčistším a nejmodernějším způsobem jsou WebSockets.

Dále byly prakticky předvedeny všechny zmíněné metody. U pollingu je výhodou, že funguje ve všech prohlížečích, nejde ale o opravdový real-time. Klient se jednoduše v pravidelných intervalech dotazuje serveru na novinky. Každá příchozí událost také má zpoždění, protože se o ní dozvíme, až se příště zeptáme serveru.

Lepší je už long polling, u kterého server neodpoví na dotaz hned, ale až ve chvíli, kdy se událost objeví. Narážíme tu ale na timeout mezi dotazem a odpovědí, který se může v různých sítích a u různých prohlížečů lišit. Další technikou pak byl streaming, kdy udržujeme spojení delší dobu. Podobných obskurních způsobů existuje celá řada.

Všechny předchozí ukázky byly jednosměrné a používaly běžný HTTP protokol. Předchozí techniky byly ukázkou, jak lépe či hůře zneužít HTTP protokol. Nejnovější metodou je WebSockets, který je přímo k podobné real-time komunikaci určen a je obousměrný. Spojení je nejprve navázáno klasicky přes HTTP, ale jsou do něj přidány další hlavičky. V těch se říká, že chcete spojení zachovat a chcete přejít na jiný komunikační protokol. Stále zůstane otevřené TCP spojení, ale zbytek komunikace už probíhá pomocí protokolu WebSockets.

Použití je pak v praxi poměrně jednoduché. Pokud použijete prohlížeč, který WebSockets implementuje, jste prakticky za vodou. Většinu komunikace zajistí samotný prohlížeč a pomocí protokolu sám zajistí udržování spojení, případně automatické navázání rozpadlé komunikace. Na straně serveru stačí využít připravené knihovny. Zpracování je pak poměrně přímočaré.

Podle Adama Hořčicy je vždy ideální použít WebSockets, pokud je to možné. Pokud to možné není, lze sáhnout po alternativním způsobu. Implementace není jednoduchá, takže doporučuji použít hotové knihovny. Ty pak vyberou nejlepší komunikační metodu. Umožňují také nastavit například prioritizaci zpráv, rozdělit příjemce na skupiny, zabezpečit komunikaci a podobně.

Pavel Tišnovský: Vývoj her v Linuxu

Pavel Tišnovský je dlouholetým autorem Root.cz a v poslední době od něj můžete sledovat dlouhý seriál o starých počítačových hrách. Právě o vývoji her byla řeč v jeho přednášce.

Pavel Tišnovský nejprve hovořil o základních požadavcích na knihovnu pro vývoj her. Většinu z nás tady asi zajímá, zda knihovna běží na více operačních systémech. Mezi podporovanými systémy by měl být nejméně Linux a Android, případně MS Windows a OS X. Stačí pak hru napsat jednou a zkompilovat ji pro různé platformy.

Od zvolené knihovny potřebujeme především přístup ke grafickému subsystému. To zahrnuje softwarový rendering, dnes bezpodmínečně nutnou hardwarovou akceleraci, fullscreen a double buffering. Kromě toho nám knihovna musí zpřístupnit také zvukový subsystém a mixér. Dále potřebujeme číst vstupní zařízení jako klávesnici či myš, potřebujeme přesný časovat a například také podporu komunikaci po síti.

Pavel začal hovořit o knihovnách pro vývoj v C/C++. Nejznámější knihovnou pro vývoj v C/C++ je asi SDL. Je na ní zajímavé to, že používá nízkoúrovňový přístup a je hodně multiplatformní. Podporuje operační systémy Linux, BSD, OS X, Windows, BeOS, Android a další. Podle webu SDL je rozpracováno asi 705 open-source her a podle jejich autorů je už 524 dokončených.

Konkurenční a starší knihovna Allegro je také určena pro tvorbu her v C/C++ a obsahuje mnohem více funkcí než SDL. To muže být výhoda i nevýhoda zároveň. SDL se můžete naučit za chvilku, ale pro podporu některých funkcí budete potřebovat rozšíření. Allegro už obsahuje vše v základu. Opět jde o multiplatformní knihovnu, která běží dokonce i v DOSu. Při vývoji hry v Allegro si dejte pozor na to, že byla nedávno vydána verze pět, která je kompletně přepsaná. Přidává ale podporu hardwarové akcelerace.

Pak se Pavel Tišnovský věnoval vývoji her v minulosti a v současnosti. Na osmibitech byl vývoj velmi omezený. Dříve se všechny hry psaly v asembleru, prakticky žádný vyšší jazyk se nepoužíval. Hry měly 512 až 8192 bajtů a jejich grafické schopnosti byly poměrně slabé, což bylo dáno i pomalými procesory.

V době šestnácti a dvaatřicetibitových počítačů už vznikaly mnohem rozsáhlejší hry. Už je tu znát jistý odklon od assembleru, velká část hry se vytvářela v nějakém přívětivějším jazyce. Dnes jsou nízkoúrovňové věci psány v C/C++ a zbytek je naskriptovaný v jazycích jako Lua, Python, LISP a podobně. Vývoj takové hry je velmi rychlý. Takovou hru je možné napsat na padesát řádků, což je výrazně méně než kdybyste ji psali třeba v assembleru.

První popisovanou knihovnou pro vyšší programovací jazyky je LÖVE. Ta je určena pro programování v jazyce Lua a výslednou hru je možné zabalit do jednoho zip archivu s příponou .love. Tento archiv se přímo spustí pomocí virtuálního stroje, který je dostupný pro mnoho různých platforem. Knihovna při svém běhu využívá řadu různých dalších knihoven, jako OpenGL, SDL, FreeType 2 a podobně. Funkce se nevolají přímo, ale jsou obalené v Lua, aby se používaly co nejpříjemněji.

Další ze zmíněných knihoven byla Pygame, která je založena na SDL. Jde opět o silně multiplatformní knihovnu, kterou najdeme na Linuxu, Windows, Solarisu, BSD a třeba taky Androidu. Pro Android neexistuje plnohodnotná implementace, ale jen jakýsi subset nejdůležitějších funkcí. Rychle se ale vyvíjí a rozšiřuje.

Dnes je ovšem moderní 3D, takže je potřeba pracovat ještě s dalšími knihovnami. Tou nejdůležitější je OpenGL. Ta je systémově nezávislá, má vazbu na grafický hardware a je založena na jazyku C. Knihovna umožňuje vykreslovat základní grafické objekty, plochy a plochy. Dále umí texturovat, vykreslovat rastrové obrázky a připravovat osvětlení. Můžete si scénu osvětlit několika různými světly a nechat vypočítat výsledek.

Díky těmto knihovnám je možné programovat hry velmi jednoduše. Stačí si přečíst nějaký tutoriál. Ty jsou většinou dobře čitelné a použitelné, protože je píší přímo jejich uživatelé, žádní akademici. Jednoduchou hru pak napíšete za dvě hodinky. Záleží spíš na dobrém nápadu, uzavřel přednášku Pavel Tišnovský.

Jiří Eischmann: Kam směřuje Fedora

Jiří Eischmann se věnoval projektu Fedora, ve kterém pracuje jako community manager. Nejprve se věnoval historii projektu a jeho cílům. Fedora 1 vznikla téměř před deseti lety, 16. listopadu 2003. Hodně se teď debatuje o tom, kam by se měla Fedora dále vydat. Hlavním heslem Fedory je být vždy na špici vývoje Linuxu. Důležité také je, že ve Fedoře najdeme jen svobodný software. Hodně lidí si zakládá na svobodném software a tato hranice je pro nás nepřekročitelná.

Součástí definice podobného projektu musí být i to, pro koho je vlastně určen. Často se probírá i cílová skupina Fedory. Kdo je vlastně našim uživatelem? Tom „Spot“ Callaway z Red Hatu tvrdí, že by se Fedora měla zaměřit na pokročilé uživatele, kteří počítačům rozumí, i na jaderné hackery jako je Linus Torvalds. Ne že by nás nezajímali i běžní uživatelé, kteří používají počítač na Facebook. Vždycky to má nějaký přesah.

Jiří Eischmann se rozhovořil i o zařízeních, na kterých Fedora běží. Ubuntu se začíná posouvat směrem k tabletům a telefonům, ale Fedora nic podobného nechystá. My v dohledné době nebudeme nic takového dělat. Chceme mít dobrou distribuci pro servery a desktopy.

Lidé se nás často ptají, zda sledujeme, kolik uživatelů Fedoru používá. Určité statistiky samozřejmě máme, ale nejsou to pro nás rozhodující metriky. Fedora nechce budovat komunitu pasivních konzumentů, ale naopak aktivních přispěvatelů. V tom se lišíme od jiných distribucí. Není pro nás podstatné, kolik milionů uživatelů nás používá, ale kolik tisíc jich k nám přispívá.

Fedora zvažuje nový dvouletý cyklus, jehož součástí by byla čtyři menší vydání. Fungovalo by to vlastně stejně jako dnes, ale velké novinky by se plánovaly tak, aby se dostaly do té dvouleté velké verze. Nezměnila by se ale doba podpory, která je dnes 13 měsíců. Řada uživatelů chce delší podporu, třeba dva roky. Ale to koliduje s našim heslem ‚first‘. U jiných distribucí jsou uživatelé spokojení s dva roky starými balíčky, ale to u Fedory nechceme. Navíc podle Eischmanna pak nastává problém s lidskými zdroji při udržování starých verzí.

Dalším diskutovaným problémem je desktopové prostředí, které je ve výchozím stavu s Fedorou nainstalováno. V dohledné době zůstaneme u Gnome, řekl Eischmann. Jedna věc jsou osobní preference, ale je třeba také dodržet jistou kvalitu. Musíte slíbit uživatelům, že jste schopni prostředí dostatečně spravovat.

Dále se Jiří Eischmann zabýval vylepšeními, které se do Fedory chystají. Jedním z nich je desktopové rozhraní pro Fedmsg, které vám přímo při práci umožňuje přijímat a zobrazovat aktuální dění ve Fedoře. Dále se chystá novinka usnadňující testování. Uživatelům budou nabízeny nové balíčky k otestování a pak budou moci jednoduše sdělit, zda je balíček v pořádku a oznámkovat jeho kvalitu.

Dále Fedora chystá integraci služeb do desktopu. Zatímco dnes se běžně integrují konzumní služby jako Facebook či Twitter, tady je záměr jiný. My chceme integrovat služby pro vývojáře, jako například GitHub a další. Už teď je možné se jednoduše připojit například k OwnCloudu.

root_podpora

Podpora cloudu je pro Fedoru velmi důležitá, stejně jako pro ostatní distribuce.Hodně se chceme zaměřit i na cloud. Nejen aby byla Fedora na cloudu dobře použitelná, ale aby i cloudové projekty byly použitelné ve Fedoře. Red Hat se tedy intenzivně snaží, aby všechny důležité balíčky byly součástí distribuce.

Další zajímavou oblastí je „Fedora for makers“. Tedy zaměření Fedory na různé kutily, bastlíře a hardwaráře obecně. Miro Hrončok má schválený projekt přípravy balíčků pro 3D tiskárny. Říkal mi, že žádná jiná distribuce tyto balíčky nemá. Nejde ale jen o 3D tisk, ale i o robotiku a další kutilské oblasti.

Byl pro vás článek přínosný?

Autor článku

Petr Krčmář pracuje jako šéfredaktor serveru Root.cz. Studoval počítače a média, takže je rozpolcen mezi dva obory. Snaží se dělat obojí, jak nejlépe umí.