Cu câteva săptămâni în urmă, Canonical a anunțat suportul de distribuție încrucișată pentru mecanismul de livrare a aplicațiilor Snap, unul care ar putea suporta aplicații mobile, desktop și bazate pe server. Anunțul a iritat unele pene în cadrul comunității Linux, care au văzut puține dovezi că alte distribuții Linux ar fi susținut Snap.
Snap este încercarea Canonical de a rafina mecanismul de împachetare și livrare a aplicațiilor pe platforma Linux. Originea Snap își găsește rădăcinile în Click, o soluție pe care Canonical a creat-o pentru platforma sa mobilă în 2014, pentru a gestiona complexitatea livrării aplicațiilor către utilizatorii de telefoane și tablete Ubuntu, un ecosistem mult diferit de cel al desktopurilor și serverelor. În plus, mobilul avea nevoie, de asemenea, să limiteze aplicațiile și să le sandboxeze, astfel încât acestea să nu compromită întreaga platformă.
Click le-a permis dezvoltatorilor să grupeze toate dependențele într-un singur pachet de aplicații, astfel încât utilizatorii și dezvoltatorii nu trebuiau să își facă griji cu privire la sistemele și bibliotecile de aplicații conflictuale. Le-a permis dezvoltatorilor să folosească cele mai recente biblioteci în aplicațiile lor, pentru a oferi noi caracteristici, deoarece acestea erau decuplate de bibliotecile instalate pe sistem.
Depășind sfera mobilă pentru a ajunge la servere și IoT
Click a evoluat în Snap, iar Canonical a extins potențialul său de utilizare la spațiile server, cloud, Internet of Things (IoT) și desktop. Odată cu lansarea Ubuntu 16.04 în aprilie, Canonical a adus în mod oficial Snap pe desktop-ul Ubuntu.
Canonical dezvoltă, de asemenea, Snappy Ubuntu Core, un sistem de operare minuscul bazat pe Linux pentru implementări de containere cloud la scară largă, dispozitive IoT și multe altele, precum și pentru tot ceea ce are nevoie de actualizări de tranziție și o amprentă minusculă. Snappy Ubuntu Core funcționează mai mult sau mai puțin ca Chrome OS și CoreOS de la Google, unde oferă actualizări tranzitorii bazate pe imagini pentru sistem și aplicații, care pot fi retrase. În același timp, oferă izolarea care este cunoscută în lumea containerelor.
Snap este sufletul acestei tehnologii.
Drumul Linux de livrare a aplicațiilor
Modelul existent de livrare a aplicațiilor pe Linux are multe defecte. Lumea Linux este în mare parte împărțită în două tabere de împachetare a aplicațiilor: rpm și deb. De asemenea, există versiuni diferite ale aceleiași distribuții care folosesc biblioteci diferite, astfel încât devine destul de dificil pentru dezvoltatorii de aplicații să împacheteze aplicații pentru Linux.
Ca urmare, dezvoltatorii de aplicații nu pot profita de cele mai recente biblioteci și nu pot oferi mai multe caracteristici utilizatorilor lor dacă distribuția încă folosește biblioteci mai vechi.
În cele mai multe cazuri, dezvoltatorii de aplicații open source nu își împachetează aplicațiile pentru distribuții. Aplicațiile populare sau stabilite de mult timp sunt de obicei împachetate de dezvoltatorii de distribuții. Cele mai noi sau mai puțin populare sunt fie împachetate de către upstream pentru fiecare distribuție pe care doresc să o susțină, fie nu sunt oferite deloc ca pachet pentru distribuții. Atunci când este lansată o nouă versiune a unei aplicații, acești dezvoltatori testează aplicația și apoi o pun la dispoziție pentru distro. După cum puteți vedea, în loc ca dezvoltatorul de aplicații să scrie doar o singură aplicație pentru întreaga platformă, care în acest caz este Linux, există mai multe persoane care aduc acea aplicație utilizatorilor.
Acesta adaugă mai multă complexitate.
Există cazuri în care Windows și MacOS primesc cele mai recente versiuni imediat, deoarece aplicațiile sunt împachetate de dezvoltatorii primari, în timp ce pentru distro-urile Linux poate dura ceva timp. Asta nu e tot; unele distribuții le primesc rapid, iar altele trebuie să aștepte săptămâni sau luni.
În cazul aplicațiilor comerciale precum Skype, Dropbox, Chrome, sarcina revine dezvoltatorului primar de a împacheta aplicațiile și de a oferi binare pentru diferite distribuții. Multe aplicații nu funcționează pe versiuni mai vechi, dar suportate, ale multor distribuții.
Într-un cuvânt, este o harababură.
Inclusiv creatorul Linux, Linus Torvalds, nu este mulțumit de modelul existent de livrare a aplicațiilor pe Linux. El nu oferă binare ale aplicațiilor sale pentru platforma Linux, citând această mizerie. Dirk Hohndel, întreținătorul Subsurface (un proiect inițiat de Linus), a explicat: „Situația actuală cu zeci de distribuții, fiecare cu reguli diferite, fiecare cu versiuni diferite ale diferitelor biblioteci, unele cu anumite biblioteci lipsă, fiecare cu diferite instrumente de împachetare și formate de împachetare … care practic le spune dezvoltatorilor de aplicații ‘plecați, concentrați-vă pe platformele cărora le pasă de aplicații’.'”
„Ambalarea aplicațiilor este extrem de importantă, dar la fel este și proveniența și întreținerea tuturor pieselor implicate”, a fost de acord Gunnar Hellekson, director de gestionare a produselor pentru Red Hat Enterprise Linux.
Snap a fost conceput pentru a aduce puțină ordine în această stare de lucruri. Dar dacă va fi adoptat este o cu totul altă întrebare.
Hellekson a susținut că instrumente precum Snap nu „rezolvă în mod magic problemele de interoperabilitate între distribuțiile Linux și, de fapt, transferă mai multă responsabilitate pentru întreținere și securitate către furnizorii de aplicații. În acest fel, ele ar putea îngreuna și mai mult dezvoltarea pe Linux, în ciuda numeroaselor beneficii pentru utilizatori.”
„Avantajele lui Snap sunt direct legate de dezavantajele sale… în esență, Snap este echivalentul legăturii statice – este convenabil pe de o parte, creează duplicări și provocări în ceea ce privește securitatea (și patch-urile de securitate) pe de altă parte”, a declarat Gerald Pfeifer, vicepreședintele SUSE pentru produse și programe tehnologice.
Cu toate acestea, nu toată lumea este de aceeași părere. Brandon Philips, cofondator și director de tehnologie al CoreOS, ne-a declarat că containerele reprezintă viitorul aplicațiilor pe Linux. Dar containerele Docker nu pot fi folosite peste tot. Ele au limitările lor. Avem nevoie de o soluție asemănătoare cu cea a containerelor, ceva de genul Snap.
În timpul unui alt interviu, Greg Kroah-Hartman, unul dintre principalii dezvoltatori de kernel Linux, ne-a spus că Android face containere „pentru aplicațiile dvs. de opt sau nouă ani deja. Fiecare aplicație rulează în propriul său spațiu de nume. Nu poate vedea în afara acestuia. Acesta este modul în care trebuie să faceți acest lucru. Acesta este viitorul Linux și al modului în care funcționează sistemele”. El a spus că Snap este același concept, aceeași idee.
Snap Goes Cross Platform
Succesul lui Snap depinde foarte mult de adoptarea sa de către comunitatea open source mai mare. La ce bun un format de aplicație dacă nimeni nu îl folosește? Fiind o tehnologie exclusiv Ubuntu, care s-ar putea să nu fie susținută oficial nici măcar de derivatele sale precum Linux Mint, KDE neon sau elementary OS, Snap s-ar putea confrunta cu o carieră nu foarte reușită.
Când Canonical a anunțat Snap, a susținut într-o conferință de presă că a lucrat cu diverse distribuții pentru a adăuga suport pentru Snap.
Canonical a spus că Snap-urile sunt disponibile în mod nativ pentru Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity și Xubuntu. Canonical lucrează, de asemenea, la validarea Snaps pe CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt și Red Hat Enterprise Linux.
Canonical și SUSE nu sunt în prezent angajate în dezvoltarea în jurul colaborării pe Snaps și, de fapt, se pare că acesta nu a fost rezultatul unei proiectări și dezvoltări deschise a comunității”, Gerald Pfeifer, SUSE.
Anunțul celor de la Canonical că au colaborat cu alte distribuții a atras unele critici din partea unor membri ai comunității open source. Dezvoltatorii Fedora nu au privit cu ochi buni acest anunț și au criticat Canonical afirmând că nu a existat niciun fel de colaborare între cele două proiecte.
Când l-am contactat pe fondatorul Canonical, Mark Shuttleworth, pentru a-l întreba despre aceste acuzații, acesta a răspuns: „Am făcut un briefing cu echipa de desktop Red Hat și suntem întotdeauna deschiși să lucrăm cu toate distribuțiile Linux pentru a activa Snaps.”
Aceasta s-a dovedit a fi o noutate pentru Red Hat, totuși, care păstorește distribuția Fedora.
„Deși lucrăm cu Canonical în mai multe comunități, am fost la fel de surprinși ca toată lumea când au anunțat implicarea noastră în această inițiativă particulară. Suntem deschiși la mai multe discuții pe această temă și pentru a vedea cum dorește comunitatea Linux în general să lucreze împreună”, a declarat Hellekson.
De asemenea, oficialii SUSE au minimalizat orice colaborare. „Canonical și SUSE nu sunt angajate în prezent în dezvoltarea în jurul colaborării pe Snaps și, de fapt, se pare că acesta nu a fost rezultatul unei proiectări și dezvoltări deschise a comunității”, a spus Pfeifer.
Ceea ce pare să se fi întâmplat este că Canonical a lucrat cu unii dezvoltatori, poate doar o mână, din alte proiecte și aceștia au ajutat la împachetarea Snaps pentru alte distribuții.
Canonical nu este perfectă
O parte din împotrivirea pe care Canonical ar fi putut să o primească poate fi un produs secundar al modului în care își desfășoară activitatea.
Pentru început, alte companii Linux, cum ar fi Red Hat și SUSE, mențin o separare foarte clară a puterilor atunci când vine vorba de Fedora și openSUSE. Fedora și openSUSE sunt proiecte destul de independente, conduse de comunitate, în care deciziile sunt luate de membrii comunității și nu de companiile care le sponsorizează.
În schimb, Ubuntu este un produs Canonical care, de asemenea, se întâmplă să fie un proiect al comunității. Datorită acestui fapt, spre deosebire de openSUSE și Fedora, Canonical are control direct asupra Ubuntu. Am învățat deja în cazul ownCloud; este foarte greu să menții un echilibru între nevoile comunității și cele ale companiei; de multe ori se ajunge la un dezastru precum ownCloud.
Se pune întrebarea cum se „lucrează” cu un proiect?
De asemenea, mulți consideră că există o lipsă de transparență în cazul Ubuntu. Uneori, mulți dintre principalii colaboratori Ubuntu și-au exprimat frustrarea deoarece Canonical a ținut sub tăcere anunțurile majore din jurul Ubuntu, ascunse chiar și membrilor de bază. Membrii Ubuntu nu au avut niciun indiciu despre Ubuntu pentru Windows sau despre nefericitul proiect Edge.
„Noi nu ținem lucrurile ascunse”, a răspuns Jim Whitehurst, CEO-ul Red Hat, la o întrebare despre abordarea acestei companii față de open source. „Când construim lucruri, nu le ascundem oamenilor pentru a face o mare dezvăluire și a spune „aici este codul”. Nu facem asta. Lucrăm în comunități încă din prima zi, tot timpul. Cred că încercăm să fim participanți foarte buni și cred că asta se vede.”
Pe lângă aceste diferențe, Canonical este, de asemenea, cunoscută pentru că face pași greșiți atunci când vine vorba de publicarea de informații. Acesta pare să fie cu siguranță cazul anunțului privind suportul pentru distribuții încrucișate pentru Snap; formularea care i-a iritat pe dezvoltatorii Fedora a fost „Dezvoltatorii din mai multe distribuții Linux”. Pentru a fi clar, Canonical nu a declarat niciodată în mod explicit în comunicatul de presă că a lucrat cu Fedora. Și, pe baza informațiilor pe care le-am cules, nu a existat niciun angajament „oficial” cu distribuții Linux precum Fedora, Red Hat, SUSE sau altele.
Acestea fiind spuse, se pune întrebarea cum se „lucrează” cu un proiect? Dacă un dezvoltator care lucrează la o aplicație colaborează cu un dezvoltator Ubuntu, un dezvoltator Fedora și un dezvoltator openSUSE pentru a aduce acea aplicație pe aceste platforme, ar fi greșit să spunem că dezvoltatorul a lucrat cu mai multe distribuții pentru a le aduce aplicația? Sau dezvoltatorul are nevoie de un angajament oficial cu liderii de proiect ai acestor distribuții pentru a putea face o astfel de afirmație? La urma urmei, este o comunitate distribuită, cu sursă deschisă.
Whither Snap?
Întrebarea mai mare este dacă Snap va fi adoptat oficial de alte distribuții? Aici lucrurile se complică puțin. Devine o problemă tehnologică și politică.
În primul rând, Snap nu este singura soluție existentă. Există multe proiecte care au încercat să ofere ecosisteme de împachetare agnostice față de distro-uri pentru ecosistemele Linux. Dar poate fi dificil să se ajungă la un consens în cadrul lumii distro-urilor Linux. Există AppImage și Flatpak, care oferă alternative adecvate la Snap; aceste proiecte există de mult mai mult timp decât Snap.
Atunci, de ce nu a adoptat Canonical aceste soluții în loc să pornească Click sau Snap?
„Am analizat și am descoperit că AppImage funcționează perfect pentru aplicațiile desktop „leaf-node””, a declarat Shuttleworth. O aplicație „leaf-node” este una care nu trebuie să se integreze cu nicio altă aplicație. Snap a fost conceput mai degrabă pentru a împacheta aplicații cu dependențe și aplicații conexe. „Snaps are o gamă de capacități pentru a descrie aceste conexiuni – interfețe, prize și sloturi, precum și fișiere partajate și așa mai departe.”
În plus, Shuttleworth ne-a spus că Snap a fost proiectat pentru niveluri mai ridicate de securitate în comparație cu AppImage, în parte pentru că echipa care lucra la telefonul mobil s-a concentrat pe securitate și eficiență, și în parte pentru că Snap folosește capacități mai noi ale kernelului.
Flatpak se presupune că a căzut victimă rivalității dintre Canonical și Red Hat în timp ce era dezvoltat de cei de la Fedora. Când l-am întrebat, Shuttleworth l-a respins ca fiind un proiect dezvoltat de un singur dezvoltator.
Acesta explică de ce Canonical a mers mai departe cu Snap.
Acum, îl vor adopta și alte distribuții? Dezvoltatorii Fedora au declarat deja că nu vor folosi Snap. Un dezvoltator Fedora a scris pe lista de discuții: „Noi, bineînțeles, nu avem niciun plan de a adopta Snappy în Fedora și, de fapt, mai mulți dezvoltatori Fedora lucrează la o soluție concurentă, Flatpak.”
Red Hat a adoptat anterior un proiect Canonical pentru inițializarea sistemului numit Upstart. Hellekson a declarat: „Acestea sunt zile foarte timpurii pentru toate aceste eforturi de împachetare și așteptăm cu nerăbdare să lucrăm cu toate comunitățile conexe pentru a face viața cât mai ușoară posibil pentru utilizatorii Linux.”
Dincolo de rivalitatea dintre Red Hat și Canonical, există unele probleme tehnice care ar putea descuraja alte proiecte să colaboreze la Snap. Unul dintre aceste motive este faptul că dezvoltatorii trebuie să semneze un CLA (Contributor License Agreement) dacă contribuie la proiectul Snap. Michael Hall, un dezvoltator Canonical, a declarat că un „CLA este necesar atunci când un dezvoltator dorește să contribuie la proiectul Snap în sine. Nu este necesar niciun CLA pentru a crea sau distribui Snap-uri ale aplicațiilor.”
CLA-urile permit Canonical să schimbe licența proiectului. Acest lucru este benefic pentru Canonical, deoarece poate relicenția un proiect, permițând ca acesta să fie folosit cu licențe non-libere sau incompatibile. De obicei, dezvoltatorilor nu le plac CLA-urile.
Frank Karlitschek de la Nextcloud ne-a spus că reziliază CLA-urile de la Nextcloud, deoarece consideră că CLA-urile nu au o reputație foarte bună în cadrul comunității open source.
Când am întrebat Red Hat dacă CLA-urile vor diminua colaborarea în jurul Snap, Hellekson a spus: „Contributor License Agreements face dificilă participarea noastră. Credem că licențierea directă, cu sursă deschisă, este o abordare mai bună și mai incluzivă.”
Răspunsul celor de la SUSE a fost cam același. Pfeifer a declarat: „Inginerii și personalul SUSE continuă să contribuie la o multitudine de proiecte open source, atât în timpul companiei, cât și în timpul nostru liber, iar acolo unde este necesar am semnat CLA-uri. Cu toate acestea, ori de câte ori inițiem sau influențăm proiecte, încercăm să ne ferim de CLA. În general, nu ne plac CLA-urile care atribuie un drept de autor care permite organizațiilor să relicențieze codul open source folosind o licență non-open source.”
Când l-am întrebat pe Shuttleworth dacă ar lua în considerare renunțarea la CLA-urile din Snap pentru a obține un sprijin mai larg din partea altor distribuții, acesta a început prin a explica de ce CLA-urile sunt bune, dar apoi a mai spus că „dacă asta ar face o diferență, atunci da, am găsi o modalitate de a renunța la ele.”
And Then There was One?
În timp, maturitatea, popularitatea și superioritatea tehnică a unuia față de celălalt ne pot lăsa cu o singură soluție. Am mai văzut asta înainte cu Upstart și systemd, unde systemd a apărut ca o tehnologie superioară și a devenit implicit pe toate cele trei distribuții Linux importante: Ubuntu, RHEL și SUSE.
În oricare dintre cazuri, ambele tehnologii se află în stadii foarte incipiente de dezvoltare și este greu de spus care proiect va avea succes. Cu toate acestea, este destul de clar că, în lumea centrată pe containere, Linux are nevoie de un nou mecanism de livrare a aplicațiilor.
Multe companii și comunități și-au exprimat sprijinul pentru soluții precum Snap. Samsung și Dell s-au alăturat Canonical în cadrul apelului de presă și au declarat necesitatea unei astfel de soluții. În ceea ce privește partea de desktop, proiecte precum LibreOffice și Firefox și-au exprimat deja sprijinul pentru Snap.
Timp va spune dacă Snap va fi adoptat în afara Ubuntu sau nu. Indiferent ce rezervă viitorul pentru Snap, ar trebui să acordăm creditul cuvenit companiei Canonical pentru că a împins limitele, forțând restul comunității Linux să se concentreze, în sfârșit, pe rezolvarea unei probleme cu care fie devenisem atât de confortabili, fie, poate, nu am avut niciodată motivația de a o rezolva.
CoreOS și Red Hat sunt sponsori ai The New Stack.