Nejdřív tě ignorují, pak se ti smějí, pak s tebou bojují a nakonec zvítězíš – motto společnosti Red Hat, které pochází z úst Mahátmy Gándhího lze celkem hezky použít jako parafrázi i pro životní pouť „balíčkovacího systému“ PBI v operačním systému PC-BSD (dnes TrueOS). Red Hat, který byl posledních ±25 let výstavní skříní balíčkovacího systému RPM, pozvolna zavádí další a další systémy, které de facto z konceptu balíčků s řešenými závislostmi odbočují směrem k PBI (řečeno slušně), resp. Windows (řečeno bez obalu politické korektnosti).
Po systému Flatpak přichází Fedora 29 se systémem Fedora Modularity s jednoduchou možností provozu různých verzí programů na různých verzích Fedory. Není ode mě úplně korektní míchat systém Modularity s Flatpaky, potažmo PBI a Windows, přesto však lze vnímat tuto novinku jako další drobný krůček od ortodoxně čistého operačního systému s jádrem ctícím princip KISS (to porušil už systemd), poskytujícím přístup blíže k hardwaru bez mezivrstev (to porušilo PulseAudio) a nesoucího si jen jednu verzi a jednu instalaci daného nástroje (což narušuje jak Flatpak, tak nově systém Modularity).
Klasické balíčkování proti novým výzvám
Dvě fundamentálně odlišné krajní ideje v oblasti distribuce a instalace programů jsou ve světě využívány. Nelze proteď a navěky říci, že jedna je lepší a ta druhá by měla upadnout v zapomenutí, neboť vždy se najde určité množství fanoušků obou přístupů.
Tím prvním je „klasická microsoftí cesta“. Historicky používána zejména ve Windows, představuje snadnou, ač poněkud dřevní a humpoláckou metodu instalace a provozu aplikací. Instalátory programů si jednoduše táhnou své závislosti. Historicky tak třeba instalace her vypadaly tak, že se nainstalovala samotná hra, po ní následovala instalace příslušné verze DirectX API (bez ohledu na to, jaká byla obsažena v systému – často vyšší), instalace nějakých kodeků (opět bez ohledu na cokoli) a případně nějaká další „zhůvěřilost“ jako třeba .NET framework (přepsáním ovladačů Catalyst pod .NET svého času naštvala velkou část zákazníků ATI).
S příchodem všeobecně dostupného a levného internetu se DirectX či .NET dodatky začaly během instalace hry stahovat z internetu (tj. ze serverů Microsoftu), ale princip zůstal stejný: tvůrce hry/programu prostě sám rozhodl, co jeho věc vyžaduje za závislosti a ty do instalačky přidal. A Windows dlouhá léta nebyly schopny jakkoli instalátorům sdělit, že příslušná verze DirectX (či dokonce vyšší) je už v systému přítomna.
Druhý přístup zpopularizovaly zejména různé linuxové distribuce postavené na majoritních balíčkovacích systémech RPM a DEB. Nemá smysl zde na těchto stránkách nosit dříví do Athén či sovy do lesa, balíčkovací systémy zkrátka řeší závislosti automaticky a chybějící prvky stahují/instalují v případě potřeby. V systému se také nenachází X různých verzí toho či onoho prvku, kdy každou z nich si nainstalovala jiná aplikace bez ohledu na zbytek systému.
PC-BSD, Fedora a jiní
PC-BSD / PBI
Nyní do toho ale přichází Fedora 29 s možností používání různých verzí knihoven a dává tak do pléna další alternativní přístup, který vedle PBI balíčků z PC-BSD/TrueOS či systémů jako Flatpak, Snap a AppImage evokuje spíše cestu Microsoft Windows, než klasický linuxový přístup.
Kritické hlasy na tuto modulárnost schovanou ve Fedora Modularity jistě zaznějí. Jde o velmi odlišný přístup k čistotě operačního systému a aplikací, který je téměř protipólem toho, co dělá třeba OpenBSD, tradičně považované za nejméně děravý operační systém vůbec.
Jaká čeká Fedora Modularity budoucnost, teprve uvidíme. Jisté je to, že běžný uživatel jménem František se tím netrápí, dokud má svoje data přístupná v podobě nějakého GUI, na které je zvyklý. Bez ohledu na to, jak aplikace v pozadí toho všeho fungují.
Diskový prostor už dávno není problém
Dobře tedy, připusťme na chvíli, že žijeme v době, kde řešit závislosti tak dokonale, jak to umí balíčkovací systémy, není nutné. Otázkou je, zdali si to můžeme s ohledem na úložný prostor dovolit. Odpověď je samozřejmě: ano. Úsloví paměť je levná platí už řadu let a nijak jej neovlivní ani občasné cenové kartely výrobců paměťových čipů či duopol na poli pevných disků (WD, Seagate).
Rozdíl mezi přítomností jediné verze dané knihovny či pěti jejích verzí na drahém SSD je obvykle rozdílem v řádku stovkách kB či maximálně desítkách MB. Tedy někde na úrovni několika málo sekund záznamu 4k/H.265 videa z běžného mobilního telefonu dneška. Paměť je levná, paměť je levná, paměť je levná. A příští rok bude ještě levnější. A další rok ještě víc …
Pokud se však uživatel nedokáže smířit s myšlenkou, že má na svém SSD takový nepořádek, že se mu na něm povaluje pět verzí dané knihovny, ač by stačila jen jedna, pak se můžeme hypoteticky ptát, zdali má podobný pořádek ve skříni s prádlem (patrně ano) či desítkách tisíc fotografií v mobilu (patrně ne). Vše je jen záležitostí toho, kterak se smířit v hlavě s jiným přístupem k věci. To nyní čeká uživatele Fedory, pokud se rozhodnou tuto novou možnost využívat naplno, stejně jako je to čekalo s příchodem Flatpaků.
Idea modularity
Z popisu systému Modularity dýchá, že vývojáři Fedory hledali řešení určitého problému, který nebylo možné ve standardním RPM realizovat. Přišli tak s možností držet vedle sebe nezávislé vývojové cykly jednotlivých nástrojů (prezentováno je to na příkladu node.js) a samotného operačního systému (zde tedy linuxové distribuce Fedora). Idea je to v podstatě elegantní, technické provedení, případná designová úskalí a z nich plynoucí bezpečnost si netroufám soudit.
Zajímavá je v onom popisu ještě zmínka o CentOS. Ano, správně je konstatováno, že desktopový testovací prostor RHELu – zvaný Fedora – potřebuje trochu jinou kadenci nových verzí programů a ustojí i trochu méně ortodoxní přístup k jistotě bezpečnosti nových verzí než enterprisový systém typu CentOS. Zde se Modularita může ukázat jako další „prvek ekosystému“, který učiní věci příjemnějšími (ať již pro vývojáře nebo uživatele), zejména v kontextu zmíněné možnosti produkovat touto cestou aktivně udržované nové verze kontejnerů.
Modularita samozřejmě nepředstavuje konceptuální náhradu za balíčkovací systémy typu RPM. Ale i ona, stejně jako Flatpaky či právě kontejnery, ukazuje další odlišný přístup k distribuci softwaru v rámci operačního systému. RPM či DEB tu s námi jsou už desítky let a o jejich další budoucnost se nejspíš bát nemusíme (byť osobně bych si více vsadil na DEB).
ČLÁNKY DO MAILU