Fedora 10 Cambridge a pět let projektu Fedora

V linuxových distribucích se začíná prosazovat specializace, což signalizuje, že oblasti využití Linuxu se rozšiřují. Zatímco některé distribuce se specializují na to, co u nás s oblibou nazýváme běžnými uživateli, jiné se specializují na vývoj, resp. vývojáře, jiné na mobilní zařízení atd. Podle toho, jak se tyto složky namixují, vypadá pak výsledná distribuce. Výhodou Linuxu oproti jiným platformám v tomto směru je, že distribuce od sebe mohou nové vlastnosti svobodně kopírovat i se zdrojovými kódy, zatímco uzavřené platformy kopírují pouze vlastnost, ale kód musí buď kupovat, nebo většinou napsat znovu. Tento model tak nejen umožňuje zpřístupnit Linux začínajícím uživatelům, ale poté, co u nich třeba dojde k uvědomění potenciálu a svobody Linuxu a vzniku potřeby zapojit se do jeho vývoje, jim umožňuje postoupit na další úroveň.

Kterým směrem se profiluje Fedora, je zřejmé z množství uváděných skutečně nových vlastností. Fedora není jen prostým kompilátem existujících OS nástrojů, ale je i jejich zdrojem. Debata nad tímto zaměřením Fedory se strhla během vývoje F10 poté, co Wikipedia oznámila, že opouští staré instalace RH9 a Fedory a jako základní platformu bude nadále využívat Ubuntu LTS. Nemálo vývojářů se snažilo prosadit vznik LTS verze Fedory. Nakonec ale celá věc vyšuměla ze dvou důvodů. Fedora LTS v podstatě má, a to CentOS, a v samotném Fedora projektu se nenašel dostatek vývojářů ochotných se o LTS starat (připomeňme, že Fedora měla před časem podprojekt Fedora Legacy, který vydával aktualizace pro starší verze, nicméně pro nezájem byl ukončen).

5 let…

Nyní tedy nastává okamžik rekapitulace pětiletého vývoje Linuxu (ne jen Fedory), tzv. flashback bez ladu a skladu (o některých tématech si povíme víc dále, o jiných už jsem psal dříve):

• rhgb → plymouth – grafický start systému
• SELinux, exec shield, fstack-protector – technologie pro větší bezpečnost
• yum – balíčkovací systémy se závislostmi
• kernel 2.4 → 2.6 – velký technologický skok celého jádra
• gcc3 → 4 – nová generace kompilátoru, určujícího výslednou kvalitu jakéhokoli kódu
• ALSA – nový Linuxový zvukový systém
• CD → DVD, LiveCD – objevila se a převládla technologie DVD, vznikla první LiveCD
• ipchains → iptables – změna logiky firewallů
• XFree86 → Xorg – přechod od XFree86 k Xorg a freedesktopu vůbec
• OpenOffice – byl vydán OpenOffice
• udev, DBus, HAL – tuto svatou trojici snad netřeba představovat
• Xen, cluster – virtualizace a klastrování
• GCJ → IcedTea → OpenJDK – boj o svobodnou javu
• Mozilla → Firefox – transformace a nástup svobodného prohlížeče
• NetworkManager – síťové technologie nabývají nebývalého významu stejně jako mobilita
• AIGLX – akcelerace GUI, nezbytné pozlátko žeroucí gigantické výpočetní výkony GPU
• LUKS – kryptování všeho možného
• mono – svobodná implementace .NET
• Cairo – přecházíme od bitmap k vektorům
• libata – … a od IDE ke SCSI
• tickless/powertop – elektronika se množí víc než houby po dešti a nenažranost je potřeba krotit
• fast user switching – každý chce dneska sedět u svého prostředí
• wireless – pamatujete ještě dobu drátovou?
• ntfs-3g – kompatibilita s FS Windows je nezbytná pro přechod uživatelů
• smolt – statistický aparát pomáhající vývojářům zaměřit se správným směrem
• policykit, packagekit

a to by snad stačilo. Je to jen připomenutí důležitých témat, která ovlivnila to, co dnes Linux především na desktopu nabízí.

Co se mimo jiné dělo ve Fedoraprojektu

Vývoj F10 na poměrně dlouhou dobu ovlivnil výpadek po napadení klíčů, kterými byly podepisovány balíky. Jak to tak bývá, nakonec je ale všechno zlé pro něco dobré. Jednak se tím prodloužil čas zrání, druhak se v rámci tohoto výpadku obnovila struktura Fedoraprojektu a vyměnil některý hardware.

Fedoraprojekt prošel během posledního období ještě jednou významnou změnou. Ta nesla krycí název „ACL Mass Open“. Neschovává se za tím nic menšího než pokračování zvětšování otevřenosti celého projektu, v tomto případě uvolněním politiky pro balíčkáře.

Infrastruktura

Ač byl tým lidí starající se o infrastrukturu zaměstnán výše zmíněným problémem s klíči, pokračoval dál i proces sjednocování a rozšiřování služeb, které fedoraproject nabízí. Mezi zajímavé součásti patří

Přehled aktualizací (bodhi) – systém, kde je vidět přehled balíčků, které jsou připraveny pro aktualizace, důvod vzniku aktualizace a tzv. karma, kterou mohou nastavovat dané aktualizaci uživatelé, kteří balík testují, a tím balík buď schválit, nebo odmítnout jeho zařazení do aktualizací.
Build systém koji – to jest přehled kompilací balíčků, výsledky sestavení a jejich zařazení.
Server distribuující spiny – spin je sestavení Fedory s modifikovanou sestavou balíčků, tedy např. verze s XFCE, FEL spin – Fedora Electronic Library, edu – vydání zaměřené na výukové programy, AOS – popíši dále, broffice – RH Brasil. Na novém vzhledu tohoto webu, který by lépe reprezentoval a popisoval zaměření jednotlivých spinů, se pracuje, zatím stránka obsahuje jen torrenty.
Smolt – statistiky sbírané Smoltem. 

Zase ten start systému

Nový grafický start Fedory nese jméno plymouth. Mnoho uživatelů Fedory 10 bude jistě zaskočeno, že tento grafický start nemají až tak grafický, a „hnidopichové“ jistě utrousí poznámku, že takovýto výkřik techniky viděli naposledy u Windows 2000. Skutečně se nový start Fedory může zdát i v porovnání se staršími grafickými starty Fedory poněkud krokem zpět. To ovšem jen na první pohled. Problém je totiž v tom, že skutečné grafické finesy fungují pouze na kartách, které podporují KMS (kernel mode setting), kterými jsou, světe div se, v tuto chvíli pouze karty Ati/AMD, na ostatních se spustí textový fallback, který skutečně vypadá poněkud „hromecotoje“, a místo plynulé změny rozlišení s fadein uvidíte splašenou čáru a někde starý obsah videoram. Pokud byste chtěli přesto žasnout nad tím, co plymouth při startu systému dělá, přidejte si na řádek kernel v grub.conf parametr vga=0×318, což je jeden z vesa módů konzole nebo si vyberte ten, který vám vyhovuje nejvíc.

$ vbetest

Sice nebudete mít KMS, ale aspoň uvidíte, o co tady jde. V instalaci je dokonce víc pluginů

$ yum search plymouth

změnit typ grafického startu můžete příkazem

$ plymouth-set-default-plugin

Pak je potřeba regenerovat initrd.

$ mv /boot/initrd-<verze> /boot/initrd-<verze>.old ; mkinitrd /boot/initrd-<verze> <verze>

Připomínám, že plugin se svým startem si může vyrobit téměř každý, takže to, co uvidíte, je do jisté míry demonstrace možností. Tedy hlavní zbraní plymouthu je podpora KMS, která, doufejme, brzy bude i pro ostatní karty, a rychlost – nestartuje žádný X server jako dřívější rhgb ani nepřepíná rozlišení pro framebuffer. Vylepšen byl i Grub, který nyní při startu ve výchozím nastavení s hiddenmenu nezobrazuje vůbec nic, tedy pokud nemáte v menu ještě jiný OS. To značnou část uživatelů zmátlo, ale jde jen o zvyk. Osobně to celkem vítám, protože jiný OS na mnoha počítačích nemám a odpočítávání a menu tak jen zdržuje. Několik změn doznal i X server. Již v F9 se optimalizovala rychlost startu, v F10 byl odstraněn Mr. FatX. Cítím u toho trochu nostalgie, neboť tlustý černý kurzor ve tvaru X a na pozadí černobílá šachovnice, pro mě po dlouhá léta znamenal první vlaštovkou oznamující start GUI. Co se dá dělat, časy se mění a velké tlusté X mate uživatele.

Skrýnšoty schválně nepřipojuji, protože plymouth je o pohybu. Nepřipojuji ani video, není pro ukázku dostačující. To prostě musíte vidět.

Válka světů vt1 a vt7

Podtématem vážícím se ke startu systému, resp. plymouthu, je válka o start X serveru v rc5 na vt1 místo léta používaného vt7. Je až neuvěřitelné, jakou bouři tato drobná změna vyvolala. V podstatě jediným důvodem této změny je, aby při startu systému nedocházelo k blikání vlivem přepínání virtuálních terminálů a aby se nezobrazoval textový login (nutno přiznat, že někteří začínající uživatelé z něj byli dost paf). To se zdálo spoustě lidí proklatě málo na to, aby měnili léta zaběhaný zvyk stisku (Ctrl+Alt+F1), pro přepnutí do konzole, krom toho se tím zneplatní stohy dokumentace. Je však potřeba se na to podívat i z druhé stránky. Pokud se podíváte do výpisu smoltu na statistiku runlevelu, zjistíte, že 98.1% zaregistrovaných strojů startuje do runlevel 5, a troufám si tvrdit, že nemalá část uživatelů již dnes vůbec netuší, že jim v systému běží textová konzole. Pro přepínání uživatelů, resp. X serverů, se pak už dneska nepoužívá přepínání virtuálních terminálů přes klávesnici (Alt+Ctrl+F7,8,9), ale klikací applet. Tzn. odpadá další argument, že uživatel bude zmaten nekontinuálností Xkových terminálů. Z pohledu běžného užívání systému se tedy pouze zrychlí a zpřehlední start, protože uživatel již neuvidí poněkud matoucí textový login. Z hlediska starých mazáků to je ovšem mazec. Naštěstí ti všichni snad budou schopni aplikovat postup návratu do starých časů:

1. do /etc/event.d/tty1 přidejte „start on started prefdm“ stejně jako pro jiná tty
2. vypněte a nepoužívejte grafický boot plymouth  – odstraňte parametr „rhgb“ z grub.conf
3. vymažte /var/spool/gdm/
4. cross fingers a reboot…

Tím se vám snad tlak… tedy X server vrátí do normálu. Proč je lepší nepoužívat plymouth, když chcete X na vt7? Protože plymouth přes parametr –force-active-vt pro gdm předávaný přes /var/spool/gdm vynucuje spuštění X na vt1… a co by taky dělal guru s grafickým startem systému…

Noroot a xguest

Mnohým však hned vzápětí tlak opět vystoupal, když padlo rozhodnutí o zakázání přihlašovat se jako root do GUI. Skutečně existují lidé, kteří to využívají (např. když konfigurují systém se vzdálenou autentizací), v jejich případě však záměrně, většina uživatelů to ale využívala spíš ke své škodě a tak trochu nevědomky, takže si myslím, že tento krok je jen dobře. (Ano existují uživatelé, kteří se kvůli kopírování souborů tam, kam běžný uživatel nemůže, odhlásili a přihlásili jako root, nemusíte tomu věřit, ale je to tak.)

A trochu škádlení nové vlastnosti Ubuntu – tzv. účtu hosta. Již ve Fedoře 8 existuje tzv. kiosk mode – což není v podstatě nic jiného. Jeho zprovoznění je záležitost příkazu

$ yum install xguest

jediná nevýhoda je, že k tomu, aby skutečně fungoval, musíte mít zapnutý SELinux, a to samozřejmě v Enforcing módu, což, přiznejme si, není na desktopu až tak běžný jev.

Slunečně licenční vítr

Tématem Fedory v desátém vydání se stal Solar. Toto téma vyšlo jako vítězné z veřejné soutěže. Má však celkem zajímavou historii, která velice dobře ilustruje naprostý nedostatek povědomí o licencích a autorském právu především u mladých vývojářů a uživatelů. Jeden autor přispěl do soutěže dvěma tématy, v obou ovšem pozorné oči uživatelů a vývojářů Fedory odhalily zakomponované prvky vypůjčené z cizích děl. Trvalo poměně dlouho autorovi vysvětlit, o co jde, co udělal špatně, a že skutečně nemůže svévolně použít část obrázku někoho jiného. V případě tématu Solar byl do obrazu zakomponován obraz, nikoli slunce, jak by se mohlo zdát, ale měsíce. V rámci finálního kola však byl obrázek zlegalizován použitím volně šiřitelné části tak, aby se skutečně jednalo o originální autorské dílo, a na něm pak bylo celé téma postaveno. Výsledek alespoň v podobě tapety posuďte sami:

Fedora 10 a GNOME Solar

Společně s obligátní změnou odstínu podle denní doby, myslím více než dobré.

Je asi zbytečné připomínat, že Fedora dál poskytuje pouze KDE4, které se verzí 4.1 dá považovat za použitelné, i když už ne na PIII 800 MHz 512 MB RAM.

Fedora 10 a KDE4

Pro takové pak F10 přináší nové desktopové prostředí LXDE. Názor na toto prostředí si udělejte sami. Já zmíním jen jeho Fedora historii (rozuměj drb). Prostředí bylo zařazené mezi vlastnosti F10. Když se ale sestavovaly první verze F10, vrchní komise se koukla do seznamu se stavem implementace a LXDE vyškrtla. Autor, který měl implemetaci na starosti, se pak velice divil, že LXDE se někam ztratilo. Byl z toho poněkud rozhořčen, všechno se urovnalo poté, co se vysvětlilo, že jaksi zapomněl aktualizovat „ukazatel“. I to se může stát.

Ani LXDE ale nezachrání fakt, že i Linux, resp. Fedora už má taky radši výkonnější hardware. Stále provozuji ještě několik stanic výše zmíněné konfigurace (PIII+-800MHz +-512MB RAM), a tak jsem si schválně měřil časy a požadavky aktualizace systému přes preupgrade. Stažení balíčků nebyl zásadní problém. Podle toho, jak máte systém nabobtnalý, se stáhne 1 až 2GB balíčků. Horší to bylo po startu upgrade. Samotná anaconda pak na tomto počítači potřebovala 322MB RAM a během instalace se používalo až 220 MB swapu. Přípravné práce anacondy pro 1071 balíčků trvaly téměř 1 h, následný upgrade téměř 4 h. Na počítačích dnešních parametrů se ale bez problémů vejdete s celou parádou do hodiny.

Abrakadabra Xorg

Xorg, resp. jeho nová verze, se stal zaklínadlem poslední doby. Že takto velký a důležitý projekt strádá nedostatkem vývojářů, je dlouhodobě jasné. Jediný způsob, jak dopřát takovémuto projektu širší testování a větší zájem vývojářů, byl prostě jej nasadit do běžné distribuce. Tak se stalo ve Fedoře 9. Nemálo uživatelů tento krok kritizovalo, i např. proto, že Ati odmítlo vydat ovladače fglrx pro vývojovou verzi X serveru. Osobně si však myslím, že bez tohoto kroku bychom dnes ve všech distribucích neměli Xorg X11R7.4 (xorg-server 1.5 – za domácí úkol můžete napsat, co znamenají všechna ta čísla verzí) s plně automatickou konfigurací a univerzálním ovladačem vstupních zařízení evdev (a z toho plynoucí hotplug). Občas sice tato automatika není úplně dokonalá, ale v takovém případě jde stále použít starý dobrý xorg.conf. Jen je potřeba zcela zakázat používání autodetekce přidáním

do ServerLayout sekce. Nový mechanismus si možná zaslouží trochu více vysvětlit. Autodetekce je realizována přes HAL. Řeťezec udev-hal-dbus je jistě všem již dobře znám. Xorg server tedy bere zařízení tak, jak vznikají v /dev, a přiřazuje jim funkce podle klíčů info.capabilities v HALu (viz lshal a /usr/share/hal/fdi/p­olicy/10osven­dor/10-x11-input.fdi)  – výhoda je, že tento způsob dovoluje odpojovat a připojovat tato zařízení za provozu. Pokud ovšem nevypnete autodetekci, jak je popsáno výše, a navíc přidáte pevnou definici do xorg.conf. A co se nestane? Stane se to, že se půjdete ptát googlu, na fóra a na root, proč se vám všechny události, jako stisk klávesy, vypisují dvakrát. Bystřejší již ovšem tuší, že tomu je tak proto, že X server má nyní vaše jedno zařízení zaregistrované dvakrát.

Zvuk pulsující

Důležitou kapitolou již třetí verze Fedory je pulseaudio. V první fázi vznikl v podstatě zvukový démon vražený do cesty mezi alsu a aplikace – tímto se jej aplikace naučily používat.

To ovšem nebyl hlavní cíl a tak v podstatě souběžně s tím začala vznikat i idea glitch free audia (nebo jak sám autor říká, méně marketingově znějící, timer based audio scheduling). O co jde. V současných zvukových kartách je „binec“. Každá poskytuje a umí něco jiného, s jinou přesností a jiným mechanismem a navíc alsa jako hw ovladač nemusí všechno podporovat, protože výrobce nedá specifikaci atd. Aplikace jsou pak „jelen“ z toho, když mají se zvukovým zařízením pracovat. Donedávna tak byly hudba a zvuky servírovány na základě hladového požadavku karty (rozuměj IRQ). Problém ovšem je, že v takové systému nelze pružně reagovat na změny a události v audio systému, protože musíte čekat minimálně do dalšího IRQ (tedy potřebujete co nejkratší buffer), v tom případě ale máte malou odolnost proti výpadkům (na tu potřebujete zase dlouhý buffer). Co nové pulseaudio dělá, je, zjednodušeně řečeno, že v podstatě každou kartu degraduje na co nejjednodušší zařízení, které má za úkol pouze neustále přehrávat dlouhý (2s) buffer. Zvukový server pak může s daty v bufferu různě žonglovat a karta prostě jen hraje další vzorek, který jí pod ukazatelem pulseaudio mění. PA se k tomu nechává probouzet přesnými časovači, nebo událostí v aplikaci. Vzhledem k délce bufferu 2 s to pak za normálních okolností vede i ke snížení množství přerušení/vzbuzení. Tuto myšlenku audio serveru, který by splňoval protichůdné požadavky dlouhého a krátkého bufferu, bylo obtížné realizovat na starších kernelech, kde se špatně časují události (přesnost kernelovského timeru při Hz=100 je 10 ms). Preciznější práce s audiem je tedy možná až od uvedení hrtimers v nových kernelech. Proto vzniká „glitch free“ verze až nyní.

Samozřejmě tento přístup s sebou nese i komplikace, a to především v tom, že ne každá zvuková karta je ochotná se nechat znásilnit k 2s bufferu a vypnutí IRQ, a je potřeba ladit čas ládování bufferu podle zátěže a rychlosti systému, což může vést ke vzniku různých podtečení, v audiu značně nepříjemných. Také to zvyšuje paměťovou náročnost, protože pokud má být zvukový server schopen kdykoli přimixovat další zvuk do bufferu v nejvyšší kvalitě, musí udržovat vzorky všech právě hraných zvuků někde po ruce. Je to holt daň za narůstající hlad po zvukových efektech apod. Stejnou už mnozí ochotně zaplatili v oblasti videa – ve 3D efektech.

První pomoc

Novým nástrojem se zajímavým potenciálem je First Aid Kit, který vznikl v české pobočce Red Hatu, a je součástí rescue módu a LiveCD. Jedná se v podstatě o framework v pythonu, který umožňuje vytvářet moduly pro záchranné úkony, které nejeden z uživatelů musí udělat po nějakém tom nešikovném zásahu do systému, ovšem mnohdy jsou mimo jeho možnosti a znalosti systému nebo příkazové řádky. Trochu škoda je, že některé úkony, které byly součástí FAK, byly principielně eliminovány během vývoje F10, a tak se množství pluginů pro FAK krapet zmenšilo – na mysli mám původní plugin pro kontrolu xorg.conf (vzpomeňme že v F10 není xorg.conf potřeba) a opravy „zaseklého“ rpm, které též již nejsou potřeba. Tedy samozřejmě z hlediska uživatele je to dobře, jen to byla trochu zbytečná práce. Co tedy FAK umí, je znovu nainstalovat GRUB, regenerovat initrd (tento plugin jsem, veden téměř za ruku Martinem Sivákem, napsal já na FUDConu), změnit zapomenuté rootovské heslo, obnovit dmraid a reinstalovat základní systémové balíky. Jednotlivé akce umí se závislostmi řetězit a v textovém i grafickém prostředí přehledně zobrazovat. K mému překvapení je ale FAK v F10 okleštěn na tři pluginy – mdadm, passwd a xserver, které mi navíc… ehm… nějak nefungují. Z FAK je tedy v F10 jen jakési torzo… což je myslím škoda.

Fedora 10 a First Aid Kit

Druhá pomoc

Z české pobočky pochází i další nástroj – SecTool, který je prezentován jako security auditing and intrusion detection system. Nejedná se o žádný online nástroj ani nástroj typu rootkit – idea je jiná a není vůbec špatná. V podstatě se jedná o systém kontroly pravidel, která lze z hlediska bezpečnosti systému považovat za smysluplná, případně změn, které mohou být přinejmenším podezřelé. Tyto kontroly pak umožňuje provádět v několika úrovních podle stádia vaší paranoii. V čem osobně vidím největší sílu je, že sectool dokáže reportovat změny, tedy při prvním spuštění vás upozorní na existující (ne)problém, uloží aktuální stav a při dalším spuštění nahlásí, pokud došlo v daném nastavení nebo např. binárce ke změně. Některé distribuce mají nástroje podobné, SecTool ale svým konceptem úrovní, pluginů, rozhraní a nápověd jde zase o něco dál.

$ sectool --list
$ sectool --level 1 --diff

Fedora 10 a sectool

Rýpnutí do RPM

V F10 se konečně pohnul i pohnutý život základního stavebního kamene distribuce a to samotného RPM. Stručně připomenu, že RPM před časem s odchodem jeho hlavního vývojáře zůstalo v poněkud neudržovaném stavu, výsledkem čehož byl vznik nějaké té odnože a nadstaveb, což se před nedávnem stalo již celkem neudržitelné. Tak vznikl tým dvou placených lidí, kteří RPM od podlahy probrali, vydali záplatovanou verzi rpm 4.4.2 a vrhli se do změn větších, které jsou nyní v téměř hotové verzi 4.6. Seznam všech změn najdete na rpm.org, jen stručně to postatné – závislosti mezi architekturami, podpora velkých souborů, LZMA komprese, podpora kontrolních součtů SHA256 a automatické odstraňování locků rpmdb (což konečně eliminuje množství hlášení chyb o zaseklém rpm, resp. yumu).

Virtualizace, kam se podíváš

Velkým tématem F10 je samozřejmě virtualizace. Celé se točí kolem veličiny libvirt, která abstrahuje jakýkoli virtualizační stroj a následně umožňuje vznik nepřeberného množství nástrojů zjednodušujících práci s virtuálními stroji. Do tohoto tématu patří virtual storage, remote virtual install, appliance tool, neboli ACT (appliance creation tool – livecd a kickstart) a AOS (appliance operating system – minimální systém Fedora – to jest jeden ze spinů popsaných výše) a amqp infrastructure – MRG = messaging, realtime, grid. Všechno to jsou témata jistě velmi zajímavá pro toho, kdo začal používat virtuálních strojů i ve větším měřítku, kdy se správa takových strojů využitím centrálního uzlu značně zjednodušuje stejně jako nasazování nových strojů za pomoci kickstartu AOS.

„Drobnosti“

Labeluuid

Z drobností pak zmíním ještě přechod od LABEL k UUID, o čemž se taktéž vedly debaty, a už si nepamatuji, který argument nakonec převážil. Pro mne jsou UUID nečitelná a zdržující. Počítače ale mají číselnou identifikaci disků rádi a umožňuje to jejich správné auto-připojování i při změnách rozdělení disku. Já většinou při prvních ručních úpravách disku skončím u /dev/sda1 /boot ext3, protože kdo má neustále dekódovat, který oddíl disku se skrývá pod ba6d5–90981-uáááá-vžžžm.

sbin

Druhou změnou poplatnou době je zahrnutí /sbin do cesty (PATH) i pro nerootovské uživatele, čímž se eliminuje množství zbytečných dotazů začátečníků, že jim nefunguje příkaz ifconfig a vznikne spusta dotazů typu, proč mi to nejde nastavit, když ten příkaz kopíruju z toho návodu správně (odpověď – protože nejsi root).

Sdílení připojení

Poměrně častým požadavkem uživatelů Linuxu je možnost „sdílet připojení“. Ať už jsou za tím pohnutky jakékoli, je pravdou, že Linux tuto činnost dokáže zvládnout na jedničku. Člověk ale musí mít, jako u většiny věcí v Linuxu, aspoň trochu ponětí o tom, co dělá, a musí najít vhodný software, v tomto případě nejčastěji dnsmasq. Ve Fedoře se tuto činnost rozhodli uživateli trochu zjednodušit a obohatit NetworkManager o další, již dlouho napůl cesty implementovanou možnost vytvořením adhoc wifi přípojného bodu, který dalším připojeným účastníkům přidělí adresu, gateway a předává jejich DNS dotazy na nadřazené DNS servery – což je to, co uživatelé požadují jako „sdílení internetu“. Bohužel, jak jste jistě postřehli, jedná se pouze o možnost pro bezdrátové klienty, nastavení „routeru“ pro klasický drát budete muset stále zvládnout sami. Další muškou na kráse je, že ne všechny wifi karty zvládají adhoc, resp. master mode.

LIRC a webcam

LIRC je jedna z věcí, které, musím se k tomu přiznat, jsem v Linuxu nikdy nezkoušel zprovoznit. Nevím, o co všechno sem tím přišel, ale vypadá to, že je to téma, které uzrálo natolik, že „sprevadzkovanie“ LIRC je možné aspoň částečně zautomatizovat.
Neodpustím si tady poznámku. Dokud si člověk musel věci takříkajíc rozchodit ručně, nejen, že se danou problematiku trochu naučil, ale mnohdy pak dovedl lépe ocenit, když pro něj někdo připravil kvalitní návod nebo balík jeho problém řešící. S filozofií „just works“ se nám sice žije mnohem snáze, ale pouze do okamžiku než se něco… víteco. Pak totiž zjistíte, že lidí, kteří tomu aspoň trochu rozumí, je čím dál míň, a naopak přibývá šamanských rad a postupů, které zná mnoho uživatelů Windows (tedy zakruťte třikrát kolečkem myši, položte ji na zádíčka a za součastného mačkání kláves Bž a Fň vzývejte inkarnaci ducha hárddisku, tím se to spraví). Někdy tak opravdu žasnu nad odborností, byť dobře míněných, rad, nemluvě o skuhralech, kteří prskají, že se jim nenastavilo optimální rozlišení monitoru, ale už zapomněli, nebo nepamatují doby, kdy se musely „ručně“ počítat modeline z parametrů monitoru, nehledě na to, že u konkurence se stále musí nastavovat ručně. Nebo už ne?

Podobně to bude i s webovými kamerami. Na FUDConu jsem potkal Hanse de Goede obtěžkaného balíčky a webovými kamerami (obrazně řečeno). Tento člověk je, či alespoň byl, čistý dobrovolník, velmi otevřený člověk, který spravuje neuvěřitelné množství balíčků, a teď si přibral na krk i rozchození všemožných kamer, takže na něj doma ze stolu koukají desítky objektivů a další mu lidé posílají. Ano, značná část vylepšení podpory webkamer přichází do Fedory „zdarma“ s novým jádrem a začleněním taktéž obdivuhodné práce Jean-Françoise Moine na gspca, ovšem má to jeden háček. Množství kamer vrací obraz v nejrůznějších záhadných formátech, se kterými aplikace neumí pracovat. Takže zbývá spousta práce s implementací jejich podpory do v4l(2) a následně přemluvení aplikací k používání tohoto api, což ještě zdaleka není zcela běžná věc. Takže když někdo napíše, že podporuje všemožné webové kamery, ještě to neznamená, že obraz z nich budete moci automaticky používat ve své oblíbené aplikaci.

gnome-do

Jsem si nechal jako žertovné „zviřátko“ nakonec. Je to taková mono blbinka, ale třeba vás její funkčnost nadchne. Nainstalujte

$ yum install gnome-do

a skoukněte video, spusťte gnome-do a můžete řádit (<super>mezerník).

Poznámka na závěr

Málem bych zapomněl – Empathy se nekoná. Není se co divit, když i sami autoři ho prohlásili za nedonošené… snad příště. Zatím si budete muset vystačit s pidginem.