Drastyczna zmiana struktury Linuksa otwiera drogę do swobody programistów i użytkowników
Nie tak dawno Matthew Miller, programista stojący na czelespołeczności Fedory, dałdo zrozumienia, że era linuksowych dystrybucji jako podstawowegokanału dystrybucji oprogramowania o otwartym kodzie źródłowym masię ku końcowi. Nawet tak popularne Ubuntu nie budzi już dziśzainteresowania porównywalnego z tym, jakie budziło w minionejdekadzie, nie mówiąc już o dystrybucjach skierowanych doprofesjonalistów. Tymczasem w świecie Linuksa pojawiają się nowe,radykalne pomysły, które mogą na nowo rozbudzić zainteresowanieprogramistów tym systemem, rozwiązując zarazem wiele problemów,doskwierających do tej pory jego zwykłym użytkownikom.
Lennart Poettering, postać w świecie Wolnego Oprogramowaniarównie wybitna co kontrowersyjna (to on jest autorem takichwynalazków jak demon inicjalizacji systemd czy podsystem dźwiękupulseaudio), przedstawił na łamach swojego bloga jeden z takichrewolucyjnych pomysłów, który jeśli się przyjmie, może na dobrezakończyć erę typowych dystrybucji GNU/Linux. Chce on,wykorzystując możliwości tkwiące w systemd oraz systemie plikówbtrfs, całkowicie zmienićsposób, w jaki przygotowywane, rozpowszechniane i instalowanejest oprogramowanie dla Linuksa.
Zdaniem Poetteringa tradycyjne podejście – dystrybucji jakoskrzynki z narzędziami – to świetna sprawa dla jednostek,które chcą zbudować dopasowane do swoich potrzeb systemy. Jest tojednak bardzo niewygodny model we wszystkich innych scenariuszach, wktórych buduje się jeden konkretny obraz systemu dla dużej liczbyinstalacji, czy to na urządzeniach wbudowanych, czy serwerowychinstancjach w chmurze. Tam nie instaluje się pakietów ani ich nieusuwa. Do dyspozycji mamy ściśle określony zbiór plików, bezmożliwości zmiany posiadanego zestawu narzędzi.
Jest to też model bardzo niewygodny dla twórców oprogramowania.Zmuszeni są oddać dystrybucję swoich projektów w ręce opiekunówtakiej Fedory czy innego Debiana i podporządkować się ich cyklowiwydawniczemu (często wolniejszemu, niż by twórca oprogramowaniachciał). W takich warunkach praktycznie niemożliwe jest teżprzeprowadzenie rzetelnych testów – liczba możliwych kombinacjizainstalowanego oprogramowania systemowego jest nieporównywalniewiększa, niż np. w OS X. Swoboda dobierania przez użytkownikówróżnych wersji bibliotek, wtyczek i jednocześnie uruchomionychaplikacji, w tylu różnych linuksowych dystrybucjach, czyni budowęi testowanie aplikacji ogromnie wymagającym zadaniem. Sytuacjępogarsza tylko fakt, że różnice między dystrybucjami niesprowadzają się tylko do numerów wersji zainstalowanegooprogramowania – w praktyce nie istnieje nawet jednolity standardumiejscowienia plików systemowych w katalogach.
Dla użytkowników sytuacja taka jest zaś o tyle niedogodna, żelubią mieć dużo świeżego oprogramowania, tymczasem może sięokazać, że w oficjalnych repozytoriach albo nie będzie tego cochcą, albo będzie jakaś starsza wersja. Przyzwyczaili się zresztądo wygodnego znajdowania, instalowania i aktualizowaniaoprogramowania w Androidzie czy iOS-ie – bez scentralizowanegosklepu z aplikacjami mogą czuć się zagubieni.
Istnieją już metody zaradzenia tym niedogodnościom, ale żadnaz nich nie jest kompleksowa. Ot np. oprogramowanie ze sklepu Ubuntuskupia się wyłącznie na desktopowych aplikacjach, w ogóle nierozwiązując problemu z systemem i jego narzędziami. Chrome OSskupia się na systemie operacyjnym, ale wyłącznie na komputerachosobistych. Docker to tylko kontenery, niewygodne w odniesieniu dodesktopowych aplikacji.
Zespół programistów pracujących nad systemd pracuje nadrozwiązaniem uniwersalnym. Będzie ono kompatybilne z typowymidystrybucjami jako skrzynkami z narzędziami, ale pozwoli nauporanie się z wymienionymi wyżej problemami we wszystkichmożliwych scenariuszach zastosowań Linuksa. Pozwoli producentomoprogramowania na łatwe zbudowanie swoich aplikacji w odpowiednimdla nich środowisku, łatwe instalowanie powstałych tak pakietówprzez użytkowników we wszystkich linuksowych dystrybucjach,zunifikowanie systemu aktualizacji całości zainstalowanegooprogramowania, a także zapewnienie odpowiednich narzędzikryptograficznych, dzięki którym oprogramowanie będzie możnazabezpieczyć przed ingerencją stron trzecich.
Niemożliwe? Jeszcze kilka lat temu faktycznie byłoby toniemożliwe. Teraz Poettering chce wykorzystać udostępnianą przezsystem plików btrfs konstrukcję subwolumenów.Nie mają one nic wspólnego z subwolumenami ZFS, nie sąurządzeniami blokowymi. Należy o nich myśleć jak o wyodrębnionychpodprzestrzeniach nazw systemu plików, do których można uzyskaćdostęp przez najwyższego poziomu subwolumen (najczęściej będzieto root), ale które można też swobodnie montować w wybranymmiejscu.
Na bazie tej konstrukcji powstają migawki takie jak usr, root,runtime, framework, app i home. Przykładowo – usr jest pełnymdrzewem /usr w konkretnej wersji, który można sobie oznaczyćwedług schematu, np.usr:org.fedoraproject.FedoraWorkstation:x86_64:23.4 (czyli kompletne/usr z 64-bitowej Fedory 23.4). Aplikacja w takim systemie możejednak wymagać innego zestawu bibliotek, niż dostarczane przezFedorę w tej wersji, więc dostaje dostęp do subwolumentu typuruntime, np. runtime:org.gnome.GNOME3_20:x86_64:3.20.1 –zawierającego tylko konkretne biblioteki GNOME. Aplikacja możepotrzebować własnego szkieletu systemu operacyjnego – wtedyskorzysta z subwolumenu typu root, np.root:revolution:org.fedoraproject.FedoraWorkstation:x86_64, w którymznajdują się odpowiednio wypełnione katalogi /etc i /var.Aplikacja może wreszcie też być kompletnym pakietem, normalnieinstalowanym w /opt – wówczas trafi do subwolumenu o nazwie np. app:org.libreoffice.LibreOffice:GNOME3_20:x86_64:133
Popakowany w taką strukturę Linux zachowuje się całkiemciekawie. Podczas startu montowany jest katalog root z jednego zsubwolumenów root a następnie pasujący do niego (z tego samegodistro i o tej samej architekturze) subwolumen usr. Kiedy użytkownikzaloguje się do systemu, jego system plików w /home montowany jestz ostatniej migawki jego subwolumenu typu home. Kiedy użytkownikchce uruchomić kontener z systemem operacyjnym, łączy sięodpowiednie subwolumeny root i usr. Gdy trzeba uruchomić aplikację,podpinany jest jej subwolumen app wraz odpowiednim subwolumenemruntime. Wszystkie te subwolumeny mogą jednocześnie istnieć wwielu wersjach, nie wchodząc ze sobą w konflikty. Rozwiązuje toteż ewentualne problemy z aktualizacjami – jeśli dany subwolumennie jest w stanie wystartować, system odpala jego wcześniejsząmigawkę.
Może to wydawać się skomplikowane, ale przy automatycznymzarządzaniu montowaniem subwolumenów przez systemd, użytkowniktego nawet nie widzi. Miejsce także nie jest marnowanezwielokrotnieniem partycji – btrfs zapewnia automatycznądeduplikację tych samych plików. W przedstawionym przez Lennartaprzykładzie można zobaczyć, jak na jednym wolumenie btrfs możewspółistnieć kilka wersji Fedory, Mageia, Arch Linux, bibliotekiGNOME i KDE, LibreOffice i Firefox, oraz kilku użytkowników.Aktualizacja subwolumenów jest również trywialna, dziękimożliwości aktualizacji obrazów systemowych przez pliki różnicowe(delta). Systemd tworzyłby migawkę obecnej wersji, zmieniałby jąplikiem różnicowym, a następnie montował uaktualniony wolumenjako aktualny.
Doprowadzenie desktopowego Linuksa do takiej postaci zajmiejeszcze trochę czasu, choć już w 2015 możemy spodziewać sięwydań Fedory, w których pierwsze elementy tego rozwiązania będąwprowadzane. Wciąż trzeba opracować kilka mechanizmów, któreistnieją tylko na papierze, w szczególności związanych zszyfrowaniem, uwierzytelnianiem i weryfikowaniem poprawności danych.Na pewno też stara linuksowa gwardia będzie na ten nowy szalonypomysł Poetteringa patrzyła tak jak wcześniej patrzyła napulseaudio czy systemd. Jednak to właśnie te tak bardzo nieuniksowerozwiązania są dziś standardem w świecie desktopowego Linuksa,więc czemu i ten pomysł nie miałby okazać się sukcesem? Jak dotej pory nikt nie pokazał niczego równie uniwersalnego, corozwiązywałoby wszystkie wcześniej wymienione problemy.
