Gli sviluppatori di diverse distribuzioni Linux (ma anche numerose aziende) hanno annunciato la collaborazione per lo sviluppo di snap, il nuovo formato alternativo ai .deb sviluppato da casa Canonical che consente di avere un unico pacchetto binario in grado di funzionare perfettamente e in modo ‘sicuro‘ su qualsiasi desktop Linux, server cloud o altro dispositivo.
Fra i partner troviamo Dell, Samsung, The Linux Foundation, The Document Foundation, Krita, Mycroft, Horizon Computing, e gli sviluppatori che contribuiscono ad Arch, Debian, OpenWrt, Ubuntu e tutte le distribuzioni derivate.

snap

Snaps funzionano ora nativamente su Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity e Xubuntu. Sono attualmente in corso di validazione su CentOS, elementary, Gentoo, Mint, openSUSE, OpenWrt e RHEL e sono facili da attivare su altre distribuzioni Linux. Insieme queste distribuzioni rappresentano la stragrande maggioranza del mondo Linux sul desktop, server e cloud.

Questa innovazione è stata presa con grande entusiasmo dai produttori di applicazioni, in quanto comporta una tremenda semplificazione: pubblicare uno snap è incredibilmente più semplice che non gestire i pacchetti .deb.

Vi riporto alcune reazioni dei vendor di software, tutti entusiasti degli snap.

-“Noi vogliamo offrire ai nostri utenti affezionati a Firefox il meglio su ogni piattaforma, device e sistema operativo. Con l’introduzione degli snap un ottimizzazione più completa di firefox diventa finalmente possibile anche su Linux.”- queste le parole di Nick Nguyen, vice presidente di Mozilla.

Mantenere i pacchetti .deb in una repo privata era complesso e occupava tantissimo tempo, gli snap, invece, sono facili da mantenere e distribuire.“- cosi’ si è pronunciato Boudewijn Rempt, project lead della Krita Foundation. Krita 3.0 è appena stato rilasciato sotto forma di snap e si aggiornerà automaticamente non appena una nuova versione diverrà disponibile.

“Pubblicare Mycroft come snap è un’ottimo modo per rendere la nostra tecnologia disponibile per molte distribuzioni Linux. La possibilità di aggiornare e rendere maggiormente sicuro un software con facilità è una cosa molto positiva. I nostri programmatori ora devono dedicare meno tempo nella gestione dei package formats e possono pertanto concentrarsi sulle nuove funzioni da implementare” cosi’ Joshua Montgomery CEO Mycroft.

-“Gli snaps sono un modo più veloce per distribuire software ad un numero elevato di utenti”Matteo Croce di OpenWrt.

Ogni snap è ‘confinato’ grazie a meccanismi di sicurezza molto evoluti, esso riceve dal sistema solo i permessi strettamente necessari per la sua esecuzione. Gli utenti, inoltre, non devono compiere decisioni di sicurezza quando installano uno snap.

Insomma questa ‘rivoluzione snap‘ sembra avere più PRO che CONTRO anche se non tutti sono d’accordo.

[Fonte]

  • Incredibile.. questo cambierà nel bene o nel male tutto il mondo linux…

    • Aury88

      non è detto…l’annuncio è stato un po’ frainteso. al momento attuale snapd (che è il software che gestisce gli snappy) non è stato adottato in maniera ufficiale da nessuno (tranne che in ubuntu-mate credo). quelli di cui si parla sono dei port fatti dagli utenti…è di certo un passo nella direzione della pacchettizzazione universale ma ci sono ancora dei problemi che potrebbero compromettere questo processo per snappy: il fatto che tutti gli snappy siano ospitati nel market canonical e tutti gli snapd fanno riferimento a quello (c’è il vantaggio per gli sviluppatori e gli utenti ma non per le distro che perderebbero il controllo sul market qualora volessero adottare snappy come default) e sopratutto la presenza di flatpack che è già stato adottato in maniera ufficiale da alcune distro (sicuro RH ma ho sentito anche di altre), che ha la condivisione dei runtime (minore duplicazione e peso, ma anche segregazione) ed è da tempo installabile su altre distro (ubuntu, fedora)
      vedremo e speriamo si affermi solo un metodo di pacchettizzazione…avere 2 metodi universali è un po’ un controsenso imho

      • Samael

        Eh, mi sembrava strano infatti che in Fedora si fosse adottato Snappy, dato che su Red Hat si usa SELinux anziché AppArmor, e soprattutto lo sviluppatore di Flatpak (Alexander Larsson) è un ingegnere di Red Hat. xD

        Senza contare che la vedo proprio dura che Red Hat si metta ad utilizzare tecnologie Canonical, e viceversa.
        Considerando quanto sono in guerra queste due, è molto probabile che cerchino di spingere le proprie soluzioni per mantenere il controllo su tutto lo stack.
        Difficilmente una delle due accetterebbe di buon grado di dipendere da un concorrente. Già systemd in Ubuntu è stato un boccone amaro che Shuttleworth ha dovuto mandare giù.

        • Teo

          Parlando di systemd ,come mai su Arch e derivate bisogna abilitare il servizio, prendiamo ad esempio iptables, mentre su Debian Ubuntu non esiste il comando “sudo enable iptables.service ” ?

          • Teo

            Mi sa che mi sono espresso male, volevo chiederti, come mai systemd è implementato in modo differente sulle varie distro ?

          • Samael

            Non è implementato in maniera differente.
            Semmai puoi trovare un servizio su una distro mentre su un altro no, ma systemd quello è.
            E la presenza o meno di un servizio dipende dalle configurazioni dei pacchettizzatori della distro.

            Nel caso di iptables.service, semplicemente quelli di Arch hanno aggiunto un servizio per systemd per andare a leggere la tabella delle regole con iptables-restore in fase di avvio e fare flush in fase di chiusura.

          • Teo

            Grazie Samael, ora mi è più chiaro.

          • Teo

            Ho pure sbagliato a scrivere, era “systemctl enable iptables.service”

        • maufor

          Preciso che non si tratta di polemica, ma di amara costatazione:
          e’ Canonical in guerra con il resto del mondo ed in particolar modo con RH, la sua nemesi… Peccato per Mark che RH sia una realta’ dai numeri molto diversi da quelli Canonical; basta dare un’occhiata a Forbes e vedere chi installa e dove si installano soluzione RHEL, al di la’ dei numeri (forniti come e da chi?) sulla presunta diffusione dei sistemi Ubuntu-based nel cloud. A livello enterprise, basta inoltre guardare chi contribuisce allo sviluppo del kernel e chi orbita (sebbene a modo suo) intorno ad OpenStack…
          Cio’ detto, finalmente qualcosa di utile e (questa volta) di condiviso che provenga dall’entourage Canonical…

          • alex

            Si, è anche una guerra commerciale. E alla fine tra chi vuoi che sia in ambito linux? per forza RH e Canonical, e non è che una sia buona e l’altra cattiva come a volte sembra uscire da alcuni post.

          • maufor

            Concordo, tutte le soluzioni possono essere valide e tutte hanno delle pecche. Tuttavia l’atteggiamento di Canonical mi risulta ancora incomprensibile. Sono anni che arrivano proclami (puntualmente smentiti dai fatti) sull’essere leader di qua e numero uno di la’. Anzi, ricordo di aver visto lo stesso Shuttleworth citare RH come un modello da abbattere… mi ricordava Jobs ed il pallino fisso contro Big Blue. Si potrebbe essere molto piu’ utili cooperando *attivamente* (e non limitandosi a pacchettizzare Debian con l’aggiunta di qualche personalizzazione ancora incompleta). Fosse una guerra commerciale, la strategia di Canonical andrebbe sicuramente rivista, considerata la forza del presunto competitor (allo stato attuale non converrebbe nemmeno presentarsi sul campo di battaglia). Insomma, voglio dire che ci si puo’ ritagliare uno spazio dove Linux e’ vulnerabile (o meglio, inesistente) senza voler per forza fare la guerra contro qualcuno. Tanto, da quanto mi risulta, la guerra e’ unilaterale…

          • Aury88

            scusa, quali annunci puntualmente smentiti?

            ubuntu si limita a pacchettizzare debian???? da quello che mi risulta ubuntu non è più una semplice pacchettizzazione di debian da anni….e i problemi con il resto del mondo linux sono nati proprio quando ha smesso di fare semplice pacchettizzazione e personalizzazione, come altre n-mila distro, e ha cominciato a creare software per il proprio so…puoi spiegare meglio o dire a cosa ti riferisci? così come l’hai detta non mi sembra la situazione attuale….di certo creare un sistema di init, un sistema di pacchetizzazione un server grafico un DE, non sono semplici pacchettizzazioni ne tanto meno banali personalizzazioni…dove ti risulta che la guerra è unilaterale? dati?

          • maufor

            Mi riferisco alle previsioni di avere un parco di 200 milioni installazioni in quattro anni, ad avere un market share del 5% sui PC acquistati, a MIR, alla chiusura di parte del servizio Ubuntu One, ed in ultimo ad Ubuntu Phone… con tanto di link. Pero’ il post non e’ passato… Evidentemente ho dato fastidio a qualcuno 🙂

          • Aury88

            anche io ho in pending alcuni post….
            confondi, non so se volutamente, annunci su obbiettivi futuri con gli annunci sull'”essere leader di qua e numero uno di la” che sono dichiarazioni su uno stato attuale…quendo fa annunci sull’essere leader in un settore o il numero uno nell’altro lo fa riportando dai dati di fonti esterne non richieste/finanziate da canonical con numeri chiari sull’installato in una certa tipologia di market/servizio
            Che centra MIR con l'”essere leader di qua e numero uno di la”? mir è in sviluppo ma già utilizzato e non è mai stata dichiarata una tecnologia leader o numero uno
            “alla chiusura di parte del servizio Ubuntu One” che centra con “essere leader di qua e numero uno di la” quello è un servizio mai spacciato per leader di alcunchè ne numero uno di alcunchè…anzi è stato un flop ammesso dalla stessa canonical e quindi chiuso perchè non generava utili

            “ed in ultimo ad Ubuntu Phone” che centra quello con “essere leader di qua e numero uno di la”? non mi risulta canonical abbia mai fatto dichiarazioni di sorta sull’essere il leader nel so per smartphone o il numero uno per quanto concerne il mercato mobile.

          • maufor

            Obiettivi futuri? Chiamiamole pure esternazioni farneticanti!

            Hai decontestualizzato i miei esempi. Il tutto era per dare l’idea di cosa potrebbe apparire Ubuntu agli occhi di un direttore tecnico minimamente pensante che si trova a decidere sulla soluzione tecnica migliore, durevole, ed affidabile…

          • Aury88

            ” tutto era per dare l’idea di cosa potrebbe apparire Ubuntu agli occhi
            di un direttore tecnico minimamente pensante che si trova a decidere
            sulla soluzione tecnica migliore, durevole, ed affidabile…” valutazioni che in ambito cloud evidentemente ha portato i direttori tecnici, si spera minimamente pensanti, a scegliere per la soluzione ubuntu…
            ammettendo che quelle siano farneticazioni, non centrano comunque nulla con gli annunci sull’essere leader o numero uno in questo o quel settore…quest’ultimi sono annunci di tutt’altra natura su una condizione attuale al periodo dell’annuncio e corredata dalle fonti che sono, mi sembra, neutrali ed esterne a canonical…e se non fossero stati dati corretti sarebbero stati smentiti

          • Aury88

            “al di la’ dei numeri (forniti come e da chi?) sulla presunta diffusione dei sistemi Ubuntu-based nel cloud” come presunta diffusione? forniti come e da chi?
            sono dati forniti da clienti e fornitori di servizi e mai negati dai concorrenti. per esempio c’è il Public-User-Survey-Report di openstack (non di canonical) che attesta percentuali del 65% per ubuntu 6% per RH e 23% per CentOS…in molti degli annunci di canonical sulle percentuali ci sono degli asterischi che rimandano alle fonti…
            un altro dato recente proviene da w3tech (non canonical) che attesta per i website il 32,7% per ubuntu, 31% per debian, il 20,5% per CentOS e il 3,8% RH…
            come sempre è una questione di market e non necessariamente il più grosso è imbattibile, di sicuro non ovunque e mi spiace per RH, ma il cloud è un settore dove canonical sta andando bene, e RH no…se guardi solo le dimensioni dell’azienda come parametro di capacità di conquistare/mantenere un mercato temo tu stia facendo lo stesso errore di yahoo con google.

          • Maddo

            In realtà Red Hat(per quanto in declino) ha ancora il dominio su tutti quegli applicativi “legacy” dove ci sono ancora contratti di assistenza decennali ancora in corso. Quindi non è così indietro(anche perché server != web). L’unico settore dove ubuntu domina, e dove davvero ha quasi zero concorrenza, è il cloud perché Red Hat non ci ha investito fin da subito e probabilmente la situazione di RHEL peggiorerà se non si affretta nell’IoT(dove l’unico concorrente serio di ubuntu è M$). In europa considera che penso venga usato più SuSe a livello enterprise che ubuntu(ovviamente sempre escludendo il cloud).

          • maufor

            Il post di Maddo (di seguito) chiarisce la situazione, sebbene non concordi del tutto sul declino di RH (nell’enterprise sta consolidando, le revenue sono in aumento). Per quanto attiene alle statistiche e agli asterischi, ognuno cita ed interpreta le proprie a modo suo. Se ci fermassimo alle statistiche dovremmo concludere che Mint e’ la distro piu’ usata cosi’ come la quasi totalita’ della popolazione italiana e’ osservante perche’ battezzata…
            La realta’ e’ che il parco installato RHEL e’ specifico ma strategico, cosi’ come sono i clienti che ha in mano ed i partner con cui fa accordi. E molti di quei clienti sono quelli che `orientano` la community (a meno di non voler credere che esista davvero la comunita’ costituita da gente che vive di aria e codice). Lo stesso discorso vale per SuSE, unica vera soluzione alternativa a RHEL in contesti enterprise che non siano Microsoft (molto, ma molto forte nell’enterprise soprattuto small/mid size ed in espansione nel cloud). I miei dati? Le aziende che ho visitato e con cui ho collaborato, in Italia e all’estero. Ho visto molto backend RHEL, talvolta SLES, ma non mi e’ mai capitato di incontrare Ubuntu. Si tratta di un punto di vista specifico, ovviamente.
            Tornando al tuo post, non si tratta quindi di “battere il piu’ grosso”. Anzi, proprio dove il piu’ grosso non gioca per niente (il desktop) si vedono i risultati: Unity?. RH non ha mai preso in considerazione il desktop; la sua valutazione e’ sostanzialmente riassumbile in “Microsoft e’ troppo forte, col desktop non faccio soldi, non ci investo un centesimo”. Voglio dire, quale migliore occasione per Canonical per consolidarsi nel desktop? Fa riflettere, o no?

          • Aury88

            “quanto attiene alle statistiche e agli asterischi, ognuno cita ed interpreta le ” proprie “a modo suo” quegli asterischi non riportano a dichiarazioni di canonical…non è un autocertificazione. riportano dati di report pubblicamente consultabili di aziende che forniscono infrastrutture e servizi.
            “Se ci fermassimo alle statistiche dovremmo concludere che Mint e’ la distro piu’ usata” se ti fermassi alle statistiche sbagliate si e sono sbagliate perchè non contano il numero di utilizzatori…quelle che contano il numero di utilizzatori con un campione statisticamente rappresentativo affermano il contrario e cioè che tra le distro linux ubuntu è la più utilizzata con un 26-27% degli utenti linux (escluso android) e mint è alcune posizioni dietro…80% è composto da utenti linux senza useragent
            “totalita’ della popolazione italiana e’ osservante perche’ battezzata” questo è un altro caso di dato usato per dimostrare una cosa che esula dal dato…ma di certo non vorrai dire che similmente se il 65% degli utenti openstack dichiara di usarlo su ubuntu in realtà non lo sta usando…vero?
            ” Si tratta di un punto di vista specifico, ovviamente.” non solo specifico in termini di market, ma anche, senza offesa, estremamente limitato visto che si basa solo su quello che vedi tu….non può essere che quelli che hanno altri genere di sistemi operativi si affidino ad altri per il supporto e che quindi non rientrano per questo nella tua statistica?

            “Fa riflettere, o no?”
            onestamente? no…canonical è presente nel desk (e gli ci sono voluti anni per diventare quello che è) ma è presente in molti altri settori dove ugualmente RH non è presente o è poco presente…il cloud è uno di questi che con il corebusiness di RH non centra nulla (e in cui canonical ha fatto quello che ha fatto nell’arco di pochi anni….questo si fa riflettere)…senza considerare che un campo in cui c’è un azienda predominante non necessariamente è inattaccabile…vedi il server dove RH è un nome storico e dove ha il predominio e dove, nonostante questo ed i ritardi canonical si è preso quote di installato non indifferenti.

            o lato mainfraim in cui non ho trovato dati ma dove c’è comunque un certo interesse in ubuntu attestato dalla collaborazione con IBM per il LinuxONE…

            e poi scusa…parli di giocare dove il più grosso non è presente e poi vorresti basare le strategie e il successo di un azienda su un campo già saturo, in declino nelle vendite e con monopolio affermato e protetto da vari lockin come quello desk? su dai!

          • maufor

            La mia visione e’ senza dubbio ristretta, cosa che ho premesso.
            Quando parli con i direttori tecnici di aziende ti rendi conto che le cose non vanno proprio come dicono le statistiche. Un conto e’ usarlo (anch’io lo uso con delle appliance), un conto e’ farne il deployment. Nel secondo caso, viene raramente preso in considerazione (sempre secondo la mia ristretta visione) perche’ non ritenuto essere un prodotto di classe enterprise. Saranno tutti prevenuti? puo’ essere. Pero’ Canonical ha dato senza dubbio una mano nel costruirsi una reputazione…

            Il cloud non e’ nel core business di RH??? Le acquisizioni che hanno fatto negli utlimi tre anni sono quindi uno spreco di denaro degli azionisti…

            Gli accordi? IBM ha sempre fatto accordi con tutti, talvolta per farci qualcosa di concreto, talvolta per affossare qualcuno (Eclipse docet). Parliamo di quelli che fa Canonical. Vogliamo parlare dell’accordo con Vmware proprio per Openstack? O con Oracle (ironia… il secondo e’ RHEL, il primo ha parte delle proprie soluzioni derivanti da RHEL…)? Dai! Sono evidenti disruptive agreements, altro che accordi fattivi! Il mainframe e’ altra cosa e sinceramente vedremo dovre andranno a parare

            Il desk non e’ saturo, e’ inesistente per Linux. Una azienda che diversifica la propria offerta come fa Canonical (dai server agli smartphone) e che si butta su MIR, che stringe accordi con Amazon per la rivendita di contenuti da desktop, per come la vedo io, dovrebbe essere minimamente interessata al desktop. Invece il risultato dov’e’?

          • Maddo

            Il problema di RH nel cloud è vagamente paragonabile a quello di Ubuntu(o linux in genere) nel desktop: sono arrivati tardi con il mercato già saturo. Su cloud per quanto red hat abbia investito l’ha fatto tardi, e il mercato è già praticamente saturo tra ubuntu e Azure. Il mercato desktop in generale è in mano a windows e di lì non si muoverà, anche perché il desktop sta diventando sempre più un prodotto di nicchia destinato a gamers che tireranno di assemblati e professionisti di varia natura, il consumer si compra l’ipad/telefono android/surface/quel che è, chi non ha un pc e non lo usa per gioco/lavoro non ha motivo di comprarselo, e se se lo deve comprare, non importa quanto linux in genere possa migliorare, windows ha l’egemonia da troppo per poter recuperare guadagnandoci. Canonical questo l’ha capito, e ha capito anche che dal desktop non ha più nulla da guadagnare checché se ne possa dire, e allora ha puntato al lato enterprise dove si fanno i soldi veri(e no, non è vero che non è concorrenziale come soluzioni di assistenza ecc…, anzi penso che l’assistenza canonical sia qualitativamente MOLTO superiorie rispetto a quella RH, un pelo sotto SLES, ma SLES è roba dell’altromondo) e ha iniziato prima col cloud(dove red hat ha una presenza irrisoria) e adesso sull’IoT(dove RH ancora non ha fatto nulla praticamente) insieme a Microsoft che ha fatto lo stesso ragionamento con windows(basta vedere cosa ha annunciato all’ultimo #BUILD per capire che a M$ di windows fine a se stesso non importi più nulla). RHEL mantiene il dominio sul “vecchio” mercato, perché i contratti di assistenza sono validi e la migrazione ad un nuovo sistema oltre che insensata(if it works it ain’t broken™) è pure costosa e rischiosa, Ubuntu domina sul cloud e sull’IoT post’ora è un testa a testa tra ubuntu e microsoft, vedremo dove porterà tutto ciò(SLES penso sia destinata a restare di nicchia per quanto tbh come prezzi e supporto è imho senza pari).

          • maufor

            La tua e’ un’analisi molto interessante.

            Non posso per dire molto su SLES (l’unica esperienza di rilievo risale ai tempi in cui era di Novel), pero’ non ho motivo di dubitare della serieta’ del prodotto e dell’assistenza. Per inciso, SuSE 7.2 e’ stata la mia prima installazione desktop e sono rimasto con loro per lungo tempo.

            Concordo sull’analisi che fai sul legacy. Il grosso di RH e’ proprio li’. Il legacy rappresenta pero’ una grossa fetta di consolidato e, almeno per quanto abbia visto, i competitor piu’ ostici sono Microsoft e Vmware.

            Quando dici che il desktop diventera’ di nicchia e’ sicuramente vero, su tempi piu’ lunghi pero’; teniamo presente che a livello enterprise gli utenti dovranno continuare ad usare Office (il vero punto di forza di MS), Exchange etc. L’IoT e’ ancora immaturo e credo ci vorra’ un po’ di tempo prima di vederlo come parte integrante dei processi aziendali. Ovviamente, sul mercato consumer e’ altra questione…

            Specificamente per il cloud, non sono convinto che un’azienda che ha lavorato con il “vecchio” mondo faccia cosi’ facilmente un salto nel buio verso un prodotto che, giusto o sbagliato che sia, e’ considerato non di classe enterprise. Gli amministratori sono prudenti e spesso chi comanda impone l’adozione di una soluzione tecnica non solo per quello che promette di fare, ma anche in funzione degli accordi che si possono fare con l’azienda che ti propone la soluzione… Ebbene proprio li’ RH predomina (e’ sul mercato praticamente da quando Linux e’ nato) con buona pace di Canonical.

          • gabriele tesio

            Beh, AT&T che è l’azienda di telefonia più grossa degli stati uniti sta sviluppando tutta la sua infrastruttura cloud con ubuntu, non credo quindi che loro non lo reputino di classe enterprise, altrimenti avrebbero scelto RH o qualcun altro (e lo stesso vale anche per servizi come spotify, netflix o walmart, che non sono proprio aziendine).

          • maufor

            Certo, possiamo andare avanti cosi’ all’infinito… per ognuno degli esempi che hai fatto ne esistono altri che vanno in direzioni diverse. Non se ne viene a capo. Per Canonical AT&T e’ senza dubbio un grosso colpo (a pensare che AT&T ha sempre fatto resistenza per via di UNIX). Piu’ di un malpensante dice pero’ che l’allenza serva piu’ a Canonical per piazzare Ubuntu phone nelle mani di un grosso operatore, che il costo dell’operazione non era (al tempo) definita (…) e che comunque si tratta di soluzioni custom. Ammetto pero’ di non essere tanto aggiornato sulla questione.

          • Maddo

            Ubuntu phone penso rientri nel progetto a lungo termine di ubuntu riguardante l’IoT: convergenza di più sistemi diversificati con uso massiccio di sensori. Ubuntu phone è più un banco di prova per questa strategia che un vero competitor per il mobile(anche perché anche qui, il mobile è saturo con ios e android, inutile girarci attorno) e unity8/mir, che saranno universali su phone/desktop etc… rientra nel grande piano di Shuttleworth per affossare RH(che è l’unica sua avversaria di rilievo), da qui anche l’accordo con M$ per il “Linux Subsystem” su win10.

          • maufor

            Siamo sempre li’… affossare la nemesi, come detto in apertura. Al di la’ della convenienza (credo ancora la cooperazione sia un modello vincente…) la vedo dura per Canonical. Unity8 ha fatto girare non poche sfere nel mondo open (personalmente avrei supportato Wayland/Gnome) e di fatto corre quasi da sola.

            Per quanto riguarda MS, sebbene non usi Windows da 15 anni guardo l’azienda con un certo rispetto. Sono quasi convinto che in un ipotetico scenario surreale finisca per uscire con una sua distro… in fondo non le mancano le competenze, le GUI le sa disegnare (un problema atavico ancora irrisolto in Linux) e non per ultimo ha gia’ in mano tutto cio’ che gli utenti usano in un computer… attenta Canonical 🙂

            Forse e’ fantascienza…

          • Aury88

            “di fatto corre quasi da sola” ma scusa, dove sarebbe il problema? soldi spesi di canonical e software opensource per la community

            “credo ancora la cooperazione sia un modello vincente” lo crede anche il mondo FOSS…e infatti vediamo che esistono poche distribuzioni, pochi ambienti grafici…pochi lettori multimediali…

          • maufor

            Non ho capito, a favore della frammentazione o no?

            “soldi spesi di canonical e software opensource per la community”… improvvisamente mi viene voglia di comprarmi un Mac.

          • Aury88

            “Non ho capito, a favore della frammentazione o no?”
            non ho un pensiero così unilaterale… la frammentazione è un problema quando rende volutamente incompatibile una cosa…ma non a livello di de intendo a livello applicativo/formato.

            ma la frammentazione di per se non è un problema…lascia solo più libertà all’utente ed è una conseguenza del fatto di avere/produrre codice opensource…non puoi impedirlo se non vuoi togliere la libertà di fare fork e onestamente il valore di questa libertà è imho molto più elevato del danno o presunto tale che fa la frammentazione.
            in questo caso la frammentazione fa ancora meno danni perchè è uno sviluppo finanziato da canonical e che non sottrae energie alla comunità…il resto del mondo linux può andare avanti come ha sempre fatto…sia che canonical abbia successo sia che fallisca miseramente…le energie che aveva la comunità pre canonical sono li non toccate da canonical che ci ha messo solo le proprie risorse per fare quello che desidera.non ha obbligato gnome a cambiare, ne wayland.

            “improvvisamente mi viene voglia di comprarmi un Mac.” allora saranno soldi spesi da te e niente codice se non il suo mero utilizzo da parte tua e degli altri clienti MAC…fortunatamente l’ambiente linux è aperto e non pone restrizioni che impediscano di uscirvene…il codice che ti piace te lo puoi addirittura prendere (forkare) e provare a portare su MAC (e anzi, sopratutto se è un applicativo vieni ringraziato dalla comunità gnu per questo ) purchè lo rilasci con la stessa licenza…questa è l’unica libertà che non hai 🙂

          • Maddo

            Unity8/Mir è un progetto nato per far convergere più sistemi sotto un’unica “bandiera”, Wayland/GNOME no. Wayland è stato pensato solo per il desktop come rimpiazzo di X11 e al momento su mobile “funziona” solo su Sailfish. GNOME invece è una causa persa, andrebbe riscritto da zero per poter fare quello che vogliono fare unity8/mir e già pur mantenendo il focus sul desktop e nient’altro rompe la compatibilità con le vecchie API ad OGNI minor update, il che è ridicolo(poveri themers).

          • Aury88

            aggiungo che mir è nato per usare driver android e permettere così un più facile porting sugli smartphone, wayland no e penso sia questo in realtà il grosso della differenza …che wayland sia in grado di gestire sia la modalità desk sia smartphone è attestato dal funzionare su jolla e su distro desk…quindi di per se, sotto questo punto di vista non penso dovrebbero esserci grossi impedimenti per la convergenza.
            GNOME più che per il desk onestamente mi sembra orientato per il tablet…ma è un po che non lo provo

          • Aury88

            non gli sta vendendo ubuntu phone….lo ha detto chiaramente Gabriele T. che AT&T sta creando l’infrastruttura cloud usando ubuntu…chi ha mai parlato di ubuntu phone?

          • maufor

            “chi ha mai parlato di ubuntu phone?” Perdonami, ma non comprendo se parli per Canonical. Nel caso, avrei un sacco di domande da farti… Tornando alla mia affermazione, e’ AT&T che ha cercato Ubuntu o Ubuntu che si e’ fatta trovare da AT&T? Pensi sul serio che il *progetto* (e non il prodotto) Ubuntu phone non c’entri niente?

          • Aury88

            non sono di canonical.
            sono abbastanza sicuro non si tratti del progetto ubuntu phone (o Ubuntu touch, da ora abbrevio inUT) in se se limitiamo il termine “progetto” a quella parte di codice su UT realizzato specificamente per lo smartphone e il resto dei settori consumer (fondamentalmente mir+unity8 + altro software).
            se parliamo invece della base che è snappy-ubuntu-core (che diventerà comune a tutti i prodotti canonical sulle varie piattaforme ed è quindi sviluppato anche per UT) sì ma è una forzatura dire che AT&T utilizzerà il codice di o a causa di UT…non so se sia chiaro…diciamo che il prodotto ubuntu usato sul cloud ha un codice di base che è il cuore del sistema operativo (che sarà condiviso da tutti i prodotti) e sopra una serie di applicativi alcuni dei quali generici (che saranno condivisi da tutti o alcuni prodotti) ed altri specifici del cloud. imho a AT&T che quelle parti del codice che userà siano stati sviluppati per lo smartphone o per un frigorifero (il riferimento non è casuale) penso poco gli importi…i motivi che l’hanno spinta a scegliere ubuntu penso non siano molto dissimili dai motivi delle altre aziende che con la telecomunicazione telefonica non hanno nulla a che fare.
            chi sia andata da chi non saprei…se la prima mossa l”ha fatta canonical o AT&T, alla fine comunque sono certo che prima di realizzare/modificare un infrastruttura vitale e/o il suo software AT&T abbia prima visto più proposte e poi abbia scelto quella a lei più adatta.
            aggiungo solo come nota che le tecnologie utilizzate da UT provengono (tranne che per mir+unity8) dallo sviluppo di ubuntu cloud e non viceversa…

          • Aury88

            + wikimedia, Uber, Lyft, instagram, Bloomberg, Paypal, Dropbox, Snapchat,Pinterest, Reddit, Airbnb…tutte realtà che hanno bisogno comunque di soluzioni e assistenza (cloud e/o server) di un certo livello e di tipo anche enterprise…
            tutti nomi i cui amministratori, nonostante la prudenza, hanno evidente ritenuto migliore l’offerta di canonical rispetto a quanto proposto dalla concorrenza.

            @maufor continui a ripetere questa cosa del fatto che ubuntu e canonical non vengano considerati di classe enterprise…una buona fetta delle aziende nel mondo informatico non sembrano pensarla alla stessa maniera….o hanno fatto un salto nel buio e quindi hanno amministratori imprudenti.

          • alex

            Forse non è un caso che la maggior parte delle aziende citate siano abbastanza recenti e “moderne”, per la maggior parte realtà nate in rete. Magari l’esperienza di @maufor è più legata ad aziende più “vecchie e tradizionali”, più probabilmente legate ai “vecchi grossi nomi”…

          • Aury88

            assolutamente! ma io volevo sottolineare solo il fatto che un azienda moderna può avere, al pari di un azienda più vecchia/tradizionale, necessità di affidarsi a soluzioni enterprise….ergo il fatto che queste aziende moderne si siano affidate a canonical e non a RH smentisce secondo me quanto afferma maufor su canonical e la classe enterprise…anche considerando che non stiamo parlando di piccoli nomi dell’informatica, ma di nomi importanti, con un certo peso e necessità non certo piccole o semplici da soddisfare da un qualunque centro di assistenza e che di certo non rischiano miliardi di dollari affidandosi alla prima azienda che passa e che gli offre il prodotto più economico.

          • alex

            Si, si. Riflettevo solo sul fatto che sono aziende che probabilmente conoscono anche la tecnologia che sta dietro alle diverse soluzioni, e possono direttamente valutarla e sceglierla sulla base di quello che offre invece di doversi basare solo sulla “fiducia” sull’azienda a cui affidarsi.

            Ma per curiosità, visto che in ambito cloud qui si parla quasi solo di soluzioni MS e Ubuntu, ma altre realtà come Google e Amazon come si piazzano nel settore? scusate se sposto il discorso 🙂

          • Maddo

            h t t p : / / thecloudmarket . com/stats#/by_platform_definition
            Dati(indicativi) che penso parlino da soli. Google e amazon comunque si limitano a dare la piattaforma in sé, mica applicativi, ci installi quello che vuoi tu.

          • Aury88

            interessantissimo. curioso come ubuntu venga classificato a parte rispetto a linux (o questo sarebbe necessariamente sopra ubuntu) xD
            sarei curioso comunque sull’origine di quei dati…sono conteggi ma conteggiano tutto o hanno un campione? non ho trovato info sul loro sito purtroppo :-/

          • Teo

            “(a meno di non voler credere che esista davvero la comunita’ costituita da gente che vive di aria e codice)”

            Ciao, mi spiegheresti per favore come sopravvivono quelle comunità che non hanno un lato enterprise e non offrono tale servizio, tipo.. Arch Linux , Chakra…

  • Dino Trevisani

    evviva l’ulteriore frammentazione nel mondo linux (snap vs flatpack è solo l’ultima dopo deb vs rpm, wayland vs mir, systemd vs mondo, gnome vs mondo) e la ridondanza di libs (che bello avere copie identiche di librerie per ogni snap installato)

  • Simone Picciau

    Molto bene!

  • wooow fantasticoo è un’ottima notizia, una rivoluzione nel mondo linux, finalmente si va verso un’unificazione, se prima si trovavano solo deb e rpm che quindi funzionavano solo su debian based e fedora, finalmente ora scaricando uno snap lo si potrà usare facilmente e in maniera immediata in molte distribuzioni.
    è un’ottima notizia davvero.
    inoltre un supporto così favorirà enormemente l’arrivo di pacchetti snap e lo sviluppo stesso di snap.
    ottimo davvero.

  • Ero molto restio sull’utilizzo di snap. Ma devo dire che l’evoluzione e la logica un pò ala docker (ovvero poter connettere eventualmente altri snap) potrebbe essere la vera arma vincente. Staremo a vedere.

    • Samael

      L’importante però è che non diventi un pretesto per trasformare gli snap in nuovi deb con ragnatele di dipendenze, altrimenti abbiamo fatto un buco nell’acqua.
      Io sarei più per un modello in stile OSX: bundle che contengono normalmente le dipendenze del software, ma possibilità di condivisione quando necessario, tipo in suite fatte di svariati programmi che hanno bisogno di condividere porzioni di codice fra di essi.
      Su OSX per queste cose esistono i pacchetti .pkg.

      • Da quello che avevo capito doveva essere qualcosa del tipo in questo bundle c’è questa robba, tipo gimp, gtk 2.8 per esempio, se hai qualcosa per cui serve gtk 2.8 dovrebbe utilizzare l’eventuale configurazione (personalizzazione) fatta per il bundle precedente anche in questo o isolarla, non ho ben capito ma sono scelte implementative. Il maggior problema è la coesistenza di due metodi di pacchettizzazione in contemporanea secondo me.

        • Samael

          Sì, sulla coesistenza sto cominciando ad avere anch’io seri dubbi.
          Il problema è che IMHO e se si vuole far sì che questi modelli abbiano successo, allora devono essere adottati di forza, facendoli diventare gli unici strumenti per gestire applicazioni di terze parti e lasciare ai vecchi gestori di pacchetti il compito di aggiornare solo la base.

          In sostanza, bisognerebbe eliminare il concetto stesso di distribuzione, Black_Codec, perché all’atto pratico è diventato un sinonimo di pacchetti e repository personalizzati.
          Se snap o flatpak diventassero lo standard, allora le distribuzioni dovrebbero smetterla di pacchettizzare il mondo e limitarsi a mantenere kernel, userland e qualche altra tecnologia di base.
          Ma all’atto pratico si finirebbe per creare mere fotocopie che si differenziano solo per il package manager e per nient’altro.
          Questo è vero soprattutto se consideriamo systemd che ha standardizzato il 99% dello userland Linux e che mira in futuro a legare le sue versioni ad alcune specifiche del kernel, in modo da arrivare ad un modello simil-BSD, con lo userland (systemd) che viaggiando in parallelo con il kernel vive in uno stato di simbiosi ed esporta sempre e solo le tecnologie native presenti nella specifica versione di Linux.

          Quindi all’atto pratico l’avere pacman, apt, dnf o altro non avrebbe nessun senso, se poi kernel, userland e stack applicativo viene gestito alla stessa maniera.
          Se si vuole un rolling in stile Arch, basterebbe semplicemente creare un repository ad-hoc e tenerlo sempre up-to-date. Idem per Debian con un repository LTS.
          Cioè, creare distro non avrebbe più alcun senso pratico se non come esercizio fine a se stesso.

          • Aury88

            beh….già adesso moltissime distro sono diverse dalle distro madri semplicemente per il parco software preinstallato e, ogni tanto, il DE di default xD
            comunque questo a mio avviso è uno degli aspetti che più bloccheranno il diffondersi di un sistema di pacchettizzazione universale…anche se si dovesse avere a disposizione il sistema di pacchettizzazione perfetto (e mutipiattaforma) questo distruggerebbe uno delle principali distinzioni tra le distribuzioni madre…e a non tutti questa cosa potrebbe piacere…insomma temo che in molti casi a guidare la scelta non saranno motivazioni tecniche

            per quanto riguarda l’utilizzare snap e flatpack come binari ufficiali penso che così saranno viste solo dalle distro che non vorranno usare queste pacchetizzazioni…ai progetti conviene troppo creare e mantenere un solo pacchetto per tutte le distro…poi quello che vogliono fare le singole distro cavoli loro e dei loro utenti, no?

            semplicemente per me le distro che decideranno di usare il vecchio sistema delle pacchettizzazione dovranno continuare a dedicare risorse alla pacchettizzazione e all’armonizzazione delle dipendenze, le altre le potranno concentrare sullo sviluppo

          • Samael

            Hai ragione, Aury88, quando dici che il problema sarà visto solo da coloro che non vorranno usarlo.
            Il punto è quante sono le distribuzioni che si terranno il loro sistema di packaging? Penso che tu abbia già intuito la risposta… xD

            Fedora non ho ancora capito cosa voglia fare con Flatpak. Vogliono usarlo per tutte le applicazioni di terze parti? O continueranno ad usare dnf per tutto e flatpak come opzione per i pacchetti precompilati presi dai siti ufficiali? Perché nella seconda opzione allora ci ritroveremmo davanti ad una roba inutile.

            Per ora l’unica che ha pianificato seriamente l’adozione di questo tipo di packaging è Canonical.
            E credimi quando ti dico che comincio a temere un altro buco nell’acqua in termini di adozione generale.

            D’altronde, parliamoci chiaro: AppImage faceva più o meno tutto ciò che Snappy e Flatpak fanno. E lo fa da secoli. Con la differenza persino che AppImage crea binari, nemmeno bundle. Quindi zero manifest, problemi di deduplicazione delle dipendenze ecc.
            Ed è stato sviluppato da uno dei maintainer del progetto PureDarwin, quindi molto vicino all’ambiente Apple/OSX.
            L’unica cosa che non faceva era il sandboxing, ma quella era una roba tranquillamente implementabile.
            Ha ricevuto critiche positive persino da Linus Torvalds e Jordan Hubbard. Eppure quanti se lo sono calcolato?

          • Aury88

            penso che in questo caso snap, pur non avendo magari qualità tecniche particolari rispetto la concorrenza, abbia la “qualità” di essere utilizzata da ubuntu che h una diffusione che le altre non hanno….
            imho il successo di un sistema di pacchettizzazione non è dato da quante distro lo utilizzano, ma da quanti programmi lo utilizzano…e questi sono incentivati solamente principalmente dal bacino di utenza e dalla facilità di mettere sul market i propri programmi due punti anche questi in cui canonical ha delle ottime carte
            questo annuncio, seppur molto pubblicitario, ha un importanza strategica per canonical perchè dice “a differenza della concorrenza noi siamo ovunque, lo stiamo già utilizzando e lo stiamo supportando, quindi rilasciate tramite snap” e poi il carico da novanta con alcuni dei progetti più famosi tra la community (firefox, krita, mycroft) che dicono quanto sia stato facile fare il pacchetto snap e caricarlo sul market…è vero che flatpak è grosso modo identico è supportato da RH (che è molto più grossa di canonical ma non ha la quota desk) ma quanto è supportato? RH fino a prova contraria ci ha messo un solo sviluppatore (che ha fatto gran parte del lavoro ed è stato incredibile nel farlo) snapd ne ha 6 che hanno fatto gran parte del lavoro e altri 6 che hanno fatto gran parte del rimanente…il primo ha 3 pull request, l’altro 28…uno sviluppo che da un idea ben diversa del livello di supporto ricevuto e quindi della possibilità di sopravvivenza…ed è di default su ubuntu (che vuol dire 80% del cloud, e sulla quota importante di desk e server linux)…tutto questo ha un peso notevole per chi deve decidere chi supportare e quindi come pacchettizzare…non so se si capisce cosa intendo…

            non penso sarà un buco nell’acqua..canonical guadagna dal cloud dove snappy è fondamentale…potrebbe non venir adottato da alcuno (in realtà debian ho letto è integrato già a livello di repository e forse addirittura presente di default nella versione testing) ma il formato imho continuerà a venir supportato perchè canonical già ci guadagna sopra

          • Samael

            Beh, aspetta…
            Alexander Larsson era l’ingegnere che ha sviluppato Flatpak, è vero. Ma il progetto è stato portato avanti col sostegno di tutta la comunità GNOME e lo si sta persino usando per KDE.

            Anche nel caso di Flatpak c’è stata un adozione da parte dei big, Krita ha annunciato il supporto, Chromium pure, LibreOffice ha già una beta. Non è che non se lo stia cagando nessuno…

            Il punto però è: quanto verrà adottato come strumento di pacchettizzazione predefinito. Io penso che verrà usato solo come strumento per distribuire applicazioni cross-distro, ma niente di più.

            Per quanto riguarda Snappy: è chiaro che Ubuntu lo userà. L’ho scritto pure io sopra.
            Ma il punto è che Snappy rischierà di avere la stessa influenza dei deb. Esistono e sono solo per Debian/Ubuntu, così Snappy esiste e sarà solo per Canonical.

            Alla fine il sistema di bundle rischia di non fornire quello che dovrebbe essere il vantaggio numero 1: distribuire binari per tutti e semplificare la pacchettizzazione nei sistemi Linux.
            In sostanza, ancora una volta ci ritroveremo con la solita frammentazione nella distribuzione delle applicazioni e nessuna soluzione mainstream.

          • El Ninho

            Secondo me, gli unici ad avere un reale vantaggio di snappy e flatpak, saranno gli sviluppatori di giochi e le app per il mobile. Per il resto tutto rimarra come sempre è stato.

          • Aury88

            il vantaggio ce lo avrebbero tutti se tutte le distro si decidessero ad usare un solo sistema di pacchettizzazione (qualunque esso sia)…se la situazione rimane frammentata adesso almeno tutti i programmi (non solo giochi o per mobile) hanno la possibilità di scegliere tra un sistema di pacchettizzazione che funziona sul 30% dei desk e potenzialmente anche e sul rimanente 70% senza apportare alcuna modifica distro-specifica, oppure continuare a fare come si è sempre fatto.

            adesso semplicemente i programmi possono decidere di fregarsene della frammentazione di linux e rilasciare con un solo formato perchè esso è virtualmente funzionante su tutte le distro…che siano le comunità delle varie distro che non vogliono adottare la nuova pacchettizzazione a farsi il port dai sorgenti

          • Aury88

            avrà pure avuto il sostegno della comunità ma all’atto pratico è stato l’unico a sviluppare il software… è un progetto che si basa sul lavoro di una sola persona e se quella persona per qualsiasi motivo dovesse non poter fare più commit il rischio è che si blocchi tutto per un bel po’.
            non dico che flatpak non se la stia cagando nessuno, dico che snapp in quanto utilizzato di default sulla distro con maggior diffusione è quella che potrebbe dare maggior fiducia sull’affidabilità futura di tale pacchettizzazione sia in ambito enterprise sia negli altri…l’annuncio di canonical potrebbe dare una scossa all’adozione di flatpack (ma più per motivi politici imho che pratici) ma allo stato attuale Snappy da più garanzie

            snappy è “solo” per canonical di default (30% utenti desk di linux) ma è anche disponibile per tutti gli altri….questo potrebbe essere già sufficiente per convincere a pacchettizzare così…

            Flatpak è per ora di default su RH e forse su fedora (che percentuale di utenti hanno?) ed è disponibile per tutti gli altri (in realtà ho visto oltre a fedora solo ubuntu, ma devo guardare meglio)…è imho molto meno allettante come situazione.
            che influenza ha deb? a mio avviso notevole, nonostante quello che viene detto dei suoi difetti, e proprio grazie ad ubuntu

            non ho ancora ben chiaro il problema del bundle….cioè fino a prova contraria un pacchetto snapp con tutte le dipendenze integrate può essere usato così com’è su tutte le distro in cui è installata snapd…c’è il problema “solo” se si vogliono condividere runtime e dipendenze, ma nessuno obbliga a farlo ed è una cosa che al massimo deve risolvere e gestire snapd, non il creatore del pacchetto snap.
            la creazione di snap di per se semplifica enormemente il sistema di pacchettizzazione… almeno questo è quello che ho capito dai vari commenti dei vari progetti e programmatori e vedendo io stesso la guida dove di fatto il tutto consiste nel dichiarare in snapcraft quale git usare e che dipendenze integrare.
            il problema del non diminuire la difficoltà di pacchettizzazione è semmai qualora un programma decida di pacchettizzare anche alla vecchia maniera per specifiche distro…ma perchè farlo se puoi coprire già con lo snap di sicuro il 30% degli utenti e probabilmente anche il rimanente 70%?
            non credo (spero) saranno in molti a fare la scelta di pacchettizzare anche in altre maniere…imho questo sarà un lavoro di cui si dovranno far carico quelle comunità dietro le varie distro che non vorranno usare snapd (pur avendolo disponibile o portabile)

          • Samael

            Aury88 non è così. Alexander Larsson ha lavorato principalmente al progetto, ma ci sono 25 contributor, tra cui gente di GNOME come Emanuele Bassi.
            Senza contare che essendo flatpak un progetto Red Hat ma sviluppato in comunità il rischio che si blocchi è pari a 0. Sotto questo punto di vista Snappy offre molte meno garanzie dato che è sviluppato interamente da Canonical.

            Per quanto riguarda l’essere disponibile, flatpak non ha bisogno di porting su altre distribuzioni. Ti basta compilarlo. Debian per dire lo ha già e quindi di riflesso anche Ubuntu lo avrà.
            Il che significa che già oggi è virtualmente disponibile ovunque.
            Questo perché flatpak non ha alcuna dipendenza con tecnologie specifiche, come invece ha Snappy che fa sandboxing con AppArmor.
            Senza di esso non c’è sicurezza. Quanti pensi l’adotteranno? Già con questo ti sei giocato il bacino delle distro indipendenti e di quelle vicine a Red Hat, visto che le prime NON usano nessuna tecnologia MAC perché è troppo complessa da mantenere e le seconde usano SELinux.
            Flatpak invece fa sandboxing principalmente con namespace e cgroup, quindi tutte le distro possono adottarlo senza modifiche.
            In aggiunta a quello, se le distro usano SELinux, possono avere uno strato di sicurezza in più. Ma all’atto pratico, il sandboxing è del tutto indipendente.

            Per il resto hai frainteso la questione, il problema di cui sto parlando non è tecnico ma politico.
            Flatpak sta venendo integrato in GNOME Software 3.22, il che significa che chiunque userà GNOME potrà avere accesso a flatpak.
            Se a questo ci aggiungi che persino KDE sta lavorando ai runtime, allora converrai con me che la situazione non è tanto unilaterale come la stai descrivendo.

            Ma anzi rischia di creare una situazione in cui flatpak diventerà l’implementazione de-facto per quanto riguarda la distribuzione di binari cross-distro e Snappy diventerà il metodo di packaging per Ubuntu.

            E no, deb non ha influenza notevole. Ha influenza solo nelle distribuzioni Debian-based per ovvi motivi, ma per il resto non esiste. Così come tutti gli altri sistemi di packaging attuali.

          • Aury88

            25 contributori…solo 3 dei quali oltre al principale con più di un centinaio di modifiche (bassi è uno di loro…282 righe aggiunte in 6 commit)…abbiamo idee molto diverse sulla definizione di supporto.
            è sviluppato di fatto da una sola persona stipendiata da RH…l’altro è sviluppato da una sola azienda (in realtà assieme ad altre come samsung) che ci ha messo diversi sviluppatori e che ha il core business basato su questo…per un azienda il primo è visto come un qualcosa affrontato da un azienda come un progetto a perdere e senza garanzia nella continuità (e se dovesse morire lo sviluppatore che ha fatto il 90% dei commit e scritto il 99% delle righe? e se l’azienda che ha stipendiato quello sviluppatore decidesse di dedicarlo ad altro?) l’altro come un progetto affidabile nella misura in cui è affidabile l’azienda che lo porta avanti (e se l’azienda decide di abbandonare il software su cui basa il suo core business?).

            per le altre distro si sta pensando di utilizzare altre strategie di confinamento (l’utilizzo di selinux), ma questa è stata una risposta di mark shuttleworth quindi non so quanto affidabile.

            non ne so molto, ma il fatto che gnome ce lo abbia tra i programmi significa che ce lo avranno di default le distro che usano gnome?

            nessun sistema di packaging (se non appunto universali)hanno influenza “per il resto”… non riesco a capire cosa intenti….ma a che i risulta l’ecosistema debian è quello con più utenti….non basta questo per poter definire deb influente?

          • Samael

            Sì, abbiamo idee molto diverse perché uno è un progetto di fatto proprietario in mano ad una sola azienda, Canonical, mentre l’altro è sviluppato in comunità.
            Il che vuol dire che Snappy è di fatto legato alle sorti di Canonical, così come OpenSolaris era legato alle sorti della SUN.
            E ho già visto che fine fanno di solito questi progetti, quando l’azienda viene acquisita da qualcuno più grosso. Solitamente o vengono ammazzati o resi closed source. E NO, non c’è possibilità di fork una volta che questi progetti muoiono, perché quando il progetto è sempre e solo in mano ad una azienda vuol dire che l’interesse gravita solo attorno a lei.
            Per questo OpenIndiana è un morto che cammina che in sei anni non è andato avanti.

            Flatpak è un progetto nato INTERAMENTE nella comunità. E non in una qualsiasi, ma in una delle più grosse comunità open source, GNOME. E ha il supporto persino in KDE.
            Che poi Alexander sia quello con più commit non vuol dire nulla. Lui è il project leader ed è lui che coordina il lavoro. Anche perché è stato lui a lavorarci per primo, già ai tempi in cui si chiamava Glick.

            Di fatto, però, sebbene Shuttleworth cerchi di far credere il contrario, è Snappy ad essere un progetto sviluppato da una singola entità, e continua ad essere gestito come un progetto orientato ad un singolo ambiente: UBUNTU.

            E la differenza tecnica te l’ho già spiegata: il primo si lega a tecnologie native del suo sistema, mentre l’altro si lega al kernel e supporta esternamente altre tecnologie.

            Sul fatto di GNOME, all’atto pratico dipende da come il team gestirà la cosa.
            Se Flatpak diventerà dipendenza di GNOME Software, sì. Tutte le distribuzioni ce l’avranno.
            E considerando come Red Hat tende a fare le cose (vedasi systemd) è molto probabile che la strada che intraprenderanno sia questa.

            Riguardo il sistema di packaging, esatto. Nessuno oggi ha influenza.
            E Snappy rischia di fare la stessa fine: un pacchetto che se verrà rilasciato lo si farà solo per Ubuntu, mentre in upstream si seguirà Flatpak.

            La differenza tra Canonical e Red Hat sta proprio in questo: la prima sviluppa il suo stack in maniera indipendente e aspetta che siano gli altri a scegliere se adottarlo o meno.
            Red Hat invece delocalizza i progetti facendoli diventare comunitari e poi usa la sua influenza per imporli in upstream collegandoli con altri progetti sempre da lei sponsorizzati.
            Per questo Upstart è morto mentre systemd ha avuto successo.

          • Aury88

            onestamente samael, senza fare polemica e senza offesa, ma non capisco
            perchè proprietario? è tutto sotto GPL e non è neanche così legato all’ambiente ubuntu (a differenza di mir o unity che sono difficili da portare)….
            perchè comunità? i commit sono al 99% realizzati da un solo sviluppatore di una azienda…no, qua non stiamo parlando di “più commit” qui stiamo parlando di interezza del progetto di fatto realizzato per il 99% da un solo individuo …però se lo fa redhat è comunitario, se lo fa canonical diventa un progetto in mano all’azienda? (nota: io sto prendendo i dati da github, quindi forse li sto fraintendendo)
            a me sembra che al massimo se c’è una differenza non tecnica tra le due questa sia unicamente nell”avversione delle varie comunità verso una delle due aziende…ma il modello di sviluppo tra i due sistemi è stato nella sostanza identico (con l’unica grande differenza nel numero di persone impiegate e di come è nato).

            può anche essere nata indipendente ma in questo caso lo sviluppo rimane realizzato da una sola persona pagata da una sola azienda che su questo sistema non ha basato ancora alcun corebusiness…lo ha solo integrato.
            dov’è la comunità che avrebbe contribuito a flatpak? nel 283 linee aggiunte da uno 355 da un altro e 557 da un altro ancora quando quello principale della redhat ne ha scritte 145’829? quindi scusami, ma come fai a dire indipendente quando il programmatore di un azienda ha realizzato la stragrande maggioranza del lavoro? solo perchè all’inizio non lavorava per RH?

            dall’altro lato vedo 30 sviluppatori, e non mi sembrano tutti dipendenti canonical e molti di loro hanno centinaia di commit e migliaia di linee di codice sviluppate…perchè questa invece a differenza dell’altra non si può considerare una comunità? perchè se anche i porting sulle varie distro sono fatti da sviluppatori di quelle distro (a meno che io non abbia frainteso, cosa probabilissima, chi siano Tim Jester-Pfadt o Richard Yao… ) questa non sarebbe una comunità?

            ora, fai l’ipotesi che io non stia dicendo cose campate in aria…perchè se RH dovesse chiudere il progetto questo passerebbe in mano alla comunità (che fino ad ora ha contribuito per al più al 1/145 del progetto) mentre nell’altro caso dovrebbe morire se Canonical decidesse di abbandonarlo? a me sembra che lo sviluppo di snapd sia stato più “delocalizzato” di quanto non lo sia stato flatpak

            “La differenza tra Canonical e Red Hat sta proprio in questo: la prima
            sviluppa il suo stack in maniera indipendente e aspetta che siano gli
            altri a scegliere se adottarlo o meno.
            Red Hat invece delocalizza i
            progetti facendoli diventare comunitari e poi usa la sua influenza per
            imporli in upstream collegandoli con altri progetti sempre da lei
            sponsorizzati.” questa cosa è molto interessante perchè fino ad ora ho sentito lamentarsi molti del contrario…arrivando anche a sostenere che canonical prendesse ma non desse nulla alla comunità e allo stesso tempo impongonesse le proprie decisioni sugli altri…

            per quanto riguarda l’usare tecnologie native ho riportato la risposta di M.S….quindi forse non è una cosa che sia costretta a rimanere necessariamente così per sempre (comunque mi hai fatto venire un dubbio…se basta sfruttare il kernel per la gestione dei privilegi, perchè si usano cose come selinux e apparmor?)

          • Samael

            onestamente samael, senza fare polemica e senza offesa, ma non capisco
            perchè
            proprietario? è tutto sotto GPL e non è neanche così legato
            all’ambiente ubuntu (a differenza di mir o unity che sono difficili da
            portare)….

            Se ragioniamo con il termine proprietario redatto dalla FSF allora no, è tutto software libero.
            Tuttavia la definizione della FSF è piuttosto blanda, perché un software o un formato può essere proprietario pur essendo open source. Proprietario non dovrebbe essere il contrario di open source, ma di comunitario.
            Ti faccio un esempio: tu puoi tranquillamente creare un tuo software che fa uso di un formato file che hai creato tu. Quel formato, pur essendo il software libero, è proprietario, perché è una cosa che detieni tu.
            Idem per il formato dei log di journald. Anche quello è proprietario.
            Nel caso di Canonical il progetto è proprietario perché il codice è tutto concentrato nelle sue mani anche a livello di copyright.
            In flatpak non è così, c’è il copyright di Alexander, quello di Red Hat, quello di Lennart e quello Colin Walters, Codethink…
            Questo vuol dire che all’atto pratico Canonical è l’unica a detenere effettivamente la proprietà del progetto. Ed è la stessa situazione di OpenSolaris con la SUN.
            Sul fatto che il 99% del lavoro sia stato fatto da Alexander, ripeto: vuol dire poco e niente perché Alex ci stava lavorando fin dall’inizio. Flatpak è nato come un suo progetto indipendente che poi ha fatto entrare in GNOME.

            può anche essere nata indipendente ma in questo caso lo sviluppo rimane
            realizzato da una sola persona pagata da una sola azienda che su questo
            sistema non ha basato ancora alcun corebusiness..

            No. Flatpak è guidato sì da un ingegnere Red Hat, ma il progetto non ha nulla a che vedere con Red Hat.
            Se Red Hat contribuisce lo fa con il suo copyright, ma il lavoro di Alexander è e rimane indipendente.
            Diverso è con Snappy dove qualunque cosa viene fatta sotto il copyright di Canonical.

            Per questo Flatpak è comunitario mentre Snappy non lo è.

            perchè se RH dovesse chiudere il progetto questo passerebbe in mano alla
            comunità (che fino ad ora ha contribuito per al più al 1/145 del
            progetto) mentre nell’altro caso dovrebbe morire se Canonical decidesse
            di abbandonarlo?

            Perché Flatpak NON è un progetto di Red Hat ma di Alexander Larsson, mentre Snappy è un progetto di Canonical.
            La differenza sta lì. Red Hat NON può tecnicamente chiudere il progetto e né impedire ad Alexander di lavorarci, perché non ha alcun diritto su quel software.
            Canonical sì. E ti ripeto: quando si hanno situazioni di questo tipo i rischi sono grandi.
            Per questo Canonical è stata criticata su MIR: perché ha imposto la cessione del copyright ai contributor rendendo di fatto il progetto proprietario.

            questa cosa è molto interessante perchè fino ad ora ho sentito
            lamentarsi molti del contrario…arrivando anche a sostenere che
            canonical prenda a non dia nulla alla comunità e allo stesso tempo
            imponga le proprie decisioni sugli altri…

            Canonical non ha mai imposto niente a nessuno e chi afferma il contrario dice il falso.
            Upstart l’aveva sviluppato lei e per lei sola. Poi gli altri lo hanno adottato.
            Anche Unity è così. Canonical ha sempre sviluppato il suo stack e poi l’ha rilasciato open source.

            comunque mi hai fatto venire un dubbio…se basta sfruttare il kernel
            per la gestione dei privilegi, perchè si usano cose come selinux e
            apparmor?

            Perché rendono più efficace il sandboxing in quanto apportano restrizioni ancora maggiori sulle risorse che le singole applicazioni possono andare ad usare, a patto però di ritrovarti con un intero framework MAC da mantenere.
            Ora la cosa può andare bene fino a che ti chiami Fedora o Ubuntu, dove esistono team appositi che si occupano dell’integrazione dei suddetti framework con la distro, tuttavia nelle distro indipendenti spesso questa manodopera non c’è, e di conseguenza si preferisce non usarli.

          • Aury88

            quindi il problema sarebbe sul copyright del formato snapp? dove è questo copyright ritirabile da canonical e che potrebbe rendere inutilizzabile tutto quanto fatto su snapd?

            Ps: mi scordo sempre di scriverlo; Grazi mille per le spiegazioni 😉

          • Samael

            Sì, quello è il problema.
            Come ti ho scritto sopra quando il progetto è accentrato nelle mani di una azienda, esso è soggetto alle logiche commerciali del singolo, e l’interesse generale è per lo più legato al semplice consumo.

            Mi spiego meglio: ti faccio l’esempio di OpenSolaris.
            La SUN all’epoca disse: tutti possono contribuire, ma il copyright è sempre e solo mio.
            Questo ridusse i contributi della comunità, perché all’atto pratico era la dimostrazione che la SUN non volesse una comunità di sviluppatori, bensì una comunità di utilizzatori.
            Questo ha fatto sì che quando Oracle acquisì la SUN, tutto il lavoro fatto su OpenSolaris venne chiuso, e difatti Solaris 11 è closed source.

            Certo, nacque il fork di illumos, che ne continua lo sviluppo del kernel. Ma illumos non è Solaris. Illumos è diventato un progetto indipendente gestito da Joyent e altri che hanno i loro personali obbiettivi.
            In comune con Solaris ha solo l’origine e alcune tecnologie. Ma per il resto ha obbiettivi differenti a seconda di chi lo sviluppa.

            L’unico tentativo di fork che intendeva continuare il lavoro era OpenIndiana, che difatti portava lo stesso nome del progetto che cercava di continuare, Indiana.
            Tuttavia, essendo che OpenSolaris era all’atto pratico un sistema proprietario gestito solo da SUN, non si è mai riusciti a mandarlo avanti, perché nessuno era in grado di continuare un prodotto nato per fini commerciali privati e con dei piani di sviluppo interni. Mancava di identità, di voglia e di capacità di evolvere.

          • Aury88

            scusa se riapro il discorso, ma mi sono un po’ informato in giro:
            la cla di canonical, che immagino sia all’origine del problema del copyright, se non ho capito male non è una cessione di copyright è una concessione all’uso che i programmatori danno a canonical. ma il codice rimane del programmatore che lo ha sviluppato.
            www. ubuntu. com/legal/contributors
            l’interruzione dello sviluppo da parte dell’azienda mi sembra sia equivalente all’interruzione dello sviluppo da parte dell’unico (di fatto ) sviluppatore…in entrambi i casi la comunità può accedere al codice e forkarlo senza alcuna violazione di copyright (essendo gpl, allmeno nella versione poco prima della chiusura) in entrambi i casi il contributore principale può cambiare il copyright sul proprio codice. la pacchettizzazione snap non mi sembra sia coperta da uno specifico brevetto/copyright e i programmi che lo realizzano sono opensource (sdk e snapcraft) ergo utilizzabili così come sono e forkabili (non hanno neanche il termine ubuntu dentro o trademark sul nome che potrebbe portare ad un trademark infringement, che è comunque facilmente risolvibile)…canonical può cambiare il copyright solo del codice da lei inserito (in realtà bisognerebbe vedere la politica aziendale, da quello che so il codice viene riconosciuta la paternità, non so se anche il copyright, ai singoli sviluppatori anche se dipendenti canonical) ma sarebbe una mossa imho assurda e che canonical nella sua storia mi sembra non abbia mai fatto neanche per tecnologie più specifiche del suo prodotto.

            l’unico problema che mi può venire in mente è al massimo sulla proprietà del database in cui sono fisicamente conservati gli snap, ma si sta lavorando affinchè si possano usare db esterni:
            http://snapcraft. io/ (guarda in “log in global snap store”).
            se anche il codice alla base di questo database è GPL non dovrebbero esserci problemi nel suo utilizzo fuori dal “controllo” canonical…
            insomma a me sembra che la vera differenza sia in realtà la percezione e il sospetto della comunità nei riguardi di canonical e dei programmi sviluppati da lei (ma anche a quelli a cui semplicemente contribuisce, non scordiamoci le reazioni quando ha deciso di sviluppare wayland) e che quindi porta alla non collaborazione di molti (ma in realtà hanno contribuito anche membri della comunità), ma dal punto di vista legale-informatico la situazione non mi sembra granchè differente….è anche vero che sono in realtà un vero ignorante del tema e tutte queste cose legali non le ho mai capite, quindi è probabilissimo che sbagli.

            C’è una risposta di M.S sui runtime condivisi dove dice che all’inizio snap funzionasse come flatpak ma si è scoperto che “non scalavano bene”…non ho ben capito cosa intendesse xD

          • gabriele tesio

            con lo ‘scalare bene’ penso abbia voluto intendere che non erano propriamente adatti all’uso che ne voleva fare canonical, ciò di usarli nell’iot, cloud, desktop, mobile e server.

          • Aury88

            quello l’avevo intuito però non capisco il perchè…mi fai dire che il ridurre la ridondanza dei runtime permetta performance migliori e di occupare spazi minori..e uindi siano più adatti a funzionare anche su sistemi dalla potenza/memoria limitata

          • Samael

            se non ho capito male non è una cessione di copyright è una concessione
            all’uso che i programmatori danno a canonical. ma il codice rimane del
            programmatore che lo ha sviluppato.

            No, Aury88, non è una semplice concessione. Non è così innocente.

            h t t p s : / / mjg59 . dreamwidth . org / 25376 . html

            Canonical’s CLA is pretty simple. In essence, it grants Canonical the
            right to use, modify and distribute your code, and it grants Canonical a
            patent license under any patents you own that may cover the code in
            question. But, most importantly, it grants Canonical the right to
            relicense your contribution under their choice of license. This means
            that, despite not being the sole copyright holder, Canonical are free to
            relicense your code under a proprietary license.

            Given
            Canonical’s market goals, this makes sense. They can relicense Mir (and
            any other GPLv3 projects they own) under licenses that keep their
            hardware partners happy, and they can ship in the phone market.
            Everyone’s a winner.

            Se a questo ci aggiungi che c’è solo il copyright di Canonical nel codice, beh. Non penso ci sia ancora bisogno di aggiungere altro.

            l’interruzione dello sviluppo da parte dell’azienda mi sembra sia
            equivalente all’interruzione dello sviluppo da parte dell’unico (di
            fatto ) sviluppatore…

            Sì, è la stessa cosa se continui ad intenderla in questa maniera, che è esattamente come Shuttleworth l’ha messa: Snappy e Flatpak sono due progetti proprietari, solo che quello di Canonical è sviluppato da più gente.
            Tutto bello, salvo il fatto che COSÌ NON È.
            Flatpak non ha un SOLO sviluppatore e non è di SUA proprietà, ma è un progetto in cui DI FATTO la community è stata coinvolta fin dall’inizio. Orbita attorno a GNOME e Freedesktop ed è indipendente da TUTTI.
            Snappy NO. Snappy è di proprietà di Canonical e su cui ha interessi SOLO LEI e NESSUN altro. Non ha nessuna affiliazione a progetti comunitari ma viene documentato sul sito di Canonical ed ospitato nella sua piattaforma (Launchpad/bzr).
            Non vi orbita una comunità di sviluppatori dietro, perché Canonical NON LA VUOLE.
            Ci sono solo gli sviluppatori Canonical a cui si aggiunge qualche contributor. E non è per una questione di numero di commit, ma di GESTIONE del progetto.
            Shuttleworth la butta sui commit perché deve CHIARAMENTE gettare fumo negli occhi e distogliere l’attenzione. QUELLO è il suo lavoro: fare propaganda e cercare di vendere preservativi ad un prete. Non lo dico con cattiveria.

            in entrambi i casi la comunità può accedere al
            codice e forkarlo senza alcuna violazione di copyright

            E ti ho già spiegato che le cose non sono così semplici, perché forkare un progetto in cui la comunità non ha mai contato niente fin dall’inizio e continuarlo porta alla stagnazione, perché manca di un’identità di fondo, volontà di contribuire e piani precisi. E ti ho fatto un esempio REALE di situazioni già successe.

            Non mi fare ripetere sempre le stesse cose, Aury88.

          • Aury88

            mi spiace…si vede che il legalese non lo capisco proprio xD
            a me sembra che la cla+gpl3 sia utilizzata per 2 motivi: 1) impedire che all’improvviso un programmatore cambi idea, e chiudendo il proprio prodotto, impedisca a canonical di continuare a vendere/utilizzare il software che lo utilizza e 2) permettere l’integrazione del software in dispositivi/prodotti che i produttori vogliono tenere chiusi. non mi sembra sia così efficacie nel far diventare codice fino a ieri accessibile, modificabile e riutilizzabile da tutti closed source…i clienti di quel produttore non sanno cosa c’è sul loro dispositivo/programma ma il codice sorgente da cui derivano è online e non gli si può cambiare licenza, giusto?
            se io fino a ieri ho programmato in gpl3 e oggi decido di chiudere tutta la parte di codice che fino a ieri era in gpl3 disponibile a tutti, modificabile da tutti riutilizzabile da tutti, posso farlo?se è così mi sembra assurdo che una cosa del genere sia mai stata accettata.
            shuttleworth non ha mai detto che flatpak è proprietario…dove lo avresti letto? ha solo detto che è di fatto un progetto sviluppato e mantenuto da una persona sola.

            “Flatpak non ha un SOLO sviluppatore e non è di SUA proprietà, ma è un
            progetto in cui DI FATTO la community è stata coinvolta fin dall’inizio” ok, scrivo meglio: Flatpack è scritto al 99% da un solo sviluppatore quindi per lo 1% è DI FATTO del resto degli sviluppatori per il 99% DI FATTO no visto che sei stato tu a dire che il detentore del copyright è chi scrive il codice,o ho capito male?…quel programmatore può cambiare idea e modificare la licenza della sua sola parte di codice visto che è stato lui a scriverlo? cosa glielo impedisce?c’è un contratto o qualcosa del genere che dice che il proprietario di questo programma, nella sua interezza è la comunità?
            forse in realtà la differenza è nell’utilizzo di una gpl più restrittiva che impedisce in qualsiasi caso la chiusura dal codice anche al proprietario del codice?
            perchè per te se da un lato il 99% del codice è scritto da uno solo c’è “l’appoggio della comunità” mentre dall’altro con una proporzione molto più alta di contributo da non dipendenti di canonical diventa “qualche contributor”?
            per il tuo esempio mai sentito parlare di NAN? ha realizzato un software internamente all’azienda e closedsource (ma freeware)…situazione che, seguendo il tuo ragionamento, avrebbe ancora di più disincentivato lo sviluppo di una comunità…quel software è conosciuto come blender, è un editor 3d ed è opensource solo a seguito di una raccolta fondi.. oggi quell’editor è gestito da un attivissima comunità.
            il tuo esempio imho attesta solo che i progetti muoiono se la comunità che li prende non è attiva o sufficientemente interessata, grossa o capace di gestirli… questo è a prescindere imho da chi o cosa ha dato avvio a questi progetti. il mio dubbio è comunque anche sul tuo considerare la comunità attorno flatpak attiva…per carità ci sono molti interessati ad usarlo, ma (purtroppo) contributo in termini di codice pochissimo (1/145 del totale) e questo lo vedo da me su github, senza che me lo dica M.S.
            mi spiace farti ripetere questa cosa, credimi neanche a me piace farti perdere tempo…ma certe dinamiche nella community che a te sembrano ovvie io non riesco a capirle.

          • Samael

            impedire che all’improvviso un programmatore cambi idea, e chiudendo il
            proprio prodotto, impedisca a canonical di continuare a
            vendere/utilizzare il software che lo utilizza

            Fermati. Quando un prodotto è comunitario e si usano licenze restrittive come la CDDL e la GPL il copyright è vincolante. Vincolante nel senso che NESSUNO può cambiare licenza all’intero progetto fino a che TUTTI non diano il consenso.

            Ti ricordi quando dissi che il chiedere ad Oracle di cambiare la licenza di ZFS era una buffonata, perché Ubuntu usa OpenZFS che è sviluppato da diverse comunità? Ecco il motivo è proprio quello.
            Anche se Oracle volesse rilicenziare ZFS sotto GPL, all’atto pratico non sarebbe possibile, perché se non c’è il consenso di TUTTI i detentori del copyright non si può far nulla.

            Idem con la GPL. Su Linux non si può cambiare licenza se TUTTI non danno l’assenso.
            Allora qual è il problema di MIR e company? Che il copyright è tutto in mano a Canonical.
            Chi detiene il copyright può fare ciò che gli pare, anche cambiare licenza. Solo che può farlo quando detiene la COMPLETA proprietà.
            Ti faccio un esempio per capire meglio: mettiamo il caso che sia io che te siamo proprietari di un appartamento.
            Io lo voglio dipingere tutto di verde e tu di blu. Chi vince tra i due? Nessuno, perché se non c’è l’assenso di entrambi nessuno può dipingere.
            Se però io posseggo TUTTA la proprietà dell’appartamento chi mi può impedire di cambiare colore?

            Chiara adesso la differenza?

            quel programmatore può cambiare idea e modificare la licenza della sua
            sola parte di codice visto che è stato lui a scriverlo? cosa glielo
            impedisce?c’è un contratto o qualcosa del genere che dice che il
            proprietario di questo programma, nella sua interezza è la comunità?

            Lo sviluppatore che vuole cambiare licenza teoricamente può farlo solo nella sua parte di codice ma non in tutto il resto ed il cambio non è retroattivo, nel senso che ciò che fino ad ora è stato GPL, GPL rimane. Il punto è che cambiare la licenza di un SINGOLO file .c all’interno di un sorgente è stupido perché non serve a niente.
            Quel file così com’è è inusabile perché fa parte di un progetto più grosso. Senza contare che il cambiare licenza non impedirebbe comunque l’uso di una versione ancora licenziata sotto GPL.
            Quindi all’atto pratico è impossibile cambiare licenza.

            Nel caso di Canonical è diverso perché lei possiede TUTTO il progetto, quindi cambiare la licenza diventa possibile.
            Certo, anche lì non ha effetto retroattivo e difatti vi è la possibilità di un fork.
            Tuttavia stiamo parlando di un prodotto i cui interessi gravitano attorno ad una sola azienda, quindi il progetto non ha motivo di esistere FUORI dalla sua orbita.
            Che cosa intendo per interessi che gravitano attorno ad una sola azienda? Intendo dire che il prodotto è nato per soddisfare un bisogno POLITICO di una azienda, non un problema generale. Se fosse stato un problema generale, il progetto sarebbe stato condiviso immediatamente.
            Ma Canonical non condivide nulla. Canonical vuole che ALTRI adottino le SUE soluzioni alle SUE condizioni. Che è diverso da condividere.

            perchè per te se da un lato il 99% del codice è scritto da uno solo c’è
            “l’appoggio della comunità” mentre dall’altro con una proporzione molto
            più alta di contributo da non dipendenti di canonical diventa “qualche
            contributor”?

            Perché nel primo caso il progetto ORBITA all’interno di comunità indipendenti, mentre nel secondo caso il progetto è nelle mani di una sola azienda. Ti ho persino fatto notare che Snappy è documentato e ospitato in ambiente Canonical.
            Perché nel primo caso NON ESISTE alcuna autorità effettiva sul progetto ma solo un project leader, mentre nel secondo caso esiste SOLO Canonical con al massimo i contributi di terzi. E la cosa è dimostrabile dal fatto che Flatpak ha diversi copyright al suo interno (e te li ho elencati), mentre Snappy NO. Ha solo il copyright di Canonical.
            Te l’ho già detto: Canonical NON VUOLE una community di sviluppo. Vuole SOLO utilizzatori e contributor che le donano il codice.
            Community di sviluppo vuol dire che Canonical si mette allo stesso livello degli altri, non al di sopra.

            il tuo esempio imho attesta solo che i progetti muoiono se la comunità
            che li prende non è attiva o sufficientemente interessata, grossa o
            capace di gestirli…

            QUESTO è il problema.
            Te lo sto dicendo fin dall’inizio. Quando il prodotto è in mano ad una sola azienda che lo porta avanti per i SUOI interessi non ha futuro al di fuori della sua orbita, perché non c’è interesse a portare avanti un prodotto nato per un capriccio esclusivo di una persona.
            Blender è un esempio differente, perché è un prodotto di cui tutta la community avrebbe beneficiato in quanto un software CRITICO per molti casi.
            Snappy, come OpenSolaris, non è critico. Sono nati per capriccio di Canonical/SUN, gestiti solamente da lei e per lei, e SENZA alcuna possibilità di condivisione del progetto.
            Di conseguenza, dato che ESISTONO alternative comunitarie, ci si concentra lì. Al massimo si riprendono concetti innovativi, se esistono, e li si porta altrove. Ma il progetto così com’è muore.
            Questo è lo stesso discorso di MIR. Fuori da Canonical non ha senso. E difatti la comunità orbita attorno a Wayland.

          • Aury88

            beh……upstart è morto quando la comunità ha deciso di abbandonare upstart in favore di systemd…la decisione di canonical di “staccare la spina” è stata una conseguenza di questo…dubito che se le altre avessero continuato ad usare upstart e canonical fosse passata ad altro upstart sarebbe morto in quel momento…anzi…daltronde tutte le distro hanno la necessità di un init per avviarsi quindi potevano continuare ad usare upstart così com’era o forkare…e nulla nella cla glielo avrebbe impedito…allo stesso tempo compiz è viva solo perchè di fatto la sta usando ubuntu…non certo in virtù della comunità che pure ha avviato quel progetto.

            Il fatto che snap sia una necessità sentita solo da canonical è secondo me non necessariamente corretto. alcuni so per certo non hanno trovato in flatpak la risposta adeguata proprio per come gestisce il runtime (ma onestamente non vedo come potrebbe dare fastidio)…in molti preferirebbero AppImage ma che sembra non essere visto di buon occhio dai produttori di software a pagamento ed è comunque un progetto avviato da tanto e ancora non decollato…snapd da alcuni è visto come un buon compromesso alle scelte tecniche degli altri due. insomma a differenza di un Mir di un unity o di qualsiasi altra cosa creata da canonical il sistema di packaging, proprio come a suo tempo lo fu upstart, ha secondo me una base di comunità interessata ad un sistema di pacchetizzazione universale trasversale a più distro e comunità e può trovare in snap una possibile base anche se inizialmente nata per capriccio di canonical….e personalmente, considerando il tempo sprecato dalle varie comunità a pacchettizzare, lo ritengo un aspetto estremamente critico.

            l’unico grosso difetto che vedo è la proprietà del repository dove sono stivati i pacchetti e che rende oggettivamente problematica la situazione di dipendenza dall’infrastruttura di canonical. ma è in corso, almeno così dicono, lo studio di un modo per creare repository differenti ed autonomi da canonical…a quel punto il repository saranno autonomi, il client (chiamiamolo così) forkabile e con una sua utilità ovunque (per esempio portare applicativi cloud e smartphone che sarebbero se no specifici e quindi realizzati solo per ubuntu)…a quel punto non ci vedo falle che possano compromettere l’autonomia da canonical

            insomma canonical può chiudere tutto il codice ma mi sembra solo nei confronti dei propri utenti/clienti…e non può impedire che codice, anche se solo suo, già condiviso possa venir usato o modificato…a me non sembra un problema di per se se non solo morale e nei confronti solo degli utenti che accetterebbero un prodotto closedsource..il guadagno per la comunità in termini di codice c’è ed è assicurato per tutto ciò che è stato rilasciata con la GPL..snappy messo dentro canonical ha un solo copyright di canonical…quello che vedi su github è di canonical al 90% (??) il resto (10%??) è dei contributori…quel codice è gpl quindi al sicuro nella sua interezza anche se canonical dovesse decidere di chiudere tutto, no? a quel punto non è come se non avesse più un padrone?

            “Ma Canonical non condivide nulla” beh…è molto ingenerosa come frase…canonical mette online liberamente studiabile e copiabile (senza CLA) tutto il codice che produce (tranne quei benedetti repository 🙁 )se poi la comunità non vuole contribuire è una scelta della comunità…quello che non condivide è la guida del progetto ma per me è una cosa naturale e necessaria…come hai detto tu stesso canonical non necessariamente ha le stesse necessità della comunità (come la comunità non ha per forza le necessità di canonical, vedi i commit di canonical rifiutati su gnome o su wayland) sopratutto visto l’ambito enterprise in cui comunque guadagna…. e siccome ci mette risorse e denaro personalmente trovo giusto che possa decidere cosa e come si debba realizzare con quel denaro…non è mai stato un problema fare un fork per realizzare le cose a modo proprio non dovrebbe neanche esserlo avviare un progetto per lo stesso motivo.

            mah…ho una visione diversa dalla tua…forse per ingenuità o non reale e completa comprensione…onestamente vedo un buon progetto, la voglia anche di condividerlo (naturalmente è chiara la strategia di canonical per renderlo così uno std ) ecc ecc…comunque per me un arrichimento della comunità anche se quel software non dovesse usarlo nessuno.

          • Samael

            beh……upstart è morto quando la comunità ha deciso di abbandonare upstart in favore di systemd…

            No. Upstart è morto quando Canonical ha deciso di non volerlo più usare.
            Il fatto che lo usasse anche RHEL non conta nulla. Canonical ha sviluppato Upstart per sé, non per gli altri.

            Il fatto che snap sia una necessità sentita solo da canonical è secondo me non necessariamente corretto. alcuni so per certo non hanno trovato in flatpak la risposta adeguata proprio per come gestisce il runtime

            E invece, sì. Snappy è nato non per soddisfare esigenze di alcuni, ma è nato per un’esigenza POLITICA di Canonical: quella di mantenere il controllo su tutto lo stack e di non dipendere dalla concorrenza.

            insomma a differenza di un Mir di un unity o di qualsiasi altra cosa creata da canonical il sistema di packaging, proprio come a suo tempo lo fu upstart, ha secondo me una base di comunità interessata ad un sistema di pacchetizzazione universale trasversale a più distro e comunità e può trovare in snap una possibile base anche se inizialmente nata per capriccio di canonical….

            No, Aury88, non c’è una comunità, QUESTO è il problema.
            Snappy NON ha una comunità. Ha solo Canonical e gente che contribuisce al progetto DI CANONICAL.
            La situazione è la stessa di Visual Studio Code: esiste una comunità di utilizzatori e gente che contribuisce, ma il progetto è e rimane di Microsoft.

            l’unico grosso difetto che vedo è la proprietà del repository dove sono stivati i pacchetti e che rende oggettivamente problematica la situazione di dipendenza dall’infrastruttura di canonical.

            Non è solo il repository, ma tutta la gestione del progetto ad essere un problema.

            a quel punto non ci vedo falle che possano compromettere l’autonomia da canonical

            Salvo il fatto che il progetto è comunque mantenuto da Canonical che decide il quanto ed il come. Beh sì, proprio il massimo dell’indipendenza.

            Se Canonical vuole che il suo progetti diventi comunitario, allora deve farsi da parte e delocalizzarlo.
            Sposti il progetto su Freedesktop o su qualunque piattaforma indipendente e smetta di imporre CLA che la rendono di fatto l’unico proprietario del codice.
            Lo faranno? Ti rispondo già io: NO.

            insomma canonical può chiudere tutto il codice ma mi sembra solo nei confronti dei propri utenti/clienti…e non può impedire che codice, anche se solo suo, già condiviso possa venir usato o modificato…

            Possa, possa possa. Tutto si può, IN TEORIA. All’atto pratico le cose non stanno così. E te l’ho già spiegato. Più volte.

            a me non sembra un problema di per se se non solo morale e nei confronti solo degli utenti che accetterebbero un prodotto closedsource..

            Neanche per gli utenti di OpenSolaris all’epoca c’erano problemi. Oggi la pensano un pelino diversamente.

            snappy messo dentro canonical ha un solo copyright di canonical…quello che vedi su github è di canonical al 90% (??) il resto (10%??) è dei contributori…

            Non mi risulta.
            A me risulta che se do un findstr /s Copyright * (o anche grep su UNIX) sul repository git clonato di snapcraft il risultato sia solo “Canonical”, con un Evan Cordell su una API rilasciata in forma permissiva. Non mi pare di vedere altro.
            E data la CLA il valore reale del copyright di Collins è di fatto inesistente.

            quel codice è gpl quindi al sicuro nella sua interezza anche se canonical dovesse decidere di chiudere tutto, no? a quel punto non è come se non avesse più un padrone?

            Eh no.
            Il codice vecchio rimane GPL ed è vero, ma sempre di Canonical è. Mica puoi cambiare il copyright. Altro che senza padrone…

            beh…è molto ingenerosa come frase…canonical mette online liberamente studiabile e copiabile (senza CLA) tutto il codice che produce (tranne quei benedetti repository 🙁 )se poi la comunità non vuole contribuire è una scelta della comunità…quello che non condivide è la guida del progetto ma per me è una cosa naturale e necessaria…

            Che è DIVERSO da condividere. E che è quello che ti sto dicendo io.
            Canonical NON VUOLE la comunità, vuole solo utenti e contributor che le diano codice. Per questo la comunità non vuole avere a che fare con lei.
            Perché all’atto pratico si rivelano essere prodotti in cui l’unico REALE interesse è quello di Canonical.

            Mi sta benissimo, sia chiaro. Ma smettiamola di confondere le cose e smettiamola di dire che Canonical condivida, perché non è così.
            Canonical non condivide. Canonical lavora per fatti suoi e basta. L’unica cosa è che non le frega niente se altri prendano il suo codice, perché la licenza lo permette. Ma questo è diverso dal “CONDIVIDERE”.

          • Le differenze nelle metodologie e filosofie di pacchettizzazione andrebbero a farsi benedire quindi.

      • Aury88

        avevo letto che snappy è ancora in evoluzione…o meglio snapd che è quello che gestisce gli snappy…ancora la situazione non è effettivamente granchè chiara e penso che sia dovuto al fatto che si vuole lasciare piena autonomia agli sviluppatori di fare quello che si vuole…il mio sospetto è che snapd però diventerà più influente nella gestione degli snappy e da mero installatore di snappy diventerà ad un certo punto un gestore anche a livello delle dipendenze… per cui se due snapp usano una dipendenza condivisa (e la verifica spero verrà fatta a livello di checksum) solo uno dei due pacchetti manterrà al suo interno la dipendenza che diventa automaticamente condivisa con l’altro (ho letto di softlink ma non ho ben capito…conoscevo solamente gli hardlink)…naturalmente se dei due pacchetti uno aggiorna ad una nuova versione della dipendenza, ognuno ritornerebbe ad avere la propria dipendenza e il link verrebbe eliminato…
        ad un certo punto snapp dovrebbe anche essere in grado di ottenere la lista delle dipendenze, ottenere la lista degli snapp che usano una dipendenza e agire sul gruppo di pacchetti che hanno una particolare dipendenza (per esempio disistallazione o downgrade fino a far scomparire una certa versione della dipendenza valutata pericolosa)…da notare che tutto questo è a livello “centralizzato” e gli snapp non dovrebbero subire alcuna modifica.
        staremo a vedere che ci riserva il futuro 🙂

        • Samael

          Softlink? Sicuro, Aury88? Cioè, io ero convinto che un’ipotetica condivisione sarebbe stata fatta tramite hardlinking, che almeno permette di preservare il file qualora l’origine venisse eliminata. Se è softlink come la gestiscono la cosa? :/

          Aury88, mi pare di capire che tu non conosca bene i softlink, quindi immagino che la differenza non ti sia ben chiara. Lascia che te la spieghi.
          Il primo, detto anche symlink o link simbolico, è un tipo di collegamento nella quale il link generato è solo un mero riferimento al file di origine. Non ha alcun valore o dato in sé, ma ha il solo scopo di creare un file con un determinato nome.
          Viene spesso adoperato come hack per mantenere la retro-compatibilità con software che richiedono determinati file o directory che sono stati spostati in altri posti o con altri nomi.
          Questo però vuol dire che il softlink è sempre e comunque dipendente dal file che l’ha generato.

          Il metodo hardlink invece prevede che il link generato diventi esso stesso il file di origine, qualora quest’ultimo dovesse essere eliminato.
          Questo metodo è lo stesso adoperato da BTRFS quando fa uno snapshot, che difatti ha dimensione teorica di 0 qualora non ci siano differenze tra lo snapshot ed il subvolume di origine, ma che poi diventano N kilo/megabyte, qualora comincino a comparire differenze tra i singoli file.

          Normalmente in un sistema come snappy sarebbe quest’ultimo il modello da adottare, in modo da deduplicare le dipendenze qualora esse fossero le stesse, ma al contempo mantenerle comunque “in vita” qualora le principali scomparissero.

          Per quanto riguarda gli hash, non se la cosa potrebbe essere gestita in questo modo.
          Mi spiego: l’hash ha senso quando sai che essendo il runtime lo stesso sia sulla macchina in sviluppo che in quella target, allora non ci possono essere differenze.
          Ma qui gli snap possono essere generati un po’ ovunque, non solo su Ubuntu, giusto? Quindi come si fa a stabilire tramite hash che la dipendenza è la stessa?
          Una dipendenza compilata su Fedora potrebbe non avere lo stesso hash di una compilata su Ubuntu.

          La “soluzione”, o meglio il workaround, che mi verrebbe in mente in questa situazione sarebbe quello di specificare all’interno del manifest dello snap la versione delle singole librerie, in modo che quando il gestore dei pacchetti va a parsare il manifest faccia confronti con gli altri pacchetti, veda chi ha già la dipendenza installata e faccia link.
          Naturalmente è un workaround per niente robusto, e bisogna persino vedere quanto è scalabile in prospettiva di un ambiente con un elevato numero di applicazioni. Ma attualmente non vedo soluzioni migliori.

          • Aury88

            hai frainteso…io ho solo riportato quello che avevo letto…mi ricordo la cosa del softlink, uscita nella discussione che era seguita la spiegazione sull’evoluzione di snapd, perchè mi aveva incuriosito avendo fino ad allosa sentito io solamente dell’hardlink (che utilizzo con software tipo FSlint quando cancello un file doppione), argomento che poi però non avevo approfondito (a proposito grazie per la spiegazione)…concordo comunque che l’hardlink sembri il metodo migliore, ma non essendo programmatore e non avendo grandi nozioni di informatica mi limito anche qui ad una valutazione solo sulla logicità del discorso.
            (io l’hardlink l’avevo inteso come un link alla “cella di memoria”…per cui se si cancella un file, che normalmente significa non l’eliminazione “fisica” dei bit di quel file ma l’apposizione di un “tag” per dire”spazio occupabile” in realtà l’hardlink continuando a puntare alla cella di memoria, che ancora contiene il file, permette di leggerlo…ma l’ho letto di questo solo distrattamente un 5 annetti fa e quindi probabilmente sto dicendo cassate xD)

            per quanto riguarda la compilazione non capisco di preciso cosa intendi…il software dovrebbe essere compilato solo per funzionare sulla tipologia di piattaforma (arm, x86) ma il file snappy che scarichi per fedora (x86) è di per se identico a quello che scarichi per ubuntu (x86)…almeno così ho capito ed era il motivo per cui si parla di pacchetto universale…il runtime utilizzato (e la sua versione) dovrebbe essere elencato tra le dipendenze, no?

            l’unico programma che è stato modificato per funzionare sulle varie piattaforme è snapd …ma i pacchetti che va a scaricare sono identici a quelli che scarica la controparte su altre distro…così almeno dalle dichiarazioni

            io il discorso gestione dipendenze l’avevo inteso proprio come il workaround da te proposto e pensavo si parlasse di quello quando lessi dell’argomento: gli snappy che dichiarano cosa usano e snapd che tiene la lista e si occupa di creare la condivisione nel caso di dipendenza alla stessa versione già utilizzata da un altro snappy.

          • Samael

            ok, chiedo venia. Dal post avevo capito che non avessi ben chiara la differenza.

            Per quanto riguarda la questione hash e compilazione, il problema sta nel deduplicare le dipendenze contenute nel singolo snap.
            Mi spiego: tu hai uno snap A che contiene libpippo alla versione 2.8.
            Poi installi uno snap B che contiene anch’esso libpippo 2.8.
            Come fai ad essere sicuro che libpippo 2.8 in A sia identica a libpippo 2.8 in B a livello di hash? I binari generati non è detto che abbiano sempre lo stesso hash, perché potrebbero essere stati compilati su due distro diverse con parametri differenti. E questo ne causa una differenza in termini di checksum.
            Quindi come fa snapd a stabilire che lo snap B deve sostituire libpippo 2.8 con un hardlink alla libreria inclusa nello snap A?

            Adesso è chiaro qual è il problema della fragilità del basarsi sugli hash?

          • Aury88

            no, sul fatto che non avessi chiara la differenza ci hai preso in pieno…anche perchè mi sembrava di essere stato abbastanza chiaro che avessi questa mancanza xD
            hai frainteso nel senso che dalla tua risposta sembrava io stessi proponendo l’uso dei softlink quando in realtà io stavo solo riportando la discussione letta.
            sul hash penso di aver capito cosa intendi…onestamente non saprei…forse l’unica per snapd è fidarsi di quanto dichiarato dallo snapp…

          • Samael

            No no, tranquillo. Avevo capito che non lo stessi proponendo tu. xD
            Infatti quando ti ho detto “sei sicuro?” intendevo se avessi letto bene, perché onestamente l’idea del symlink la considero un design troppo fragile, in quanto ti porta a dover mettere dei controlli in fase di rimozione di uno snap, affinché il demone si occupi di eliminare i symlink e sostituirli con una copia della libreria prima della rimozione, mentre con un hardlink non avresti bisogno di nulla di tutto questo.

            Per la questione fiducia, esatto. Per quello l’ho definito un workaround poco robusto.
            Proprio perché devi assumere che il manifest dica sempre e solo il vero.

          • Aury88

            comunque gli snapp da quello che ho capito vengono realizzati tramite snapcraft….non si può fare in modo che snapcraft compili sempre nella stessa maniera a prescindere dal sistema su cui gira?

          • Samael

            No, perché è un problema binario.
            Anche se usassi snapcraft, rimane il fatto che un binario compilato su fedora potrebbe produrre un hash diverso da uno compilato su ubuntu.

  • Ilgard

    In realtà non ci sono proprio contro all’uso di snap.

  • holmannus

    La posizione di Adam Williamson:
    https : / / tinyurl . com / zh42eln

No more articles