Kontenery i bajery

Ubuntu można lubić lub nienawidzić i podobnie jest z pomysłami Marka Shuttlewortha. Jednak chyba każdy przyzna, że to właśnie ta osoba stoi za dystrybucją Linuksa, która spopularyzowała pingwina, a można nawet śmiało rzecz, że wprowadziła go na biurko. To nie Gentoo, Slackware, Debian, RedHat, Fedora czy OpenSUSE kojarzy się przeciętnemu Kowalskiemu z Linuksem tylko właśnie Ubuntu.

Ubuntu 16.04 LTS to pierwsza dystrybucja dla mas, w której możemy użyć kontenerów, czyli VFS zawierających aplikację i jej wszystkie potrzebne do działania zasoby (skompilowane biblioteki, pliki konfiguracyjne, pliki graficzne etc.), wraz z odwzorowaniem struktury katalogów w systemie. Kontenery NIE zastąpią i nawet NIE próbują zastępować tradycyjnej formy dystrybucji oprogramowania na Linuksa. To jest rozwiązanie równoległe, które ma wiele zalet, jak i wiele wad – i w zależności od potrzeb środowiskowych użytkownika, zależy ich użyteczność, a nawet sens istnienia. Jeśli ktoś ma teraz zamiar zacząć biadolić, że po co mu to jak jest apt‑get, aptitude, zypper, pacman czy cokolwiek innego, niech się jeszcze raz zastanowi nad tym co właśnie przed chwilą przeczytał. ;)

Zalety:

• deweloper może przygotować program raz i zapomnieć o jego istnieniu na długie lata ;)
• deweloper komercyjnego programu nie musi udzielać wsparcia dla wszystkich dystrybucji lub rezygnować ze wsparcia na rzecz tylko najpopularniejszych
• użytkownik może pobrać program wprost od programisty, bez pośredniczenia w tym legionu paczkujących
• użytkownik może uruchomić program na wielu bardzo różniących się od siebie dystrybucjach
• użytkownik może w łatwy sposób przenosić oprogramowanie
• użytkownik może łatwo decydować o miejscu docelowym na oprogramowanie bez wachlowania symlinkami
• użytkownik może łatwo przetestować dany program bez konieczności dodawania repozytoriów i ściągania dodatkowych bibliotek
• użytkownikowi łatwiej jest utrzymać higienę systemu
• użytkownik może przechowywać kilka wersji tego samego programu bez problemów z zależnościami
• użytkownik może łatwo ograniczyć uprawnienia aplikacji

Wady:

• duży rozmiar kontenerów ze względu na to, że nie odczytują np. bibliotek z systemu tylko muszą je mieć wewnątrz siebie
• wymagane repozytorium z kontenerami i system patchowania delta lub żmudne ręczne aktualizacje jak ma to miejsce np. na Windows
• aktualizacja bibliotek itp. spada na barki twórcy programu (czyli można się spodziewać, że będzie okazjonalna - również jak na Windows)
• znacznie dłuższe uruchamianie programu
• brak integracji ze środowiskiem graficznym (tray, ppm w managerze plików etc.)

Moim zdaniem to jest przyszłość dystrybucji aplikacji na Linux. Oczywiście nie wszystkich, przecież żaden szaleniec nie będzie kontenerował mikrobów w CLI jak np. dd czy tree. Jest to głównie narzędzie dla producentów komercyjnego oprogramowania, ponieważ znosi różnice pomiędzy wersjami i edycjami distro, a także zdejmuje z dewelopera konieczność doglądania i przygotowywania paczek na ich niezliczoną ilość. Czyli tak jak na Windows czy OS X. :)

Dla mnie prywatnie to także wygodne narzędzie, ponieważ lubię być obsesyjnie niezależny od połączenia z internetem, a jak wszyscy wiemy, obecnie Linuksa trudno używać bez dostępu do sieci (w kwestii instalacji programów rzecz jasna).

Mamy kilka konkurujących ze sobą formatów: Snappy, Flatpak i AppImage. W dzisiejszym wpisie zajmę się tylko tym ostatnim, jako wg. mnie najprostszym i najciekawszym.

Jak prostym? Wystarczy pobrać plik i nadać mu atrybut wykonywalny (w Linux Mint pod prawym przyciskiem myszy należy wybrać "Właściwości", przejść na zakładkę "Uprawnienia" i zaznaczyć "Wykonanie"). To wszystko! Po takim zabiegu jedyne co musi zrobić użytkownik to dwukliknąć na plik. Resztą zajmie się loop (*.appimage to tak naprawdę obraz *.iso).

Oczywiście takie pliki można dopisywać do docków, apletów, czegokolwiek w taki sam sposób jak binarki czy aktywatory. Nie przeszkadzają spacje, ani znaki specjalne w nazwie pliku i można go umieszczać w dowolnym miejscu w systemie, a nawet poza.

Czym to się różni od „modułów” w np. Slax ? Między innymi tym, że wszystko uruchamiane jest na żądanie, a nie wraz ze startem systemu.

Jak wygląda integracja ze środowiskiem graficznym? Nijak… Jako jeden z przykładów, a do tego kluczowy z punktu widzenia wygody użytkownika jest skojarzenie formatów plików z aplikacją. Przynajmniej w Linux Mint 17.3, na którym to testowałem, owszem działa, ale tylko do czasu restartu.

To samo dotyczy ikon aplikacji. Dopóki są cache’owane dopóty zastąpią domyślne.

Bezpieczeństwo

Podobnie jak w przypadku paczek w repozytoriach, użytkownik skazany jest na zaufanie do paczkującego (z tym że tutaj „paczkujących” jest naparstek, a samo rozwiązanie dość niszowe, więc...). Tylko Krita udostępniła własną paczkę AppImage na swojej stronie. Pewnym półśrodkiem może być piaskownica, którą trzeba pobrać i doinstalować. Wówczas format *.appimage skojarzony zostanie ze skryptem i trzeba też zdjąć atrybut wykonywalny z pliku (z wykonywalnym uruchomi się normalnie, bez ograniczeń). Sandbox to jednak ubogi ponieważ nie pozostawia wyboru użytkownikowi: blokuje cały dostęp do systemu plików (czyli np. nie można zapisać owocu swoich prac).

W Linux Mint wystarczy dwukliknąć na pobranej paczce i kliknąć w przycisk "Zainstaluj pakiet".

Od tej pory uruchamianie aplikacji *.appimage odbywa się tak samo, z tą różnicą że użytkownik zostanie o tym poinformowany.