Poche settimane fa, Canonical ha annunciato il supporto di distribuzioni incrociate per il meccanismo di consegna delle applicazioni Snap, che potrebbe supportare applicazioni mobili, desktop e server-based. L’annuncio ha arruffato alcune piume all’interno della comunità Linux, che ha visto scarse prove di qualsiasi altra distro Linux che supporta Snap.
Snap è il tentativo di Canonical di perfezionare il meccanismo di imballaggio e consegna delle applicazioni sulla piattaforma Linux. L’origine di Snap trova le sue radici in Click, una soluzione che Canonical ha creato per la sua piattaforma mobile nel 2014, per gestire la complessità della consegna delle app agli utenti di telefoni e tablet Ubuntu, un ecosistema molto diverso dai desktop e server. Inoltre, il mobile aveva anche bisogno di confinare le app e sandboxarle, in modo che non compromettessero l’intera piattaforma.
Click ha permesso agli sviluppatori di raggruppare tutte le dipendenze in un unico pacchetto di app, così gli utenti e gli sviluppatori non dovevano preoccuparsi di sistemi e librerie di app in conflitto. Permetteva agli sviluppatori di utilizzare le ultime librerie nelle loro app, per offrire nuove funzionalità in quanto disaccoppiate dalle librerie installate sul sistema.
Da Mobile a Server e IoT
Click si è evoluto in Snap e Canonical ha esteso il suo potenziale utilizzo agli spazi server, cloud, Internet of Things (IoT) e desktop. Con il rilascio di Ubuntu 16.04 in aprile, Canonical ha portato ufficialmente Snap sul desktop di Ubuntu.
Canonical sta anche sviluppando Snappy Ubuntu Core, un piccolo sistema operativo basato su Linux per implementazioni di container cloud su larga scala, dispositivi IoT e molto altro, e tutto ciò che ha bisogno di aggiornamenti transitori e di un ingombro ridotto. Snappy Ubuntu Core funziona più o meno come Chrome OS e CoreOS di Google, dove offre aggiornamenti transitori basati su immagini per il sistema e le applicazioni che possono essere ritirate. Allo stesso tempo, offre il confinamento che è noto nel mondo dei container.
Snap è l’anima di quella tecnologia.
Il pasticcio Linux di App Delivery
Il modello esistente di app delivery su Linux ha molti difetti. Il mondo Linux è per lo più diviso in due campi di confezionamento delle app: rpm e deb. Inoltre, ci sono diverse versioni delle stesse distribuzioni che usano librerie diverse, quindi diventa abbastanza impegnativo per gli sviluppatori di app pacchettizzare le applicazioni per Linux.
Come risultato, gli sviluppatori di app non possono trarre vantaggio dalle ultime librerie e offrire più funzionalità ai loro utenti se la distribuzione sta ancora usando librerie più vecchie.
Nella maggior parte dei casi, gli sviluppatori di app open source non pacchettizzano le loro applicazioni per le distribuzioni. Le applicazioni popolari o di lunga data sono di solito pacchettizzate dagli sviluppatori delle distribuzioni. Quelle più recenti o meno popolari sono pacchettizzate dall’upstream per ogni distro che vogliono supportare, o non sono offerte affatto come pacchetto della distro. Quando viene rilasciata una nuova versione di un’applicazione, questi sviluppatori la testano e poi la rendono disponibile per la distro. Come potete vedere, invece dello sviluppatore di app che scrive solo un’app per l’intera piattaforma, che in questo caso è Linux, ci sono molte persone che portano quell’app agli utenti.
Aggiunge più complessità.
Ci sono casi in cui Windows e MacOS ottengono le ultime versioni immediatamente, poiché le app sono pacchettizzate dagli sviluppatori primari, mentre le distro Linux possono richiedere un po’ di tempo. Non è tutto; alcune distro le ottengono velocemente, mentre altre devono aspettare settimane o mesi.
Nel caso di app commerciali come Skype, Dropbox, Chrome, l’onere è dello sviluppatore primario di pacchettizzare le app e offrire binari per diverse distribuzioni. Molte applicazioni non funzionano su versioni più vecchie, ma supportate, di molte distribuzioni.
In una parola, è un casino.
Anche il creatore di Linux, Linus Torvalds, non è contento del modello esistente di consegna delle app su Linux. Non offre i binari delle sue applicazioni per la piattaforma Linux citando questo casino. Dirk Hohndel, il manutentore di Subsurface (un progetto iniziato da Linus), ha spiegato: “La situazione attuale con decine di distribuzioni, ognuna con regole diverse, ognuna con versioni diverse di librerie diverse, alcune con alcune librerie mancanti, ognuna con diversi strumenti di imballaggio e formati di imballaggio … che fondamentalmente dice agli sviluppatori di app ‘vai via, concentrati sulle piattaforme che si preoccupano delle applicazioni.
“Il packaging delle applicazioni è enormemente importante, ma lo è anche la provenienza e la manutenzione di tutti i pezzi coinvolti”, ha concordato Gunnar Hellekson, direttore della gestione dei prodotti per Red Hat Enterprise Linux.
Snap è stato progettato per portare un po’ di ordine in questo stato di cose. Ma se sarà adottato è tutta un’altra questione.
Hellekson ha sostenuto che strumenti come Snap non “risolvono magicamente i problemi di interoperabilità tra le distribuzioni Linux, e in realtà spostano più responsabilità per la manutenzione e la sicurezza ai fornitori di applicazioni. In questo modo, potrebbero rendere lo sviluppo su Linux ancora più difficile nonostante i molti benefici per gli utenti.”
“I vantaggi di Snap sono direttamente correlati ai suoi svantaggi … in sostanza, Snap è l’equivalente del collegamento statico – è conveniente da un lato, crea duplicazioni e sfide per quanto riguarda la sicurezza (e le patch di sicurezza) dall’altro,” ha detto Gerald Pfeifer, vice presidente dei prodotti SUSE e programmi tecnologici.
Tuttavia, non tutti sono della stessa opinione. Brandon Philips, co-fondatore e chief technology officer di CoreOS, ci ha detto che i container sono il futuro delle applicazioni su Linux. Ma i container Docker non possono essere usati ovunque. Hanno i loro limiti. Ciò di cui abbiamo bisogno è una soluzione simile ai container, qualcosa come Snap.
Durante un’altra intervista, il principale sviluppatore del kernel Linux Greg Kroah-Hartman ci ha detto che Android ha fatto i container “per le vostre applicazioni per otto o nove anni. Ogni applicazione gira nel proprio spazio dei nomi. Non può vedere al di fuori di esso. Questo è il modo in cui si deve fare. Questo è il futuro di Linux e il modo in cui i sistemi funzionano”. Ha detto che Snap è lo stesso concetto, la stessa idea.
Snap Goes Cross Platform
Il successo di Snap dipende molto dalla sua adozione da parte della più grande comunità open source. A cosa serve un formato di app se nessuno lo usa? Essendo una tecnologia Ubuntu-only, che potrebbe anche non essere supportata ufficialmente dai suoi derivati come Linux Mint, KDE neon o OS elementare, Snap potrebbe affrontare una carriera non così di successo.
Quando Canonical ha annunciato Snap, ha affermato in una conferenza stampa che ha lavorato con varie distribuzioni per aggiungere il supporto per Snap.
Canonical ha detto che Snap è nativamente disponibile per Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity, e Xubuntu. Canonical sta anche lavorando alla convalida di Snaps su CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt e Red Hat Enterprise Linux.
Canonical e SUSE non sono attualmente impegnate nello sviluppo intorno alla collaborazione su Snaps, e in effetti, sembra che questo non sia il risultato di una progettazione e sviluppo della comunità aperta”, Gerald Pfeifer, SUSE.
L’annuncio di Canonical di aver lavorato con altre distribuzioni ha attirato alcune critiche da alcuni membri della comunità open source. Gli sviluppatori di Fedora non hanno preso bene questo annuncio e hanno criticato Canonical affermando che non c’è stata alcuna collaborazione tra i due progetti.
Quando abbiamo seguito il fondatore di Canonical Mark Shuttleworth, per chiedere di queste accuse, ha risposto, “Abbiamo fatto un briefing con il team desktop di Red Hat e siamo sempre aperti a lavorare con tutte le distribuzioni Linux per abilitare Snaps.”
Questa si è rivelata una novità per Red Hat, tuttavia, che gestisce la distribuzione Fedora.
“Mentre lavoriamo con Canonical in diverse comunità, siamo rimasti sorpresi come tutti gli altri quando hanno annunciato il nostro coinvolgimento in questa particolare iniziativa. Siamo aperti a ulteriori discussioni su questo, e a vedere come la comunità Linux in generale vuole lavorare insieme”, ha detto Hellekson.
Anche i funzionari di SUSE hanno minimizzato qualsiasi collaborazione. “Canonical e SUSE non sono attualmente impegnate nello sviluppo intorno alla collaborazione su Snaps, e in effetti, sembra che questo non sia stato il risultato del design e dello sviluppo della comunità aperta”, ha detto Pfeifer.
Quello che sembra essere successo è che Canonical ha lavorato con alcuni sviluppatori, forse solo una manciata, di altri progetti e hanno assistito nel packaging di Snaps per altre distribuzioni.
Canonical non è perfetta
Parte del contraccolpo che Canonical può aver ricevuto può essere un sottoprodotto di come fa affari.
Per esempio, altre aziende Linux, come Red Hat e SUSE, mantengono una separazione dei poteri molto chiara quando si tratta di Fedora e openSUSE. Fedora e openSUSE sono progetti abbastanza indipendenti, guidati dalla comunità, dove le decisioni sono prese dai membri della comunità e non dalle aziende sponsor.
Al contrario, Ubuntu è un prodotto Canonical che è anche un progetto comunitario. A causa di ciò, contrariamente a openSUSE e Fedora, Canonical ha il controllo diretto su Ubuntu. Abbiamo già imparato nel caso di ownCloud; è davvero difficile mantenere un equilibrio tra le esigenze della comunità e della società; spesso finisce in un disastro come ownCloud.
Si pone la questione di come si ‘lavora’ con un progetto?
Inoltre, molti sentono che c’è una mancanza di trasparenza con Ubuntu. A volte molti dei principali collaboratori di Ubuntu hanno espresso frustrazione per il fatto che Canonical ha tenuto i principali annunci su Ubuntu sotto silenzio, nascosti anche ai membri del nucleo. I membri di Ubuntu non avevano idea di Ubuntu per Windows o dello sfortunato progetto Edge.
“Non tratteniamo le cose”, il CEO di Red Hat Jim Whitehurst ha risposto ad una domanda sull’approccio di quella società all’open source. “Quando costruiamo cose, non le nascondiamo alla gente per fare una grande rivelazione e dire ‘ecco il codice’. Non lo facciamo. Lavoriamo in comunità dal primo giorno, tutto il tempo. Penso che cerchiamo di essere davvero dei buoni partecipanti, e penso che questo venga fuori.”
In cima a queste differenze, Canonical è anche nota per fare alcuni passi falsi quando si tratta di rilasciare informazioni. Questo sembra certamente essere il caso dell’annuncio del supporto cross-distribuzione per Snap; la formulazione che ha irritato gli sviluppatori Fedora era “Sviluppatori di più distribuzioni Linux”. Per essere chiari, Canonical non ha mai dichiarato esplicitamente nel suo comunicato stampa che ha lavorato con Fedora. E in base alle informazioni che abbiamo raccolto, non c’è stato alcun impegno “ufficiale” con distro Linux come Fedora, Red Hat, SUSE o altre.
Detto questo, si pone la questione di come si “lavora” con un progetto? Se uno sviluppatore che lavora su un’applicazione collabora con uno sviluppatore di Ubuntu, uno sviluppatore di Fedora e uno sviluppatore di openSUSE per portare quell’applicazione su quelle piattaforme, sarebbe sbagliato dire che lo sviluppatore ha lavorato con più distribuzioni per portare l’applicazione a loro? O lo sviluppatore ha bisogno di un impegno ufficiale con i capi progetto di queste distribuzioni per poter fare una tale dichiarazione? È una comunità distribuita, open source, dopo tutto.
Dove si trova Snap?
La domanda più grande è: Snap sarà adottata ufficialmente da altre distro? È qui che le cose si complicano un po’. Diventa una questione tecnologica e politica.
Prima di tutto, Snap non è l’unica soluzione in giro. Ci sono molti progetti che hanno cercato di offrire ecosistemi di packaging agnostici alle distro per gli ecosistemi Linux. Ma può essere difficile trovare il consenso all’interno del mondo delle distro Linux. Ci sono AppImage e Flatpak, che offrono alternative adeguate a Snap; questi progetti sono stati in giro molto più a lungo di Snap.
Perché quindi Canonical non ha adottato queste soluzioni invece di avviare Click o Snap?
“Abbiamo esaminato la questione, e abbiamo scoperto che AppImage funziona perfettamente per le applicazioni desktop ‘leaf-node’”, ha detto Shuttleworth. Un’applicazione leaf-node è un’applicazione che non ha bisogno di integrarsi con altre app. Snap è stato progettato più per confezionare applicazioni con dipendenze e applicazioni correlate. “Gli snap hanno una gamma di capacità per descrivere queste connessioni – interfacce, spine e slot, così come file condivisi e così via.”
In aggiunta a questo, Shuttleworth ci ha detto che Snap è stato progettato per livelli più elevati di sicurezza rispetto ad AppImage, in parte perché il team che lavorava sul cellulare era concentrato sulla sicurezza e l’efficienza, e in parte perché Snap utilizza capacità del kernel più recenti.
Flatpak è presumibilmente caduto vittima della rivalità tra Canonical e Red Hat mentre veniva sviluppato da persone Fedora. Quando l’ho chiesto, Shuttleworth l’ha liquidato come un progetto sviluppato da un singolo sviluppatore.
Questo spiega perché Canonical è andata avanti con Snap.
Ora, altre distro lo adotteranno? Gli sviluppatori Fedora hanno già dichiarato che non useranno Snap. Uno sviluppatore Fedora ha scritto sulla mailing list, “Noi, naturalmente, non abbiamo piani per adottare Snappy in Fedora, e infatti, diversi sviluppatori Fedora stanno lavorando su una soluzione concorrente, Flatpak.”
Red Hat ha precedentemente abbracciato un progetto Canonical per l’inizializzazione del sistema chiamato Upstart. Hellekson ha detto: “Questi sono i primi giorni per tutti questi sforzi di packaging, e non vediamo l’ora di lavorare con tutte le comunità correlate per rendere la vita il più facile possibile per gli utenti Linux.”
Al di là della rivalità tra Red Hat e Canonical, ci sono alcune questioni tecniche che possono scoraggiare altri progetti dal collaborare su Snap. Uno di questi motivi è che gli sviluppatori devono firmare un CLA (Contributor License Agreement) se contribuiscono al progetto Snap. Michael Hall, uno sviluppatore di Canonical, ha detto che un “CLA è necessario quando uno sviluppatore vuole contribuire al progetto Snap stesso. Non c’è nessun CLA richiesto per creare o distribuire Snap di applicazioni.”
I CLA permettono a Canonical di cambiare la licenza del progetto. Questo è vantaggioso per Canonical, in quanto possono ri-licenziare un progetto, permettendone l’uso con licenze non libere o incompatibili. Agli sviluppatori di solito non piacciono i CLA.
Frank Karlitschek di Nextcloud ci ha detto che sta terminando i CLA da Nextcloud, poiché ritiene che i CLA non abbiano una buona reputazione all’interno della comunità open source.
Quando abbiamo chiesto a Red Hat se i CLA avrebbero smorzato la collaborazione intorno a Snap, Hellekson ha detto: “I Contributor License Agreement rendono difficile per noi partecipare. Crediamo che le licenze open source siano un approccio migliore e più inclusivo.”
La risposta di SUSE è stata molto simile. Pfeifer ha detto: “Gli ingegneri e lo staff di SUSE continuano a contribuire ad una pletora di progetti open source, sia nel tempo dell’azienda che nel nostro, e dove necessario abbiamo firmato i CLA. Tuttavia, ovunque e ogni volta che iniziamo o influenziamo progetti, cerchiamo di stare alla larga dai CLA. Generalmente non ci piacciono i CLA che assegnano un copyright che consente alle organizzazioni di concedere nuovamente la licenza del codice open source utilizzando una licenza non open source.”
Quando abbiamo chiesto a Shuttleworth se avrebbe considerato di eliminare i CLA da Snap per ottenere un più ampio supporto da altre distro, ha iniziato spiegando perché i CLA sono buoni, ma poi ha anche detto che “se questo farebbe la differenza, allora sì, troveremmo un modo per eliminarli.”
E poi ce n’era uno?
Con il tempo, la maturità, la popolarità e la superiorità tecnica di uno sull’altro possono lasciarci con una soluzione. Lo abbiamo già visto con Upstart e systemd, dove systemd è emerso come una tecnologia superiore ed è diventato il default su tutte e tre le principali distro Linux: Ubuntu, RHEL e SUSE.
In entrambi i casi, entrambe le tecnologie sono nelle primissime fasi di sviluppo, ed è difficile dire quale progetto avrà successo. Tuttavia, è abbastanza chiaro che nel mondo container-centrico, Linux ha bisogno di un nuovo meccanismo di consegna delle applicazioni.
Molte aziende e comunità hanno espresso sostegno per soluzioni come Snap. Samsung e Dell si sono uniti a Canonical nella conferenza stampa e hanno dichiarato la necessità di una tale soluzione. Sul lato desktop, progetti come LibreOffice e Firefox hanno già espresso supporto per Snap.
Il tempo dirà se Snap sarà adottato al di fuori di Ubuntu o no. Qualunque cosa il futuro abbia in serbo per Snap, dovremmo dare a Canonical il dovuto credito per aver spinto la busta, costringendo il resto della comunità Linux a concentrarsi finalmente sulla risoluzione di un problema che ci era diventato così comodo o, forse, non abbiamo mai avuto la motivazione per risolvere.
CoreOS e Red Hat sono sponsor di The New Stack.