Fedora se s další verzí chystá změnit koncepci. Někdo by mohl, a oprávněně, říci: „Už zase?“ Je to ale prostě život, který také nestagnuje a každý se musí přizpůsobovat podmínkám okolí, které se mění. Koncept „Fedora.Next“, jak je pracovně nazýván, se snaží reflektovat několik zásadních změn. Zejména je to nástup architektury ARM, která v podstatě dominuje oblasti mobilních zařízení, ale získává výrazné postavení i v nejrůznějších embedded zařízeních, malých serverech atd.
I když Fedora byla vždy spíše „desktopová“ distribuce, hlavní proud se prostě přesouvá na tablety (někdo dokonce bere i 100 tablet týdně) a ARM. Další změnou je nutnost začít dělit právě funkcionalitu systému podle oblasti jeho použití, neboť každá z nich má jiné zaměření a i jiné tempo s jakým se s ním pracuje. Fedora by tak měla mít tři základní druhy – Workstation, Server a Cloud. Není to nic zásadně inovátorského, otázkou je, jak toho dosáhnout a vyhovět všem. Aktuálně to Fedora řešila tzv. spiny, ale koncept se příliš neujal, v zásadě existovalo stabilně pouze několik málo spinů jako KDE a XFCE, další různě přicházely a odcházely podle potřeb různých skupin.
Celý proces se změnou struktury Fedory v podstatě odstartovala konference Flock 2013, (i když náznaky byly již na FUDconu 2013), kde se objevilo množství prezentací jako „Why Fedora sucks?“, „The Fedora Crystal Ball: Where are we going for the next five years?“, „Fedora Revamp – Next Steps“ a nebo „An Architecture for a More Agile Fedora“ – většinu příspěvků lze nalézt v různých formách na blogu Máirín Duffy. Zde najdete i velmi ilustrativní obrázek o tom, kolik lidí a jak dlouho se angažují ve vývoji distribucí:
Nejdůležitější z prezentací je asi An Architecture for a More Agile Fedora – Architektura pro agilnější Fedoru (slovo agilní je už nějaký ten rok také populární, že), kde Matthew Miller navrhl rozdělit vývoj „balíků“ do několika základních kruhů:
- Kruh 0: Jádro OS
- Kruh 1: Fedora core
- Kruh 2: Stacky a prostředí
- Kruh 3: Aplikace
Mohlo by se zdát, že Fedora se tak vrací kruhem ke staršímu konceptu Fedora Core a repozitářů s přidruženými aplikacem Fedora Extras. Nyní by ovšem mělo jít o trochu něco jiného. Všechny kruhy by se měly vyvíjet přímo pod projektem Fedora, ale každý by měl mít jinou politiku a hlavně jiné tempo. FESCO (řídící výbor Fedory) nakonec tento koncept usměrnil zhruba do této podoby:
- Base Design
- Environments & Software Stacks
- Produkty:
- Fedora Workstation
- Fedora Server
- Fedora Cloud
Otázkou je, jak se plynule a ideálně se povede naroubovat tuto myšlenku na stávající infrastrukturu a kolik lidí se na této přeměně bude ochotno podílet. Jak to tak bývá, nic se nejí tak horké, jak se to uvaří. Nicméně Fedora 20 se v některých směrech připravuje pro uvedení tohoto konceptu v život. První z viditelných je rozdělení změn dříve označovaných jako „Feature“ do dvou skupin, a to „Systémové změny“ a „Změny samostatně oddělitelné“.
Za sebe mohu řící toliko, že neustálá změna struktury sice motivuje nové/mladé lidi, kteří mají zájem je implementovat se účastnit, naopak starým harcovníkům neustálé změny konceptů pod rukama nemusí příliš vyhovovat. Jsem proto zvědav, jak dopadne např. koncept Fedora serveru, který počítá s dvouletým vývojovým cyklem oproti půlroční Base.
Co tedy ta Fedora 20?
Instalátor
Může to znít sice absurdně, ale nejdůlejžitější, i když zároveň nejzbytečnější částí systému je instalátor. Kdo používá systém jako Fedora trvale, v podstatě instalátor potřebuje jednou za mnoho let. Jenže k tomu, abyste vůbec mohli systém začít používat, abyste ho tak říkajíc dostali mezi lidi, potřebujete instalátor. Takže je to komponenta velmi důležitá pro vstup, ale většinou ji pak nikdo dál moc nepotřebuje.
S nadsázkou se diskutovalo i o tom, že v podstatě každé vydání Fedory není o ničem jiném než o instalátoru, takže proč nevydávat jen instalátor. Instalátor Anaconda doznal v posledních vydáních značných změn, potřeba jeho vlastností je vlečena narůstající rychlostí změn v oblasti HW a to především zavedením UEFI místo BIOSů, Secure Bootu a GPT místo MBR, stále komplikovanějšími konstrukcemi disku (SSD+HDD) a grafických karet (duální grafiky), komplikovanějšími strukturami souborých systémů (RAID, LVM). Instalátor Anaconda tedy s F20 snad již dostatečně dospěl. Jak moc se ho dotknou konceptuální změny další Fedory se uvidí, protože několik verzí bylo v Anacondě záhodno klikat pouze doporučeným směrem.
FedUpgrade
Co se pro změnu pokazilo, a to značně, je možnost aktualizace z předchozí verze. Tuto funkci kdysi zastávala též Anaconda, pak se oddělil upgrade do „preupgrade“ a od přepsání Anacondy možnost upgrade zmizela úplně a nahradila ji v podstatě offline aktualizace přes „FedUp“. Při přechodu na F20 se ovšem nástroj FedUp dostupný v předchozích verzích ukázal jako nefunkční, ovšem přišlo se na to až po vydání F20. Trochu trapas, ale stane se, opravená verze už je dostupná v aktualizacích.
Yumý skupiny
Jemně porouchaný je/byl i yum v F20 a to především kvůli měnícímu se konceptu skupin v yumu, který částečně souvisí i se změnou struktury samotné Fedory. Yum přestal reprezentovat skupiny balíků jako… hm… skupiny a udělal z nich objekty. Tato vlastnost se sice oficiální stala již s F19, ale evidetně se začíná používat až s F20. Nyní to tedy funguje tak, že pokud je nějaká skupina označena (mark), pak se z ní nainstaluje vše a udržuje se to „synchronní“ – tedy pokud nějaký balík z označené skupiny ručně smažete, zase se s updatem doinstaluje. To je sice hezké, ale pokud chcete systém udržovat bez zbytečného balastu, celkem problematické. Na druhou stranu konečně funguje (mělo by fungovat) to, že pokud nainstalujete nějakou skupinu a pak ji chcete odebrat, neodstraní se vám půl systému, ale skutečně jen to, co se původně se skupinou nainstalovalo.
V každém případě je záhodno, abyste před aktualizací starší verze či instalací Fedory 20 věnovali zvýšenou pozornost stránce se známými chybami.
DNF yumem 2.0?
Dá se říci, že yum prodělal od své integrace do Fedory hodně změn. Stal se z něj velmi všestraný a komplikovaný nástroj (připomeňme poměrně nedávnou implementaci yum history), který ale evidetně přestal být dostatečně sexy, trochu kulhá dokumentace a vývojáři také ochabli. Takže paralelně s yumem nám začal vznikat fork DNF (jak se autor snaží propagovat, dnf neznamená prostě vůbec nic), knihovna hawkey jako API pro dotazování se na balíky RPM a jako knihovna pro řešení závislostí se používá libsolv ze SuSE. Vše má být samozřejmě lepší než yum. Důvod ke vzniku DNF a nepoužití něčeho jako zypp je ponechání určité zpětné kompatibility s yumem, ovšem implementace nad libsolv. Uvidíme, jak dopadne, až bude DNF umět to, co yum, zatím to vypadá nadějně.
Usage: yum [options] COMMAND Usage: dnf [options] COMMAND
List of Commands: List of Commands:
check Check for problems in the rp
check-update Check for available package check-update Check for available pa
clean Remove cached data clean Remove cached data
deplist List a package's dependencie
distribution-synchronization Synchronize in distribution-synchronization Synchron
downgrade downgrade a package downgrade downgrade a package
erase Remove a package or packages erase Remove a package or pa
fssnapshot Creates filesystem snapshots
groups Display, or use, the groups group Display, or use, the g
help Display a helpful usage mess help Display a helpful usag
history Display, or use, the transac history Display, or use, the t
info Display details about a pack info Display details about
install Install a package or package install Install a package or p
langavailable Check available languages
langinfo List languages information
langinstall Install appropriate language
langlist List installed languages
langremove Remove installed language pa
list List a package or groups of list List a package or grou
load-transaction load a saved transaction f
makecache Generate the metadata cache makecache Generate the metadata
provides Find what package provides t provides Find what package prov
reinstall reinstall a package reinstall reinstall a package
repo-pkgs Treat a repo. as a group of
repolist Display the configured softw repolist Display the configured
search Search package details for t search Search package details
shell Run an interactive yum shell
swap Simple way to swap packages,
update Update a package or packages
update-minimal Works like upgrade, but goes
updateinfo Acts on repository update in
upgrade Update packages taking obsol upgrade Upgrade a package or p
upgrade-to Upgrade a package on y
version Display a version for the ma
Gnomedie
Fedora je i ve vleku změn v Gnome, které se snaží seč může pasovat na prostředí pro idioty. Omlouvám se vývojářům za tento expresivní výraz, nicméně nejsem první ani poslední, kdo ho použil, a asi tedy poměrně dobře vystihuje cíle Gnome. Jemně mi to připomíná Firefox, který v každé verzi přehazuje čudlíky a provádí nesmyslné změny v UI v zájmu… nevím koho. V nejnovějším Gnome tak zmizela ikona NetworkManageru z horní lišty. Že celá lišta jen zabírá obrazovku, zatím zřejmě nikomu nevadí, ovšem na PC s několika profily drátových připojení nemáte jak to připojení změnit. Vtipné je i to, že na zamčené obrazovce zůstane sdružená ikonka reproduktoru a vypnutí PC, ovšem po kliknutí na ni se ukáže pouze ovládání hlasitosti a šmitec. Kategorizace aplikací v „Aktivitách“ zmizela už dříve, orientace je tedy naprosto stejně nemožná jako u Androidu, v Gnome 3.10 se opět objevují jakési skupiny, ale orientace stále nic moc. Směr, který Gnome nabírá s další integrací např. Facebooku, mi přijdě značne podlézavý, nesympatický a sobecký, vypadá jako druhý Android. Není divu, že prostředí jako XFCE nebo LXDE získávají na popularitě.
Bestovní usability usecase kůloidního Gnome 3.10
Displej manažér
Samostatnou kapitolu, kterou bych nejraději nazval Evergreen, je přihlašovací „display manager“. To, že nový GDM byl dlouho dobu nepoužitelný a stále má problémy s méně obvyklými situacemi (rozuměj je perfektní pro „normal use case“, ale jak nejste normal, jste v p…dachu), po tom, co ten starý byl odepsán pro zastaralost, se totéž stalo KDM. Takže vzniká nový SDDM, který je supr čupr Qt4, umí QtQuick téma, ale neumí XDMCP nebo přepínat klávesnice. K autorově cti je nutno říci, že na tom prý maká, tak snad se nedočkáme situace jako s GDM, kde autoři po implementaci pentliček ztratili zájem, protože XDMCP nikdo normální nepotřebuje, stejně tak jako nikdo normální nemá v seznamu uživatelů tisíce položek.
Možná že skutečně ne, protože další, co nás čeká, je Wayland, který se do F20 nedostal pro „nepoužitelnost“. Již teď mám husí kůži ze schizofrenie Xka vs. Wayland, kdy několik verzí nebude zase fungovat nic. A to je ještě ten lepší případ, protože obvykle to dopadne tak, že některé věci již nebudou fungovat nikdy, neboť už to je příliš minoritní funkce pro budoucnost, zatímco fade efekty mají budoucnost otevřenou. Souhlasím s autory Waylandu, že kód Xek už není téměř nikdo schopen spravovat a že je to návrh z minulého století, jen si vždy říkám, zda to současné bude lepší.
Zatím poněkud vývojové SDDM
Jounarldo vs. Syslogino 1:0
Neutuchajicí generátor problémů je i systemd, který po tom, co se etabloval jako PID1, explodoval a zabírá další a další domény unixových démonů. Tentokráte mu padl za oběť syslog a je již zcela nahrazen journald. Osobně journalctl občas použiji, ale mám s ním stejný problém jako se systemd – nevěřím mu. Stejně tak jako u systemd, který nemá ošetřeny některé méně obvyklé situace, především krizové, i journactl mi občas servíruje logy, které nechápu a nevím, zda přede mnou ve své boží prozřetelnosti neschová to či ono. Přesto, že vidím i jeho výhody, mám problém přijmout způsob, kterým je prezentuje. Celkem zajímavé je si přečíst dva roky starý komentář autora rsyslogd. Se systemd mám opakující se problémy s „automatickým“ vytvářením konzolí, zamrzáním konzolí/klávesnic u dlouho běžících strojů, restartováním, kdy systemd tvrdí, že mám stále aktivní sezení atd. Nejhorší, co jsem zažil, byla nemožnost aktivovat reboot kvůli chybějícímu souboru ctrl-alt-del.target. Krom toho je jak systemd, tak journald obtížně srozumitelný a z mého pohledu netransparentní. Jeden z prostých důkazů je i to, že většina lidí stále startuje do „init 5“ a nikoli „multi-user.target“.
Důvěrou mne nenaplňuje ani 32 binárek systemd-*, v /lib/systemd/, 400+ unit souborů s definicemi různých obezliček. Poněkud obtížně stravitelné je i to, že unity jsou ve formátu .ini souborů Windows, obsahují nedefinovanou (rozuměj dokumentovanou, ale neomezenou), neustále se rozrůstající skupinou direktiv s kryptickými názvy, podle toho, jak se látají různé situace, a journald log principem ze všeho nejvíc připomíná EventLog z Windows. Nerad bych abych vypadal jako odpůrce systemd, který jistě umožnil využití mnoha nových linuxových vlastností v jejich plné síle, ale vzdálení se unixovým principům, znemožnění interoperability a poněkud nešťastný přístup autorů způsobují přesně ten stav, který jsem popsal jako „nevěřím mu“.
Nepojmenovávejte a nekreslete pozadí
Kuriózní problémy vznikají ve Fedoře i s pojmenováními vydání a tentokráte i s pozadím (plochy). Co se týče pojmenování, téměř každé slovo je v nějaké zemi/jazyce sprosté, takže se vždy ozve někdo, jak strašně negativní to bude mít dopady, tentokrát někdo vytvořil i dlouhé vlákno diskuse o tom, zda podklad příliš nepřipomíná svastiku, na kterou jsou zvláště alergické německé orgány. Výjimečně paranoia nevyhrála, protože onen zapovězený symbol můžete vidět pouze, pokud byste si prohlédli pozadí v zrcadle… ehm.
Bobříci
Fedora se zapojila i do úžasně nového nápadu z Mozilly na sbírání „odznáčků“. Zatímco dříve se bobříci šili na košile, nebo lepily či razítkovaly do průkazek, dnes sbíráme sociální obrázky. Má to být styl satisfakce pro aktivní lidi, je to jistě hezké, ale fakticky si je tak leda můžete… vystavit na blogu.
Copr
Daleko zajímavější mi přijde poněkud nepropagovaný project „copr“, což tentkráte není oblíbené pojmenování vztahu k práci, ale build systém pro libovolné SRPM, ze kterého vám vytvoří yum repozitář s výslednými RPM, takže každý si může nechat sestavit upravený balík nějaké aplikace z Fedory, aniž by si instaloval na svůj počítač kompletní vývojové prostředí.
Lidé za Fedorou
Fedora 20 by pomalu, ale jistě mohla dostat nálepku „česká distribuce“. Množství českých jmen za nejrůznějšími komponentami Fedory totiž vytrvale narůstá. Jaroslav Řezník se dokonce stal Program Managerem – co to obnáší, se ho zeptejte raději sami, abych jen tak od boku vyjmenoval další: Bohuslav Kabrda, Miroslav Suchý – copr + Developer Assistant GUI, Pavel Šimerda – Network Manager, M. Bříza- SDDM, Perl 5.18 – Jitka Plesníková, Ruby on Rails 4.0 – Vít Ondruch, Josef Stříbný.
Jednou z nejhorších lidských ztrát pro Fedoru pak byla letošní smrt Setha Vidala, kterého na kole srazilo auto. Seth se podílel na vývoji mnoha součástí Fedory, krom jiného i na copru.
Zátah
Abychom ale nekončili tak ponuře, je nutno říci, že Fedora 20 je, „aspoň jak on říká“, další výborné vydání Fedory a vrtochy starého pisálka nesmíte brát vážně, protože Fedora se skládá z mnohem většího množství komponent, než je těch pár výše vyjmenovaných, naopak je zde nemálo pozitivních kroků, jako např. pokračující rozšiřování Network Manageru a jeho možnost ovládat vše i z příkazové řádky, virtualizace ARMu na x86, nový klikací instalátor aplikací, nikoli balíčků – většina uživatelů je bez instalátoru aplikací prostě ztracena, kdo ví proč. (Trošku mne děsí ikonka nákupní tašky, ale je to snad jen ikonka.) Dát to vše dohromady, aby to nebyla katastrofa, je velký kus obdivuhodné práce, zvláště, když máte ještě tu drzost neustále porušovat základní pravidlo: když to funguje, tak na to nesahej.
Your mileage may vary.
Neboli: vaše zkušenost může být poznamenána vaším hardware. Svádět jakékoli nefunkčnosti na tu či onu verzi či distribuci je bláhové, fakticky je rozbitý jen váš počítač. ;)
ČLÁNKY DO MAILU
