Snapcraft si aggiorna a una nuova versione e aggiunge un plugin per creare “snap” persino del kernel.

snapcraft-2.25-1

Snapcraft è un programma sviluppato da Canonical appositamente per Snappy Ubuntu Core, la versione di Ubuntu per server e cloud, di cui è parte integrante. Si tratta di un packaging tool che produce pacchetti di tipo .snap (chiamati appunto snap) compatibili con lo Snappy Store.

Uno snap contiene anche tutte le sue dipendenze e per certi versi è superiore ai classici .deb e .rpm. I vantaggi sono principalmente la certezza che non ci saranno incompatibilità create da versioni di pacchetti e dipendenze discordanti oltre alla possibilità di ottenere una versione precedente di uno snap senza preoccuparsi di dover regredire anche le sue dipendenze. Gli snap vengono poi resi disponibili su un apposito repository a cui accede lo Snappy Store.

Snapcraft permette di creare questi pacchetti direttamente da codice sorgente, con l’aiuto di un file di configurazione apposito che dice al programma cosa deve fare parte dello snap. L’intero procedimento è descritto qui.

La vera novità di questa versione consiste nella possibilità di creare snap del kernel. Questa funzione è ancora sperimentale ma permette di pacchettizzare l’intero kernel con configurazioni e patch di propria scelta; chiunque abbia compilato un kernel si renderà conto di quanto possa essere comodo.

L’aggiornamento è disponibile da ieri mattina sui repository di Ubuntu 16.04 beta. Per installarlo da zero è sufficiente invocare apt-get:

sudo apt update && sudo apt install snapcraft

[Fonte]

  • Luky

    Io sono sempre stato dell’idea che un pacchetto .deb fatto bene derivi da chi lo crei, vengono fatti troppi controlli non a livello di dipendenza del pacchetto stesso ma della versione. Non è detto che con una versione diversa di una libreria il programma non possa funzionare.

    • Samael

      Questo è vero solo in teoria, ma non nella pratica.
      Un pacchetto può funzionare bene con una versione differente della libreria SOLO se questa non ha avuto cambi di API.
      Tuttavia, un tempo una situazione di questo genere si verificava solo nelle major release. Adesso invece il concetto stesso di versione non ha più senso, quindi il break è molto più frequente.
      Vedasi GTK+3, vedasi lua ecc.

      Senza contare che che a causa di libtool, abbiamo il problema del symlink alle versioni versioned, che eliminano ogni possibilità di condivisione, se non cambiando il path e di conseguenza indicando al loader dove andare a prendere la libreria.

      Ci sono svariati motivi per il quale il modello dei package manager Linux è broken by design e va modificato.
      Senza contare che ormai non ha più senso parlare di condivisione dello stack, dato che:
      1) lato server, chiunque faccia deploy in bare-metal e non usi container è un idiota. A prescindere. Esiste Docker, signori miei. Usatelo.
      2) lato desktop, è ridicolo pensare che io debba aggiornare la distro per avere un’applicazione alla versione più recente.
      In aggiunta a questo per anni si è pensato che un repository di terze parti avrebbe risolto il problema. Ma così non è, perché molto spesso le applicazioni richiedono obbligatoriamente una versione più recente di una dipendenza.
      E quando essa viene fornita nel repository di terze parti finisce per rompere la compatibilità con il resto del mondo, in quanto sostituisce una dipendenza ufficiale ed usata da altri software. Vedasi i PPA su Ubuntu.

      Onestamente, basta.
      Sono 16 anni che su OSX la gente usa applicazioni senza problemi perché forniscono bundle semi-statici.
      E se ci aggiungiamo che questo modello deriva da NeXTSTEP, allora possiamo dire che lo fanno da più di 20-25 anni.

      E NO. Prima che arrivino i soliti a sparare la fesseria del “nuovo non significa migliore”…
      So benissimo che nuovo != migliore, ma lasciate che sia IO a scegliere se è o meno migliore per ME. E non qualche persona terza che ha esigenze diverse dalle mie.

      In ogni caso, Snapcraft è una roba lato cloud/IoT, come Snappy.
      Sono soluzioni create per i sistemi server di nuova generazione che devono solo fare da hypervisor e host di container.

      • Matteo Iervasi

        Da quel che ho potuto capire leggendo un po’ su internet gli snappy saranno utlizzati anche nella versione desktop, quindi alla fine andrà a vantaggio di tutti (dato che assomigliano ai bundle OSX, un po’ più avanzati però). Anche loro si impacchettano le librerie all’interno, così come su OSX non si ha il “dependency hell” (a me piacciono un sacco Ubuntu e le distro Debian-based, ma questo è uno degli aspetti che più odio, come gli sviluppatori Ubuntu del resto)

        Alcuni poi hanno, giustamente, fatto notare come questo modello possa influire sulla sicurezza, in quanto un software potrebbe utilizzare una vecchia versione di una libreria, ma è proprio per questo motivo che gli snappy fanno un sandbox dell’applicazione 🙂

        Un altro vantaggio poi è la facilità con cui si può fare un pacchetto snappy, ho avuto modo di vedere qualche video anche se non ho ancora provato direttamente e sembra molto più semplice rispetto a un tradizionale .deb

        Si insomma, era ora che venisse cambiata questa cosa 😀

        • Samael

          Alcuni poi hanno, giustamente, fatto notare come questo modello possa
          influire sulla sicurezza, in quanto un software potrebbe utilizzare una
          vecchia versione di una libreria, ma è proprio per questo motivo che gli
          snappy fanno un sandbox dell’applicazione 🙂

          Questo è vero in parte. 🙂
          O meglio, sulla carta è così perché ogni bundle è indipendente dall’altro.
          Tuttavia all’atto pratico non lo è, perché con questo modello teoricamente si dovrebbe mandare in pensione l’idea che gli sviluppatori della distribuzione siano anche coloro che mettono a disposizione le applicazioni.
          Tecnicamente chi ha il compito di mantenere un software è il suo sviluppatore, non la distro.
          Le comunità della distro dovrebbero solo fornire il sistema operativo ed un sistema di gestione del software, quindi: kernel+userland+interfaccia grafica+package manager/host remoto per le applicazioni. Stop. Nient’altro.

          Il resto deve essere sempre e solo a carico di chi sviluppa il software, come è sempre stato nel resto del mondo.
          Il che significa che ogni sviluppatore dovrà patchare *solo il suo software* e metterlo in upload.
          Poi il package manager verificherà se la versione installata è uguale a quella hostata nei server, ed in caso così non fosse potrebbe fornire un upgrade.

          L’upgrade potrebbe persino essere fornito in due modi:
          – scarichi di nuovo tutta l’applicazione
          – usi tecnologie come xdelta3 e fai diff binario, come avviene con RPMDelta e con gli aggiornamenti di FreeBSD.

          Sul sandbox delle applicazioni ti dirò, possiamo persino farlo meglio di OSX, grazie ai cgroup, namespace e a systemd, visto che Linux dispone di tecnologie per resource limiting e containerizzazione. Tutte che cose che OSX non ha perché non è un OS lato server.

          • Matteo Iervasi

            Esattamente, beh è molto simile al modello Google con Android. Io faccio la mia applicazione, la carico sul mio account Google Play, pian piano arriva a tutti quelli che han la versione vecchia, il tutto in maniera automatica e graduale. Google si deve solo preoccupare di migliorare il sistema, non le applicazioni (tranne le sue ovviamente). Però su Android non c’è il sandboxing che ci sarà su Linux 😀

            Penso sia la giusta direzione, anche perchè così si potrà usare una nuova versione di un software senza dover per forza aggiornare tutto quanto, come adesso.

            Alla fine diventerà una sorta di rolling-release, o no? 🙂

          • Samael

            Sì, il termine esatto sarebbe half-rolling: l’OS rimane stabile, o comunque legato alle politiche del ciclo di vita stabilite dai suoi sviluppatori, mentre lo stack applicativo si mantiene sempre aggiornato ed indipendente.

          • Aury88

            penso che in realtà Canonical voglia andare nella direzione della rolling per le non lts e di semi-rolling per le lts…se il modello applicato per le non lts è quello degli OTA di UT (facile da immaginare verrà esteso anche al desk visto che si tratterà di fatto dello stesso identico OS) parliamo di rilasci frequentissimi del os…e in quest’ottica secondo me è da inquadrare appunto la nuova acquisita capacità di snapcraft di fare snap del kernel (Ubuntu potrà così avere il nuovo kernel praticamente non appena esce una nuova versione)
            a prescindere da quello che vorrà fare canonical con la sua distro di sicuro la situazione è diventata molto meno complicata sia per gli utenti sia per gli sviluppatori. al momento il difetto delle snappy, che ne limita la diffusione, è quello di venir utilizzato “solo” sugli smartphone, IoT e sui server …onestamente non vedo l’ora di vedere cosa succederà quando (e se) uscirà ubuntu personal per desk

          • Samael

            Sì, potrebbe anche essere così, Aury88. E non sarebbe nemmeno la prima a farlo.
            Per esempio OmniOS lo fa già, mentre SmartOS addirittura non ha nemmeno LTS ma viene rilasciato ogni due settimane e basta.

            Naturalmente Snappy per adesso starà solo sul cloud/IoT, ma onestamente non riesco a dare torto a Canonical.
            Il mercato di Ubuntu, paradossalmente a quello che tutti pensano, non è il desktop ma il cloud.
            Quindi chiaramente dato che la partita dell’IT odierno si gioca lì preferiscono portare le loro innovazioni prima in quei settori.
            Probabilmente vogliono fare la mossa inversa di Microsoft. Mentre questa ha cercato di imporsi nei server facendo leva sul monopolio desktop, Ubuntu penso che voglia far leva sul dominio nel cloud per orientare gli sviluppatori/DevOps di SaaS a lavorare direttamente sul suo sistema operativo anche lato workstation.
            E da lì poi veicolare anche Ubuntu Touch tramite la convergenza cercando di dargli una quota commercialmente rilevante.

          • Aury88

            sì Samael, questa è la strategia di canonical, almeno da quello che ho inteso da alcune risposte di Mark Shuttleworth a varie interviste.
            Credo che sia l’unica mossa possibile per canonical… alla fine ha solo il settore cloud dove va veramente bene (nel desk che che se ne dica è comunque una delle distro più usate, se non ancora la più usata…rimane il fatto comunque che da questo settore non arrivavano abbastanza introiti), ed è giusto sfruttare questa cosa in ogni maniera possibile per cercare di conquistare altri mercati in cui si è in forte svantaggio
            onestamente sono molto ottimista…tecnologie come la convergenza vera, gli snappy ecc portano ad indubbi vantaggi ad un po’ tutti quelli che hanno a che fare con il SO: sviluppatori, utenti e sopratutto la stessa canonical… questa strategia ha un solo grande punto debole è cioè l’estesa fase di sviluppo iniziale durante il quale si rischia di perdere clienti e sviluppatori…la fase di sviluppo iniziale sembra però ormai prossima alla fine, vedremo se dopo canonical sarà in grado di sfruttare il vantaggio di dover lavorare su un solo so per tutti i propri clienti/utenti…
            ps: gli snappy approderanno preso sul desk secondo me (la 16:10 quasi sicuramente ci sarà una versione con gli snappy)…alla fine la loro introduzione è stata una delle motivazioni principali al passaggio al software center gnome al posto dell’USC 😉

      • Luky

        Su linux approcci del genere sono rari, li ho visti in certi videogiochi gli eseguibili o sono linkati statici o hanno proprio le librerie nella stessa cartella. Es. hotline miami.
        Ma ad esempio anche steam stesso.

        • Samael

          Su Linux non si sceglie l’approccio statico per due motivi sostanzialmente:
          – GNU (L)GPL che crea i soliti problemi riguardo la compatibilità
          – GLIBC che è una pessima libc, nota in questo caso per rendere bloat i binari statici per motivi ignoti, oltre ad avere molti altri problemi che la rendono un pessimo esempio di free software

          Su Linux di solito si usa l’approccio tarball/script autoestraente del software con incluse le dipendenze; ed è l’approccio tipico dei software commerciali, come VMware Workstation, VirtualBox, Mocha Pro ecc.
          Software che difatti girano su tutte le distro Linux senza problema alcuno.

  • mikronimo

    Una domanda OT: solo a me il video pubblicitario parte ad un volume assurdo? Se la risposta è no, sarebbe il caso di ridurlo, perché oltretutto non c’è un comando nel visore che permetta di farlo.

No more articles