Red Hat Linux 10 Beta (Severn)

Milan Keršláger

Minulý týden v pondělí (21. července 2003) byla uvolněna nová beta Red Hat Linuxu, která nese označení Severn. Pojďme se podívat, co je v ní nového a co nám přináší. Protože má firma Red Hat, Inc. na vývoj Linuxu velký vliv, bude to jistě zajímavé i pro uživatele jiných distribucí. Článek je spíše souhrnem zkušeností a příručkou, než recenzí.

Úvod

Nová betaverze Red Hat Linuxu s kódovým označením Severn, která byla zveřejněna v pondělí 21. července 2003 představuje novinky, které pravděpodobně uvidíme i na podzim v ostré verzi. I když je betaverze funkční, nedoporučuje se ji jako obvykle používat na místech, na kterých vám záleží. Kromě potíží s některou komponentou může být problémem i neexistence bezpečnostních aktualizací, které by se mohly do vydání ostré verze objevit (v jarní betě to byl například případ Samby a jádra s ptrace problémem).

I když lze vývoj již velmi dlouho sledovat průběžně i v distribuci Raw Hide, která je aktualizována téměř denně, je Severn pro nadcházející ostrou verzi prvním uceleným souborem, který by měl jít snadno nainstalovat a jsou k dispozici ISO soubory. Adresy s RPM balíčky a ISO soubory můžete nalézt na níže uvedených adresách.

Protože v poslední době proběhlo několik plamenných diskusí o možnosti šíření a vypalování ISO souborů s Red Hat Linuxem, pokusím se stručně shrnout pravidla, kterými je případný "palič" vázán. Kvůli ochraně ochranných známek je v podstatě omezeno jen pálení za úplatu komerčními subjekty, protože by tak firma Red Hat, Inc. přišla o podíl na zisku z použití jejich vlastních ochranných známek (komerční firma může přepalovat za úplatu, ale musela by uzavřít s firmou Red Hat licenční smlouvu nebo odstranit z distribuce loga s ochrannými známkami Red Hat Linuxu a použít pro takovou distribuci jiný název). Pokud budete ISO soubor pálit pro svoji potřebu nebo svému příteli, není v tom žádný problém. Podrobnosti i s příklady naleznete na adrese http://www.redhat.com/about/corporate/trademark/guidelines/.

Instalace

Pro instalaci budete potřebovat první 3 ISO soubory (severn-i386-disc1.isosevern-i386-disc3.iso). Můžete je buď vypálit na CD, umístit na HDD, FTP, NFS nebo HTTP server. Nejjednodušší je instalaci spustit zavedením systému z 1. CD. Pokud nemáte všechny ISO soubory vypáleny, zadejte při startu parametr (instalační program se zeptá, odkud budete instalovat - jestli z HDD, NFS, FTP, HTTP nebo z CD):

linux askmethod

Druhou možností je použít startovací diskety z adresáře /images. Kvůli nedostatku místa je na první disketě pouze ovladač pro IDE disk a CD-ROM. Budete-li chtít distribuci instalovat přes síť (třeba s ISO obrazy umístěnými na NFS serveru), budete potřebovat doplňující disketu s ovladači síťových karet (drvnet.img). Instalujete-li na (případně z) SCSI nebo USB disků, budete potřebovat disketu s ovladači blokových zařízení (drvblock.img). Pro obsluhu PCMCIA zařízení je k dispozici obraz diskety pcmciadd.img.

Stejně jako v předchozí verzi je k dispozici ISO obraz boot.iso, který obsahuje všechny ovladače a může být vypálen i na malý CD disk. Podrobný návod najdete v dokumentaci k předchozím verzím Red Hat Linuxu, například na adresách:

Hardwarové nároky

Následující tabulka ukazuje, jaké jsou minimální HW nároky pro instalační program. Pod těmito údaji se skrývá i fakt, že budete-li mít alespoň tuto konfiguraci, bude možné systém nějakým způsobem používat. Neradujte se však předčasně, protože některé aplikace mohou mít pro pohodlné používání nároky o něco vyšší (třeba OpenOffice). Naopak systém můžete provozovat i na nižší konfiguraci, pokud vypnete všechny nepotřebné subsystémy (nejčastější využití pro firewally a routery).

Minimální požadavky na hardware
Textový režimGrafický režim
Procesor Pentium 200MHz Pentium II 400MHz
Paměť RAM 64MB 128MB, doporučeno 192MB

Kromě procesoru a paměti potřebujeme také prostor na pevném disku. Ani tato verze bohužel neumožňuje v rámci instalačního programu přeorganizovat rozdělení disku tak, abychom uvolnili místo pro Linux. Buď si tedy volný prostor musíte připravit předem nebo se smířit s tím, že program parted (ve verzi 1.6.3) budete muset spustit ručně (z příkazového řádku ještě před rozdělením disku v instalačním programu). Hodnoty uvedené v tabulce jsou minimální a není v nich zahrnuto místo, které budete potřebovat pro svoje data nebo další používané programy.

Požadavky na volné místo na HDD
Potřebné místo na HDD
Minimální instalace475MB
Server850MB
Osobní stanice1.7GB
Pracovní stanice2.1GB
Vše5GB

Instalátor (Anaconda)

Samotný instalační program nedoznal žádných výrazných změn. Zachována zůstala možnost testovat instalační CD, což pomáhá správně rozpoznat vadná média a vyloučit tak chybu instalačního programu v případě chybně vypálených CD. Nově byla naprogramována podpora grafické instalace při využití FTP a HTTP protokolu, ovšem je potřeba při startu instalace použít parametr "graphical". Při spuštění instalačního programu z CD není vyžadována další paměť, jinak je potřeba dalších asi 64MB paměti pro instalační obraz. V případě instalace z HDD není potřeba další paměť, protože nové rozhraní jádra umožňuje změnit tabulku rozdělení disku i v případě, že je nedotčený oddíl připojen.

Nově je také k dispozici instalace s využitím VNC, kdy lze použít jinou stanici pro zobrazení grafického instalačního programu (vhodné např. pro instalaci Linuxu na počítač v racku bez nutnosti připojovat monitor). Podrobnosti pro předání parametrů viz RELEASE-NOTES.

Změna modelu vývoje distribuce

Asi nejzajímavější změnou, kterou vydání Severnu přináší, je změna modelu vývoje distribuce na otevřený.

Do dnešní doby měly všechny komerčně vyvíjené distribuce uzavřený model vývoje, což znamená, že firma najala team lidí, který uvnitř firmy vyvíjí novou verzi distribuce. Pokud se nemýlím, tak z komerčních distribucí snad pouze Red Hat a Mandrake vydávaly pravidelně veřejné beta verze, které předcházely oficiálnímu vydání "ostré" verze. Všechny distribuce pak mají více či méně početné skupiny beta testerů, kteří mají k tomuto uzavřenému modelu vývoje přístup a hlásí všechny problémy vývojářům.

Tzv. beta teamy jsou velmi důležité i pro tvůrce (ať už komerční či nekomerční) programů, které se v Linuxu používají, protože jedině tak mohou jejich vývojáři své produkty předem otestovat a případně opravit tak, aby fungovaly již v okamžiku vydání nové verze distribuce (např. VMware). Do těchto teamů může obvykle vstoupit kdokoliv, nicméně musí být buď ve správný okamžik na správném místě (tj. musíte si třeba všimnout náboru nových testerů) nebo musí zastupovat nějakou firmu (např. v Beta teamu Red Hatu jsou zástupci IBM, VMware a podobně), případně významnou skupinu vývojářů.

Stejně to funguje i u jiných produktů (např. MS Windows, MS Office, atd.), kde ovšem musíte třeba za členství platit (resp. platit za nadstandardní "péči" vývojářů).

Jak to tedy nyní bude u vývoje distribuce Red Hat? Všechny beta verze budou veřejné a veřejný bude i časový plán vývoje včetně vydání ostré verze (což v minulosti firma Red Hat nikdy nedělala). Kromě toho bude komukoliv umožněno podílet se na vývoji samotné distribuce, pokud splní určité podmínky. Tyto podmínky nejsou zatím pevně dány, nicméně se předpokládá, že kromě dobře udělaného balíčku bude muset být zřejmé, že dotyčný bude balíček schopen v rámci distribuce i udržovat.

Časový plán vydání distribuce Red Hat 10 (Cambridge)
Datum Událost
21. července 2003 Vydání Beta 1
8. srpna 2003 Konec zveřejňování aktualizací (pouze významné chyby)
18. srpna 2003 Vydání Beta 2
15. září 2003 Vydání Beta 3
6. října 2003 Red Hat 10 (Cambridge)

Kromě zveřejnění časového plánu byl také oznámen záměr pro vydání následující verze, která bude závislá na vydání jádra 2.6. Pokud to bude dříve, než za půl roku, vyjde následující distribuce dříve. Pokud by to mělo být později, obejde se i následující verze distribuce bez nového jádra.

Otevření vývoje má za cíl zejména umožnit do distribuce integrovat programy a balíčky, které jsou kvalitní a které již jsou na Webu vystaveny a jejich tvůrci pravidelně vydávají nové verze pro Red Hat Linux (např. http://freshrpms.net, http://www.fedora.us, http://atrpms.physik.fu-berlin.de). Firma Red Hat tak bude moci rozšířit záběr distribuce, aniž by dramatickým způsobem rozšiřovala svůj team placených vývojářů. Bude se tak moci zaměřit na QA (Quality Assurance, čili na záruku kvality produktu) a na Enterprise řešení (Enterprise Linux tvoří dnes majoritu příjmů firmy Red Hat, nicméně tato "velká" verze je a bude stále vyvíjena nad volně šiřitelnou verzí).

Pro podporu otevřeného vývoje byly zřízeny stránky http://rhl.redhat.com, kde najdete další informace. Dlužno dodat, že otevřený model vývoje zatím nemá pevně stanovená pravidla, protože o nich teprve bude probíhat diskuse (zřejmě převážně v rhl-devel-list listu, viz tabulka níže).

Kromě vytvoření speciálních stránek vznikly i nové konference, které již nejsou pojmenovány podle kódových jmen jednotlivých distribucí. Pokud se chcete do některé z nich přihlásit, pošlete mail se slovem subscribe v subjektu (věci) na adresu <jméno_listu>-request, kde jméno listu je jedno z následujících:

Elektronické konference pro vývoj distribuce
Jméno listuElektronická adresaPopis
rhl-list rhl-list@redhat.com Pro uživatele distribucí Red Hat Linuxu
rhl-beta-list rhl-beta-list@redhat.com Pro testery betaverzí Red Hat Linuxu
rhl-devel-list rhl-devel-list@redhat.com List pro vývojáře a vývoj distribuce
rhl-docs-list rhl-docs-list@redhat.com Pro účastníky dokumentačního projektu

Diskuse mohou probíhat i na IRC, více informací viz RELEASE-NOTES. Archivy listů najdete na již zmíněné adrese http://rhl.redhat.com.

Zásadní změny v jádře Linuxu

Jednoznačně největší význam mají pro novou verzi distribuce změny v jádře Linuxu, které se stanou součástí nové verze Red Hat Linuxu. Je to způsobeno jednak tím, že pro firmu Red Hat, Inc. pracuje Alan Cox, který dokáže zajímavé věci efektivně prosadit do oficiálního jádra, které vydává Linus Torvalds (resp. Marcelo Tosatti v případě posledních jader řady 2.4.x), jednak také tím, že díky majoritnímu podílu na trhu Linuxu se bere vše, co obsahuje distribuce Red Hat, víceméně za standard (a všechny ostatní distribuce to dříve či později budou obsahovat také) a konečně jednak také proto, že pokud se něco objeví v distribuci Red Hat, tak je to vyzkoušená a stabilní věc. Firma Red Hat totiž poskytuje na všechny součásti distribuce podporu a žádné součásti z této podpory nevyjímá (proto v ní některé polofunkční, i když třeba velmi zajímavé věci, nejsou obsaženy). Na tomto místě je však potřeba podotknout, že některé zde zmíněné novinky nemusí ve finální verzi být (jak už se několikrát stalo např. u podpory ACL, ACPI, HTree atd.), protože bude odhalen problém, který se nepodaří do rozhodujícího okamžiku vyřešit.

ACPI

Zřejmě nejzásadnější novinkou je zařazení ACPI (Advanced Configuration and Power Interface, viz http://www.acpi.info) do jádra. Rozhraní ACPI je nástupcem APM (Advanced Power Managment) a řeší jeho nedostatky (podpora více procesorů, jednoznačná definice zda řízení provádí BIOS nebo jádro, integrace doplňujících vlastností atp.). Bohužel však existuje norma ACPI a tzv. Redmond-ACPI, tj. implementace ACPI v produktech od Microsoftu. Problém je v tom, že implementace od Microsoftu obsahuje chyby, které Microsoft neřeší vydáním oprav, ale tvůrci BIOSů tím, že upravují své BIOSy tak, aby fungovaly s Windows, i když se tím odchylují od normy (pochopitelně, zákazníci požadující funkční Windows tvoří většinu jejich zákazníků).

Bez podpory ACPI není jádro Linuxu schopno si rozumět s integrovaným HW na mnoha dnes vyráběných počítačích (zejména notebooky, např. na mém Compaqu jádro bez ACPI nenalezne IDE disk ani CD-ROM). Tímto krokem se Linuxu skutečně otevře cesta na desktopy (kromě toho, že by se mohlo stát, že se nerozeběhne ani na novém HW, který je určen pro dosavadní nasazení na PC).

Dlužno dodat, že použité ACPI implementuje pouze rozpoznání zařízení, ale neimplementuje uspání počítače (tzv. sleep a stand-by režimy). Nicméně by pomocí něj mělo být možné zjistit stav baterií, řídit snižování spotřeby a sledovat teplotu CPU. Zde jsem však narazil na problém, protože applet v panelu Gnome pro zobrazování stavu baterií havaruje v případě, pokud před jeho spuštěním nejsou ručně zavedeny moduly battery a ac. Problémy by se mohly vyskytnout i u aplikací, které čtou informace pouze z APM.

Pokud budete mít s ACPI na svém počítači problémy nebo jen chcete dát přednost starému APM (které může ve vašem případě poskytovat mnohem širší možnosti), stačí jádru při startu předat parametr acpi=off. Oba systémy totiž nemohou být aktivní zároveň.

Aby toho nebylo málo, je jádro s ACPI kódem tak velké, že se nevejde na disketu, takže bootovací diskety nelze na počítačích vyžadujících ACPI použít a je nutné je při startu instalace nebo pro spuštění záchranného (rescue) režimu nahradit bootem z CD-ROM.

Zařazení ACPI do jádra je krok je veskrze pozitivní a dá se říci, že přichází na poslední chvíli. Jiné distribuce Linuxu obsahovaly podporu ACPI již dříve, ale je smutné, že ho distributoři nebyli do dnešního dne schopni uvést do takového stavu, aby bylo přijato i do oficiálního Linusova jádra. Dnes je sice již ACPI (v podobě jak je použito v této betaverzi) v Alanově -ac záplatách a díky změně Marcelova postoje i v jeho 2.4.22-pre1 (takže bude s největší pravděpodobností zahrnuto i v nadcházející verzi 2.4.22), nicméně zatím stále na některých počítačích nemusí fungovat správně a zbývá některé věci dodělat.

Exec-Shield

Jednou z největších nectností platformy x86 je nemožnost komplexní a jemně nastavitelné ochrany paměti. Důvodem je původní HW implementace Intelu na procesoru i386, kde jsou spojeny dva příznaky ochrany paměti do jednoho (read or execute). Z toho těží drtivá většina exploitů (tj. způsobů, jak využít chyby v programu k získání vyšších práv nebo přístupu k chráněným zdrojům počítače), které přepíší zásobník chybně napsaného programu a uloží tak na něj neautorizovaný kód, který je posléze vykonán (a tím dojde ke spuštění neautorizovaného kódu, tj. programu, který nenapsal tvůrce chybného programu). Základním textem, který se těmito typy útoků zabývá, je článek Smashing The Stack For Fun And Profit, viz: http://www.insecure.org/stf/smashstack.txt.

Zhruba 5 let již existují různé záplaty do jádra Linuxu, které tento nejběžnější problém odstraňovaly znemožněním spuštění kódu na zásobníku (non-exec stack patch). V samotném jádře Linuxu však tyto úpravy zahrnuty nejsou. Důvodem je, že díky omezení architektury procesorů rodiny x86 lze útok provést jinak a ochranu tak obejít (jen je to obtížnější). Proto Linus vždy podobné záplaty odmítl zařadit.

Je otázka, zda podobný efekt nebude mít i zařazení Exec-shieldu do jádra Red Hat Linuxu. V každém případě tato úprava povede k eliminaci nejběžnějších exploitů, kdy lze neoprávněně získat například práva uživatele root (administrátora systému). Konečným řešením problémů to však zřejmě nebude, i když je dnes již možný přechod na 64 bitovou architekturu Itania nebo procesorů od AMD (jenže x86 ELF ABI označuje zásobník jako spustitelný i na architekturách, které ochranu umožňují a zde se otevírá prostor s tím něco udělat). Exec-Shield napsal Ingo Molnar, podrobnější informace naleznete na těchto adresách:

Stejným problémem trpí i produkty Microsoftu, avšak zatímco v Linuxu je největší vlna odstraňování těchto problémů již minulostí a dnes se objevují řádově komplikovanější opravy (zneužití souběhu (race condition) - např. problém ptrace v jádře Linuxu), je u Windows problém tyto jednoduché díry bez zdrojových kódů jádra a dalších programů objevit. Nicméně to není nemožné, jak dokazují zveřejňování těchto chyb různými skupinami po celém světě, které je nacházejí zkoumáním a trasování binárního kódu (viz třeba exploity a poslední security updaty od Microsoftu). V tomto ohledu je tedy zřejmě Linux napřed.

Standardně je Exec-shield v jádře distribuce zapnut a jednotlivé programy ho mohou vypnout, pokud jsou napsány tak, že spustitelný zásobník potřebují (takže lze programy používající tuto nestandardní techniku opravovat postupně). Zápisem do /proc lze Exec-shield vypnout, zapnout bez výjimky, zapínat jen pro jednotlivé programy nebo naopak pro jednotlivé programy vypínat (možnost individuálního vypnutí nebo zapnutí ochrany jednotlivými programy není podle RELEASE-NOTES zatím implementována, nicméně nástroj chstk je již v distribuci přítomen). Navíc je v popisu hodnot nastavení Exec-shieldu v RELEASE-NOTES drobná chyba (hodnota 3 má být always enabled).

Vypnutí automatického zavádění modulů do jádra

Zavedení neautorizovaného modulu nebo modulu s chybou může být pro některé administrátory nepřijatelné riziko. Proto jádro poskytuje možnost zavedení modulu vypnout a možnost zavádět moduly lze obnovit pouze restartem systému. K tomu slouží příkaz:

echo off > /proc/modules

Podpora laptopů

Jádro lze přepnout do režimu, kdy seskupuje diskové operace a umožňuje tak využít možnosti usínání disků pro úsporu baterií přenosných počítačů (disky zůstávají dostatečnou dobu v klidu). Úsporný režim lze aktivovat zápisem čísla 1 a deaktivovat zápisem čísla 0 do /proc:

echo 1 > /proc/sys/vm/laptop_mode
echo 0 > /proc/sys/vm/laptop_mode

APM skripty aktivují laptop režim automaticky při přechodu na napájení bateriemi.

Novinky a chyby v systému

Grafický boot

Při startu systému asi překvapí jednoduchý grafický teploměr. I přes to, že jiné distribuce tuto vlastnost mají již hodně dlouho, Red Hat ji dlouho nepoužíval. Dnes najdete v distribuci balíček rhgb, který se o ni stará. Pokud systém obsahuje jádrem podporovanou grafickou kartu, měl by být grafický boot aktivní od začátku (tj. už v okamžiku, kdy se zavádí jádro), jinak až v okamžiku spuštění startovacích skriptů (jako třeba na mém Compaq notebooku).

Pokud někomu grafika skrývající bootovací informace vadí, může předat jádru parametr nogui. Pokud chcete potlačit grafický teploměr během zpracování startovacích skriptů, stačí v souboru /etc/sysconfig/init nastavit proměnnou GRAPHICAL="no". Pokud se chcete na průběh startu podívat jen jednorázově, přepněte se na 1. konzoli kombinací kláves CTRL+SHIFT+F1.

Měl bych zde zmínit i dokumentovanou chybu, díky které se automatická detekce nového HW pomocí programu kudzu nezobrazí a tím pádem se bootovací proces zastaví a nepokračuje. Pokud se s tím setkáte, zakažte grafický boot, jak je vysvětleno výše nebo se nedotýkejte klávesnice a čekejte na timeout.

Kromě hezkého vzhledu musím grafickému startu vytknout další prodloužení již tak dlouhého čekání na start systému, které je způsobené čekáním na zavedení X serveru nutného pro zobrazení grafiky. Uvítal bych konečně úpravu startovacích skriptů tak, aby byly spouštěny na pozadí a nečekalo se na dokončení startu každého programu. Nejde jen o čekání u desktopu, ale i o zbytečné prodlužování výpadku při restartu systému (třeba serveru kvůli zavedení opraveného jádra).

Podpora UTF-8

Už od verze 8.0 je nastaveno při nové instalaci implicitně kódování UTF-8, které je konečným řešením všech problémů s různými kódováními. Pomocí UTF-8 lze totiž vyjádřit jakýkoliv známý znak. Proto při tisku nebo zobrazení na obrazovce není potřeba při použití čínského znaku uprostřed českého textu měnit font, čímž se veškeré zobrazování a vkládání znaků zjednodušuje.

Nepříjemným důsledkem tohoto postoje je skutečnost, že uživatelé mohou narazit na programy, které dosud UTF-8 nepodporují. Největším problémem je dosud nemožnost zpracovávat UTF-8 znaky pomocí Samby v názvech souborů při sdílení přes síť, případně pro FTP a podobně (tj. národní znaky budou přes Sambu nebo uvnitř systému vidět špatně). U Samby si musíme počkat na verzi 3.0, která již UTF-8 kódování bude podporovat. U ostatních programů je potřeba tlačit na vývojáře, aby tyto nedostatky odstranili (zavedením UTF-8 totiž mají stejné problémy jako my i západoevropské státy, které dosud těžily z kompatibility kódování ASCII a ISO-8859-1 z hlediska programování vstupů a výstupů).

Pozitivním momentem je, že Gnome-terminal dokáže překódovávat zobrazené znaky, takže si uvnitř něj můžete spustit SSH nebo telnet relaci s počítačem pracujícím v jiném kódování a mít vstupy a výstupy správně čitelné. Negativním momentem je, že mi při použití české mapy klávesnice při stisku normálních kláves (třeba písmeno n) místo napsání znaku aktivoval položku v menu. Stejný problém jsem zaznamenal i v jiných místech Gnome. Pokud tedy nechcete nebo nemůžete Gnome-terminal používat, můžete použít programy xterm(1) nebo luit(1) a jejich volby -en a -lc. Převody textových souborů lze provést pomocí programu iconv, který je součástí Glibc (tj. stejnojmennou funkci lze použít i uvnitř programů, které potřebují překódovávat své vstupy a výstupy). Pro zobrazení souborů v různých kódováních lze použít program lv(1). Uživatelé editoru ViM mohou použít v konfiguračním souboru ~/.vimrc nastavení:

set fileencodings=utf-8,iso-8859-2

V takovém případě můžete otevírat soubory v kódování UTF-8 nebo ISO-8859-2 a editor vždy bude automaticky překódovávat vstup i výstup, takže ani nepoznáte, že pracujete s různě kódovanými textovými soubory.

Negativním momentem naopak je, že dosud není opraveno několik nepříjemných chyb. První z nich je problém klávesové mapy v grafickém prostředí XFree86, kde instalátor nedoplňuje anglickou mapu klávesnice, což může být dost nepříjemné. Proto je potřeba ručně opravit soubor /etc/X11/XF86Config tak, aby obsahoval tyto dvě řádky (parametr XkbLayout je potřeba opravit, XkbOptions pak nastavuje přepínání oběma klávesami SHIFT a signalizaci pomocí svítivé diody LED u Scroll Lock.

Option  "XkbLayout"   "us,cz_qwerty"
Option  "XkbOptions"  "grp:shift_toggle,grp_led:scroll"

Dalším problémem je skutečnost, že klávesová mapa pro textovou konzoli je dosud napsána v kódování ISO-8859-2, takže je potřeba k ní doplnit parametr -u, který zajistí překódování stisknutých kláves do UTF-8. Proto je potřeba tento parametr doplnit do souboru /etc/sysconfig/keyboard k definici mapy takto:

KEYTABLE="cz-lat2 -u"

Zdá se, že nejdéle se bez řešení budeme potýkat se zobrazováním českých manuálových stránek programem man. Zde je problém uvnitř programu troff, který nemá nadefinované jako platné české znaky s háčky (tj. ěščřž) a prostě je na výstupu vynechává. Manuálové stránky jsou správně zobrazovány v grafických prohlížečích manuálových stránek, což ovšem nemusí být pro mnoho uživatelů dostačující. V současné době přejímá Red Hat balíček programu groff včetně záplat z distribuce Debian a soudě podle mých několika neúspěšných mailů tento problém jejich vývojáře vůbec nepálí (nedostal jsem žádnou reakci, i když udržují 400kB záplatu). Stejně tak se k tomu staví tvůrci programu groff, kteří odkazují na verzi 2, která ovšem zatím stále neexistuje.

Jistým nedostatkem je také nutnost vypnout automatické oznamování kódování WWW serverem Apache, protože informace z HTTP hlavičky mají přednost před META, která se pro oznámení kódování používá uvnitř HTML souboru (tj. je potřeba v souboru /etc/httpd/conf/httpd.conf nastavit AddDefaultCharset Off). Pokud byste ponechali nastavení na UTF-8, musely by být všechny HTML soubory v UTF-8 kódování. Na druhou stranu se při tomto nastavení vyhnete možným bezpečnostním problémům.

Pokud nechcete UTF-8 používat, není to problém, stačí pouze buď globálně (v souboru /etc/sysconfig/i18n) nebo pro daného uživatele (~/.i18n) nastavit locale podle potřeby. Pro použití češtiny a kódování ISO-8859-2 v grafickém prostředí by tedy tento soubor měl obsahovat:

LANG=cs_CZ

Pro nastavení správné mapy klávesnice a fontu na textové konzoli (opět pro ISO-8859-2) by měly následující soubory obsahovat toto:

# cat /etc/sysconfig/keyboard
KEYTABLE="cz-lat2"
# cat /etc/sysconfig/i18n
LANG="cs_CZ"
SYSFONT="lat2a-16"

Vyhlazování písem

Stejně jako dříve je v XFree86 pro práci s fonty použit nový fontconfig systém spolu s knihovnou Xft, který kromě zkrácení názvu fontů do lidské podoby umožňuje i velmi hezké vyhlazování písem v aplikacích (tzv. AA - AntiAliasing). Předpokládá se, že starý způsob práce s fonty časem zanikne.

Vyhlazené fonty působí na monitoru velmi hezky, pokud není používáno patkové písmo. Problém jsem zaznamenal v programu Mozilla i v OpenOffice. Písmena jsou chybně zobrazena tučně, přičemž některá písmena jsou posunuta v řádku o kousek níž. To vůbec nevypadá dobře a bude to (doufejme) ve finální verzi odstraněno. Následující 2 obrázky demonstrují problém v Mozille. První obsahuje text zobrazený implicitním fontem (chybně) a druhý WWW stránku denníku iDnes používajícího bezpatkové písmo (správně). Problém lze obejít i tak, že si bezpatkové písmo nastavíte jako implicitní (což ovšem problém neřeší, jen se na text pak dá dívat).

Demonstrace problému s fonty
Chybně rendrované fonty v Mozille Správně zobrazená stránka používající jiné fonty (iDnes.cz)

Doplňující fonty je možno do systému přidat jednoduše jejich nakopírováním do adresáře /usr/share/fonts nebo do uživatelova adresáře ~/.fonts a spuštěním příkazu:

fc-cache <adresář>

Další možností je použít program Nautilus (pro zobrazování souborů) a zadat do vstupního pole adresu fonts:///. Pak lze nové fonty jednoduše do okna přetáhnout (soubory s fonty nesmí být komprimované).

Multimédia

Ditribuce stále neobsahuje dostatečnou podporu multimédií, která je způsobena licenčními problémy (firma Red Hat, Inc. by musela platit za každou volně staženou kopii poplatky majitelům licencí na MP3, případně další použité multimediální formáty).

Pokud se chcete těšit z plné podpory multimédií, doporučuji nainstalovat si z http://atrpms.physik.fu-berlin.de MPlayer, který obsahuje podporu pro nejběžnější multimediální formáty (MP3, Ogg, MPEG, DivX, RealPlayer, Windows media, Quicktime) a do Mozilly začlenit MozPlugger http://mozplugger.mozdev.org, pomocí kterého lze rozšířený MPlayer z Mozilly automaticky používat.

Aktualizované programy

Nové verze s sebou vždy nesou nové verze programů, což je většinou nejsilnějším důvodem pro aktualizaci. Vzhledem k tomu, že se Red Hat u verze 9 rozhodl pro změnu číslování, viz článek o verzi Red Hat Linux 9 (Shrike), nemůžeme na první pohled u další verze říct podle čísla verze nic (kromě toho, že je novější). Budeme se tedy muset na podívat na jednotlivé části podrobněji. Může vám to pomoct v rozhodnutí, jestli je na aktualizaci ten pravý čas nebo budete chtít počkat až na další verzi. Všechny odkazy na verze budou v pořadí nejprve verze z distribuce Red Hat 9, v závorce pak případná verze dostupná v aktualizacích ke dni vytvoření článku a jako druhé číslo bude verze vyskytující se v betaverzi Severn (o které se zde píše).

Binární kompatibilita

Binární kompatibilita je s Red Hat Linuxem verze 9 zachována, i když kompilátor GCC byl aktualizován. Systémové knihovny Glibc zůstaly ve stejné verzi. To je jistě potěšující, i když to nezaručuje, že se stejně bude chovat i finální verze.

Základní komponenty

Nejzákladnější součástí distribuce je jádro (kernel). Z verze 2.4.20 pokročilo na verzi 2.4.21 (jádro se v řadě 2.4.x dnes již vyvíjí poměrně pomalu a kvůli ověření stability nebude v betaverzi nejnovější dostupné). Druhou nejzákladnější součástí je knihovna Glibc, která setrvala na verzi 2.3.2 (i když je v balíčku o poznání více záplat). Třetím stavebním kamenem je kompilátor GCC, pomocí kterého je celá distribuce překládána. Ten povýšil z verze 3.2.2 na verzi 3.3, což může být zásadní otázkou při zvažování přechodu na novou verzi Red Hat Linuxu (nebo Mandrake, který na tom bude pravděpodobně stejně). Pro zachování zpětné kompatibility je v distribuci k dispozici balíček gcc32, který obsahuje předchozí verzi kompilátoru (3.2.3).

Nová verze kompilátoru může být zajímavá pro vývojáře, kteří chtějí držet krok a upravit své aplikace tak, aby je nový kompilátor byl schopen přeložit nebo chtějí využít jeho nového potenciálu. V posledním roce je totiž vyvíjen velký tlak na to, aby kompilátor GCC respektoval normu (respektive k tomu tlačí programátory odmítáním některých nedovolených, specifických nebo vyloženě špatných konstrukcí), a tak bylo potřeba hodně programů opravit.

Grafická prostředí

U Gnome 2.2.0 není vidět přílišný posun, použité komponenty se buď neliší prakticky vůbec nebo jen málo. Větší změna je jen v použitém Webovském prohlížeči, který využívá pro rendrování stránek engine Gecko z Mozilly. V předchozí verzi byl použit Galeon, který byl nahrazen programem Epiphany, protože Galeon verze 1.2.x již nebyl svými vývojáři udržován.

Plocha v Gnome s programy Mozilla a Epiphany

KDE se posunulo z verze 3.1 na verzi 3.1.2, což také není přílišný krok. Jeho knihovny Qt pokročily z verze 3.1.1 na verzi 3.1.2. Stejně tak nedošlo k prakticky žádné změně u XFree86 (stále verze 4.3.0).

V obou grafických rozhraních je po instalaci nastaveno téma BlueCurve, které vzniklo ve firmě Red Hat a již od verze 8.0 dává oběma prostředím stejný sjednocující vzhled. Z vnějšího pohledu nedošlo ke změnám a stále jsou v rozlišení 1024x768 na ploše velmi velké až humpolácké ikony. To samé platí pro panel, který je zbytečně veliký (na můj vkus i v rozlišení 1280x1024). Ještě že jde zmenšit ručně...

Příjemnou novinkou je využití funkce RandR, která v jednoduchém panelu dovoluje i obyčejnému uživateli změnit rozlišení obrazovky (tj. ne jen virtuální rozlišení pomocí kombinace kláves CTRL+ALT+šedivé_+, ale skutečné rozlišení displeje).

Ostatní programy

Následující tabulka uvádí přehledně verze programů Red Hat Linuxu 9 a verze obsažené v betaverzi Severn. Obsahuje výběr nejdůležitějších komponent. Pokud zde nenajdete svůj oblíbený program, podívejte se přímo do distribuce (odkazy jsou uvedeny na začátku článku). Kvantitativně lze shrnout změnu jednoduše - ze 1402 balíčků na 1455. Z toho je vidět, že ani sama distribuce příliš nenakynula.

Přehled verzí programů v RH 9 a betaverzi Severn
Balíček Red Hat 9 Red Hat Beta Severn
Apache (httpd) 2.0.40 2.0.45
PHP 4.2.2 4.3.2
Bind 9.2.1 9.2.2
vsftpd 1.1.3 1.2.0
Sendmail 8.12.8 8.12.9
PostgreSQL 7.3.2 7.3.3
MySQL 3.23.54a 3.23.57
Samba 2.2.7a 2.2.8a
Mozilla 1.2.1 1.4
OpenOffice 1.0.2 1.0.2
AbiWord 1.0.4 1.99.2
Evolution 1.2.2 1.4.3
KOffice 1.2.1 1.2.1
Gimp 1.2.3 1.2.3
OpenSSL 0.9.7a 0.9.7a
OpenSSH 3.5p1 3.6.1p2
Perl 5.8.0 5.8.1
ViM 6.1 6.2.18

Přidané a odebrané balíčky

Do distribuce byl přidán balíček s ACPI démonem (acpid), avšak nemá zatím rozumné standardní nastavení. Bylo přidáno několik dalších balíčků pro podporu BlueTooth (bluez-* balíčky). Pro podporu zápisu ve formátu DVD+RW/+R byl přidán balíček dvd+rw-tools. V distribuci najdeme nově i balíček freeradius s podporou protokolu RADIUS. Zařazen byl i balíček nano se stejnojmenným jednoduchým editorem (jako náhrada za pico a joe).

Z distribuce byl definitivně odebrán balíček pine, protože obsahuje nevyhovující licenci (non-OpenSource) a jeho údržba je problematická. To je trošku škoda, ale na druhou stranu tento program nebyl dosud lokalizovaný a měl problémy s UTF-8. Kromě toho lze Mutt nastavit do režimu, kdy ho lze ovládat klávesami stejnými, jako v pine. Sám jsem na mutt přešel asi před dvěma roky a mohu říct, že se mi to vyplatilo, i když z počátku jsem dost prskal :-)

Pro omezené zdroje ve vývoji byl odebrán i balíček tripwire. Balíčku Glide3 hrozí odebrání pro potíže na jiných platformách, LILO se už také považuje za zastaralé, protože Grub je dostatečně dobrá náhrada. Vyřazení hrozí i balíčkům ncpfs a mars-nwe (u druhého se není co divit, Samba je mnohem lepší a navíc výborně udržovaná).

Jádro 2.6

Jádro verze 2.6 není v betaverzi použito a nebude použito ani v ostré verzi, protože teprve zahájilo fázi stabilizace (14. července byla vydána první pre-verze 2.6.0-pre1, dnes je k dispozici již 2.6.0-pre2). Nicméně můžete nakouknout pod pokličku dalších vylepšení (viz článek o jádru 2.6) a vyzkoušet připravené balíčky z adresy http://people.redhat.com/arjanv/2.5/ (Arjan van de Ven je jedním z vývojářů jádra u firmy Red Hat, Inc.).

Závěr

Na závěr jsem si kromě zhodnocení nechal jednu perličku. I když v této betaverzi daný balíček není, můžete v distribuci Raw Hide nalézt balíček yum, což je volně šiřitelný nástroj pro údržbu systému. Pokud bude do ostré verze zařazen, bude to velmi zajímavý krok, protože tento nástroj je v podstatě ekvivalentem nástroje up2date a RHN (Red Hat Network, tedy služba, za kterou si Red Hat nechává platit a která je ve volně šiřitelné distribuci prakticky jediným zdrojem příjmů [1 počítač = $60 ročně]).

Celkově je vidět, že tentokrát dostane příležitost k pokroku ne jen prostředí a technologické novinky, ale distribuce Red Hat Linuxu se zlepší zejména v možnosti zasáhnout desktop (díky ACPI a Laptop režimu pro správu virtuální paměti). Nasazení Exec-shieldu je zajímavý krok a povede zřejmě k pročištění zbytku distribuce (čistota programátorských technik umožní na odpovídajících platformách dosáhnout výrazně vyšší bezpečnosti).

Velmi zajímavým krokem je snaha o uplatnění otevřeného vývoje ne jen na jednotlivé komponenty, ale i na celou distribuci, což je svým způsobem u komerční distribuce překvapivý (ale logický) krok. Je otázka, co konkrétně přinese a neodvažuji se v tuto chvíli odpovědně ukázat na pozitiva a negativa. Na to si budeme muset ještě chvíli počkat. Nicméně osobně tento krok vítám a myslím si, že je pozitivní (i když jsem již zaslechl názor, že je to jen pěkně vypečený a vyčuraný krok komerční firmy, která chce získat něco zadarmo). Myslím si to proto, že mohu zřetelně vidět, že firma Red Hat, Inc. komunitě okolo Linuxu vrací protihodnoty, které nás a Linux obohacují a posunují vpřed tím, že přidává k již vytvořenému dílu další hodnoty a dává je opět volně k dispozici (o což podle mě v tomto světě free software jde především) a dělá u toho minimální obstrukce (zejména tím, že vystavuje ISO soubory i zdrojové kódy ihned bez zbytečných prodlev, veřejně a vývoj již dlouho díky distribuci Raw Hide neprobíhá za zavřenými dveřmi).

Celkově se tedy dá říct, že je co chválit, i když některá zákoutí (zejména v UTF-8 a uživatelské přítulnosti) už dost zasmrádají :-)