Fedora 1415: tvář budoucího Linuxu

Řekněme si to na rovinu – ve Fedoře 14 toho moc nového nebylo. Tedy mohli bychom opěvovat novou tapetu a starý font, ale myslím, že to není potřeba. Hlavní těžiště dějů se přesunulo do změn webových stránek, dokumentace a testování. F15 je ale jiné kafe.

Ono to nefunguje

V podstatě ihned zavírám okno prohlížeče s diskusemi typu: Ve verzi X mi to fungovalo, ale ve verzi Y mi to nefunguje, takže celá verze Y je špatná a vůbec ji neměli vydat. Uživatelé si totiž ve většině případů neuvědomují, že se zpravidla nejedná o chybu distribuce verze Y, ale např. problém s jádrem, ovladačem grafiky nebo firmwarem jejich WiFi. A jediný kdo je v současné záplavě HW schopen otestovat zrovna ten jejich kus v nové verzi Y, jsou oni sami.

Problém vzniká z nepochopení toho, že kombinace SW a HW, který provozují, je jedna z myriád možných, navíc do značné míry závislá na implementaci toho kterého výrobce, který si tu ušetří drátek od referenčního designu, tam změní firmware a na problémy je zaděláno. Pokud tedy někomu něco fungovalo a nefunguje, má tyto možnosti: pídit se po příčině a tu nahlásit (lokalizaci problému bisekcí zvládne téměř každý, kdo aspoň trochu ovládá balíčkovací systém své distribuce), nestěžovat si a používat to, co mu funguje.

Pokud tedy ve své nevědomosti doufáte, že testování provede někdo zrovna u vaší distribuce za vás, je to představa veskrze naivní.

Testování

Všechny distribuce řeší jeden důležitý problém, a to je právě testování. Pro většinu uživatelů se tak stane testovacím dnem až den finálního vydání, což je do značné míry špatně. Osobně bych jako řešení viděl existenci automatických testů. Problém ovšem je, kdo je bude udržovat a psát. Fedora se to snaží řešit tzv. testday – testovacími dny, kdy vývojáři připraví speciální LiveCD se zaměřením na některou oblast a popis testů, které se mají provést a jejich výsledek nahlásit. Nápad dobrý, ale taky má své vady. Buď není testerů dost, aby otestovali dostatečně široké spektrum konfigurací, nebo neumějí problém dostatečně popsat, nebo, když už jich je dost, není dost vývojářů, aby všechny problémy odstranili. Je to výrazně lepší než nic (nazvěme to pravým jménem: vydání betaverze a oznámení nestačí), ale k ideální situaci to má daleko.

Další „mechanismus“, který přichází na scénu až během F15, je tzv. Test Case Management nástroj Nitrate (TCMS) založený na Djangu a Pythonu, který by měl sloužit ke správě automatických testů, napsaných pro opravované chyby. Jeho ostré nasazení ale bude ještě chvíli trvat. Něco podobného má Mozilla pod jménem Tinderbox.

Aktualizace lépe a radostněji

Fedora řeší i problém příliš mnoha, příliš častých a občas i značně nešťastných aktualizací. V aktualizacích již dlouho existuje mechanismus přidělování karmy novým aktualizacím, až s F14 se ale pro přijetí některých balíků mezi aktualizace stává povinná pozitivní karma alespoň od dvou lidí. Během F15 se vedla diskuse, zda povolit či ne přidělování karmy i správcem balíku. Zatím je to zřejmě především z důvodu nedostatku testujících tolerováno. Karmu lze přidělovat i anonymně, pokud byste se obávali zakládání dalšího účtu, nebo dát najevo svůj názor veřejně.

Nejhorší jsou pak chyby v kritických balíčcích. To se ve Fedoře snaží od F14 řešit zavedením nové kasty tzv. ProvenTesters (ověření testeři), kteří musejí schválit aktualizace balíků ze seznamu critical path packages (kritické balíky).

Během vývoje F15 se objevil ještě jeden nástroj pojmenovaný AutoQA (je vidět, že Fedora se opravdu snaží vylepšovat systém automatických kontrol a testů). AutoQA má zatím dvě důležité vlastnosti:

1. depcheck, který komplikovanými cestami zjišťuje, zda případný update nezpůsobí problémy se závislostmi v řetězci aktualizací
2. updradepath, který kontroluje, že všechny aktualizace v po sobě jdoucích vydáních Fedory mají vyšší číslo verze než předchozí vydání, čímž se již nebude stávat, že po upgradu v systému zůstanou verze balíků ze starého vydání

Uvidíme jak to bude fungovat, zatím AutoQA běží v experimentálním režimu. Výsledky AutoQA se pak objevují v komentářích aktualizací (sekce Feedback na obrázku).

Něco dokumentace ke čtení

Dokumentace v anglickém jazyce pro F14 je již skutečně mnoho – Accessability, Amateur Radio, Burning, Deployment, Fedora Live, Installation, Musicians, Power Management, Security, Software management, Storage a User Guide. Plus samozřejmě Release Notes. Zde si musím nasypat popel na hlavu, protože jako koordinátor překladů shledávám množství dokumentace v českých podmínkách, kde se do překladů zapojují řádově jednotky lidí (i když na Transifexu máme momentálně jeden z větších týmů), za nepřeložitelné. A tak překlady dokumentů stíhají snad jen Indové a Číňani. Pro generování dokumentace a její strukturování a stylování přešel Fedora projekt na Publican, který je založený na DocBooku. Výsledek je nahrazení starého webu docs.fedorapro­ject.org podstatně bohatším a přehlednější strukturou webových knih.

Překlady se pro F15 přesunuly ze samostatného serveru translate.fedo­raproject.org přímo na Transifex (http://fedora­.transifex.net/), což vyvolalo krapet kontroverzi, proč si Fedora nemůže nainstalovat Transifex na vlastní server. Důvody jsou zřejmé – Dmitris Glezos, který Transifex původně v rámci Fedory začal vyvíjet, založil obecnější Transifex.net, kde nabízí překladatelské prostředí širšímu publiku včetně komerční sféry a tak se pomalu, ale jistě neměl kdo starat o instalaci přímo pod Fedora projektem. Výsledek byl, že Transifex na Fedoře stále zaostával, až se stal nepoužitelným. Podle mne byl přesun na transifex.net celkem logický krok, nicméně pro F16 se uvažuje o opětovném přesunu zpět na servery Fedora projektu. Sám k tomu nevidím důvod… uvidíme, jak to dopadne.

Web Překabátěný

Nový web, a vlastně vzhled všech stránek fedoraprojektu, který přišel s F14, je jistě úchvatně poplatný době – velká patička, kterou můžeme pozorovat i na serverech iinfa, a hlavní část úvodní stránky zabraná animovanými happy people s happy feature ve všech barvách. Nebyla to jediná změna, i když rozsáhlá, přibyly např. nové stránky fedoracommuni­ty.org. Značná část nového webu je přeložena do češtiny, ovšem nutno říci, že překládání těchto PR sloganů je trochu únavné. O záživnosti jejich čtení nemám příliš iluze. Patří to ale k době.

Dvě novinky

Nepříjemný osud potkal v F14 dvě novinky. MeeGo a systemd. Zatímco MeeGo se v podstatě nedopatřením objevilo nakonec i v oznámení o vydání ovšem bylo nepoužitelné, pak systemd byl zcela legitimně stažen po Beta vydání. Zatímco MeeGo po poněkud překotných změnách v rozložené Nokii obrátky příliš nenabírá, systemd je téma, kterému je potřeba se věnovat více, protože je to jedna z vlastností, které zřejmě zásadně ovlivní budoucí práci s mnoha linuxovými systémy.

Init Systemd

Ještě jsme si ve Fedoře nestihli zvyknout ani na Upstart, a už se na nás řítí ještě komplexnější systém – systemd. Náhrada lety prověřeného a poměrně jednoduchého „initu“ a systému init skriptů, startujících vše podstatné v operačním systému. Skriptované startovací procedury mají dvě zásadní nevýhody – jsou pomalé (většinou dané sériovým zpracováním) a neřeší závislosti. Za výhodu lze považovat jistou flexibilitu a jednoduchost takového řešení, která je ale v dnešní době vykoupena značně nesourodým systémem rc.d skriptů, který je v každé distribuci tak trochu svůj. Upstart zavedl mechanismus událostí na jejichž základě se k životu měly zřetězeně probouzet další služby. Výsledkem je přepis dříve víceméně neformálně vedených pravidel do Upstart init skriptů s danou syntaxí. Od initu ze SysV se ale v samotných skriptech příliš nezměnilo, jen se změnil zápis, struktura rcX.d se přenesla do zápisu v /etc/init/*.conf a vývojáři, resp. správci balíčků byli do jisté míry nuceni přemýšlet, kam do řetězce služeb zařadit svého démona. Také logika Upstartu je poněkud explozivní. Tedy fakt, že se nastartuje služba D-Bus, je událostí, která spouští všechny služby na něm závislé.

Myšlenka dobrá, ale má špatné následky. Proč? Totiž spuštění D-Busu má mít za následek start všech služeb na něm závislých, když mnohé z nich v daném momentě nejsou vůbec potřeba. Své dělá i značná míra zpětné kompatibility, která v podstatě umožňuje pouštět skrz Upstart staré dobré init skripty. Primární mechanismus Upstartu ale používá jiný a poněkud méně průhledný systém událostí, než používaly init skripty. Nalezení popisu a seznamu možných událostí je poněkud obtížné. Např. takový start sériové konzole je (ve Fedoře) událost fedora.serial-console-available, což zjistíte v /etc/init/seri­al.conf. Ale kdo tuto událost vyvolává a jakým způsobem, se obtížně dohledává.

Sockety

Systemd přichází s jiným mechanismem. Je založen na dobře známém mechanismu socketů. Vychází z myšlenky, že serializace startu služeb je v podstatě pouze důsledek nutnosti čekání jednotlivých služeb na start socketu jiné služby. Pokud systemd vytvoří sockety nezávisle na startu dané služby, pak je možné startovat závislé služby ihned po vytvoření socketu, místo čekání na start celého démona.V případě, že se socket začne využívat dřív než je jeho obsluha nastartovaná, přichází na řadu mechanismus vyrovnávací paměti schovaný za socketem, který požadavky shromažďuje do té doby, než si je převezme démon, jemuž socket patří. Tento mechanismus mimochodem nabízel už stařičký démon inetd, tedy nejedná se o závratně novou myšlenku.

D-Bus

K socketům je však potřeba v dnešní době přidat ještě další mechanismy spuštění služby, a to na základě požadavků přijatých skrz D-Bus a na základě vzniku zařízení nebo cesty. Princip však zůstává stejný. Jen vyrovnávací paměť socketu je např. pro D-Bus nahrazena pamětí D-Busu. Trochu složitější je to pro zařízení a cesty. V případě zařízení systemd v podstatě fušuje do řemesla udev, nicméně dává možnost v udev použít jednotný systém spouštění služeb přes systemd místo volání konkrétních skriptů či binárek. Zajímavý je i princip buzení na základě cesty. Příkladem budiž např. tisk. Takové zpracování souboru k tisku nemusí běžet permanentně a kontrolovat obsah spoolu, ale může být vyvoláno až v okamžiku, kdy je zde něco k tisku připraveno.

Mount /

Z pohledu systemd jako prvního procesu v systému je je potřeba se vypořádat ještě s jedním důležitým úkolem, který je nezbytný pro většinu démonů. Tím je připojení diskových oddílů. I tento problém lze řešit použitím procesu podobného k procesu popsanému v předchozích částech. Využívá se k tomu taktéž letitého mechanismu autofs, který připojuje diskové oddíly až na požádání. Požadavky, které směřují na takový oddíl, jsou pozdrženy do okamžiku, kdy je oddíl připojen. To způsobí blokování jen a pouze toho démona, resp. požadavku na daný konkrétní oddíl. Výjimka jsou samozřejmě kořenový svazek /, /proc a /sys, které musí systemd připojit takříkajíc klasicky. V případě, že připojení oddílu přes autofs, např. z důvodu chyby na oddíle, neproběhne v pořádku, je vrácena regulérní chybová zpráva a je na démonu, aby se s ní vypořádal, neznamená to ale fatální selhání řetězce startu.

Shell

Další nosnou myšlenkou je odstranění shellovských skriptů ze startovacího procesu. Jak jsem psal výše, skripty jsou sice snadno upravitelné, ale pomalé a náchylné k různé interpretaci v různých podmínkách (nastavení proměnných, různé shelly). Shellovské skripty samozřejmě nemá cenu odstraňovat za každou cenu, ale jejich repetitivní části (start, stop, status, vytvoření pid) může převzít společně s hlídáním procesů jeden kód.

Kontejnerování

Problém současných start-stop funkcí je i ten, že nejsou schopny spolehlivě odstranit všechny části spouštěné služby. Zde systemd začal využívat mechanismus zavedený do jádra teprve nedávno, původně pocházející z LXC (linux containers), kterému se říká cgroups. Cgroups slouží primárně k omezení konzumace zdrojů skupinou procesů, systemd ho však využívá i pro kontejnerování celých démonů a jejich potomků, což umožňuje mnohem spolehlivěji kontrolovat start, fork i stop všech součástí služby. Takový kill pak znamená odstranění všech součástí dané cgroup a tedy skutečné odstranění všech součástí služby.

systemctl stop crond.service #požádá službu o regulérní ukončení
systemctl kill crond.service #pošle kill všem součástem služby crond.service

Když už ale systemd cgroups využívá, není důvod nepoužít je i k omezování zdrojů pro služby. Zatím toho ale nelze dosáhnout přímo pomocí systemd. Nicméně uvažuje se o tom.

Units

Místo init skritpů využívá systemd tzv. units. Unita je textový konfigurační soubor s poměrně jednoduchou strukturou stejnou jakou mají .desktop soubory. Samotný název souboru říká, o jaký druh unity se jedná, zda service, socket, device, mount, target, automount, timer, path nebo snapshot. Všechny unity jsou popsány strukturou souborů v /lib/systemd/ a symbolickými odkazy (což jemně připomíná rcX.d->init.d). Pro administrátory je pak určen /etc/systemd/, který má vyšší prioritu.

Příklad unity pro DBus (dbus.service):

[Unit]
Description=D-Bus System Message Bus
Requires=dbus.socket
After=syslog.target

[Service]
ExecStartPre=/bin/dbus-uuidgen --ensure
ExecStartPre=-/bin/rm -f /var/run/messagebus.pid
ExecStart=/bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
ExecReload=/bin/dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig

Konfigurace v /etc/init a shell skripty v init.d využívá systemd jen pro zachování kompatibility se SysV. Skripty by systemd neměl pouštět, pouze je parsovat jako jinak formátovaný konfigurační soubor, což je mimochodem dost zvláštní způsob zachování zpětné kompatibility, který dle mého v některých případech moc nefunguje (využívá v podstatě obsah LSB hlavičky). Spouštět je lze samozřejmě také pomocí právě direktiv Exec*.

Man

Ač si to mnozí vývojáři neuvědomují, úspěch skvělých myšlenek závisí nejen na geniálnosti designu, ale především na srozumitelnosti a dostupnosti dokumentace. Systemd má zatím dokumentaci na velmi dobré úrovni to ve formě manuálových stránek. Pokud např. hledáte dokumentaci k definici služby „service“, najdete ji pod man systemd.service atd. Je tedy zbytečné tu rozebírat jednotlivé unity. Kdo chce, jejich popis snadno najde.

Unit = nový shell?

Obecně lze říci, že každý typ unity má skupinu vlastností, které určují jeho chování. Bohužel stejně jako u Upstartu, jedná se v podstatě o nový „programovací jazyk“ interpretovaný skrz systemd. Již teď se ozývají hlasy, že tato množina není schopna pokrýt flexibilitu shell skriptu. Otázkou je, zda to je cílem. Systemd má dvě možnosti – buď jeho autoři povolí a struktury systemd se začnou rozrůstat do obludných rozměrů, takže se z nich časem stane další shell, nebo si budou stát za svým a nutit autory služeb k jisté disciplíně. Jak to dopadne ukáže čas. Já osobně se obávám prvního, ve druhém případě ale zase hrozí, že systemd nebude přijat plebiscitem.

Hranice systemd

Celý problém s různými init systémy stojí a padá s definicí hranice mezi službou a aplikací a mezi službami, které poskytuje systém (system) a službami, které vyžaduje uživatel (session). To vše je dnes v podstatě boj o místo na slunci mezi různými „démony“, D-BUSem, udev a HALem, k tomu se přidává ConsoleKit, PolicyKit, DeviceKit (dnes už splývající s udev), RtKit a trochu i PackageKit. Nalezení hranic mezi jejich kompetencemi je pak trochu tenký led a často se vytrácí původní unixová myšlenka, aby jedna „aplikace“ dělala jen jednu věc, ale pořádně. Zda se nějaká koncepce prosadí a bude se vyhřívat na slunci tak dlouho jako stařičký SysV init (kterému je nějakých 28 let), je v dnešním překotném světě otázka. Když nic jiného, přichází systemd s neotřelým přístupem a značným urychlením startu paralelizací a přesunem spouštění služeb až do okamžiku jejich potřeby – takříkajíc automaticky. Což je bohužel věc, která mne mnohde děsí.

Řetězení a paralelizace

Za možnou nejslabší stránku z „onoho“ automatického považuji právě transakční systém zpracovávající závislosti mezi unity. Zde je totiž množství „fuzzy“ logiky, která se snaží vykouzlit ze závislostí, které píše člověk ve formě unit, optimální průběh spouštění služeb. Člověk je ale vstup velmi chybující, a tak vidím jako potenciální riziko, že jeden špatný zásah do unit může vést k obtížně dohledatelným problémům při startu sytému, což je většinou fatální při správě vzdálených strojů.

Ovládání init vs. systemd

Přesto, že se autor(ři) snaží zachovat v ovládání a příkazech kolem systemd jistý řád, je ovládání o řád komplikovanější než „staré způsoby“.

Uveďme si několik příkladů

systemctl isolate multi-user.target =   init 3
systemctl start network.service     =   /etc/init.d/network start
ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
                    =   sed s/^id:.:/id:3/ /etc/inittab

Vůbec poměrně jednoduchá struktura inittab souboru byla zrušena a nahrazena poněkud kryptickými konfiguracemi. To ostatně přišlo již s Upstartem. Nezbývá než si povzdechnout, kde jsou časy vzniku příkazů „ls“. Dnes by byl jeho politicky korektní zápis nejspíš „list –files –and –directories“.

Uveďme si další příklad a to, jak zjistit jaké služby se vlastně startují v tom kterém „runlevelu“ – správně v systemd „targetu“:

systemctl show multi-user.target

Zde si můžeme demonstrovat další zvláštnost chování systemd, resp. systemctl. Tou je přizpůsobování výstupu velikosti terminálu a automatický scrolling. Pokud vyvoláte takovýto příkaz pro pouhé zobrazení v terminálu, budou řádky ořezány na šířku terminálu, případně bude v některých příkazech zobrazeno jen tolik informací, aby se správně formátované vešly na šířku terminálu. Výstup bude navíc automaticky stránkován. Je to trochu nezvyklé chování, které může napoprvé poněkud zmást. Pokud nemáte o ořezání zájem a chcete vidět výstup celý, např. proto, že vám ořezání (jako v tomto případě) skryje podstatnou informaci v řádku Wants=, můžete výstup klasicky přesměrovat do routy a použít např. less nebo grep podle libosti. Výstup již bude kompletní.

Z dalších změn, které systemd přináší jmenujme ještě odstavení stařičkého mechanismu chroot, který by se se systemd již neměl používat – nahrazeno pomocí namespaces, cgroups a nspawn, které skutečně izolují včetně systémových volání, nebo potřebu doplňovat systém o runit nebo daemon tools – supervizi unit provádí sám systemd. Pro zájemce o detailnější informace nezbývá než odkázat na Lennartovy zápisky.

Linux Dnes

Pro rekapitulaci – z čeho se tedy skládá systém zhruba dnes:

Jak je vidět, architektura Linuxu se vyvíjí, do popředí se dostávají novější technologie z linuxového jádra, které by byla škoda nevyužívat jen proto, že správci jsou na něco zvyklí. Ať už jsou to z těch nových cgroups, capabilities, namespaces nebo selinux či inotify. Kdo se chce v oboru orientovat, musí jít s dobou a naplňovat to, co mnohým kladli na srdce při přebírání vysokoškolského diplomu – dále se vzdělávat.

Setuid ano či ne

Bezpečnost je stále aktuální téma. Jedním z pozůstatků jednoduchého, ale dnes již (údajně) nedostatečně škálovatelného mechanismu je použití setuid u některých spustitelných souborů, jejichž akce bylo potřeba provádět s právy jiného uživatele (nejčastěji root). Tyto soubory jsou častým terčem útoků a vůbec snadným způsobem získání vyšších oprávnění.

Proto již dlouho a pozvolna probíhá snaha o jejich eliminaci a nahrazení setuid prostřednictvím jiných mechanismů, bohužel mnohdy komplikovaných – naposledy „file capabilities“. To je mechanismus do značné míry vázaný pouze na souborové systému, které jej podporují a navíc podobně „průhledný“ jako SELinux. Zatímco setuid je vidět z běžného „ls -la“ a jeho přenos podporuje naprostá většina kompresních a kopírovacích programů, u capabilities tomu tak není. Nahrazení setuid pomocí file capabilities tak zůstává u mnoha případů značně diskutabilní.

Jako příklad je uváděn prostý ping, který pro přístup k soketu potřebuje rootovská práva, ale pak je zahazuje. Zatímco zahození vyšších práv je úloha v pingu implementovaná a poměrně jednoduchá, nahrazení pomocí capabilities je komplikované a vyžadovalo by ping přepsat.

Nakonec porovnejme si nastaveni setuid s capabilities:

chmod u+s bash.suid =   setcap cap_net_bind_service+eip bash.cap

Gnome 3 she2l

Zcela vlastní kapitolu si zaslouží Gnome 3 alias Gnome Shell. Co k tomu říci na úvod… Každá velká změna, rozuměj akce, vyvolá velkou reakci. V případě KDE 3 vs. 4 se dalo říci, že čtyřka byla oproti trojce pomalá, padavá, nedodělaná a chybělo jí spousta věcí. Zaváděla nové postupy, které starým psům přišli jako psí kusy a tak jsme měli možnost číst množství nespokojených štěků.

Jak je to s Gnome 2 vs. 3? Podobně. Ovšem jsou tu dvě důležitá ALE. První je, že to není pomalé ani na starých strojích, a druhé je, že zaváděné novoty jsou nádhera ne jen na pohled, ale i na používání. Jediný zádrhel je, že bezpodmínečně potřebujete akceleraci grafiky, což by od F15 neměl být takový problém. Od teď můj pohled začíná být subjektivní a ani jiný být nemůže. Gnome shell je v některých oblastech chudší a občas padá – ovšem většinou jen shell a ten se opět restartuje. Jak jsem naznačil, ovládání mne nadchlo, protože je jednoduché a do značné míry kopíruje linuxový styl práce (aspoň tedy mé).

Někomu to může připadat zvláštní, ale menu typu Aplikace v různých gui používám minimálně a velmi mne vytáčí když u WXP je potřeba procházet několikaposchoďovým stromem menu (je až neuvěřitelné co někteří jedinci dokáží do menu nasyslit). Značnou část aplikací pouštím přes terminál, jen několik málo (jako terminál) mám na liště jako zkratku. V Gnome 3 připomíná práce s menu spíš gesta myší, resp. princip se vrací do jisté míry ke kořenům GUI na Unixech, které často využívalo cosi jako „Focus On Mouse Over“. Najetí do levého rohu zobrazí celoobrazovkové „menu“, najetí nad políčko „hledat“ ho zaměří, stisk kláves „t e enter“ pustí terminál. Paráda.

Ovládat lze tento mechanismus i elegantně z klávesnice. Stisk klávesy ehm… s okénkem otevře shell, psaním rovnou začnete hledat aplikaci. Zrušení tlačítek minimalizace a maximalizace oken, taktéž spíš vítám. Maximalizaci lze provést poklepem na horní rám okna, minimalizace mi chybět nebude, ač jsem ji svého času používal. Přepínání oken klasika Alt+Tab. S G3 se teprve seznamuji, jistě se najdou i další vychytávky. Zajímavou, ale taktéž dobře udělanou vlastností je vícero ploch. V Gnome 3 se totiž volné plochy vytváří dynamicky – tedy vždy máte o jednu volnou plochu navíc než právě používáte. Pokud na ní přesunete nebo otevřete okno, vytvoří se další. To je skutečně jednoduchý a efektivní postup.

Nejzajímavější jsou v tomto směru reakce uživatelů charakterizovatelné rozezlením „Jak si v tom Gnome shellu můžu vytvořit více desktopů?!“ následované údivem „To je geniálně jednoduché!“. A tak je to u Gnome 3 s vícero věcmi. Co z toho plyne? Jako vždy. Nepřistupovat k novým věcem se starými návyky. Je vidět, že je možné ovládání desktopu udělat jinak a někdo nad tím přemýšlí. Zkuste mu to oplatit a nad svým používáním desktopu se zamyslet též. Třeba přijdete na to, že to jde dělat i jinak.

Pokud vám z důvodu absence akcelerace nemůže nastartovat plnohodnotný shell, je zatím v Gnome 3 i tzv fallback mode, který v prostředí Gnome 3 spustí gnome panel v mnohém podobný tomu z Gnome 2. To samé se stane, pokud z nějakého důvodu stále ještě používáte volbu nomodeset a váš ovladač grafiky tak běží v zastaralém režimu, nebo pokud k tomu Gnome donutíte nastavením změnou proměnné IsRunnableHel­per=/bin/false v /usr/share/xses­sions/gnome-session, kterážto cesta je sice možná, ale nepřežije aktualizaci a je to skutečně jen fallback (ve finále by na to měl být nějaký čudl v nastaveních).

Pár drobných

Fedora přináší i několik dalších „drobných“ vylepšení (tím nechci snižovat jejich náročnost nebo závažnost, jen se jim zde již budu věnovat jen okrajově). Jedná se o dotažení DNSSec až na váš desktop, přesun /var/(run|lock) a /media do tmpfs, což je aktuální i např. vzhledem k rozšiřujícím se SSD, základy dynamického firewallu nebo boxgrinder. Dříve Fedora připravovala tzv. AOS – appliance OS. Pomocí boxgrinderu si jej můžete vytvořit sami na základě textového konfiguračního souboru.

Pozornost si zaslouží i rozrůstající se ABRT (Advanced Bug Reporting Tool). Autoři si správně uvědomují, že zasílání některých hlášení je pro uživatele komplikované a obtěžující, protože v případě takového pádu gnome-shellu se provádí trasování od gnome až po jádro. K tomu je potřeba stáhnou mnohdy veliké množství ladících informací (debuginfo) – klidně i 1GB. Problémem je i to, že různí uživatelé mají různé verze balíků (protože aktualizace provádí různým tempem), mnohdy mají dokonce balíky, které už z hlavních repozitářů byly odstraněny (časté u vývojových verzí) a v takovém případě se obtížně vytváří trasování. Proto přišli s myšlenkou Retrace Serveru, který bude udržovat ladící informace a poskytovat je „předžvýkané“ ABRT. Realizace je ve svém počátku, ale je to jistě dobrý směr.

Zátka

Protože většina uživatelů slyší spíš na to, co vidí (a tak pro ně bude systemd jen zase „něco, co se rozbilo“), bude se pro většinu muset stát hlavním lákadlem obrazová prezentace Fedory v podobě Gnome 3. Je to smutné, ale je to tak, stejně jako v jiných oblastech, kde pozlátko převažuje nad obsahem (věděli jste např. že všechna zařízení ovládaná dotykem prstů na kapacitních displejích zcela znemožňují použít stylus a tedy např. jakékoli přesnější kreslení?). Zkuste si tedy s přicházející Betou Fedory 15 aspoň Gnome 3 – ať už máte kapacitní display nebo se stále ještě plazíte po stole s myší.