V minulém dílu jsme ukončili delší kapitolu seriálu, která se zaměřovala hlavně na konfiguraci JWM jako desktopového prostředí pro ukázkovou Arch Linux distribuci. Na začátku dnešního dílu se vrátíme k samotnému Archu a ukážeme si několik dalších možností správy balíčků. V minulých dílech jsme si ukázali poměrně podrobně možnosti základního správce balíčků pacman. Ten umožní instalovat pouze balíčky z oficiálních repozitářů, takže jsme k němu následně doplnili jednoduchou aplikaci pro instalaci balíčků z oficiálních repozitářů i AUR – packer. Arch nám ale nabízí možností mnohem víc a tak si některé z přehledu na ArchWiki představíme – Správce balíčků.
Jako první zařadíme do výběru a představení poměrně známou aplikaci, která je dokonce v některých distribucích, založených na Archu, instalována automaticky. Jedná se o yaourt – velmi podobnou aplikaci, jako je packer, tzn. obálku (wrapper) pro pacman s rozšířením možnosti instalace balíčků z AUR. Jak ukazují dva první obrázky první galerie, jsou pro jeho instalaci potřeba dva další balíčky, jeden z AUR a druhý z oficiálního repozitáře. Celková velikost na disku je pak cca 720 kB. Práce s yaourt se trochu liší od práce s packerem. To nám ukáže třetí obrázek v první galerii. Zde jsou vidět dvě možné verze pro aktualizaci celého systému. První je stejná, jako u packeru, ale způsobí aktualizace balíčků pouze z oficiálních repozitářů. Pokud bychom chtěli aktualizovat i balíčky z AUR, musíme použít rozšířenou verzi příkazu
yaourt -Syua
To je jeden z důvodů, proč raději používám jiné správce balíčků. Při pokusech jsem také zjistil, že jsou občas problémy s instalací závislosti package-query a kromě toho má packer lepší a přehlednější výstupy do konzole. Více je možné se dozvědět vyvoláním nápovědy nebo manuálu – Yaourt manual. Další možností je vlastně fork správce packer – apacman. Čtvrtý obrázek první galerie ukazuje, že kromě samotného balíčku pro správce je nutné ještě přidat balíček wget. Pátý obrázek ukazuje dvě věci – velikost na disku je minimální (wget má asi 2.6 MB, ale může se hodit i mimo správu balíčků) a k dispozici jsou ještě dvě volitelné závislosti – apacman-deps a apacman-utils. Šestý obrázek první galerie pak jasně dokládá, že se opravdu jedná o správce „a la“ packer…
Pomocí tohoto správce si cvičně zkusíme instalovat výše uvedené závislosti. Ze sedmého obrázku v první galerii je zřejmé, že to vyžaduje docela slušné množství i objem závislostí z oficiálních repozitářů. Pokud budeme pokračovat dále, bez problémů se provede instalace prvního požadovaného balíčku, ale u druhého se objeví nečekaná a nepříjemná chybová hláška – viz osmý obrázek první galerie. Hlášení o chybě resp. nápověda k němu, může být sice trochu neobvyklé, ale přesto nám instalace neproběhne. Instalované balíčky na sobě nijak nezávisí, takže bychom klidně mohli pokračovat. Vzhledem k tomu, že se ale jedná o poměrně častou chybku v balíčcích v AUR, tak si stručně řekneme, jak z této nepříjemné situace ven:
- zapomeneme na instalaci přes správce balíčků…
- najdeme si na AUR příslušnou stránku balíčku a stáhneme si požadovaný archiv (Download snapshot)
- archiv rozbalíme a otevřeme si v novém adresáři soubor PKGBUILD
- najdeme 7. řádek souboru, kde je text
license="GPL"
- text změníme na
license=("GPL") - změnu uložíme
- v adresáři otevřeme terminál a spustíme známý příkaz pro instalaci balíčků z AUR
makepkg -ACcsis
- pak proběhne vše bez problémů a balíček se instaluje – viz devátý obrázek v první galerii
Opravu chyby v souboru PKBUILD můžeme samozřejmě provést i v rámci instalace balíčků pomocí správce. Stačí zvolit tuto možnost, kterou nám správci nabízejí – viz předchozí obrázek a volba Y na nabídku Edit apacman-utils PKGBUILD with $editor? [Y/n]. Po opravě doběhne spuštěná instalace bez problémů.
Další naší ukázkovou volbou bude správce balíčků cower. On to vlastně ani není žádný správce balíčků, protože sám sebe deklaruje jako jednoduchý nástroj pro získávání informací a stažení balíčků z AUR. Pro nás je v tuto chvíli důležitý v tom, že slouží jako nutná závislost pro další správce, které se chystáme představit. Když se balíček pokusíme instalovat (sám žádné závislosti nemá), tak narazíme na nepříjemnost s ověřením bezpečnostních klíčů – viz první obrázek ve druhé galerii. Mohli bychom samozřejmě schválit uložení nových klíčů nebo to řešit jinak, ale nebudeme si zbytečně komplikovat život. Použijeme další verzi balíčku a instalaci spustíme příkazem
apacman -S cower-git
Zde proběhne instalace bez problémů a my si můžeme zkusit spustit příkaz pro aktualizaci balíčků z AUR s pomocí nového nástroje:
cower --update
Vzhledem k tomu, že máme za sebou několik aktualizací z minulých kroků, tak se nic zajímavé nestane a neukáže. Proto přejdeme na dalšího zástupce jednoduchých správců balíčků a podíváme se na pacaur. To už je plnohodnotný správce balíčků, který pro práci s AUR používá právě před chvílí instalovaný nástroj cower. Pacaur nemá žádné závislosti (samozřejmě v aktuální sestavě distribuce, na čisté instalaci to může být jinak!) a zabere cca 280 kB na disku. Jedná se o velmi podobný nástroj, jako byly již dříve uvedené. Je zajímavý hlavně tím, že dokáže od sebe oddělit příkazy pro manipulaci pouze s oficiálními repozitáři, AUR nebo oběma druhy najednou – viz druhý obrázek druhé galerie. Další zajímavostí tohoto správce balíčků je možnost si k němu doinstalovat velmi jednoduchou GUI aplikaci Argon. Třetí obrázek ve druhé galerii ukazuje při jeho instalaci aktuálně dvě závislosti, konečný počet jsou ale čtyři. celková velikost instalovaného balíčku je cca 3 MB.
Čtvrtý obrázek druhé galerie nám napovídá, že je k dispozici nejenom samotný správce, ale také jednotlivé dílčí úlohy. Těch si ale nebudeme všímat a spustíme hlavní aplikaci. Její jednoduchý vzhled je vidět na pátém obrázku ve druhé galerii. Jak je z obrázku zřejmé, máme zde k dispozic pět základních operací – instalaci a odstranění vybraného balíčku/ů, nastavení notifikačních hlášení, zobrazení vybraných balíčků (aktuálně instalovaných v systému) a aktualizaci systému. Poslední tři uvedené operace jsou pak blíže viditelné na dalších třech obrázcích. Odstranění balíčků zkoušet nebudeme, ale pokusíme se instalovat posledního vybraného zástupce z řady správců balíčků – burgaur. Jedná se o nadstavbu nad nástrojem cower, napsanou v jazyce Python.
Devátý obrázek ve druhé galerii ukazuje zadání názvu balíčku, pak následuje kliknutí na příslušné tlačítko. Otevře se okno terminálu (VTE) a spustí se samotná instalace – viz desátý obrázek druhé galerie. Aplikace sice hlásí, že je instalace kompletní (viz předposlední obrázek ve druhé galerii), ale není to pravda, balíček ani závislosti v systému nejsou. Takže Argon opustíme s tím, že je to sice možná zajímavý nástroj, ale jeho funkčnost je poněkud omezená… Hledat řešení vzhledem k dalším možnostem nemá smysl a tak budeme pokračovat s poslední ukázkou, kterou ale budeme muset nainstalovat jinak. Burgaur slouží pouze pro manipulaci s balíčky v AUR, takže si z něj na posledním obrázku druhé galerie ukážeme pouze příkaz pro aktualizaci balíčků.
Bylo zde uvedeno několik možností, jak jednoduše a za pomoci terminálových příkazů spravovat balíčky v Arch Linuxu. Je prakticky nemožné nějak „neprůstřelně“ určit, která z variant je lepší či vhodnější. Bude to samozřejmě záviset na konkrétním uživateli, takže uvedu pouze svůj názor. Žádnou GUI aplikaci nepotřebuji a používám pouze packer. Klidně bych si dovedl představit i velmi podobný apacman, ale ostatní varianty jsou pro mne zbytečné a nezajímavé. Pokud by někdo měl chuť a čas, může samozřejmě vyzkoušet i další možnosti, které jsou uvedené v přehledu na ArchWiki. Tímto bychom mohli přehled řádkových nástrojů ukončit a přesunout se do oblasti grafických správců balíčků, ze které si představíme celkem 4 zástupce. Prvním z nich bude PacmanXG.
Jak je z odkazu zřejmé, jedná se o výtvor ruských programátorů, což samo o sobě nemusí znamenat žádný problém. Co už ale trochu větší problém je, balíček existuje pouze pro 32-bit architekturu i686. Majitelé 64-bit architektury pak bohužel mají smůlu! Nakonec se ukázalo, že mají smůlu úplně všichni… Pokud se podíváme na samotný balíček na AUR pacmanxg, tak najdeme pouze volitelné závislosti. Když se ale pokusíme balíček instalovat, objeví se jako závislost balíček ssx. Problém je v tom, že tento balíček byl označen jako zastaralý a nejde pomocí správce nainstalovat. Nejde to obejít ani pomocí přímé instalace z AUR, protože balíček se zdrojovým kódem se nenachází na očekávaném místě a nejde proto stáhnout. Nepomůže ani přímé stažení instalačního balíku novější verze aplikace ze stránek projektu. Ta při instalaci vyžaduje další závislost, která ale v žádném repozitáři Arch není (alscenter). Tím naše snažení ukončíme a podíváme se na dalšího zástupce dané skupiny.
V tomto případě se jedná o obecný nástroj pro správu balíčků, který teoreticky může fungovat ve větším množství linuxových distribucí – AppSet. V Archu je k dispozici příslušný balíček v AUR – AppSet-Qt. Jak už název balíčku napovídá, jedná se o aplikaci vytvořenou ve frameworku Qt verze 4. Tu už máme instalovanou, takže bude třeba přidat pouze jednu závislost (qtwebkit). Celková velikost je pořád ještě únosných cca 36 MB (z toho 34 MB je qtwebkit), ale samozřejmě mnohem větší, než v předchozí skupině jednoduchých správců balíčků. Na prvním obrázku ve třetí galerii je vidět, že je opět k dispozici hlavní aplikace a několik dílčích. Vzhled hlavní aplikace je pak viditelný na druhém obrázku třetí galerie. Při spuštění se nám aplikace usídlí v systémové oblasti panelu, kde s ní můžeme provést tři operace: ukázat či skrýt hlavní okno, aktuálně provést kontrolu aktualizací nebo aplikaci ukončit – viz třetí obrázek třetí galerie.
Jak je z obrázku hlavního okna patrné, můžeme zde najít 4 základní oblasti: hlavní menu s ikonami výkonných tlačítek, ikony s jednotlivými oblastmi balíčků, hlavní informační okno a spodní tři záložky. Také se můžeme všimnout, že aplikace není lokalizována do češtiny, což může být pro některé uživatele nepříjemné. Jako první je v hlavním menu položka Update pro spuštění aktualizace systému. Pokud ji použijeme a nějaké aktualizace budou k dispozici, uvidíme něco, co nám ukazuje čtvrtý obrázek třetí galerie. Aktualizace jsou viditelné i na ikoně v panelu. Pro spuštění aktualizace použijeme tlačítko Check and apply. Následně se objeví okno se seznamem aktualizovaných balíčků – viz pátý obrázek ve třetí galerii. Zde můžeme akci ukončit nebo potvrdit. Automaticky se spustí odpočet na 15s a když nic neuděláme, spustí se aktualizace, kde je prvním krokem zadání administrátorského hesla – viz šestý obrázek třetí galerie. Po zadání hesla se proces spustí a dokončí.
Pomocí ikon pro výběr skupiny balíčků se dostaneme do seznamu balíčků včetně jejich bližšího popisu – viz sedmý obrázek ve třetí galerii. Můžeme si všimnout, že se název skupiny objevil i na prostřední záložce, což znamená, že se jedná o seznam balíčků z oficiálních repozitářů. Balíčky v přehledu mají označení pro tři stavy: je dostupná aktualizace, balíček je nebo není aktuálně instalován. Balíčky je odtud možné instalovat nebo odstranit asi tak, jako je to obvyklé i u jiných grafických správců balíčků. Proto nemá cenu to zde nijak podrobněji rozebírat. Pokud si přepneme na záložku AUR, tak při prvním spuštění nevidíme žádné balíčky. Je proto nutné použít volbu List installed. Následně se objeví seznam všech balíčků, které máme v systému a pocházejí z AUR – viz osmý obrázek třetí galerie. Devátý obrázek ve třetí galerii pak ukazuje, že je možné zde také balíčky jednoduše vyhledávat.
Dalším zástupcem této skupiny může být aplikace Octopi. Podobně jako v předchozím případě se jedná o grafickou nadstavbu základního správce balíčků pacman. Pro změnu je napsaná pomocí knihoven Qt5 a pro správu balíčků z AUR používá buď yaourt nebo pacaur. Na prvním obrázku ve čtvrté galerii je vidět, že jsou třeba pouze dva balíčky jako závislosti. Celková velikost instalace je cca 27.5 MB, což je o něco méně, než v předchozím případě. Při instalaci jedné části aplikace (octopi-notifier) narazí ale správce na jeden zákeřný problém – viz druhý obrázek čtvrté galerie. Z hlášky je zřejmé, že v systému není k dispozici knihovna z KDE resp. Qt5, konkrétně pak KNotifications. Řešení nepříjemné situace se nabízí dvojí:
- nějakým způsobem doinstalovat chybějící knihovnu. To by ale nebylo jednoduché a navíc by to přineslo do systému mnoho (pro uživatele, kteří nepoužívají KDE) zbytečných závislostí
- spolehnout se na možnosti Arch Linuxu. Stačí se podívat na to, co všechno je možné k Octopi najít v AUR – viz třetí obrázek ve čtvrté galerii. Z obrázku je patrné, že se zde dané řešení nachází – balíček octopi-notifier-noknotify
Zkusíme tedy tento balíček nainstalovat jako první. Jaké je ale naše překvapení, když tento pokus dopadne úplně stejně. Je to totiž způsobeno tím, že samotný balíček nejde nainstalovat a bere si s sebou také octopi, které ale závisí na balíčku octopi–notifier, který atd… Zatím nebudeme instalovat části KDE a pokusíme se stáhnout a instalovat balíček octopi přímo z AUR. Při této příležitosti si také ukážeme něco, co jsme už zmínili – úpravu souboru PKBUILD přímo ve správci balíčků. Postup bude následující:
- z AUR stáhneme archiv pro octopi a rozbalíme ho do adresáře octopi
- z nového adresáře spustíme příkaz pro vytvoření a instalaci balíčku
makepkg -ACcis
- výsledek je bohužel opět stejný, tzn. neúspěšný!
Zkusíme proto další variantu pomocí příkazu
packer -S octopi-git
Výsledek je vidět na čtvrtém obrázku čtvrté galerie. Uděláme opět pokus a na dotaz ohledně editace souboru PKBUILD odpovíme Ne. Necháme instalaci doběhnout až k vytvoření balíčku, ale jeho instalaci zarazíme (i když dopadla dobře!). Zadáme stejný příkaz znovu a tentokrát odsouhlasíme editaci souboru PKBUILD – viz pátý obrázek ve čtvrté galerii. Na obrázku to sice vypadá zajímavě, ale velmi brzy zjistíme, že se text souboru nedá rozumně měnit a upravovat. To je samozřejmě problém, tedy přesněji byl by to problém, pokud bychom neuvedli další informaci – otevřené okno patří editoru VIM, takže musíme použít příslušné povely, abychom mohli text nějak upravit a změny uložit. Konkrétně to zde nebudeme rozebírat, pouze odkážeme na stručný přehled ovládání editoru VIM – Vi commands. Bylo by také samozřejmě možné změnit nastavení systémových proměnných a přiřadit do té příslušné jiný textový editor.
Tímto ukončíme pokusy a vrátíme se ke konečné instalaci balíčku octopi-git. Ta proběhne bez problémů i bez úprav a na šestém obrázku čtvrté galerii vidíme, že se instaloval i problematický balíček a další součásti aplikace. Sedmý obrázek ve čtvrté galerii pak ukazuje, jak vypadá aplikace po spuštění. Již na první pohled je z obrázku zřejmé, že je aplikace lokalizována do češtiny. V hlavním okně se nachází hlavní menu, pět spouštěcích ikon pro základní operace, editační pole pro vyhledávání balíčků, seznam všech balíčků s rozlišovacími ikonami, záložky s informacemi o vybraném balíčku a výběr skupin balíčků. Zajímavá je poslední záložka Použití, kde najdeme základní nápovědu k aplikaci.
Jako první ukázku si celkem logicky zvolíme aktualizaci systému. K tomu použijeme první ikonu zleva – Synchronizovat databázi (Ctrl+D). Po kliknutí na ní se ale objeví chybové hlášení – viz osmý obrázek čtvrté galerie. Naštěstí je v hlášení nápověda, takže zkusíme situaci vyřešit příkazem
packer -S gksu
Tímto příkazem instalujeme grafickou nadstavbu nad sudo pro zadání uživatelského/administrátorského hesla. Po ukončení instalace můžeme znovu zkusit první krok aktualizace a jak je vidět na devátém obrázku ve čtvrté galerii, výsledek vypadá lépe. Zadáme tedy heslo uživatele, ale očekávaný výsledek se bohužel nedostaví! Musíme tedy zadat heslo administrátora a tento výsledek jej již mnohem lepší – viz desátý obrázek čtvrté galerie. Tím se nám také zpřístupní druhá ikona – Aktualizace systému (Ctrl+U). Po jejím použití vidíme na obrázku č. 11 ve čtvrté galerii okno s přehledem nalezených aktualizací a možnostmi pro její spuštění či ukončení akce. My budeme samozřejmě pokračovat (můžeme si zde všimnout, že lokalizace není úplně na 100 %) a jsme znovu vyzvání k zadání administrátorského hesla. Po jeho úspěšném zadání se aktualizace spustí a v okně se objeví příslušné informace, viz předposlední obrázek čtvrté galerie.
Sice jsme na to zatím neupozornili, ale celou dobu je ve spodní liště k dispozici (kromě přehledu a počtu balíčků) ještě další položka – červená ikona s nějakým číslem. V předchozím kroku jsme totiž provedli aktualizaci balíčků pouze z oficiálních repozitářů. Zmíněná položka pak představuje aktualizaci balíčků z AUR pomocí aplikace pacaur. Můžeme tedy kliknout na ikonu a v okně se nám objeví informace o dostupných verzích balíčku/ů – viz poslední obrázek ve čtvrté galerii. Pokud klikneme na šipku vedle počtu dostupných aktualizací, objeví se možnost Instalovat. Pokud jí použijeme, objeví se již známý terminál, kde odsouhlasíme instalaci a ta je následně provedena. Bylo by samozřejmě možné rozebírat tuto aplikaci dále, ale raději se pustíme do té poslední, kterou jsme pro naší ukázku vybrali.
Jedná se o aplikaci Pamac, konkrétně pak je v AUR balíček pamac-aur. Ten při instalaci nevyžaduje žádné závislosti a jeho konečná velikost je tak cca 1.5 MB. Pokud bychom ale instalovali na „čistý“ stroj, je třeba přidat yaourt, aby se dosáhlo možnosti manipulace s balíčky v AUR. Jak ukazuje první obrázek v páté galerii, je opět k dispozici více jednotlivých součástí, konkrétně 6. My si pro spuštění vybereme volbu pamac-tray s tím, že nám zobrazí ikonu v systémové části panelu. Zde se nabízejí další tři volby: Správce aktualizací, Správce balíčků, Ukončit. Vše je pak vidět na druhém obrázku páté galerie. Volby asi není třeba představovat, takže si je rovnou vyzkoušíme. Vzhled aplikace pro správu aktualizací je vidět na třetím obrázku v páté galerii. Vše je aktuální, takže zde jsou vidět pouze informace o tom, že systém je aktuální a příkazy pro aktualizaci repozitářů, spuštění aktualizace, pokud nějaké jsou a ukončení aplikace. K nastavení se vrátíme ještě později.
Informaci o přítomnosti aktualizací nám dává i samotná ikona v panelu. Pokud má bílou barvu, nejsou žádné aktualizace k dispozici a informuje o tom i bublina s nápovědou po najetí kurzorem myši nad ikonu. Pokud má ikona barvu červenou, tak jsou aktualizace k dispozici a je tedy možné spustit správce aktualizací a provést je. To by asi k aktualizacím bylo vše a na čtvrtém obrázku páté galerie se můžeme podívat, jak vypadá hlavní okno správce balíčků. Jak je z obrázku patrné, jsou v horní části okna 4 možnosti operací – Aktualizovat databáze, Použít změny, Zrušit všechny plánované změny a vpravo pak čtyři volby, jak to ukazuje pátý obrázek v páté galerii. Další tři obrázky páté galerie ukazují, jak vypadají volby z menu a položek Skupiny, Stav a Repozitáře.
Poslední obrázek v páté galerii pak ukazuje, jaké správce balíčků nabízí možnosti pro manipulaci s vybraným balíčkem, které se objeví po pravém kliku myší na příslušný řádek. Bylo by možné a hlavně vhodné (považuji totiž tuto aplikaci za nejlepší variantu pro grafického správce balíčků na Archu) pokračovat v popisu práce s pamac dále. Má to ale jednu vekou komplikaci: vše se zdá být plně funkční, ale není možní spustit dialog pro nastavení aplikace. Tím pádem si ani nemůžeme ukázat, jak do pamac zařadit podporu balíčků z AUR a další důležité věci. Bohužel se mi nepodařilo najít řešení tohoto problému, a tak se obracím na čtenáře: pokud někdo má nějaký nápad, sem s ním a já ho zařadím do dalších dílů. Každopádně se k aplikaci pamac vrátíme ještě později.
V další části se budeme věnovat něčemu, co je celkem běžné při instalaci nějaké linuxové distribuce s nějakým DE. Jedná se o aplikaci Display Manager. Je to vlastně grafický správce přihlášení, který se objevuje na konci bootovacího procesu místo námi dříve používaného shellu. Na výše uvedené stránce je stručný přehled možných správců přihlášení a my si z této nabídky vybereme tři zástupce: lxdm, lightdm a sddm.
lxdm
Jak již samotný název napovídá, jedná se o správce přihlášení pro LXDE, který ale může fungovat i mimo toto prostředí: lxdm. Pro jeho instalaci stačí pouze jeden balíček
packer -S lxdm
První obrázek v šesté galerii nám ukazuje, že nejsou aktuálně potřeba žádné závislosti a konečná velikost aplikace je zanedbatelná.
lightdm
Tento správce přihlášení byl koncipován jako obecný nástroj, který je možné použít pro více desktopových prostředí: lightdm. Než se pustíme do jeho instalace, tak si na druhém obrázku šesté galerie ukážeme, jaké jsou k němu k dispozici balíčky. Tento přehled zde uvádíme hlavně proto, že u tohoto správce přihlášení nestačí instalovat pouze jeden jediný balíček, ale je nutné přidat některý ze dvou uvedených balíčků (lightdm-gtk-greeter nebo lightdm-kde-greeter). Instalace pak bude vypadat např. takto:
packer -S lightdm lightdm-gtk-greeter
Třetí obrázek v šesté galerii nám ukazuje, že kromě obou balíčků je třeba aktuálně jeden další jako závislost. Celková velikost instalaci je sice cca 10× větší, než v předchozím případě, ale pořád ještě velmi únosná.
sddm
Poslední zástupce v našem výběru je vlastně náhradou za správce kdm, který byl používán v prostředí KDE4. Nový správce je určen hlavně pro prostředí Plasma KDE5 a LXQt: sddm. Pro instalaci opět stačí jediný balíček:
packer -S sddm
Na čtvrtém obrázku šesté galerie vidíme, že nejsou třeba aktuálně žádné závislosti a instalace je větší, než obě předchozí. Tím bychom měli vše připravené a můžeme se podívat na to, jak správce přihlášení zařadit do systému a spustit tak, jak jsme si to popsali. Pro tuto činnost opět využijeme možnosti systemD s tím, že každý z námi instalovaných správců přihlášení má k dispozic svou vlastní službu. Pro správné nastavení budeme potřebovat dva po sobě jdoucí příkazy:
sudo systemctl enable lxdm[lightdm,sddm].service sudo systemctl start lxdm[lightdm,sddm].service
První z příkazů povolí start správce přihlášení při startu systému a druhý nám ho spustí z naší aktuální situace v konzole. Je také samozřejmě možné použít možnosti povolení startu správce přihlašování podle návodu na výše uvedené ArchWiki. Výsledek prvního příkazu vidíme na pátém obrázku v šesté galerii. Po spuštění druhého příkazu se opravdu objeví správce přihlašování lxdm, jak je to zřejmé ze šestého obrázku šesté galerie. Do našeho prostředí se můžeme s jeho pomocí samozřejmě okamžitě přihlásit a nebo využít možnosti pro restart stroje s tím, že se správce automaticky spustí. Po přihlášení si můžeme všimnout, že se virtuální obrazovka zmenšila na nižší rozlišení. K tomu se ještě vrátíme. Pokud bychom použili nástroje pro správu sezení a odhlásili uživatele, už se nevrátíme do konzole, ale opět do správce přihlášení.
Abychom mohli vyzkoušet dalšího správce přihlášení, musíme ten stávající zakázat. To uděláme příkazem
sudo systemctl disable lxdm.service
Následně pak můžeme povolit a spustit další ukázku
sudo systemctl enable lightdm.service sudo systemctl start lightdm.service
Na sedmém obrázku v šesté galerii vidíme, jak vypadá hlavní okno správce přihlašování lightdm. Opět můžeme vyzkoušet okamžité přihlášení nebo restart virtuálního stroje. Úplně stejným způsobem můžeme zakázat lightdm a povolit a nastartovat sddm. Pokud ale start správce provedeme, bohužel nenastartuje a zůstane nám blikající kurzor na černé obrazovce. Nic ale není ztraceno: stačí restartovat virtuální nebo fyzický stroj pomocí „vypínače“ a při novém startu stroje se již správce přihlášení objeví – viz osmý obrázek šesté galerie.
Nyní se ještě vrátíme k rozlišení obrazovky. Na fyzickém stroji to nebude problém, ale je dobře, že jsme si toho na stroji virtuálním mohli všimnout. Nejedná se totiž o jedinou rozdílnost oproti dříve používanému startu z konzole. Pokud si pozornější experimentátoři všimli, kromě jiného rozlišení nám chybí také ikona automaticky spuštěné aplikace ClipIt. To je oboje dáno tím, že při startu sezení pomocí správce přihlášení se ignoruje obsah souboru $HOME/.xinitrc. Náprava je naštěstí poměrně jednoduchá a spočívá ve třech krocích:
- zkopírujeme si obsah souboru $HOME/.xinitrc do nového souboru příkazem
cp .xinitrc .Xprofile
- nový soubor otevřeme v textovém editoru a smažeme poslední řádek se startem WM
exec jwm
- změny uložíme a restartujeme stroj
Po novém přihlášení přes správce je již vše v pořádku, rozlišení je nastavené a správce schránky si to také pohodlně trůní v systémové části panelu. Vzhledem k tomu, že se část našeho seriálu nezadržitelně blíží ke konci, tak využijeme předchozí instalaci a spuštění správce přihlášení k poslední ukázce. Ta bude spočívat v tom, že si nainstalujeme dvě další prostředí a porovnáme jejich nároky na systémové prostředky s JWM. Je samozřejmě složité nějaká prostředí vybrat, ale nakonec bylo rozhodnuto použít celkem kompletní, jednoduché a funkční DE Mate a můj oblíbený dlaždicový WM Awesome.
Pro instalaci Mate použijeme dvě skupiny, které nám Arch nabízí, aby byla konfigurace DE skoro kompletní. Příkaz vypadá následovně:
packer -S mate mate-extra
Jak ukazuje první obrázek v sedmé galerii, je rozsah instalace na naše dosavadní poměry absolutně závratný… Ale obecně řečeno to na docela kompletní prostředí včetně sady nástrojů není vůbec špatné! Druhé prostředí se instaluje pomocí pouze jednoho balíčku
packer -S awesome
Jak vidíme na druhém obrázku sedmé galerii, jsou potřeba 4 balíčky závislostí a celková velikost instalace je opět v dimenzích, na které jsme byli doposud zvyklí. Po ukončení instalace provedeme restart stroje a podíváme se na spuštěného správce přihlášení. Třetí obrázek v sedmé galerie nám jednoznačně ukazuje, že všechna instalovaná prostředí jsou k dispozici. Námi původně využívané a pracně nastavené JWM je zde jako defaultní, takže si ho spustíme. Abychom mohli nějak porovnat spotřebu systémových prostředků pro jednotlivá prostředí, použijeme tři aplikace, které jsme kdysi dávno nainstalovali: Gnome System Monitor, LXTask, HTop. Zaměřovat se budeme hlavně na spotřebu paměti, kterou nám tyto nástroje ukazují.
Na čtvrtém obrázku sedmé galerie vidíme situaci u JWM. Z obrázku je také možné získat celkem nepříjemnou informaci: každý z nástrojů ukazuje u spotřeby paměti jinou hodnotu a to s dosti velkým rozdílem! Krajní hodnoty se liší o 70 %!!! S tím se ale nedá nic dělat, obecně ani konkrétně nám to nevadí, protože srovnání je stejně relativní. Proto ukončíme JWM, restartujeme stroj, aby byly stejné podmínky a spustíme Mate. Než se pustíme do srovnání s předchozím prostředím, tak se podíváme na jedno trochu jiné. V minulé kapitole jsme instalovali celkem tři grafické správce balíčků. Mate nám je automaticky spustilo a všechny jejich ikony jsou v systémové oblasti panelu viditelné. Pátý obrázek v sedmé galerii nám ukazuje, jak je aplikace AppSet-Qt násobně náročná na spotřebu paměti proti srovnatelným nástrojům Octopi a Pamac. Aby bylo srovnání alespoň trochu logické, ukončíme AppSet-Qt a Octopi (Pamac ponecháme jako celkem logickou součást kompletního DE) a spustíme stejné systémové nástroje. Na šestém obrázku sedmé galerie je pak viditelný stav systémových prostředků pro prostředí Mate. Jenom krátké upozornění: v tomto případě je možné u aplikace Pamac volbu pro nastavení bez problémů otevřít. Takže je jasné, že problém nesouvisí se samotnou aplikací, ale s prostředím. Bližší představení necháme na později.
Nakonec si spustíme Awesome (nebudeme ho nijak konfigurovat, ale ponecháme ho v „továrním“ nastavení). Aby si to případní zájemci mohli skutečně vyzkoušet, tak uvedeme dvě základní klávesové zkratky pro naše účely:
- Win + P = spuštění jednoduchého spouštěče aplikací, kde se hledaná aplikace vybírá postupným psaním jednotlivých znaků
- Win + Shift + Q = ukončení Awesome a návrat do správce přihlášení
Na posledním obrázku v sedmé galerii vidíme stav systémových prostředků v posledním případě vybraného prostředí. Abychom ještě trochu více ukázali relativní rozdíly ve spotřebě paměti pro jednotlivá prostředí, na konec dnešního dílu dáme tabulku, která si bere hodnoty z aplikaceHTop.
| Prostředí | Relativní spotřeba RAM |
|---|---|
| JWM | 100 % |
| Awesome | 109 % |
| Mate | 161 % |
Dnešní díl jsme věnovali bližšímu popisu dalších terminálových i grafických správců balíčků a aktualizací. Další kapitolou pak byl stručný popis vybraných správců přihlášení včetně úpravy parametrů systému při spuštění tímto způsobem. Nakonec jsme provedli rychlé a stručné porovnání třech různých uživatelských prostředí s ohledem na spotřebu systémových prostředků. Od příštího dílu se pustíme do další části našeho seriálu a postupně si představíme několik zajímavých distribucí, které vycházejí z Arch Linuxu..
