r   e   k   l   a   m   a
r   e   k   l   a   m   a

Drastyczna zmiana struktury Linuksa otwiera drogę do swobody programistów i użytkowników

Strona główna AktualnościOPROGRAMOWANIE

Nie tak dawno Matthew Miller, programista stojący na czele społeczności Fedory, dał do zrozumienia, że era linuksowych dystrybucji jako podstawowego kanału dystrybucji oprogramowania o otwartym kodzie źródłowym ma się ku końcowi. Nawet tak popularne Ubuntu nie budzi już dziś zainteresowania porównywalnego z tym, jakie budziło w minionej dekadzie, nie mówiąc już o dystrybucjach skierowanych do profesjonalistów. Tymczasem w świecie Linuksa pojawiają się nowe, radykalne pomysły, które mogą na nowo rozbudzić zainteresowanie programistó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 Oprogramowania równie wybitna co kontrowersyjna (to on jest autorem takich wynalazków jak demon inicjalizacji systemd czy podsystem dźwięku pulseaudio), przedstawił na łamach swojego bloga jeden z takich rewolucyjnych pomysłów, który jeśli się przyjmie, może na dobre zakończyć erę typowych dystrybucji GNU/Linux. Chce on, wykorzystując możliwości tkwiące w systemd oraz systemie plików btrfs, całkowicie zmienić sposób, w jaki przygotowywane, rozpowszechniane i instalowane jest oprogramowanie dla Linuksa.

Zdaniem Poetteringa tradycyjne podejście – dystrybucji jako skrzynki z narzędziami – to świetna sprawa dla jednostek, które chcą zbudować dopasowane do swoich potrzeb systemy. Jest to jednak bardzo niewygodny model we wszystkich innych scenariuszach, w których buduje się jeden konkretny obraz systemu dla dużej liczby instalacji, czy to na urządzeniach wbudowanych, czy serwerowych instancjach w chmurze. Tam nie instaluje się pakietów ani ich nie usuwa. Do dyspozycji mamy ściśle określony zbiór plików, bez możliwości zmiany posiadanego zestawu narzędzi.

r   e   k   l   a   m   a

Jest to też model bardzo niewygodny dla twórców oprogramowania. Zmuszeni są oddać dystrybucję swoich projektów w ręce opiekunów takiej Fedory czy innego Debiana i podporządkować się ich cyklowi wydawniczemu (często wolniejszemu, niż by twórca oprogramowania chciał). W takich warunkach praktycznie niemożliwe jest też przeprowadzenie rzetelnych testów – liczba możliwych kombinacji zainstalowanego oprogramowania systemowego jest nieporównywalnie większa, niż np. w OS X. Swoboda dobierania przez użytkowników różnych wersji bibliotek, wtyczek i jednocześnie uruchomionych aplikacji, 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 nie sprowadzają się tylko do numerów wersji zainstalowanego oprogramowania – w praktyce nie istnieje nawet jednolity standard umiejscowienia plików systemowych w katalogach.

Dla użytkowników sytuacja taka jest zaś o tyle niedogodna, że lubią mieć dużo świeżego oprogramowania, tymczasem może się okazać, że w oficjalnych repozytoriach albo nie będzie tego co chcą, albo będzie jakaś starsza wersja. Przyzwyczaili się zresztą do wygodnego znajdowania, instalowania i aktualizowania oprogramowania w Androidzie czy iOS-ie – bez scentralizowanego sklepu z aplikacjami mogą czuć się zagubieni.

Istnieją już metody zaradzenia tym niedogodnościom, ale żadna z nich nie jest kompleksowa. Ot np. oprogramowanie ze sklepu Ubuntu skupia się wyłącznie na desktopowych aplikacjach, w ogóle nie rozwiązując problemu z systemem i jego narzędziami. Chrome OS skupia się na systemie operacyjnym, ale wyłącznie na komputerach osobistych. Docker to tylko kontenery, niewygodne w odniesieniu do desktopowych aplikacji.

Zespół programistów pracujących nad systemd pracuje nad rozwiązaniem uniwersalnym. Będzie ono kompatybilne z typowymi dystrybucjami jako skrzynkami z narzędziami, ale pozwoli na uporanie się z wymienionymi wyżej problemami we wszystkich możliwych scenariuszach zastosowań Linuksa. Pozwoli producentom oprogramowania na łatwe zbudowanie swoich aplikacji w odpowiednim dla nich środowisku, łatwe instalowanie powstałych tak pakietów przez użytkowników we wszystkich linuksowych dystrybucjach, zunifikowanie systemu aktualizacji całości zainstalowanego oprogramowania, a także zapewnienie odpowiednich narzędzi kryptograficznych, dzięki którym oprogramowanie będzie można zabezpieczyć przed ingerencją stron trzecich.

Niemożliwe? Jeszcze kilka lat temu faktycznie byłoby to niemożliwe. Teraz Poettering chce wykorzystać udostępnianą przez system 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ębnionych podprzestrzeniach nazw systemu plików, do których można uzyskać dostęp przez najwyższego poziomu subwolumen (najczęściej będzie to root), ale które można też swobodnie montować w wybranym miejscu.

Na bazie tej konstrukcji powstają migawki takie jak usr, root, runtime, framework, app i home. Przykładowo – usr jest pełnym drzewem /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że jednak wymagać innego zestawu bibliotek, niż dostarczane przez Fedorę w tej wersji, więc dostaje dostęp do subwolumentu typu runtime, np. runtime:org.gnome.GNOME3_20:x86_64:3.20.1 – zawierającego tylko konkretne biblioteki GNOME. Aplikacja może potrzebować własnego szkieletu systemu operacyjnego – wtedy skorzysta z subwolumenu typu root, np. root:revolution:org.fedoraproject.FedoraWorkstation:x86_64, w którym znajdują się odpowiednio wypełnione katalogi /etc i /var. Aplikacja może wreszcie też być kompletnym pakietem, normalnie instalowanym 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łkiem ciekawie. Podczas startu montowany jest katalog root z jednego z subwolumenów root a następnie pasujący do niego (z tego samego distro i o tej samej architekturze) subwolumen usr. Kiedy użytkownik zaloguje się do systemu, jego system plików w /home montowany jest z ostatniej migawki jego subwolumenu typu home. Kiedy użytkownik chce uruchomić kontener z systemem operacyjnym, łączy się odpowiednie subwolumeny root i usr. Gdy trzeba uruchomić aplikację, podpinany jest jej subwolumen app wraz odpowiednim subwolumenem runtime. Wszystkie te subwolumeny mogą jednocześnie istnieć w wielu wersjach, nie wchodząc ze sobą w konflikty. Rozwiązuje to też ewentualne problemy z aktualizacjami – jeśli dany subwolumen nie jest w stanie wystartować, system odpala jego wcześniejszą migawkę.

Może to wydawać się skomplikowane, ale przy automatycznym zarządzaniu montowaniem subwolumenów przez systemd, użytkownik tego nawet nie widzi. Miejsce także nie jest marnowane zwielokrotnieniem partycji – btrfs zapewnia automatyczną deduplikację tych samych plików. W przedstawionym przez Lennarta przykładzie można zobaczyć, jak na jednym wolumenie btrfs może współistnieć kilka wersji Fedory, Mageia, Arch Linux, biblioteki GNOME i KDE, LibreOffice i Firefox, oraz kilku użytkowników. Aktualizacja subwolumenów jest również trywialna, dzięki moż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 wolumen jako aktualny.

Doprowadzenie desktopowego Linuksa do takiej postaci zajmie jeszcze 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óre istnieją tylko na papierze, w szczególności związanych z szyfrowaniem, uwierzytelnianiem i weryfikowaniem poprawności danych. Na pewno też stara linuksowa gwardia będzie na ten nowy szalony pomysł Poetteringa patrzyła tak jak wcześniej patrzyła na pulseaudio czy systemd. Jednak to właśnie te tak bardzo nieuniksowe rozwiązania są dziś standardem w świecie desktopowego Linuksa, więc czemu i ten pomysł nie miałby okazać się sukcesem? Jak do tej pory nikt nie pokazał niczego równie uniwersalnego, co rozwiązywałoby wszystkie wcześniej wymienione problemy.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.