Kilka tygodni temu, Canonical ogłosił wsparcie dla mechanizmu dostarczania aplikacji Snap, który może obsługiwać aplikacje mobilne, desktopowe i serwerowe. Ogłoszenie to poruszyło niektórych członków społeczności linuksowej, którzy widzieli niewiele dowodów na to, że jakakolwiek inna dystrybucja Linuksa wspiera Snaps.
Snap jest próbą firmy Canonical udoskonalenia mechanizmu pakowania i dostarczania aplikacji na platformie linuksowej. Pochodzenie Snap znajduje swoje korzenie w Click, rozwiązanie, które Canonical stworzył dla swojej platformy mobilnej z powrotem w 2014 roku, do obsługi złożoności dostarczania aplikacji do Ubuntu użytkowników telefonów i tabletów, ekosystem znacznie różni się od komputerów stacjonarnych i serwerów. Dodatkowo, mobile również potrzebował ograniczyć aplikacje i sandbox je, tak aby nie zagrozić całej platformie.
Click pozwolił deweloperom wiązać wszystkie zależności w jednym pakiecie aplikacji, więc użytkownicy i deweloperzy nie musieli się martwić o konflikty systemów i bibliotek aplikacji. Pozwoliło to programistom na korzystanie z najnowszych bibliotek w swoich aplikacjach, aby zaoferować nowe funkcje, ponieważ były one oddzielone od bibliotek zainstalowanych w systemie.
Beyond Mobile to Servers and IoT
Click ewoluował w Snap, a Canonical rozszerzył jego potencjalne zastosowanie na serwer, chmurę, Internet Rzeczy (IoT) i przestrzenie desktopowe. Wraz z wydaniem Ubuntu 16.04 w kwietniu, Canonical oficjalnie przyniósł Snap do pulpitu Ubuntu.
Canonical jest również rozwój Snappy Ubuntu Core, maleńki Linux oparty system operacyjny dla dużych wdrożeń kontenerów w chmurze, urządzeń IoT i wiele więcej, i wszystko, co potrzebuje przejściowych aktualizacji i mały footprint. Snappy Ubuntu Core działa mniej więcej tak jak Google Chrome OS i CoreOS, gdzie oferuje przejściowe aktualizacje oparte na obrazie dla systemu i aplikacji, które mogą być cofnięte. Jednocześnie oferuje ograniczenie, które jest znane w świecie kontenerów.
Snap jest duszą tej technologii.
Linux Mess of App Delivery
Istniejący model dostarczania aplikacji na Linuksie ma wiele wad. Świat Linuksa jest w większości podzielony na dwa obozy pakowania aplikacji: rpm i deb. Ponadto, istnieją różne wersje tych samych dystrybucji, które używają różnych bibliotek, więc staje się to dość trudne dla twórców aplikacji do pakowania aplikacji dla Linuksa.
W rezultacie, twórcy aplikacji nie mogą skorzystać z najnowszych bibliotek i zaoferować więcej funkcji swoim użytkownikom, jeśli dystrybucja wciąż używa starszych bibliotek.
W większości przypadków, twórcy aplikacji open source nie pakują swoich aplikacji dla dystrybucji. Popularne lub znane od dawna aplikacje są zazwyczaj pakowane przez twórców dystrybucji. Nowsze lub mniej popularne są albo pakowane przez upstream dla każdego distro, które chcą wspierać, albo nie są oferowane jako pakiet distro w ogóle. Kiedy nowa wersja aplikacji zostaje wydana, deweloperzy testują ją, a następnie udostępniają ją dla distro. Jak widać, zamiast dewelopera aplikacji piszącego tylko jedną aplikację dla całej platformy, którą w tym przypadku jest Linux, jest wielu ludzi dostarczających tę aplikację użytkownikom.
To dodaje więcej złożoności.
W niektórych przypadkach Windows i MacOS otrzymują najnowsze wersje natychmiast, jako że aplikacje są pakowane przez głównych deweloperów, podczas gdy dystrybucje Linuksa mogą zająć trochę czasu. To nie wszystko; niektóre dystrybucje dostają je szybko, a niektóre muszą czekać tygodniami lub miesiącami.
W przypadku komercyjnych aplikacji, takich jak Skype, Dropbox, Chrome, to na głównym deweloperze spoczywa obowiązek pakowania aplikacji i oferowania binariów dla różnych dystrybucji. Wiele aplikacji nie działa na starszych, ale wspieranych, wersjach wielu dystrybucji.
Słowem, jest to bałagan.
Nawet twórca Linuksa, Linus Torvalds, nie jest zadowolony z istniejącego modelu dostarczania aplikacji na Linuksa. On nie oferuje binariów swoich aplikacji dla platformy Linux powołując się na ten bałagan. Dirk Hohndel, opiekun Subsurface (projektu zapoczątkowanego przez Linusa), wyjaśnił: „Obecna sytuacja z dziesiątkami dystrybucji, każda z innymi zasadami, każda z różnymi wersjami różnych bibliotek, niektóre z brakiem niektórych bibliotek, każda z różnymi narzędziami do pakowania i formatami pakowania … to w zasadzie mówi twórcom aplikacji 'odejdź, skup się na platformach, które dbają o aplikacje.
„Pakowanie aplikacji jest niezwykle ważne, ale tak samo ważne jest pochodzenie i utrzymanie wszystkich zaangażowanych elementów”, zgodził się Gunnar Hellekson, dyrektor ds. zarządzania produktami w Red Hat Enterprise Linux.
Snap został zaprojektowany, aby przynieść trochę porządku do tego stanu rzeczy. Ale czy zostanie on przyjęty, to już zupełnie inna kwestia.
Hellekson argumentował, że narzędzia takie jak Snap nie „magicznie rozwiązują problemy interoperacyjności pomiędzy dystrybucjami Linuksa, a w rzeczywistości przenoszą większą odpowiedzialność za utrzymanie i bezpieczeństwo na dostawców aplikacji. W ten sposób mogą sprawić, że rozwój w Linuksie będzie jeszcze trudniejszy pomimo wielu korzyści dla użytkowników.”
„Zalety Snapa bezpośrednio wiążą się z jego wadami … w istocie Snap jest odpowiednikiem statycznego linkowania – z jednej strony jest wygodny, z drugiej tworzy duplikację i wyzwania w odniesieniu do bezpieczeństwa (i łatania zabezpieczeń)”, powiedział Gerald Pfeifer, wiceprezes SUSE ds. produktów i programów technologicznych.
Jednak nie wszyscy są tego samego zdania. Brandon Philips, współzałożyciel i dyrektor ds. technologii w firmie CoreOS, powiedział nam, że kontenery są przyszłością aplikacji na Linuksie. Ale kontenery Docker nie mogą być używane wszędzie. Mają one swoje ograniczenia. To, czego potrzebujemy, to rozwiązanie podobne do kontenerów, coś jak Snap.
Podczas innego wywiadu, wiodący twórca jądra Linuksa Greg Kroah-Hartman powiedział nam, że Android robi kontenery „dla twoich aplikacji już od ośmiu lub dziewięciu lat. Każda aplikacja działa w swojej własnej przestrzeni nazw. Nie może widzieć poza nią. To jest sposób, w jaki musisz to zrobić. To jest przyszłość Linuksa i sposobu działania systemów.” Powiedział, że Snap to ta sama koncepcja, ten sam pomysł.
Snap Goes Cross Platform
Sukces Snapa bardzo zależy od jego przyjęcia przez większą społeczność open source. Co dobrego jest format aplikacji, jeśli nikt go nie używa? Jako Ubuntu-only technologia, która może nawet nie dostać oficjalnie wspierane przez jego pochodnych, takich jak Linux Mint, KDE neon lub elementary OS, Snap może zmierzyć się z nie tak udanej kariery.
Kiedy Canonical ogłosił Snap, twierdził na konferencji prasowej, że pracował z różnymi dystrybucjami, aby dodać wsparcie dla Snap.
Canonical powiedział, że Snaps są natywnie dostępne dla Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity i Xubuntu. Canonical pracuje również nad walidacją Snaps na CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt i Red Hat Enterprise Linux.
Canonical i SUSE nie są obecnie zaangażowane w rozwój współpracy nad Snaps, a w rzeczywistości wygląda na to, że nie był to wynik projektowania i rozwoju otwartej społeczności,” Gerald Pfeifer, SUSE.
Ogłoszenie przez Kanonical, że współpracowali z innymi dystrybucjami, przyciągnęło krytykę ze strony niektórych członków społeczności open source. Deweloperzy Fedory nie byli zadowoleni z tego ogłoszenia i skrytykowali Canonical twierdząc, że nie było żadnej współpracy między tymi dwoma projektami.
Kiedy skontaktowaliśmy się z założycielem Canonical, Markiem Shuttleworth, aby zapytać o te zarzuty, odpowiedział: „Zrobiliśmy krótką relację z zespołem desktopowym Red Hat i jesteśmy zawsze otwarci na współpracę ze wszystkimi dystrybucjami Linuksa, aby umożliwić Snaps.”
Okazało się to jednak nowością dla Red Hat, które prowadzi dystrybucję Fedora.
„Podczas gdy pracujemy z Canonical w kilku społecznościach, byliśmy tak samo zaskoczeni jak wszyscy inni, kiedy ogłosili nasze zaangażowanie w tę konkretną inicjatywę. Jesteśmy otwarci na więcej dyskusji na ten temat, i aby zobaczyć, jak społeczność Linuksa ogólnie chce współpracować”, powiedział Hellekson.
Oficjele SUSE również zbagatelizowali jakąkolwiek współpracę. „Canonical i SUSE nie są obecnie zaangażowane w rozwój wokół współpracy na Snaps, a w rzeczywistości wydaje się, że nie był to wynik otwartego projektowania i rozwoju społeczności,” Pfeifer said.
What seemed to have happened is that Canonical pracował z niektórymi deweloperami, być może tylko garstką, innych projektów i oni pomagali w pakowaniu Snaps dla innych dystrybucji.
Canonical nie jest doskonały
Część nacisków, które Canonical mogło dostać może być produktem ubocznym tego jak robi biznes.
Na przykład, inne firmy linuksowe, takie jak Red Hat i SUSE, utrzymują bardzo wyraźny podział władzy, gdy chodzi o Fedorę i openSUSE. Fedora i openSUSE są dość niezależnymi, kierowanymi przez społeczność projektami, w których decyzje są podejmowane przez członków społeczności, a nie przez firmy sponsorujące.
W przeciwieństwie do nich, Ubuntu jest produktem Canonical, który również jest projektem społecznościowym. Z tego powodu, w przeciwieństwie do openSUSE i Fedory, Canonical ma bezpośrednią kontrolę nad Ubuntu. Przekonaliśmy się już w przypadku ownCloud; naprawdę trudno jest utrzymać równowagę między potrzebami społeczności i firmy; często kończy się to katastrofą, jak w przypadku ownCloud.
Rodzi się pytanie, jak się „pracuje” z projektem?
Wielu uważa również, że w Ubuntu brakuje przejrzystości. W czasach wielu wiodących Ubuntu współpracowników wyraziło frustrację, jak Canonical trzymał główne ogłoszenia wokół Ubuntu pod przykrywką, ukryte nawet przed członkami rdzenia. Członkowie Ubuntu nie miał pojęcia o Ubuntu dla Windows lub chorego projektu Edge.
„Nie trzymamy rzeczy z tyłu,” Red Hat CEO Jim Whitehurst odpowiedział na pytanie o podejście tej firmy do open source. „Kiedy coś budujemy, nie ukrywamy tego przed ludźmi, aby zrobić wielkie ujawnienie i powiedzieć 'oto kod’. Nie robimy tego. Pracujemy w społecznościach od pierwszego dnia, przez cały czas. Myślę, że staramy się być naprawdę dobrymi uczestnikami i myślę, że to widać.”
Na szczycie tych różnic, Canonical jest również znane z popełniania pewnych błędów, jeśli chodzi o ujawnianie informacji. Wydaje się, że tak było w przypadku ogłoszenia wsparcia dla Snapa w różnych dystrybucjach; sformułowanie, które zirytowało deweloperów Fedory brzmiało „Deweloperzy z wielu dystrybucji Linuksa.” Aby było jasne, Canonical nigdy nie powiedziało wprost w swoim komunikacie prasowym, że współpracuje z Fedorą. I bazując na informacjach, które zebraliśmy, nie było żadnego „oficjalnego” zaangażowania z dystrybucjami Linuksa takimi jak Fedora, Red Hat, SUSE lub innymi.
To powiedziawszy, pojawia się pytanie, jak się „pracuje” z projektem? Jeśli deweloper pracujący nad aplikacją współpracuje z deweloperem Ubuntu, deweloperem Fedory i deweloperem openSUSE, aby przynieść tę aplikację na te platformy, czy byłoby źle powiedzieć, że deweloper pracował z wieloma dystrybucjami, aby przynieść aplikację do nich? Czy może deweloper potrzebuje oficjalnego zaangażowania liderów projektów tych dystrybucji, aby móc wydać takie oświadczenie? To jest rozproszona, open source społeczność, po wszystkim.
Whither Snap?
Większym pytaniem jest, czy Snap zostanie oficjalnie przyjęty przez inne dystrybucje? W tym miejscu sprawy się nieco komplikują. Staje się to kwestią technologiczną i polityczną.
Po pierwsze, Snap nie jest jedynym rozwiązaniem w okolicy. Istnieje wiele projektów, które próbowały zaoferować ekosystemy pakowania niezależne od dystrybucji dla ekosystemów Linuksa. Ale może być trudno znaleźć konsensus w świecie dystrybucji Linuksa. Istnieje AppImage i Flatpak, które oferują odpowiednie alternatywy dla Snap; te projekty istnieją znacznie dłużej niż Snap.
Dlaczego więc Canonical nie przyjął tych rozwiązań zamiast zaczynać od Click lub Snap?
„Przyjrzeliśmy się temu i stwierdziliśmy, że AppImage działa idealnie dla 'leaf-node’ aplikacji desktopowych,” powiedział Shuttleworth. Aplikacja leaf-node to taka, która nie musi się integrować z żadną inną aplikacją. Snap został zaprojektowany bardziej do pakowania aplikacji z zależnościami i powiązanymi aplikacjami. „Snapy mają szereg możliwości opisywania tych połączeń – interfejsów, wtyczek i gniazd, a także współdzielonych plików i tak dalej.”
Dodatkowo Shuttleworth powiedział nam, że Snap został zaprojektowany dla wyższych poziomów bezpieczeństwa w porównaniu do AppImage, częściowo dlatego, że zespół pracujący nad telefonem komórkowym skupiał się na bezpieczeństwie i wydajności, a częściowo dlatego, że Snap wykorzystuje nowsze możliwości jądra.
Flatpak podobno padł ofiarą rywalizacji między Canonical i Red Hat, ponieważ był rozwijany przez ludzi z Fedory. Kiedy zapytałem, Shuttleworth odrzucił to jako projekt rozwijany przez jednego dewelopera.
To wyjaśnia dlaczego Canonical poszedł naprzód ze Snapem.
Teraz, czy inne dystrybucje go przyjmą? Deweloperzy Fedory już zadeklarowali, że nie będą używać Snapa. Jeden z deweloperów Fedory napisał na liście mailingowej, „Oczywiście, nie mamy żadnych planów przyjęcia Snappy w Fedorze, i w rzeczywistości wielu deweloperów Fedory pracuje nad konkurencyjnym rozwiązaniem, Flatpak.”
Red Hat wcześniej przyjął projekt Canonical do inicjalizacji systemu o nazwie Upstart. Hellekson powiedział: „To są bardzo wczesne dni dla wszystkich tych wysiłków związanych z pakowaniem i czekamy na współpracę ze wszystkimi powiązanymi społecznościami, aby jak najbardziej ułatwić życie użytkownikom Linuksa.”
Poza rywalizacją pomiędzy Red Hat i Canonical, istnieją pewne problemy techniczne, które mogą zniechęcić inne projekty do współpracy nad Snapem. Jednym z takich powodów jest fakt, że programiści muszą podpisać umowę CLA (Contributor License Agreement), jeśli wnoszą swój wkład w projekt Snap. Michael Hall, programista Canonical, powiedział, że „CLA jest potrzebne, gdy programista chce wnieść swój wkład do samego projektu Snap. Nie ma CLA wymaganego do tworzenia lub dystrybucji aplikacji Snaps.”
CLA pozwalają Canonical na zmianę licencji projektu. Jest to korzystne dla Canonical, ponieważ mogą oni ponownie licencjonować projekt, pozwalając na używanie go z niewolnymi lub niekompatybilnymi licencjami. Deweloperzy zazwyczaj nie lubią CLA.
Frank Karlitschek z Nextcloud powiedział nam, że kończy z CLA z Nextcloud, ponieważ uważa, że CLA nie mają zbyt dobrej reputacji w społeczności open source.
Kiedy zapytaliśmy Red Hat, czy CLA będą tłumić współpracę wokół Snapa, Hellekson powiedział: „Contributor License Agreements utrudniają nam uczestnictwo. Wierzymy, że proste, otwarte licencjonowanie jest lepszym, bardziej integrującym podejściem.”
Odpowiedź SUSE była bardzo podobna. Pfeifer powiedział: „Inżynierowie i pracownicy SUSE nadal biorą udział w wielu projektach open source, zarówno w czasie pracy w firmie, jak i we własnym zakresie, a tam, gdzie było to konieczne, podpisaliśmy umowy CLA. Jednakże, gdziekolwiek i kiedykolwiek inicjujemy lub wpływamy na projekty, staramy się trzymać z dala od CLA. Generalnie nie lubimy umów CLA, które przypisują prawa autorskie umożliwiające organizacjom ponowne licencjonowanie kodu open source przy użyciu licencji nieopen source.”
Kiedy zapytaliśmy Shuttlewortha, czy rozważyłby usunięcie CLA ze Snapa, aby uzyskać szersze wsparcie od innych dystrybucji, zaczął od wyjaśnienia, dlaczego CLA są dobre, ale potem powiedział również, że „jeśli to zrobiłoby różnicę, to tak, znaleźlibyśmy sposób, aby je usunąć.”
And Then There was One?
Z czasem, dojrzałość, popularność i techniczna wyższość jednego nad drugim może pozostawić nas z jednym rozwiązaniem. Widzieliśmy to już wcześniej z Upstartem i systemd, gdzie systemd wyłonił się jako lepsza technologia i stał się domyślnym rozwiązaniem we wszystkich trzech wiodących dystrybucjach Linuksa: Ubuntu, RHEL i SUSE.
W obu przypadkach obie technologie są na bardzo wczesnym etapie rozwoju i trudno powiedzieć, który projekt odniesie sukces. Jednak jest całkiem jasne, że w świecie skoncentrowanym na kontenerach, Linux potrzebuje nowego mechanizmu dostarczania aplikacji.
Wiele firm i społeczności wyraziło poparcie dla rozwiązań takich jak Snap. Samsung i Dell dołączyli do Canonical w rozmowie prasowej i stwierdzili potrzebę takiego rozwiązania. Na koniec pulpitu, projekty takie jak LibreOffice i Firefox już wyraziły wsparcie dla Snap.
Czas pokaże, czy Snap zostanie przyjęty poza Ubuntu, czy nie. Niezależnie od tego, co przyniesie przyszłość dla Snap, powinniśmy dać Canonical należny kredyt za pchanie koperty, zmuszając resztę społeczności Linuksa, aby w końcu skupić się na rozwiązaniu problemu, który albo stał się tak wygodny, lub, być może, nigdy nie miał motywacji, aby rozwiązać.
CoreOS i Red Hat są sponsorami The New Stack.
.