Hlavní navigace

Recenze Mandrake 9.2 (4)

12. 11. 2003
Doba čtení: 8 minut

Sdílet

Další díl obšírné recenze nového Mandraku. Dnes si povíme o Mandrake Control Center, o vypalování, multimédiích, závěr obstarají kruté historky o tuhnutí.

Mandrake Control Center (mcc)

Mandrake Control Center je nepochybně chlouba celé distribuce – a oprávněně. Nejenže je graficky zdařilá, ale dovoluje myší nastavit všechny důležité aspekty operačního systému. Vše, co jste zapomněli nastavit během instalace, můžete napravit v mcc. Prostředí mcc je lokalizováno, nápověda však zůstala v angličtině. Podívejme se teďmcc na zub trochu detailněji.

Konfiguraci zavaděče lze povolit automatické přihlášení vybraného uživatele, vytvořit disketu pro automatickou instalaci a změnit zavaděč na LILO nebo Grub. V Nastavení hardwaru kromě běžných položek můžete změnit i rozlišení obrazovky nebo konfigurovat televizní kartu. V položce Přípojné body najdete možnost měnit nastavení Samby, NFS i WebDAV. Máte-li v počítači dvě síťové karty, lze pomocí DrakGW sdílet internetové spojení do celé sítě. DrakConnnect má nově profily, takže teoreticky lze změnit IP adresu, bránu a DNS pouhým přepnutím profilu. V praxi to funguje velmi špatně až vůbec:

  • po každé, i opakované změně profilu se objevují hlášení o instalaci nových balíčků
  • změna profilu nezmění IP adresu
  • smazání nově vytvořeného profilu je v nabídce, ale profil nesmaže
  • nelze se vrátit k původní IP adrese
  • a jako třešnička na dortu jsou po spuštění DrakConnect hezká tlačítka v celém mcc permanentně nahrazena ošklivými.

O něco lépe se chová Průvodce nastavením DrakConnect. Ruční nastavení IP, brány a DNS v DrakConnect provést lze, profily ale zatím raději nepoužívejte.

Bezpečnostní nastavení podporují nástroje DrakSec, DrakPerm a DrakFirewall. DrakSec vás poprvé oslovuje už během instalace, kdy volíte celkový profil zabezpečení (Slabý, Standardní, Vyšší, Paranoidní). V mcc vám umožní zcela přesně doladit desítky bezpečnostních kontrol. NástrojDrakPerm plní vítanou úlohu: hromadné nastavení oprávnění souborů. Z jeho popisu jsem to neuhodl ani na páté čtení:


Chyba nebyla na mém přijímači ani v překladu, nýbrž v anglickém originále. DrakPerm je seznam pokynů pro program msec; ten se pravidelně automaticky spouští a opravuje oprávnění souborů podle těchto pokynů. Systémová nastavení obsahují vše, co se nevešlo jinam: změnu nabídek (provádí se automaticky pro všechny správce oken najednou), služby, písma (včetně importu TTF z Windows), logování, datum a čas, přidávání/odebírání uživatelů. Dokonce lze odsud zálohovat data celého disku nebo vybrané adresáře. Zálohování lze provést na síť, pásku, disk nebo na vypalovačku. Jenže když jsem to zkusil, DrakBackup oznámil@ádné zařízení nenalezeno (sic!), ačkoliv vypalování programem cdrecord funguje bezvadně. Proč, netuším, neživím a hlavně po ničem nepátrám.

Nástroje poskytované v Mandrake Control Center jsou bohaté a promyšlené. Když to tak půjde dál, hordy administrátorů školených na klik-klik-doubleclick-reboot vytlačí vysoké kněžstvo příkazového řádku z administrace mnoha linuxových serverů. Sodoma a Gomora!1

Vypalování

Moje nová vypalovačka podporuje Mount Rainier, podobně jako všechny dnes dodávané vypalovačky. Mandrake neobsahuje potřebný nástrojcdmrw a možná ani nemá podporu v jádře. Věřím, že Mount Rainier bude možné zprovoznit podle návodu v článku Mt. Rainier pod Linuxem.

Pro normální vypalování nabízí Mandrake standardně programy K3b a Nautilus, přičemž preferován je K3b. Vypalování se provádí metodou single session. Volba pro multi session disk v K3b neexistuje. Po zadání „-multi“ do seznamu parametrů pro program cdrecord v nastavení K3b sice byl vypálen multi session disk, ale zase nefunguje import sezení. Objeví se následující chyba:


To vypadá spíš jako chybný parsing logu z cdrecord než jako naprostá nefunkčnost. Nicméně na výsledku to nic nemění. Vypalování pomocí Nautilu dopadlo mnohem hůř. Použil jsem multi session disk vypálený v K3b výše popsaným trikem a přesvědčil jsem se pomoci příkazu cdrecord -msinfo, že na disk půjde vypálit další session. Nautilus po vypálení zahlásil naprostý úspěch operace, ale výsledkem byl prázdný disk! Druhé sezení vytvořené Nautilem prostě překrylo první sezení a soubor zadaný do Nautilu také nebyl zapsán. Zkusil jsem znovu zjistit stav příkazem cdrecord -msinfo, ale operační systém reagoval totálním zaseknutím (podrobněji popsaným níže). Po restartu se povedlo vypálení i v Nautilu, nicméně opět jen single session.

Netvrdím, že v Mandrake 9.2 lze multi session disk vytvořit jen na příkazovém řádku. Naopak, lze instalovat alternativní vypalovací software, který to zvládne. Výrobce se prostě rozhodoval mezi výkonnějším softwarem s obtížnějším ovládáním a méně výkonným softwarem s jednoduchým ovládáním. Proto se zřejmě rozhodl např. pro ripování CD instalovat KAudioCreator místo schopnějšího Gripu. Ale to už načínáme kapitolu

Multimédia

Je to dobře, nebo špatně, že zvukové CD nelze přehrát prostým poklepáním na ikonu CD ani klepnutím na pravé tlačítko? Mám pocit, že v distribuci typu Mandrake, kde se mnohá hardwarová zařízení automaticky objevují na ploše pouhým připojením k počítači, je to celkem anachronismus. Aspoň, že se přehrávač schová do panelu a lze jej snadno podle potřeby vyvolat. Ripování CD a převod do formátu ogg nebo mp3 zařizuje KAudioCreator. Proč Mandrake standardně raději nepoužívá vyzrálý a osvědčený Grip? Důvodů může být více. Řekl bych, že KAudioCreator sice umí méně věcí, ale o to snadněji se nastavuje a jednodušeji vypadá. A pak je to KDE aplikace; těm dává Mandrake přednost. Pro přehrávání videozáznamů Mandrake standardně používá Totem (rozhraní pro Xine). Ten si ale neporadí s každým kodekem na planetě ani nezobrazí automaticky titulky; tato zásluha patří Arpihomplayeru, jejž lze snadno doinstalovat včetně grafického rozhraní. Na kartě NVidia s neakcelerovanými open source ovladači ale mplayer žádný film nepromítne, protože nastavené rozhraní pro video out, xv, není open source ovladačem podporováno. Máte dvě možnosti: v příkazovém řádku mplayeru nařídit parametrem výstup protokolem X ( -vo x11), nebo instalovat originální ovladač NVidia, dodaný na Bonus CD. Druhé řešení je trvalejší a rozumnější. Jeden háček přesto zbude: grafické rozhraní mplayeru nedovoluje přepnout kódování titulků do „normy“ Win-1250. Takže opět zbývá buď spustit mplayer na příkazovém řádku, nebo konvertovat titulky do normy ISO-8859–2.

Zmatky pro klávesové zkratky

KDE má v Mandrake 9.2 částečně nevhodně nastavené, částečně nefunkční klávesové zkratky. Například Alt-PrintScr a Ctrl-PrintScr by měly vyvolávat snímek okna, ale nedělají to, ačkoliv jsou tyto zkratky uvedeny ve Zpřístupnění/Klávesové zkratky v Ovládacím centru KDE. Ctrl-Tab je použit pro přepínání virtuálních ploch, takže v OpenOffice s ním nelze volit mezi navrhovanými variantami slov v režimu automatického doplňování. Naproti tomu kombinace Ctrl-F10 v tomto centru uvedena není, a přesto nepracuje Ctrl-F10 v Open Office jako přepínač na zobrazení skrytých znaků. V jiných správcích oken tyto zkratky normálně fungují. Zde se tedy uživatel nevyhne ručnímu dolaďování.

Trojkombinace Ctrl-Alt-Del vyvolává v KDE nabídku Konec relace. Pokud ale zmáčknete Ctrl-Alt-Keypad Del, napíše se normální čárka. No dejme tomu. Ctrl-Esc vyvolává seznam úloh KsysGuard ve zjednodušené podobě (jen seznam bez grafů zátěže), a to je fajn. Taky se mi zamlouvá zapnutá podpora pro kernelové horké klávesy Alt-SysRq, i když jsem na ně zřejmě doplatil. O tom je následující kapitola:

Zasekáváme se…

Výhody nativního formátu OpenOffice jsem mohl nedobrovolně ocenit při psaní této recenze: Mandrake 9.2 zatuhl. Myš strnula a indikátory Caps Lock a Scroll Lock blikaly v hypnotickém rytmu přejezdu přes koleje bez závor.2 Vzpomněl jsem si nadevítiocasou kočku Alt-SysRq-S, Alt-SysRq-U, Alt-SysRq-B a s jednovteřinovými přestávkami aplikoval. Po restartu OpenOffice odmítl recenzi načíst a označil soubor jako nečitelný. Snad je devítiocasá kočka pro reiserfs nevhodná. Kdybych býval použil formát MS doc, nebylo by pomoci. Otevřený XML formát OpenOffice byla moje poslední naděje… Johanka vyslyšela mé úpění a ujala se extrakce dat z XML s totálním úspěchem. Johanka for president!

naprostému zatuhnutí se stejnými příznaky došlo tentýž den ještě dvakrát, vždy během práce s vypalovačkou střídavě pomocí programu k3b/nautilus acdrecord. Snad jsem měl smůlu. Systém, který by se hroutil třikrát denně, by dělal Linuxu hanbu. Pochopil bych, kdyby zatuhla aplikace, ale celý operační systém by měl běžnou práci vždy přežít.

… a destabilizujeme se

Destabilizovat systém lze i snadněji, např. pomocí Konqueroru. Ten je neobyčejně žravý, když má zobrazit velký obraz. Po klepnutí na obrázek typu PNG o rozměrech 4000*3000 pixelů při pouhých čtyřech barvách postupně alokoval 70MiB – a dalších 100 MiB si schramstly X WindowS! Během tohoto procesu alokace, který trval přes 60 vteřin, byl operační systém zcela nepoužitelný – myš běhala plynule, ale místo klepání na ikony jsem mohl klidně kopat do patníku. Nešlo přitom o swapování, protože mám instalováno 512MiB operační paměti a swap zůstal zcela neobsazený. Po celých mučivých 60 vteřin nefungovaly ani nouzové zkratky: Ctrl-Esc pro vyvolání správce úloh, Ctrl-Alt-Del pro odhlášení a Ctrl-Alt-Backspace pro ukončení X WindowS zůstaly bez odezvy.

Citlivé povahy prosím, aby zbytek tohoto odstavce přeskočily. Výše uvedené by se ve Windows 2000/XP, pokud vím, nestalo. There, I said it. Správce úloh lze ve WinXP/2000 kombinací Ctrl-Alt-Del promptně vyvolat. Tím nic neporovnávám ani nezevšeobecňuji, jen konstatuji konkrétní fakt. Mimochodem použité jádro bylo 2.4.22–21mdk, které tuším obsahuje patche na zlepšení latence. Samozřejmě, že Konqueror je vinen nenasytností, ale operační systém by měl u takto triviální situace svižně reagovat na požadavek zobrazení správce úloh.

Pro srovnání, před otevřením stejného obrázku pomocí programu Gimp zabíraly X WindowS 14MiB a Gimp 8 MiB, po otevření pak Gimp 40 Mib a X stále jen 14 MiB. Otevírání trvalo jen čtyři vteřiny a v celém jeho průběhu operační systém reagoval normálně.

Nepochybuji, že by to šlo nějak vyřešit, např. strategickým umístěním příkazu ulimit. Ten ale nelze v grafickém prostředí nastavit. Nejblíže řešení je applet Odchytávač chybných procesů v prostředí KDE, jenže ten umí hlídat jen CPU, nikoliv operační paměť.

Do kapitoly o stabilitě nepřímo patří i režim failsafe, dostupný ve správcích přihlášení (KDM, GDM). Tento režim má správci umožnit přihlášení, když nelze spustit žádného správce oken, ale X WindowS je v pořádku. Typicky byste jej použili třeba po neúspěšné instalaci nové verze KDE. A režim failsafe u Mandrake 9.2 nefunguje. Zobrazuje sice Konzole, ale jen cípeček levého horního rohu umístěný v pravém dolním rohu obrazovky. Podotýkám, že failsafe u Mandrake 9.0 sice nepoužívá Konzole, ale zato funguje.

Abych jen nenadával: V Mandrake 9.0 byla odporná chyba supermountu: když jste otevřeli CD-ROM disk poklepáním na ikonu na ploše (čímž se spustil Konqueror) a pak jste otevřeli další okna Konqueroru v režimu správce souborů v jiných adresářích, mechanika CD-ROM nešla otevřít, dokud jste nezavřeli všechna okna Konqeroru. Tato chyba se v Mandrake 9.2 nevyskytuje.

Pokračování příště…

CS24_early

1(Tento povzdech je míněn jako vtip. Zkušení odborníci najdou práci vždy. Nebojme se přenechat nudnou část naší práce klikátorům.)

2Mám pocit, že jsem někde četl, že tato signalizace znamená něco konkrétního. Doplňte mě v diskusi pod článkem, pokud o tom víte detaily.

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