Jiří Eischmann (kromě jiného i významný autor článků v magazínu LinuxEXPRES) pracuje pro distribuci Fedora jako vývojový manager, proto se zaměřil v přednášce na řešení problémů linuxového desktopu z pohledu Fedory, resp. projektu Fedora Workstation, který je cílen právě na desktopové uživatele. A o jaké problémy jde?
Upgrade systému a aplikací
V současnosti tvoří systém a uživatelský software (jednotlivé aplikace) jednolitý softwarový blok, který se distribuuje dohromady. Znamená to enormní zátěž na vývojáře, kteří musí kalkulovat s velkým množstvím možných konfigurací. Proto dochází k tomu, že rozličné aplikace se nestihnou otestovat v rámci cyklů, ve kterých se jednotlivé distribuce vydávají. To znamená, že se v dané distribuci objevuje software, jehož kompatibilita nebyla otestována s danou verzí distra. Pak jen mohou vývojáři doufat, že „to vyjde“.
Snímek z prezentace Jiřího Eischmanna (CC BY-SA 3.0)
Snahou je oddělit software pro systém a aplikační software. Díky tomu by vývojáři mohl prezentovat přesně určenou a definovanou množinu balíčků. Znamená to tedy, že by se systém aktualizoval jako celek, což by mělo vést k lepší testovatelnosti systému. Nebude se totiž pak již vyskytovat v blíže neurčené modifikaci předem neurčených balíčků, které distribuce podporuje. Tento přístup by se měl odrazit v lepší stabilitě systému. Aplikace se pak budou aktualizovat formou rolling release.
Důraz je a bude kladen na automatické testování, například prostřednictvím nástroje openQA společnosti OpenSUSE, s níž Fedora spolupracuje, tak, aby se ulevilo dobrovolníkům-testerům.
O smyslu a principu openQA si můžete přečíst také v článku o openSUSE Leap (z přednášky Tomáše Chvátala na LinuxDays).
Dalším možným přístupem jsou tzv. synchronní aktualizace. Předpokladem je, že by se v pravidelném intervalu, např. 1 měsíc, prováděla aktualizace celého softwarového repozitáře a zasílala uživatelům. Pochopitelně kritické aktualizace by se vydávaly okamžitě.
Výrazně se rovněž zapracovalo (zásluha firmy Red Hat) na podpoře firmwaru pro hardware. Firma je připravena poskytovat úložiště firmwaru i pro jiné distribuce. Podmínkou samozřejmě je, že výrobce daného hardwaru spolupracuje. Takto se jednoduše odstraní závislost na Windows při aktualizacích firmwaru.
Správa napájení
Někteří uživatelé si mohli všimnout, že jejich zařízení s nainstalovaným Linuxem spotřebovává více proudu, než když na něm mají jiný systém, tedy napájení vydrží kratší čas. Není to důsledek energetické nenasytnosti Linuxu, ale jeho nevhodného výchozího nastavení spotřeby energie.
Systém by již od výchozího nastavení měl být spořivý a zapínat určité režimy spotřeby bez nutnosti interakce s uživatelem. Nejlépe ve spolupráci se senzory intenzity světla. Úsporný režim bez nutnosti interakce s uživatelem se ve Fedoře realizuje prostřednictvím aplikace gnome-batery-bench. K úspoře energie nicméně přispívá i vhodná volba používaných aplikací.
Společný vzhled i chování GNOME a KDE aplikací
Letitý problém – linuxové desktopy znamenají pro uživatele výhodu výběru prostředí, které jim vyhovuje, ale pro vývojáře znamená kopu starostí navíc. Pokud vyvíjí nějakou aplikaci, musí se rozhodnout, zda ji napíše v GtK+ anebo v Qt. Tedy zda bude portována na GNOME nebo KDE.
Jiří Eischmann při přednášce na LinuxDays
Tento problém řeší ve Fedoře snahou integrovat obě prostředí mezi sebou – ne snad vyrobit jedno prostředí, které by bylo hybridem KDE a GNOME, ale vylepšit integraci aplikací napsaných pro jedno prostředí v druhém prostředí. Konkrétně lze ve Fedoře najít světlý motiv Adwaita portovaný na Qt a v budoucnu bude i tmavý. Dalším výrazným příspěvkem je synchronizace nastavení mezi jednotlivými prostředími. Týká se to např. klávesových zkratek.
Uživatelé si mohli všimnout, že pokud definují v nějakém desktopu GNOME klávesové zkratky pro dané prostředí, budou stejné ve všech dalších desktopech GNOME, které si nainstalují; stačí je tedy definovat jednou. Snahou je, aby se toto nastavení (nejen zkratek) dokázal vyexportovat a přenést do dalšího prostředí. Týká se to i různých vstupních zařízení.
Jak naložit se softwarem
Zajímavou otázkou je, jak zajistit na jedné straně snadnější výrobu softwaru pro vývojáře a na straně druhé dostatečné zabezpečení pro uživatele. Výroba softwaru je náročná, protože:
- v Linuxu se uplatňují různé balíčkovací systémy,
- používají se různé verze knihoven,
- linuxové distribuce se velmi rychle mění, a vývojář tak neví, kterou má brát jako referenční a kontrolovat kompatibilitu pro každou další verzi distra.
Původní unixový koncept, který spočíval na myšlence, že je třeba software ochránit před zásahem uživatelů, na osobních počítačích neplatí. Ve světě malwaru je to naopak, uživatel by měl být chráněn před potenciálně škodlivým softwarem. Roste tedy přesvědčení, že by aplikace neměly mít přístup do celého systému, tedy aby se jim v principu nedůvěřovalo a přístup do systému by měly mít co nejmenší.
O přednášku byl velký zájem, sedělo se i na schodech
Tento problém řeší tzv. sandboxované aplikace, které by kromě zvýšené bezpečnosti měly vývojářům umožnit jednodušší distribuci softwaru uživatelům. Runtime, v němž aplikace běží, se připojuje do adresáře /usr. Další komponentou je aplikační bundle, který obsahuje metadata, soubory aplikace a seznam exportovaných souborů (patří sem např. ikona nebo spouštěč). Pro build a debugger je zde SDK runtime.
A poslední, velmi důležitou komponentou je nástroj pro stahování, instalaci a vlastní správu aplikací Xdg-app. Pokud má dané distro k dispozici všechny potřebné technologie, bude taková sandboxovaná aplikace nezávislá na distribuci. To samozřejmě znamená, že se bude vyskytovat v jedné podobě. Určitou nevýhodou tohoto přístupu je obtížnější aktualizace a také větší velikost souborů, potřebných pro instalaci.
Nicméně je to jen alternativa oproti balíčkovacímu systému, který by měl běžet i nadále. Rozlišit jednotlivé aplikace by uživatel měl na základě pojmenování spouštěče (příp. jinak).
Problémy okenního správce X a náhrada v podobě Waylandu
Kompozitní okenní správce X trpí leckterými neduhy, které by mělo vyřešit nasazení Waylandu:
- Výrazně vyšší stabilita Waylandu oproti X.
- Podpora pro přepínání mezi grafickými kartami za běhu – pokud jsou v počítači dvě grafické karty, mezi kterými se chce uživatel přepojit, musí se odhlásit, používá-li S manager. Ve Waylandu toto odpadá a je možné nejen přepínat grafické karty, ale i vykreslovací prostředí (implementace OpenGL).
- Jednodušší možnost škálování (nejen v celých číslech, ale i desetinově).
Architektura Waylandu (Javier Cantero, CC BY-SA 4.0)
Zároveň se pracuje na podpoře HiDPI desktopů tak, aby byly rozumně škálovatelné při synchronním zobrazení na různých zařízeních s různým stupněm rozlišení.
Sdílení nastavení desktopu s dalšími uživateli
V korporátní sféře a všude tam, kde je třeba nastavit desktop pro mnoho uživatelů současně, dosud neexistoval rozumný nástroj. Nástroj Fleet desktop má tento problém řešit. Jednoduše umožňuje vytvořit různé profily nastavení desktopu a tyto profily pak aplikovat (nasdílet) na neomezený počet desktopových stanic. Distribuce bude probíhat zřejmě přes LDAP.
