Fedora 11: běh na krátké tratě

Start

Změna základní

Kdo to dříve nepostřehl, logo Fedory bylo marketingově prezentováno jako symbol trojjedinný – infinity + freedom + voice, neboli nekonečno, svoboda a hlas. To byly tři základní atributy, kterými se Fedora prezentovala. Co si pod nimi každý představí, je na něm. Každopádně se jedná o pojmy značně abstraktní (pro některé jedince až příliš). Tyto tři pojmy se proto již během života Fedory 10 přetransfor­movaly na čtveřici, se kterou bude prezentována Fedora 11 – tzv. 4Foundations – freedom, friends, features, first- které říkají do jisté míry totéž, ale přece jen srozumitelněji. Pro ty, kteří nevládnou jazykem britských kolonií, provedu krátký rozbor – svoboda (myšleno svobodný software a kultura vůbec), přátelé (přátelství – software založený na kooperaci a podporující ji), vlastnosti (ve smyslu nové a lepší vlastnosti, inovace) a první (vedoucí pozice v oblasti, první v zavádění novinek). O marketingu si každý může myslet svoje, ale víme, že některé produkty vlastně nic jiného než marketing neprodává. Linuxu jsou stále nedostatky v této oblasti vytýkány, i když se přece jen situace za poslední roky trochu zlepšila.

Zatáčka

Co tedy Fedora 11 přináší, aby naplnila tyto strategické body (a na co se jinde můžete těšit do příštích verzí).

Palimpsest

Do obrazu vbíhá další Kit. Varoval jsem vás, Donalde. Střelec D. Zeuth nespí na vavřínech HALu, ale otevřeně přiznává, co někteří jen trousí pod vousy. HAL je obluda a má přebytky, které mít neměl. HAL s FDI soubory duplikují do značné míry udev a zneprůhledňují celý proces práce se zařízeními. Navíc na velkých systémech trpí neúměrně dlouhým startem, stejně tak na pomalých zařízeních (embedded). Ač koncept HALu jako neprivilegovaného mechanismu pro privilegované akce se ukázal správný, HAL na sebe zbytečně nabalil příliš mnoho funkcí a ani pomocí nich neřeší uspokojivě některé problémy jako např. správu napájení, dělení disků, vytváření a správu RAIDů, přístup k privilegovaným informacím např. SMARTu apod. DeviceKit tak jediným výstřelem posílá HAL k zemi a hrne se na jeho místo společně s udev. Udev už všichni známe, zajímá nás hlavně nový borec. Poučen z předchozích nezdarů, nedává mu autor takové ambice jako HALu, ale cílí na oblast, jež má mezery – tedy spíše oblast aplikační. A myslím, je to zásah dobrý. Jen to jméno grafického rozhraní asi nikdy na poprvé nenapíšu správně… palipset? Palimpset? Palimpsest! (Mimochodem je to označení pro rukopis psaný na recyklovaném pergamenu.. že by nějaký skrytý význam?)

Abyste rozuměli, HAL tím není zcela odstaven, samozřejmě bude existovat přechodné období a kromě toho bude právě pro nejrůznější enterprise distribuce udržován i nadále. DeviceKit jen přebere tu původní zamýšlenou funkcionalitu a přidá něco nového. Přesnější popis DeviceKitu nechť si čtenář projde sám, kdo je obeznámen s mechanismy Kitů a HALu např. z mých starších článků, pro toho mechanismus nebude nic nového, jen se pozměnila funkcionalita. A kdyby se vám po instalaci F11 náhodou objevila bublina ohlašující „A hard disk is failing“, nepanikařte. To jen DeviceKit upozorňuje na hlášení SMARTu, které může znamenat ledacos.

i386 je mtrvá, PAE vládne všem

Některé distribuce k tomu přistoupily již dávno a Fedora je v tomto trochu pozadu, nicméně s F11 končí éra architektury i386 ve Fedoře a základní optimalizací se stává i586. S tím budou jistě spojeny zmatky a spousta práce jak na straně distribuce (massrebuild – kompletní rekompilace všech balíků – ta by přišla ovšem i tak kvůli změně verze gcc na 4.4), tak na straně uživatele, kde ti, co měli doposud i386, budou muset upgradovat nejen verzi systému, ale i architekturu. Osobně jsem to přestál i přes varování instalátoru, že to může dopadnout špatně, jen s minimálním zádrhelem, který měl sice za následek systém, který nešel nastartovat, ale pro poučeného uživatele byl řešitelný doinstalací jednoho chybějícího balíku (sysvinit) ze záchranného módu. Taktéž balíky KDE byly v poněkud žalostném stavu,

$ yum groupinstall kde-desktop

ale udělalo svou práci.

Aby toho ale nebylo málo, je tu ještě jedna změna, která z architektur udělá zmatek na druhou, a to jest výchozí použití jádra s PAE (physical address extension) pro adresaci velkých pamětí na 32b architekturách. Uvažovalo se i o instalaci x86_64 kernelu při instalaci 32b verze Fedory na systému, který podporuje 64b, ale tato možnost nakonec v F11 není. Počítačů a skuhrajících uživatelů s více než 4 GB paměti přibývá, instalátor by tedy měl automaticky na systémech, které to podporují, instalovat kernel, který je využije. Dohady, jak takový systém identifikovat, byly dlouhé a až množství chyb a dotazů ukáže, zda byl zvolený postup správný. V zásadě by to mělo jít na každý procesor, který na

cat /proc/cpuinfo | grep pae

odpoví řádkou flags, která pae obsahuje, což je v podstatě vše od Pentia II. Nutno podotknout, že někomu to stejně nepomůže, protože někteří výrobci desek v rámci úspor např. nepřipojují všechny piny sběrnice a podobné vychytávky, takže ani PAE jim nezajistí využití celých 4 GB, natož více.

Ve výchozím použití PAE se skrývá jedna záludnost. Většině uživatelů se totiž změní balík s jádrem – tedy přesněji jeho název z „kernel“ na „kernel-PAE“. To má bohužel nemálo následků především v oblasti doplňků typu proprietárních driverů nVidia a Ati, protože zatímco doposud všechny návody uváděly, že stačí použít pro instalaci yum install kmod-nvidia xorg-x11-drv-nvidia, nyní bude nezbytné rozlišit mezi jádry s a bez PAE. Tedy v případě že máte PAE jádro, což je velmi pravděpodobné, musíte nově instalovat

$ yum install kmod-nvidia-PAE xorg-x11-drv-nvidia

Stejně tak např. pro balík kernel-devel  – odpovídající je nyní kernel-devel-PAE.

Kernel v F11 je vylepšen ještě o jednu věc, a to relatime. Kdo se trochu zajímá o výkon linuxového kernelu, je mu známa nevýhoda mechanismu atime, který s každým přístupem k souboru aktualizuje jeho časovou značku. Tato vlastnost je vyžadována POSIXem a má svůj význam. Protože ale zápis atime zpomaluje diskové operace (musí nastat při každém čtení), někdo jej úplně vypíná. Takové řešení ale není ideální. Proto již před časem vznikl mechanismus, který atime značku aktualizuje jen někdy. Tento mechanismus je díky vývojářům Fedory začleněn do kernel 2.6.30 a pro Fedoru backportován do 2.6.29 a jmenuje se relatime. Ingo Molnar označil odstranění atime za jedno z největších zrychlení diskových operací za dlouhou dobu.

Rovinka

Silnější šifry a podpisy nejen v rpm

Jak většina čtenářů tohoto serveru jistě postřehla, s nástupem výkonnější techniky a bystřejších mozků se dříve neotřesitelné šifry typu MD5 odebírají do propadliště dějin. Jak to bude v následujících letech, nikdo neví, a tak pro jistotu Fedora sáhla rovnou pro SHA256, která je nově použita pro podpisy balíků i kontrolní součty obrazů instalačních médií. Až si tedy uděláte sha1sum staženého DVD a budete se divit, že řetězec je dvakrát kratší než ten, se kterým ho máte porovnat, zkuste sha256sum, mělo by to být lepší.

Presto RPM

Změna používaných šifrovacích metod v rpm není jediná. V F11 pokračuje vývoj rpm. Nová verze je zaměřena na optimalizaci využití paměti a podle autorů je to skok celkem výrazný (maximální využitá paměť při testování se snížila z 1,5 GB na cca 300 MB). Vývojář yumu se totiž již dlouho bránil nářkům na pomalost yumu právě tím, že nyní je nejužšší místo již samotné rpm. Ač si nemyslím, že při běžném použití je yum s rpm nějak pomalý, konzumace paměti např. při upgradech celého systému byla opravdu nepříjemná. Tentokrát jsem opět mohl oživit starý oblíbený testovací PIII800/768 MB a upgrade se nestal noční můrou, ale proběhl celkem hladce a rychle, takže to nejsou jen planá čísla.

Již delší dobu se mluví i o další vlastnosti, a to využití stahování pouze rozdílových balíků, alias DeltaRPM. Ačkoliv pro F10 i F9 existují, resp. existovaly experimentální repozitáře, pro F11 je využití deltarpm nastaveno jako výchozí. Jeho implementaci v yumu zajišťuje plugin Presto, pokud jste po upgrade a plugin nemáte, stačí doinstalovat

$ yum install yum-presto

Tři týdny před vydáním se objevily spekulace, že Presto se do F11 nedostane, protože není připravená infrastruktura, nicméně ohlas byl tak velký, že se do toho vývojáři obuli a Presto je tady.

Na deltarpm je potřeba se podívat z více stran. Je totiž super, že stahujete podstatně méně dat, ale platíte za to natřikrát. První problém je dostupnost rozdílových repozitářů, které zatím nejsou na všech zrcadlech, a tak stahování může být ve výsledku pomalejší než stahovat celý balík – to se snad brzy po vydání finální verze F11 změní. Druhý problém je výpočetní výkon potřebný k sestavení nového balíku. Není to sice nijak dramatické, ale prostě to nějakou dobu trvá. Třetí platba je v podobě místa na disku, protože abyste mohli stahovat rozdílový balík, musíte mít na disku ten předchozí. Pokud nemáte, stáhne se samozřejmě celý. Fakticky je tedy záhodno v yumu nastavit keepcache=1 a počítat s tím, že podle množství instalovaných aplikací zabere cache tak 2–5 GB. Rozdíl ve stahovaném objemu je ale opravdu značný. Největší hrůzu mám vždy z aktualizací OpenOffice.org, kde samotné OOo je většinou přes 200 MB. Zažil jsem totéž i během vývoje F11 a pro celé OOo se stáhlo dohromady pár MB. Celá 300MB aktualizace pak zaznamenala úsporu 68 %, v jiném případě až 75 %. (Neměl bych napsat do titulku – „Fedora 11 – až o 75% rychlejší stahování“?)

Anaconda

Dá se říci, že v F11 nezůstal kámen na kameni, což při tak krátkém vývojovém cyklu bude jistě znamenat nemálo problémů, resp. změn v chování. Nejen, že se předělávaly všechny balíky kvůli změně architektury, na většině systémů se změní architektura jádra, mění se HAL za DeviceKit, nebo RPM za DeltaRPM, ještě si v projektu usmysleli, že přepíší část instalátoru, a to jsem zatím nezmínil oblíbené písničky jako PulseAudio nebo Xorg.

Anaconda prodělala hlavní změnu ve správě disků a v jejich dělení. Pro uživatele by co se rozhraní týče k žádným změnám dojít nemělo, ty se udály jen pod kapotou a měly by usnadnit správu diskových oddílů různých typů na různých zařízeních (LVM, RAID, iSCSI, kryptované oddíly).

Jednou ze změn je i výchozí použití nového souborového systému ext4. Otázku, zda máte tento FS začít používat nebo ne, za vás nerozhodnu. Výhody ext4míří především do oblasti zlepšení výkonu velkých souborových systémů, nicméně může přinést i zajímavé zlepšení pro běžné desktopové použití. S ext4 dochází ke změně formátu dat popisujících uložení souboru na disku. Ext4 ovladač je ale schopen pracovat i se strukturou ext3 (resp. vlastně ext2) a využívat jen některá výkonostní zlepšení ext4. Zatímco při konverzi z ext2 na ext3 byl do systému přidán jen žurnál a bylo možné FS připojit v podstatě beztrestně i jako ext2, pokud „překonvertujete“ na ext4, je změna nevratná a jednou překonvertovaný systém nejde jednoduše vrátit na ext3. FS ext3 lze sice připojit jako ext4 typ, ale modifikovaný ext4 už nikoli jako ext3. Překonvertujete jsem napsal do uvozovek, protože jediný způsob, jak naráz překonvertovat na ext4, je provést zálohu, oddíl disku přeformátovat a data na něj nakopírovat. Je tu ale i jiná možnost a ta je jednou ze zajímavých vlastností ext4 – postupná modifikace struktury dat, při nových zápisech souborů. Postup této konverze je tu popsán v článku o migraci na ext4. Jen doplním, že při této konverzi nedojde ke skutečné změně diskových struktur na ext4, k té dochází až při práci se soubory, přesněji při jejich zápisu, nebo až na soubor dojde řada při tzv. online defragmentaci, která ale ještě není dokončena, takže zatím není zapnuta.

PulseAudio

Lennart Poettering to nemá jednoduché. Na jedné straně ho chápu, když musím co týden řešit s někým problém typu nejde mi zvuk, nejde mi mikrofon, na druhé straně nevím, zda nedělá až zbytečně zle, resp. nesnaží se změnit příliš mnoho najednou. Lennart skutečně nešetří ALSA a poukazuje na nejrůznější neduhy zvukového systému. V mnohém má pravdu – vzpomeňme už jen původní nešťastné nastavení všech mixer hejblátek na nulu při inicializaci alsy, kvanta nejrůznějších nepochopitelných přepínačů a šoupátek v alsamixeru nebo nesourodou implementaci ovladačů. Jeho snaha převést zvukový systém Linuxu od globálně ovládaného zvukového zařízení k modernímu nastavení, které je založené na zvukových tocích s nimiž lze různě žonglovat, a na zvukových profilech, tak jak to je např. v Mac OS X, je jistě chvályhodná. Bohužel, když uživatelům zrušíte známý mixér a nahradíte ho jedním šoupátkem, schováte jim možnost přepnout na jejich překombinovaném HW mikrofon z interního na externí, a když jim řeknete, že ovládání hlasitosti zvuku z CD mechaniky přes kartu je zastaralé a nepodporované, nemůžete čekat, že vás vynesou do nebe. Nám konzumentům zvukových požitků tak nezbude, než poděkovat za „samozřejmosti“ typu funkční USB reproduktory (nechápu, kdo mohl vymyslet honit zvuk přes USB, ale kdo chce kam) nebo bluetooth headset a jejich snahu ocenit projevením dostatku shovívavosti při transmutaci zvukového systému, která nám občas něco schová. Jinými slovy, po system-config-soundcard nás opustil i gnome-volume-control. Pokud toužíte dostat se ke starým nastavením karty, musíte hodně hluboko až na

$ alsamixer -c0

Na základě poměrně bouřlivého ohlasu byl nakonec do F11 přidán zpět gst-mixer alias gnome-volume-control. Jeho použití je ovšem označeno za zastaralé. (Na mém stařičkém Sound Blasteru 16 ISA je to stejně všechno jedno, protože ten už se asi opravy v ALSA, aby ho korektně identifikoval HAL, nedočká.)

20s startup

Řekněme, že Fedora si neklade zbrkle nereálné cíle, ale klade si nereálné cíle postupně. A tak zatímco v F10 byl úkol 30s startup a oblast zlepšování se zaměřovala především na start Xserveru, v F11 je za úkol 20s startup. Na stránkách vývojáře, který se tímto zabývá, najdete i porovnání některých distribucí.

Harald na to jde vědecky, a tak kromě bootchartu se snaží identifikovat největší jedlíky výkonu disku. Jako pět nej z nich označil

• modprobe (celkem pochopitelné),
• gconfd-2 (který mi pije krev od té doby, co se startuje i se SeaMonkey),
• setroubleshootd (ve kterém vidí možnost zlepšení),
• xkbcomp a
• rpcbind.

Setroubleshoot byl nakonec z výchozího startu systému odstraněn a byl přepracován readahead, aby jednak běžel s nižší prioritou, a za druhé, aby se seznam „přednačítaných“ knihoven apod. aktualizoval po manipulacích s balíky (odtraňování, přidávání). V současné době trvá start na jeho testovacím systému 22–24 s. Na mém (viz výše) to je 57–69 s. Jak vidno, je tedy výsledek této snahy hodně relativní. Přestože chápu důležitost rychlé připravenosti systému, připomínají mi snahy zobrazit uživateli co nejdříve přihlašovací obrazovku chování operačního systému, jehož jméno se nesmí vyslovovat a který sice výzvu ke stisku Ctrl+Alt+Del zobrazí brzy, ovšem po ní následují minuty pozorování otravného startu toho, co skutečně potřebujete – grafického prostředí. Škoda, že se stejná pozornost nevěnuje i suspendu a hibernaci, ale třeba na to časem dojde. Teď se soupeří ve startupu.

Xaaaorgh

Xserver se v posledních verzích Fedory stal přímo pověstný. Nejprve uvedením nové verze, nekompatibilní s binárními ovladači, poté přechodem na autokonfiguraci (tedy odstranění nutnosti mít xorg.conf) a nyní přichází armagedon č.3 – DRI2. K tomu si připočítejme snahu o implementaci KMS do všech tří základních ovladačů (radeon, nouveau, intel), přidání 3D akcelarace pro radeony r5×x/6×x a nebo přechod na UAX akceleraci 2D, a máme obrázek o stavu Xserveru – zdaleka ne všechno funguje, jak má. Uživatelé se oprávněně ptají, proč se Xserver v tomto stavu dostává do stabilního vydání. Odpověď je jednoduchá – jiný Xserver není. Všem v této souvislosti doporučuji pročíst velice pěkně popsaný osud ovladačů intel „Sharpening the Intel Driver Focus“. Všichni bychom rádi viděli kvalitní OS ovladače grafických karet s funkčním 3D nebo suspendem apod., ale s tempem produkce nových karet a vlastností se mi to zdá čím dál víc nemožné. Pokud nezačne sám výrobce nabízet ovladače i pro Linux s přijatelnou licencí, budeme brzo rádi, že nám jde aspoň nějaká grafika. Už teď se, alespoň podle mých zkušeností, v podstatě nedají používat nové grafické karty, aniž byste (pokud máte štěstí, že vůbec fungují) nepociťovali buď suboptimální výkon, nebo neřešili nedostatky funkční (dual head, rotace, nesprávná rozlišení, nedostupnost přídavných vstupů/výstupů, hw de/komprese videa atd). Otázka je, zda se situace zlepšuje, zhoršuje či nemění. Svůj názor můžete vyjádřit níže.

V Xorg došlo ještě k dalším změnám. Pro mnoho uživatelů je ta nejcitelnější nefunkčnost klávesové zkratky Ctrl+Alt+Backspace pro ukončení Xserveru. Funkce samozřejmě není definitivně odstraněna, pouze ve výchozí konfiguraci vypnuta. Pro zapnutí stačí přidat do Section ServerFlags

Option "DontZap" "false"

Celkem jsem se divil, že tento vpravdě veterán zkratek vydržel tak dlouho. Ač podle mě nechtěné použití této zkratky nepatřilo mezi nejčastější, může existovat okruh desktopových uživatelů, pro které je něco takového jako shození celého grafického prostředí jednou klávesovou zkratkou značně nepochopitelné. Tento způsob ukončování aplikací byl zcela legitimní v době, kdy všechny aplikace reagovaly na term signál korektním ukončením, a tak při ukončení Xserveru prostě skončily i všechny aplikace v něm puštěné. V době potvrzovacích okének „Ano, skutečně chci aplikaci ukončit“ je již ale tento způsob poněkud brutální a ti, kdo vědí, k čemu je, si ho jistě dokáží zapnout.

Jiné stránky

ABRT

Obraťme ale opět pozornost k věcem, které se daří lépe. Mezi ně bych zařadil ABRT, neboli automatic bugzilla reporting tool. V zásadě jde o to, že je možné crash reporty některých aplikací ukládat rovnou do bugzilly. Což, to si každý řekne, že musí generovat strašné množství záznamů, které nikdo nebude schopen zpracovat. Ale v tom je právě ten vtip. Chyba při pádu aplikace vygeneruje i klíč, který je pro stejnou chybu, byť z různých zdrojů, stejný, takže v bugzille jen přibývají další záznamy ke stejné chybě, čímž nejen, že se snižuje množství reportovaných nebo špatně reportovaných chyb, ale dá se tak odhadovat i četnost a závažnost chyby.

Bugzappers

Na tomto místě bych také rád vyzdvihl velice užitečnou aktivitu skupiny BugZappers, která se během posledních dvou vývojových období dostala do povědomí díky kvalitnímu a preciznímu vedení. Bugzapper je jednotlivec (třeba vy), který má jistá větší práva pro manipulaci s chybami v bugzille a má na starost první třídění chyb. Většina populárních OS projektů totiž trpí značným množstvím mnohdy špatně nebo duplicitně hlášených chyb. Autoři software pak místo skutečného opravování chyb nebo psaní užitečných vlastností dokola píší do bugzilly žádosti o doplnění informací o chybě, nebo přebírají množství stejných chyb. K tomu, aby se člověk stal bugzapperem, pak není potřeba v podstatě nic než schopnost umět číst, klikat myší. Časem si osvojíte okruh chyb v oblastech, o které se staráte, a stane se z vás guru. Neméně záslužnou činností je i organizace TestDays. Při nich jsou připraveny scénáře a LiveCD zaměřené k otestování nějaké funkcionality. Testeři pak oznamují výsledky jednotlivých scénářů na jejich instalaci, resp. HW. Pro vývojáře je to důležitý zdroj informací, protože nemohou sami vyzkoušet takové množství hardware, které během TestDay vyzkoušejí dobrovolníci. Pro vás je pak výhodou, že zrovna té vaší konfiguraci se může dostat větší pozornosti vývojářů.

Vstříc Windows

Zajímavé budou jistě i dvě další novinky, které bych zařadil do jednoho pytle s názvem „vstříc windows“. A to openchange a windows crosscompiler. Openchnage již zřejmě zaznamenali ti, kdo musí spravovat mailové prostředí a jsou nuceni řešit heterogenní prostředí s MS Windows, resp. MS Exchange. V F11 je tedy dostupná libmapi, která umožňuje aplikacím jako Evolution a KDEPim přistupovat k Exchange serveru. Crosscompiler pro Windows je cílen na vývojáře především multiplatformních aplikací, kterým umožní sestavovat i binárky pro Windows přímo z Linuxu. Odpadne tím nutnost restartů, vlastnictví licencí Windows apod. Asi to nebude pro Redmond velká rána, ale je to určitě zajímavá vlastnost.

Leonidas

Grafické téma F11 je… jiné. Přijde mi, že během vývoje F11 se mu nevěnovala taková pozornost jako v předchozích verzích. Tapeta působí poněkud kubisticky, jednoduché je i téma pro instalátor nebo výchozí téma plymouthu. Ale jak to tak bývá, je to věc vkusu. Naštěstí máme možnost si témata změnit na některá starší, nebo nějaké úplně jiná.

Virtuály

Již po mnoho vydání Fedory je věnována pozornost virtualizaci. Ani v F11 tomu není jinak. Bohužel se nejedná o můj šálek šťávy, takže mohu pouze shrnout, že dochází k zajímavým posunům v bezpečnosti a dalšímu zjednodušení práce s virtuálními stroji. Podrobnosti najdou zájemci např. v rozhovoru s jedním z vývojářů.

Poznámka FEL

Díky skupině starající se o Fedora Electronic Labspin se rozrůstá i množství nástrojů pro návrh integrovaných obvodů. Pro většinu lidí je sice slovní spojení návrh integrovaných obvodů poněkud nepochopitelné, je to ale oblast pro naši dnešní technospolečnost naprosto nepostradatelná, protože bez ní by nefungoval žádný z elektronických zázraků, které teď nejspíš používáte. Fedora se snaží sestavit a prezentovat kompletní řetězec pro návrh obvodů, když pro nic jiného, tak pro akademické prostředí, kde není zdaleka potřeba komerční software. Doporučuji prohlédnout prezentaci, která vypadá velice zajímavě.

Jak instalovat a upgradovat

Fedora nabízí kompletní soubor instalačních metod. Jako základní se dá použít LiveCD, jehož instalátor v podstatě pouze překopíruje obraz CD na disk. Instalace je rychlá, ale má svá úskalí. Na CD se zdaleka nevejde vše, a tak zvláště neanglicky mluvící mají potíž s rodným jazykem. Také z něj nelze provádět upgrade. Dále je k dispozici DVD s kompletní instalací (ovšem nikoli se všemi balíčky, ty by se na DVD nevešly) nebo 6 instalačních CD. Kromě toho Fedora umožňuje síťovou instalaci k jejímuž započetí vystačíte se 170 MB CD netinst.

Upgrade lze provést buď z instalačního DVD, nebo bez médií pomocí preupgrade nebo yumu. (Z LiveCD nelze provést upgrade, již z principu.) Preupgrade je aktualizační aplikace, kterou Fedora nabízí již od verze 9, resp. poprvé ji bylo možné použít pro přechod z F8 na F9. S ní je možné aktualizovat z jakékoli verze na jakoukoli verzi. Novinkou posledního vydání preupgrade je, že provádí upgrade všech komponent na jejich nejnovější verze (dříve prováděl skoky pouze verze odpovídající stavu při vydání), včetně aktualizací z repozitářů třetích stran (pokud dodržují použití $releasever nebo mají fixní adresu). Tím tuto metodu považuji za téměř dokonalou. Upgradovat lze i pomocí yumu na běžícím systému a spousta lidí to tak dělá. Je to ale metoda nedoporučovaná. Pokud budete upgradovat, bude váš souborový systém překonvertován na ext4 pouze v případě, že ručně zadáte parametr instalátoru ext4migrate. Takto komplikované to je schválně, aby tuto migraci dělali jen pracovníci poučení, kdož vědí, jaká to nese rizika (např. grub neumí ext4, takže pokud nemáte /boot na separátním ext3 oddílu, jste v… síti zlého obra).

Pro F11 byly přepracovány a přestrukturovány i poznámky k vydání, které každému doporučuji ke čtení. Bohužel v češtině si je nepřečtete. Nejsou lidi. (Rozuměj překladatelé.)

Finiš

Jak vidíte, novinky ve Fedoře se neomezují pouze na kosmetiku a je jich mnohem víc, než jsem zde zvládl popsat. Při šestiměsíčním vývojovém cyklu se skutečně jedná o sprint na krátké trati. Ihned po vydání F11 teď přebere štafetový kolík nejrychlejšího vývoje Rawhide alias F12. Naopak po jednom měsíci se odebere do důchodu F9. Pokud nechcete zrovna řídit lokomotivu Rawhide, máte možnost zůstat u ještě 7 měsíců podporované F10… ale nenechte si ujet vlak.