Pár hete a Canonical bejelentette a Snap alkalmazáskiszállítási mechanizmus terjesztésközi támogatását, amely mobil, asztali és szerver alapú alkalmazásokat egyaránt támogathat. A bejelentés felborzolta a kedélyeket a Linux közösségen belül, akik kevés bizonyítékot láttak arra, hogy más Linux disztribúció támogatná a Snapet.
A Snap a Canonical kísérlete arra, hogy finomítsa az alkalmazások csomagolását és terjesztési mechanizmusát a Linux platformon. A Snap eredete a Clickben gyökerezik, egy olyan megoldásban, amelyet a Canonical még 2014-ben hozott létre a mobilplatformhoz, hogy kezelje az alkalmazások Ubuntu telefon- és táblagép-felhasználóknak történő szállításának bonyolultságát, amely ökoszisztéma messze eltér az asztali számítógépektől és szerverektől. Ráadásul a mobilon is szükség volt az alkalmazások korlátozására és sandboxolására, hogy azok ne veszélyeztessék az egész platformot.
A Click lehetővé tette a fejlesztők számára, hogy az összes függőséget egyetlen alkalmazáscsomagba csomagolják, így a felhasználóknak és a fejlesztőknek nem kellett aggódniuk az egymással ütköző rendszerek és alkalmazáskönyvtárak miatt. Lehetővé tette a fejlesztők számára, hogy a legújabb könyvtárakat használják az alkalmazásaikban, hogy új funkciókat kínáljanak, mivel azok függetlenítve voltak a rendszerre telepített könyvtáraktól.
A mobilon túl a szerverekre és az IoT-re
A Clickből Snap lett, és a Canonical kiterjesztette a felhasználási lehetőségeket a szerver, a felhő, az Internet of Things (IoT) és az asztali gépek területére. Az Ubuntu 16.04 áprilisi kiadásával a Canonical hivatalosan is elhozta a Snapet az Ubuntu desktopra.
A Canonical a Snappy Ubuntu Core-t is fejleszti, egy apró Linux-alapú operációs rendszert nagyszabású felhő-konténer telepítésekhez, IoT-eszközökhöz és sok máshoz, valamint bármihez, ami átmeneti frissítéseket és apró lábnyomot igényel. A Snappy Ubuntu Core nagyjából úgy működik, mint a Google Chrome OS és a CoreOS, ahol átmeneti képalapú frissítéseket kínál a rendszerhez és az alkalmazásokhoz, amelyek visszaállíthatók. Ezzel párhuzamosan kínálja a konténerek világában ismert zártságot.
A Snap ennek a technológiának a lelke.
Az alkalmazásszállítás linuxos zűrzavara
A Linuxon meglévő alkalmazásszállítási modellnek sok hibája van. A Linux világa többnyire két táborra oszlik az alkalmazások csomagolását illetően: rpm és deb. Emellett ugyanannak a disztribúciónak különböző verziói vannak, amelyek különböző könyvtárakat használnak, így az alkalmazásfejlesztők számára nagy kihívást jelent az alkalmazások Linuxra való csomagolása.
Ez azt eredményezi, hogy az alkalmazásfejlesztők nem tudják kihasználni a legújabb könyvtárak előnyeit, és nem tudnak több funkciót kínálni a felhasználóiknak, ha a disztribúció még mindig régebbi könyvtárakat használ.
A legtöbb esetben a nyílt forráskódú alkalmazásfejlesztők nem csomagolják az alkalmazásaikat a disztribúciókhoz. A népszerű vagy régóta ismert alkalmazásokat általában a disztribúció fejlesztői csomagolják. Az újabb vagy kevésbé népszerű alkalmazásokat vagy az upstream csomagolja az egyes támogatni kívánt disztribúciókhoz, vagy egyáltalán nem kínálja őket disztribúciós csomagként. Amikor egy alkalmazás új verziója megjelenik, ezek a fejlesztők tesztelik az alkalmazást, majd elérhetővé teszik a disztró számára. Mint látható, ahelyett, hogy az alkalmazásfejlesztő csak egy alkalmazást írna az egész platformra, ami ebben az esetben a Linux, sok ember hozza el ezt az alkalmazást a felhasználókhoz.
Ez még bonyolultabbá teszi a dolgot.
Vannak esetek, amikor a Windows és a MacOS azonnal megkapja a legújabb verziókat, mivel az alkalmazásokat az elsődleges fejlesztők csomagolják, míg a Linux-disztroknál eltarthat egy ideig. Ez nem minden; egyes disztribúciók gyorsan megkapják őket, másoknak pedig heteket vagy hónapokat kell várniuk.
A kereskedelmi alkalmazások, például a Skype, a Dropbox, a Chrome esetében az elsődleges fejlesztő feladata az alkalmazások csomagolása és a binárisok felajánlása a különböző disztribúciókhoz. Sok alkalmazás nem működik számos disztribúció régebbi, de támogatott verzióin.
Egyszóval, ez egy zűrzavar.
Még a Linux megalkotója, Linus Torvalds sem elégedett a Linux jelenlegi alkalmazásszállítási modelljével. Erre a zűrzavarra hivatkozva nem kínálja az alkalmazásainak bináris változatait a Linux platformra. Dirk Hohndel, a Subsurface (egy Linus által indított projekt) karbantartója kifejtette: “A jelenlegi helyzet tucatnyi disztribúcióval, mindegyik különböző szabályokkal, mindegyik különböző könyvtárak különböző verzióival, egyeseknél bizonyos könyvtárak hiányoznak, mindegyiknél különböző csomagolóeszközökkel és csomagolási formátumokkal … ez alapvetően azt mondja az alkalmazásfejlesztőknek, hogy ‘menjetek el, koncentráljatok olyan platformokra, amelyek törődnek az alkalmazásokkal.'”
“Az alkalmazások csomagolása rendkívül fontos, de ugyanilyen fontos az összes érintett darab származása és karbantartása is” – értett egyet Gunnar Hellekson, a Red Hat Enterprise Linux termékmenedzsment igazgatója.
A Snapet azért tervezték, hogy rendet teremtsen ebben a helyzetben. De hogy elfogadják-e, az már egy teljesen más kérdés.
Hellekson szerint az olyan eszközök, mint a Snap, “nem oldják meg varázsütésre a Linux-disztribúciók közötti interoperabilitási problémákat, és valójában a karbantartás és a biztonság nagyobb felelősségét hárítják az alkalmazásgyártókra”. Ily módon még nehezebbé tehetik a Linuxon való fejlesztést a felhasználók számára nyújtott számos előny ellenére.”
“A Snap előnyei közvetlenül kapcsolódnak a hátrányaihoz … lényegében a Snap a statikus linkelés megfelelője – egyrészt kényelmes, másrészt duplikációt és kihívásokat teremt a biztonság (és a biztonsági javítások) tekintetében” – mondta Gerald Pfeifer, a SUSE termékekért és technológiai programokért felelős alelnöke.
Mindenesetre nem mindenki van ezen a véleményen. Brandon Philips, a CoreOS társalapítója és technológiai igazgatója elmondta, hogy a konténerek jelentik az alkalmazások jövőjét Linuxon. A Docker konténerek azonban nem használhatók mindenhol. Vannak korlátaik. Amire szükségünk van, az egy konténer-szerű megoldás, valami olyasmi, mint a Snap.
Egy másik interjúban Greg Kroah-Hartman, a Linux kernel vezető fejlesztője elmondta, hogy az Android már nyolc vagy kilenc éve csinál konténereket “az alkalmazásokhoz. Minden alkalmazás a saját névterében fut. Nem lát azon kívülre. Így kell ezt csinálni. Ez a Linux és a rendszerek jövője”. Szerinte a Snap ugyanez a koncepció, ugyanez az elképzelés.
Snap Goes Cross Platform
A Snap sikere nagyban függ attól, hogy a szélesebb nyílt forráskódú közösség elfogadja-e. Mit ér egy alkalmazásformátum, ha senki sem használja? Mint egy Ubuntu-only technológia, amelyet talán még a származékai, mint a Linux Mint, a KDE neon vagy az elementáris OS sem támogatnak hivatalosan, a Snap nem túl sikeres karrier elé nézhet.
A Canonical a Snap bejelentésekor egy sajtótájékoztatón azt állította, hogy különböző disztribúciókkal dolgozik együtt a Snap támogatásának hozzáadásán.
A Canonical szerint a Snap natívan elérhető az Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity és Xubuntu számára. A Canonical dolgozik a Snaps érvényesítésén a CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt és Red Hat Enterprise Linux rendszereken is.
A Canonical és a SUSE jelenleg nem vesz részt a Snaps együttműködés körüli fejlesztésben, és valójában úgy tűnik, hogy ez nem nyílt közösségi tervezés és fejlesztés eredménye” – mondta Gerald Pfeifer, SUSE.
A Canonical bejelentése, miszerint más disztribúciókkal dolgoztak együtt, némi kritikát váltott ki a nyílt forráskódú közösség egyes tagjaiból. A Fedora fejlesztői nem vették jó néven ezt a bejelentést, és kritizálták a Canonical-t, mondván, hogy a két projekt között semmiféle együttműködés nem volt.
Amikor utánajártunk a Canonical alapítójának, Mark Shuttleworth-nek, hogy megkérdezzük ezeket a vádakat, így válaszolt: “Tájékoztattuk a Red Hat desktop csapatát, és mindig nyitottak vagyunk az összes Linux-disztribúcióval való együttműködésre a Snaps lehetővé tétele érdekében.”
Ez azonban a Fedora disztribúciót pásztorló Red Hat számára újdonságnak bizonyult.
“Bár több közösségben is együttműködünk a Canonical-lal, ugyanúgy meglepődtünk, mint mindenki más, amikor bejelentették részvételünket ebben a konkrét kezdeményezésben. Nyitottak vagyunk a további megbeszélésekre erről, és arra, hogy lássuk, a Linux közösség összességében hogyan akar együttműködni” – mondta Hellekson.”
A SUSE illetékesei szintén lekicsinyelték az esetleges együttműködést. “A Canonical és a SUSE jelenleg nem vesz részt a Snaps-szal kapcsolatos együttműködés körüli fejlesztésben, és valójában úgy tűnik, hogy ez nem nyílt közösségi tervezés és fejlesztés eredménye volt” – mondta Pfeifer.
Az, ami úgy tűnik, az történt, hogy a Canonical más projektek néhány – talán csak egy maroknyi – fejlesztőjével dolgozott együtt, és ők segítettek a Snaps csomagolásában más disztribúciók számára.
A Canonical nem tökéletes
A Canonical által talán kapott ellenérzések egy része az üzleti tevékenységének mellékterméke lehet.
Egyrészt más Linux-cégek, például a Red Hat és a SUSE nagyon világos hatalommegosztást tartanak fenn a Fedora és az openSUSE esetében. A Fedora és az openSUSE meglehetősen független, közösség által irányított projektek, ahol a döntéseket a közösség tagjai hozzák, nem pedig a támogató vállalatok.
Az Ubuntu ezzel szemben a Canonical terméke, amely történetesen szintén egy közösségi projekt. Ennek köszönhetően az openSUSE-val és a Fedorával ellentétben a Canonicalnak közvetlen ellenőrzése van az Ubuntu felett. Az ownCloud esetében már megtanultuk; nagyon nehéz fenntartani az egyensúlyt a közösség és a vállalat igényei között; ennek gyakran az ownCloudhoz hasonló katasztrófa a vége.
Felmerül a kérdés, hogyan “dolgozik” az ember egy projekttel?
Az Ubuntunál sokak szerint hiányzik az átláthatóság is. Időnként sok vezető Ubuntu közreműködő kifejezte csalódottságát, mivel a Canonical az Ubuntuval kapcsolatos fontos bejelentéseket titokban tartotta, még az alaptagok előtt is elrejtve. Az Ubuntu-tagoknak fogalmuk sem volt az Ubuntu for Windowsról vagy a rosszul sikerült Edge projektről.
“Nem tartjuk vissza a dolgokat” – válaszolta Jim Whitehurst, a Red Hat vezérigazgatója egy kérdésre, amely a vállalat nyílt forráskódhoz való hozzáállására vonatkozott. “Amikor dolgokat építünk, nem rejtjük el az emberek elől, hogy egy nagy leleplezést csináljunk, és azt mondjuk, hogy ‘itt a kód’. Mi nem ezt tesszük. Az első naptól kezdve folyamatosan közösségekben dolgozunk. Úgy gondolom, hogy igyekszünk igazán jó résztvevők lenni, és azt hiszem, ez átjön.”
Ezeken a különbségeken felül a Canonical arról is ismert, hogy elkövet néhány hibás lépést, amikor az információk közzétételéről van szó. Ez mindenképpen így tűnik a Snap disztribúciók közötti támogatásának bejelentésekor; a Fedora fejlesztőket bosszantó megfogalmazás a következő volt: “Több Linux-disztribúció fejlesztői”. Hogy egyértelmű legyen, a Canonical sajtóközleményében soha nem mondta ki kifejezetten, hogy a Fedorával dolgozik együtt. Az általunk összegyűjtött információk alapján pedig nem volt “hivatalos” elkötelezettség olyan Linux disztribúciókkal, mint a Fedora, a Red Hat, a SUSE vagy mások.
Ezzel együtt felmerül a kérdés, hogy hogyan “dolgozik” valaki egy projekttel? Ha egy alkalmazáson dolgozó fejlesztő együttműködik egy Ubuntu fejlesztővel, egy Fedora fejlesztővel és egy openSUSE fejlesztővel, hogy az alkalmazást eljuttassák ezekre a platformokra, akkor helytelen lenne azt mondani, hogy a fejlesztő több disztribúcióval dolgozott együtt, hogy az alkalmazást eljuttassa hozzájuk? Vagy a fejlesztőnek hivatalos együttműködésre van szüksége ezen disztribúciók projektvezetőivel, hogy ilyen kijelentést tehessen? Elvégre ez egy elosztott, nyílt forráskódú közösség.
Hol a Snap?
A nagyobb kérdés az, hogy a Snapot hivatalosan is átveszik-e más disztribúciók? Ez az a pont, ahol a dolgok egy kicsit bonyolulttá válnak. Ez egy technológiai és politikai kérdéssé válik.
Először is, a Snap nem az egyetlen létező megoldás. Sok olyan projekt van, amely megpróbált distro-agnosztikus csomagolási ökoszisztémát kínálni a Linux ökoszisztémák számára. De nehéz lehet konszenzust találni a Linux disztró világán belül. Ott van az AppImage és a Flatpak, amelyek a Snap megfelelő alternatíváit kínálják; ezek a projektek sokkal régebb óta léteznek, mint a Snap.”
Miért nem fogadta el tehát a Canonical ezeket a megoldásokat ahelyett, hogy a Click vagy a Snap elindításával foglalkozott volna?
“Megnéztük, és úgy találtuk, hogy az AppImage tökéletesen működik a “leaf-node” asztali alkalmazásokhoz” – mondta Shuttleworth. A leaf-node alkalmazás olyan alkalmazás, amelynek nem kell integrálódnia más alkalmazással. A Snapet inkább a függőségekkel és kapcsolódó alkalmazásokkal rendelkező alkalmazások csomagolására tervezték. “A Snapnek számos képessége van ezeknek a kapcsolatoknak a leírására – interfészek, csatlakozók és slotok, valamint megosztott fájlok és így tovább.”
Ezeken kívül Shuttleworth elmondta, hogy a Snapet az AppImage-hez képest magasabb szintű biztonságra tervezték, részben azért, mert a mobilon dolgozó csapat a biztonságra és a hatékonyságra összpontosított, részben pedig azért, mert a Snap újabb kernelképességeket használ.”
A Flatpak állítólag a Canonical és a Red Hat közötti rivalizálás áldozatául esett, mivel a Fedora emberei fejlesztették. Amikor megkérdeztem, Shuttleworth elutasította, mint egyetlen fejlesztő által fejlesztett projektet.
Ez megmagyarázza, miért ment előre a Canonical a Snap-nel.
Most, más disztrók is átveszik majd? A Fedora fejlesztői már kijelentették, hogy nem fogják használni a Snapet. Egy Fedora-fejlesztő a levelezési listán ezt írta: “Természetesen nulla tervünk van a Snappy átvételére a Fedorában, sőt, több Fedora-fejlesztő dolgozik egy konkurens megoldáson, a Flatpakon.”
A Red Hat korábban felkarolta a Canonical Upstart nevű projektjét a rendszer inicializálására. Hellekson elmondta: “Ez még nagyon korai időszak mindezen csomagolási erőfeszítések számára, és várakozással tekintünk az összes kapcsolódó közösséggel való együttműködés elé, hogy a Linux-felhasználók életét a lehető legkönnyebbé tegyük.”
A Red Hat és a Canonical közötti rivalizáláson túl vannak olyan technikai problémák, amelyek más projekteket is visszatarthatnak a Snap együttműködésétől. Az egyik ilyen ok az, hogy a fejlesztőknek CLA-t (Contributor License Agreement) kell aláírniuk, ha hozzájárulnak a Snap projekthez. Michael Hall, a Canonical egyik fejlesztője elmondta, hogy “CLA-ra akkor van szükség, ha egy fejlesztő magához a Snap projekthez akar hozzájárulni. Nincs szükség CLA-ra ahhoz, hogy alkalmazások Snapjeit hozzák létre vagy terjesszék.”
A CLA-k lehetővé teszik a Canonical számára, hogy megváltoztassa a projekt licencét. Ez előnyös a Canonical számára, mivel újralicencelhetik a projektet, lehetővé téve annak használatát nem szabad vagy nem kompatibilis licencekkel. A fejlesztők általában nem szeretik a CLA-kat.
Frank Karlitschek a Nextcloudtól elmondta, hogy megszünteti a CLA-kat a Nextcloudtól, mivel szerinte a CLA-knak nincs túl jó híre a nyílt forráskódú közösségen belül.
Amikor megkérdeztük a Red Hatot, hogy a CLA-k gátolják-e a Snap körüli együttműködést, Hellekson azt mondta: “A hozzájárulási licencszerződések valóban megnehezítik a részvételünket. Úgy gondoljuk, hogy az egyenes, nyílt forráskódú licencelés jobb, befogadóbb megközelítés.”
A SUSE válasza nagyjából ugyanez volt. Pfeifer elmondta: “A SUSE mérnökei és munkatársai továbbra is rengeteg nyílt forráskódú projekthez járulnak hozzá, mind a vállalat idejében, mind a saját időnkben, és ahol szükséges volt, ott aláírtuk a CLA-kat. Azonban bárhol és bármikor is kezdeményezünk vagy befolyásolunk projekteket, igyekszünk távol tartani magunkat a CLA-tól. Általában nem szeretjük az olyan CLA-kat, amelyek olyan szerzői jogot ruháznak át, amely lehetővé teszi a szervezetek számára, hogy nyílt forráskódot nem nyílt forráskódú licenccel licenceljenek újra.”
Amikor megkérdeztük Shuttleworth-t, hogy fontolóra venné-e a CLA-k elhagyását a Snapről, hogy szélesebb támogatást kapjon más disztribúciókból, azzal kezdte, hogy elmagyarázta, miért jó a CLA, de aztán azt is mondta, hogy “ha ez változtatna valamit, akkor igen, megtalálnánk a módját annak, hogy elhagyjuk.”
And Then There Was One?
Az érettség, a népszerűség és az egyik technikai fölénye a másikkal szemben idővel egyetlen megoldást hagyhat nekünk. Ezt már láttuk korábban az Upstart és a systemd esetében, ahol a systemd jobb technológiaként jelent meg, és mindhárom vezető Linux disztróban alapértelmezetté vált: Ubuntu, RHEL és SUSE.
Mindkét esetben mindkét technológia a fejlesztés nagyon korai szakaszában van, és nehéz megmondani, hogy melyik projekt lesz sikeres. Az azonban elég egyértelmű, hogy a konténerközpontú világban a Linuxnak igenis szüksége van egy új alkalmazásszállítási mechanizmusra.
Sok vállalat és közösség fejezte ki támogatását a Snaphez hasonló megoldások iránt. A Samsung és a Dell csatlakozott a Canonicalhoz a sajtótájékoztatón, és kijelentették, hogy szükség van egy ilyen megoldásra. Asztali oldalon az olyan projektek, mint a LibreOffice és a Firefox már kifejezték támogatásukat a Snap iránt.
Az idő majd megmutatja, hogy a Snapet az Ubuntun kívül is elfogadják-e vagy sem. Bármit is tartogat a jövő a Snap számára, meg kell adnunk a Canonicalnak a kellő elismerést, amiért a Linux közösség többi tagját arra kényszerítette, hogy végre egy olyan probléma megoldására összpontosítson, amelyhez vagy annyira hozzászoktunk, vagy talán soha nem volt motivációnk a megoldásra.
A CoreOS és a Red Hat a The New Stack támogatói.