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.