In Ubuntu 15.10 potrebbe approdare una versione con il sistema di pacchetti Snappy al posto di apt / dpkg.

Ubuntu Snappy
A pochi giorni dal rilascio di Ubuntu 15.04 Vivid, gli sviluppatori Canonical stanno già lavorando alla futura versione 15.10 trapelando alcune possibili novità. Will Cooke, Ubuntu Desktop Manager di Canonical, ha segnalato il possibile rilascio di una versione di Ubuntu 15.10 basata sul nuovo sistema di pacchetti Snappy, sviluppato da Canonical che verrà incluso di default nella futura versione con Unity 8 e Mir. Snappy è un sistema di pacchetti che punta a rendere Ubuntu più stabile e sicuro fornendo all’utente la possibilità di avere applicazioni aggiornate e per gli sviluppatori evitare problemi legati a librerie, dipendenze ecc.

Con Snappy ogni singola applicazione viene rilasciata in un tarball che contiene tutti i file necessari per eseguire un’applicazione, senza struttura imposta di directory, dipendenze, e un singolo file di metadati che contiene il nome del pacchetto, la versione e percorsi dei file binari ecc.

Comandi di Ubuntu Snappy

Tengo a precisare che Ubuntu 15.10 e le derivate ufficiali rimarranno con il gestore dei pacchetti apt/dpkg, Canonical consentirà molto probabilmente agli utenti e sviluppatori di poter testare il nuovo sistema di pacchetti Snappy grazie ad una build dedicata (come accade attualmente con la versione con Unity 8 e MIR).

Ricordo inoltre che attualmente è solo una proposta, in data odierna non c’è alcuna conferma da parte di Canonical dell’arrivo della nuova build di Ubuntu basata su Snappy.

  • ma il porting a qt è moruto?

  • ienuz12

    Escluderei gia’ a priori il supporto per i driver grafici proprietari.

  • Davide Depau

    Spero che ottimizzino bene un po’ tutto, ho notato dei problemi di memoria con unity-panel-service e indicator-session-service…

  • spero davvero che a breve snappy sostituisca apt, lo trovo davvero interessante

  • Questo snappy mi ricorda un po’ i Bundle di fedora

  • jboss

    altro overhead alla distro più pesante del mondo, spero che debian non vada in pensione definitivamente in ambito desktop.

    • loki

      capirai se non te ne spunti con l’ennesima balla… dove sarebbe l’overhead di cui parli?

      • jboss

        en . wikipedia.org/wiki/Operating-system-level_virtualization

      • jboss

        en.wikipedia. org/wiki/Operating-system-level_virtualization read

        • Samael

          Operating-system-level virtualization usually imposes little to no overhead,

          Renditi conto che sei stato smentito dallo stesso sito che hai linkato.

          I container non causano alcun overhead perché, sebbene rientrino nel campo della virtualizzazione, il processo che avviene non è altro che un avvio di una applicazione in un runtime replicato e messo in isolamento dalla stessa sessione del kernel host.

          Il principio è lo stesso del chroot, ma con un livello di isolamento di gran lunga maggiore.

          L’overhead avviene quando la piattaforma virtualizzata si basa su una sessione del kernel indipendente dal sistema host che opera su hardware emulato.
          E questa non è OS-level virtualization, ma Hypervirtualization.
          Che è quella che fanno VMware, VirtualBox, Xen, KVM ecc.

          • jboss

            no i container hanno un piccolo overhead informati meglio, tutte le virt hanno overhead.

          • Samael

            Talmente tanto piccolo che su FreeBSD ci fai girare applicativi Linux a velocità nativa in Jail le cui syscall vengono wrappate da linuxulator.

          • Kim Allamandola

            Se parli di virtualizzazione completa (VMWare, Xen, VirtualBox, Qemu, …) su x86 certo, ad es. su Power no. E Power l’ho citato apposta perché non ha più da qualche generazione istanze non virtuali, almeno usando AiX…

        • loki

          “virtualization”
          posso fermarmi qui o deve leggere tutto un articolo che parla di un’altra roba?

          • Samael

            No, in realtà non parla di altra roba.
            Cioè, i container sono davvero sistemi di OS-level virtualization.
            Infatti ci sono in lista Jails, Docker, OpenVZ, lxc e zones.

            Che poi con la virtualizzazione reale c’entra poco e niente.

            Il punto di quella pagina di wikipedia è che lo smentisce al primo rigo della sezione Overhead.

          • loki

            sì, mi sono espresso male, la fretta… intendevo che non c’entra niente con l’overhead

  • Kayuz6

    Ubuntu for the win!

  • Simone Picciau

    Come Mac OS!

    • lucapas

      Insomma si va a ritroso. A me il sistema a pacchetti piace perché c’è un enorme risparmio di spazio che non hai con nessun altro sistema operativo. In 10 GB hai tutto quello che ti serve quando un Windows o Mac occupano 5-10 volte tanto!

      • luciano

        ci sono giochi programmi che occupano tranquillamente 10 20 GB lo spazio occupato dal sistema operativo nel 2015 è l’ultimo dei problemi ..

      • Samael

        Insomma si va a ritroso.
        A ritroso?
        Al contrario, hanno finalmente capito qual era il modello da seguire dopo anni di panzane sulla presunta affidabilità del modello a ragnatela di pacchetti.
        Modello che da secoli ha mostrato i suoi limiti e il suo essere poco evolvibile.
        Specie con le applicazioni complesse che ci ritroviamo oggi.

        E la cosa più triste è che sono 15 anni (anzi, più di 20/25 anni se ci sommiamo anche il periodo NeXTSTEP) che su OSX si usa modello simile in tutta tranquillità, mentre su Linux ci si affidava ai guru Red Hat come Ulrich Drepper che sparavano cagate sul presunto modello dinamico che ha portato alle strutture a ragnatela attuali, salvo poi vedere oggi la stessa Red Hat che cerca disperatamente soluzioni di compromesso alle sue teorie strampalate e prive di riscontri reali.

        Qualunque azienda con le mani in pasta nell’IT ha capito che la situazione doveva cambiare.
        L’aveva capito la SUN 8 anni fa quando lanciò Project Indiana (anticipando tutto e tutti, come con lo ZFS) e ora finalmente lo hanno capito anche Red Hat e Canonical.

        c’è un enorme risparmio di spazio che non hai con nessun altro sistema operativo
        C’è anche un livello di complessità e di scarsa affidabilità che non c’è negli altri sistemi operativi.
        Che non vuol dire che Windows o OSX siano la panacea.
        Ognuno ha i suoi problemi.

        • jboss

          invece anche me sembra che si vada a ritroso e di ritornare ai tempi dei mainframe

          • jboss

            solo molto più scalabile e adattata all’compito che deve eseguire.

      • Simone Picciau

        Chiaro, con questo sistema dei bundle avresti librerie duplicate sparse qua e là

        • Marco Moraschi

          E le librerie sparse potrebbero davvero essere un grosso cruccio per l’utilizzatore medio di ubuntu.
          Non parliamo della loro duplicazione.. vuoi mettere?
          …. E se poi uno ha messo il tema verdino e le librerie sono marrone scuro??? come le abbini?
          E se io vivo in un monolocale? Ho comprato un portatile da 11″ perchè ho poco spazio in salotto e ubuntu mi duplica le librerie senza chiedermi il permesso … è un maleducato!
          E pensare che il mio problema era installare la stampante …

  • Speriamo solo nella versione desktop.

  • giuseppe

    canonical ( ubuntu ) cerca ingegneri informatici ed altro , qui
    dovrebbero esserci persone valide ed all’ altezza chi fosse interessato :
    http://www.canonical.com/careers/all-vacancies

  • carlo coppa

    Ma veramente c’è qualcuno che oggi si preoccupa dello spazio che utilizza il SO ? Oggi chi ha poco spazio ha 250Gb…certo ci sono ancora catorci con dischi ridicoli, ma su quei cosi lì Ubuntu comunque non verrebbe installato, quindi quello dello spazio è l’ultimo dei problemi. Poi sicuramente ogni sistema ha i suoi pro e contro, quindi serve fare una valutazione oggettiva che deve comprendere sicurezza-stabilità-compatibilità-aggiornamento e quindi valutare pro e contro, senza pregiudizio, non perché un sistema è utilizzato nei Mac o in Windows al posto di Red-Hat o Canonical deve essere migliore o peggiore, nessuno ne ha il monopolio. Io da quello che ho letto in giro credo che non sia una brutta idea, ma poi come tutto occorre vederlo all’opera per capire meglio.

  • (matTE0)

    Praticamente diventa come GoboLinux e sinceramente la cosa mi piace, spero solo che tenga l’alberatura delle directory un po’ più sensato.

  • Marco Moraschi

    La butto lì da ignorante chiedendo lumi a chi ne capisce … posto che snappy si porta dietro questo e quello, non è che facendo un layer di compatibilità con snappy potrebbero cadere tanti muri tra le distro?
    Io per esempio non ho mai avuto affinità con yum aur rpm … probabilmente perchè ho incominciato coi .deb … ma un domani snappo tutto snappo di brutto. E penso che anche per i developer sarebbero diversi sbattoni in meno.
    Sicuramente ho scritto una o più castronerie … spiegatemi senza picchiarmi troppo che la mamma mi ha fatto delicato.

    • No no fermiamoci un secondo.
      Snappy è come apt,aptitude,dpkg,yum,pacman etc è un gestore dei pacchetti con la differenza che i primi non utilizzando il concetto di boundle risolvono le dipendenze mentre questo non fa altro che fare estrazione del tar, spostamente in cartelle apposite, creazione eventuali link fine.
      Snappy non è un layer di astrazione è un unzip/untar o come lo volete chiamare avanzato.

      • Samael

        mentre questo non fa altro che fare estrazione del tar, spostamente in cartelle apposite, creazione eventuali link fine.

        No, non sposta niente perché altrimenti si va a perdere ciò per cui è stato pensato: separare il sistema operativo dallo spazio per le applicazioni.
        Snappy porta applicazioni self-contained, ovvero tar che includono tutto il necessario+un file contenente metadati che serve per identificare e gestire il tutto.
        L’applicazione viene gestita completamente in uno spazio isolato gestito da AppArmor.

        Nella root del sistema non avrai più le librerie installate e condivise come le avrai oggi.
        E ogni container avrà il suo albero di dipendenze già soddisfatto.

      • fedefigo92

        Vuoi dire che con snappy si riescono a installare direttamente i tar?miracolo ci ho provato un sacco di volte per programmi che avevsno solo il tar e non ci sono mai riuscito…brava canonical rendi linux ancora più accessibile

        • Se il tar è compilato secondo le specifiche di snappy si 😛

        • un tar generalmente contiene o il binario gia compilato e quindi basta anche un doppio click sul binario per eseguire il software come nel caso di firefox ad esempio, oppure contiene il necessario per la compilazione e li devi essere tu a compilartelo da solo…
          in entrambi i casi devi accertarti di avere tutte le dipendenze richieste per far funzionare il software, altrimenti non ti si avvia (a meno che il tar non contiene anche tutte le librerie necessarie al suo funzionamento)

    • Kim Allamandola

      Tutte le domande ben poste sono ben accolte in una communit open, o almeno dovrebbero esserlo!

      Cmq la risposta è so e ni: oggi chi sviluppa non lo fa pensando a questa o quest’altra distro. Lo fa sulla sua distro favorita limitandosi a buone pratiche come non hard-codare path a files specifici ecc. I singoli packagers delle singole distro se ritengono interessante un dato sw si occupano di portarlo nella loro distro.

      Questa è una delle forze dell’essere open: non sei tu sviluppatore a doverti preoccupare di star dietro alle distro, sono loro che stan dietro a te e tutti essendo il codice pubblico cercano di limitare le brutture per non essere mazzolati a dovere. Il problema del supporto alle distro riguarda solo il sw proprietario che come tale non può contare sui packagers per essere portato…

      • Marco Moraschi

        beh però .. io utente che voglio usare digikam e su una distro è ad una certa versione su un’altra distro un’altra o magari il pacchetto non c’è neppure … io potrei esserne felice.
        Oppure ancora vado su un sito per scaricare un certo software e mi dice … se hai questa distro con questa versione scarica questo oppure se hai questa distro con quest’altra versione scarica quest’altro …. oppure pacchetto snappy e via andare.
        A me non sembra male come utente fancazzista nulla facente
        (utente medio desktop)

    • Marco Moraschi

      sì … più che i developer i manteiner

    • Samael

      Non ti picchiamo, perché hai esposto educatamente dei quesiti interessanti.
      E quindi meriti una risposta pacata e seria.

      La risposta è sì e no allo stesso tempo.

      Mi spiego: ad oggi l’incompatiblità è data dal fatto che ogni applicazione è legata ad una specifica versione della libreria installata.
      Se tu con l’applicazione distribuisci anche le due dipendenze, chiaramente risolvi il problema.

      Quindi, da un punto di vista tecnico sì perché l’applicazione ha già le sue dipendenze soddisfatte.
      Da un punto di vista pratico no, perché è richiesto Snappy.
      In sostanza se una distro non adotta Snappy tu non potrai usare quel pacchetto, allo stesso modo di come non puoi installare un rpm senza un package manager rpm. Idem per i deb.

  • Secondo me snappy e il concetto di boundle è veramente la stupidaggine del millenio.
    Cerchiamo di capire che la situazione attuale, dipendenze e ramificazione, non è l’ottimo ma di sicuro è meglio, molto meglio, che avere 80 volte le stesse librerie.
    Allora c’è innanzittutto da chiarire una cosa i bundle ala osx o come snappy non sono la pace dei sensi, sono una furbata per scrollarsi di dosso il problema di risolvere compatibilità che vengono a sgretolarsi con l’aumentare di versione delle librerie, facciamo un esempio che forse rende meglio.

    Allora ho il programma prog1 che ha come dipendenza la libreria lib1 in versione 1.0, e la chiameremo per comodità lib1-1.0, il boundle prevede uno zip con la seguente struttura (semplificazione concettuale):
    /
    /progs/prog1
    /libs/lib1-1.0

    Ora quando lo installo avrò nel mio fs:
    /progs/prog1/prog1 e /progs/prog1/lib1-1.0

    Anche in questo caso è una semplificazione concettuale.
    Quando il programma prog2 avrà bisogno della libreria lib1-1.0 avrò:
    /progs/prog2/prog2 e /progs/prog2/lib1-1.0

    Attualmente come funziona io ho:
    /progs/prog1 e /progs/prog2 che puntano a /libs/lib1

    Se arriva prog3 che vuole lib1 in versione 2.0 con i bundle avrò:
    /progs/prog3/prog3 e /progs/prog3/lib1-2.0

    senza creare danno agli altri 2, mentre allo stato attuale avrei /progs/prog1,prog2,prog3 che puntano a /libs/lib1 che ora è alla versione 2.0 e quindi prog1 e prog2 potrebbero non funzionare.

    Per scongiurare questo problema uso i bundle che triplicano lo spazio usato solo per evitare che prog1 e prog2 siano costretti ad aggiornare alla versione 2.0 di lib1, versione che magari corregge anche gravi bug ma di cui i programmatore nel 99% dei casi se ne strasbattono.

    Finito l’esempio si era già parlato di rivedere il concetto di struttura del fs linux ora non credo ci voglia un genio per capire che non serve fare i boundle per evitare di doversi adattare ai cambiamenti di versione ma basterebbe usare una sintassi diversa del tipo:
    /progs/prog1,prog2,prog3
    /libs/lib1/1.0,2.0 etc

    Se proprio volessimo dirla tutta questa cosa sono anni che viene proposta e mai discussa seriamente. Non credo serva avere 3 volte la copia di lib1 ma magari basta 2 volte una in versione 1.0 e una in versione 2.0 per quanto sarebbe meglio aggiornare prog1 e prog2 per farli funzionare con 2.0

    • +1

    • Samael

      Cerchiamo di capire che la situazione attuale, dipendenze e
      ramificazione, non è l’ottimo ma di sicuro è meglio, molto meglio, che
      avere 80 volte le stesse librerie.

      Ne sei sicuro?
      La situazione attuale ti dimostra esattamente il contrario.
      Vaglielo a dire agli ingegneri della SUN che si sono ritrovati con il caos che è diventato Java.
      Ma soprattutto, vaglielo a dire agli ingegneri
      di Red Hat che avevano dato ragione a quell’incompetente di Ulrich
      Drepper che diceva le tue stesse cose, salvo poi rimangiarsi tutto dopo
      dieci anni con Project Atomic perché si sono accorti che deployare
      applicativi su Linux è diventato un inferno.
      E aggiungo, vaglielo a dire ai dev di NixOS.

      Allora c’è innanzittutto da
      chiarire una cosa i bundle ala osx o come snappy non sono la pace dei
      sensi, sono una furbata per scrollarsi di dosso il problema di risolvere
      compatibilità che vengono a sgretolarsi con l’aumentare di versione
      delle librerie,

      Furbata?
      Quindi le soluzioni intelligenti diventano furbate?
      Ah ok, buono a sapersi.
      Pensa solo che NeXTSTEP/OSX usa il modello a binari statici da più di 25 anni senza problemi.
      Ma sicuramente sono loro gli scemi e noi gli intelligenti.
      Infatti sono così scemi che loro scaricano una applicazione e la lanciano con un doppio click. La spostano nel cestino e la rimuovono dal sistema.
      Immagino che noi intelligenti quando la rimuoviamo dal Software Center non lasciamo niente di orfano nel sistema, o sbaglio?

      Loro sono così scemi che a meno di funzionalità specifiche mantengono retrocompatibilità con i runtime di svariate versioni di OSX (ad oggi quasi sempre 10.7-10.10).
      Noi invece siamo così intelligenti che non puoi installare Handbrake che richiede GTK+ >= 3.10 se il sistema fornisce una versione precedente, non senza cambiare path e wrappare i binari.

      Loro sono così scemi che tramite il formato binario Mach-O possono cambiare architettura del sistema sottostante in maniera poco traumatica perché possono creare binari multi-architettura nello stesso bundle.

      Ma tranquillo, sono loro gli scemi. Noi siamo più furbi e intelligenti.
      Chissà come mai però siamo noi che stiamo cambiando soluzione e non loro.
      Mah, sarà una coincidenza.

      ma di cui i programmatore nel 99% dei casi se ne strasbattono.

      Come la fai bella facile, tu.
      Mi chiedo se tu sia stato davvero in un team di pacchettizzazione serio.
      Quanti bug gravissimi hanno fixato le GTK+3 che cambiano API ogni sei mesi?
      Credi davvero che i problemi si riducano ad una sola mancanza di voglia di ricompilare?
      Hai capito davvero poco del problema.

      Il fatto è che:
      – Ad oggi non ci sono metodi sani per mantenere runtime più vecchi per la compatibilità delle applicazioni senza evitare di aggiornare il sistema operativo;

      – Ad oggi non ci sono metodi sani per aggiornare un applicativo senza aggiornare tutto il resto;

      Non sono cazzate inventate a caso: si chiama dependency hell, ed è un fenomeno famoso quanto la controparte Java detta Jar Hell.

      Il problema non è ricompilare perché la libreria più aggiornata è migliore.
      I problemi sono che il linking attuale della libc di Linux (glibc) fa schifo in quanto versioned, e che il modello a linking dinamico sta mostrando i suoi limiti strutturali.
      E quella di glibc è una aberrazione che non sarebbe mai dovuta esistere, motivo per il quale al di fuori di Linux chi non ha bisogno di GNUismi se ne sta lontano e preferisce usare libc più sane.
      Ecco perché oggi ti ritrovi porcherie come applicazioni che non partono perché la GLIBC è N.1 mentre tu hai la N.0, e chiunque abbia bisogno di distribuire applicazioni binarie deve portarsi dietro la libc.so.6 per evitare problemi.

      Finito
      l’esempio si era già parlato di rivedere il concetto di struttura del
      fs linux ora non credo ci voglia un genio per capire che non serve fare i
      boundle per evitare di doversi adattare ai cambiamenti di versione ma
      basterebbe usare una sintassi diversa del tipo:
      /progs/prog1,prog2,prog3
      /libs/lib1/1.0,2.0 etc

      LOL
      Sai cosa significa una soluzione del genere?
      Lo spiego anche al signor Buratto che mette +1 a caso senza sapere quello di cui parla.
      Significa che ti ritroveresti cose come:
      libc.so.6.2.10,2.11,2.12,2.13,2.14,2.15,2.16,2.17 ecc.
      ALL’INFINITO

      Questo moltiplicalo per TUTTE le librerie del tuo sistema operativo e poi moltiplicalo di nuovo per 2 quando si parla di sistemi multilib.

      Cioè, per limitare il problema del versioning delle librerie proponi l’aumentare il versioning stesso?
      Stai quadruplicando il dependency hell per combattere il dependency hell.

      Sai chi propone questo schifo di soluzione?
      FreeBSD con i suoi compatNx.
      Sai cosa dicono gli stessi dev di FreeBSD? Usateli solo se strettamente necessario (ergo, MAI) perché la doppia versione della stessa libreria può causare problemi in fase di linking e loading, in quanto il linker fa casino quando si ritrova più versioni della stessa libreria che fornisce simboli simili.
      Non a caso ci sono stati più casi in cui ti ritrovavi applicazioni compilate su FreeBSD 9 e linkate su runtime della 5x e casi di applicazioni che caricavano runtime della 5x pur essendo compilati con la 9x.

      E renditi conto che FreeBSD proprone nuove versioni del runtime ad ogni major relase, quindi con molta meno frequenza di GLIBC.
      Infatti oggi esistono runtime per la 5x,6x,7x,8x,9x e 10x.
      Sei runtime contemporaneamente. Ora, se già con due soli runtime si rischiano casini, prova solo ad immaginare cosa succederebbe con 6 e oltre.

      Difatti per evitare di raddoppiare il problema per le due architetture, FreeBSD non ha un sistema di multilib ma propone l’uso di Jail in cui installare la controparte 32bit del sistema operativo.

      Per dire: su FreeBSD non c’è un metodo decente per installare applicazioni sceme come WINE, senza portarsi dietro una copia 32bit di tutto il sistema operativo+i ports.

      Chissà se tutte queste cose il signor Buratto le conosce, o mette +1 a caso per il gusto di far vedere che sa quello di cui parla…

      Ad oggi l’unico metodo più sano (leggasi: che fa meno schifo) è:
      mettere la libreria in un percorso differente e wrappare i binari con LD_LIBRARY_PATH in modo da obbligare il loader a pescare solo librerie specifiche. Che è quello che fanno tutti quelli che distribuiscono binari ed è quello che fanno in poche parole Snappy e Atomic, senza l’uso della variabile d’ambiente e con l’aggiunta di policy di sicurezza basate su AppArmor (Snappy) e SELinux+Docker (Atomic).
      Tuttavia, per evitare di creare di nuovo ragnatele ingestibili si preferisce distribuire le dipendenze all’interno del path dell’applicazione stessa, in modo quindi da separare lo spazio applicativo dal sistema sottostante.
      Anche a costo di raddoppiare lo spazio utilizzato.
      Da un lato hai l’aumento di spazio, dall’altro l’aumento della complessità dell’infrastruttura.
      Si tratta di scegliere su quale piatto della bilancia posarsi.

      Purtroppo l’unica soluzione decente, il linking statico, è stata scartata tramite l’uso del FUD in pieno stile MS.
      E come risultato oggi ci ritroviamo con ‘ste soluzioni pessime, e dobbiamo lottare contro una complessità troppo grande per essere gestita con metodi oramai inadeguati.

      • Ti chiedo di rileggere i commenti prima di sparare a 0.
        Innanzittutto ho detto che introdurre il versioning eviterebbe l’utilizzo di bundle perché appunto ti tieni solo le lib che ti interessano alla versione che ti interessano no che ti tieni tutto lo scibile umano quando aggiorni se non c’è dipendenza necessaria con la vecchia versione la rimuovi e fine, lo stesso discorso che si ha con i bundle.
        Con una soluzione del genere io richiamerei lib1-2.0 invece che il generico lib1 non vedo la cosa come un vincolo insormontabile, ma sarà perché per come la vedo io molti dei problemi li minimizzate alla semplice gui, chi fa applicativi server o librerie gli tange poco il cambio delle gtk, magari invece librerie che cambiano continuamente di versione per sopperire alle mancanze del systemd di turno sono più rognose da smazzare.
        Comunque confondete le soluzioni server con le soluzioni desktop, magari selinux + docker è comodo in ambiti server ma risulta molto scomodo in ambiti desktop dove le GUI la fanno da padrone e i problemi di gtk/qt release sono frequenti. In ambito server te l’ho spiegato le rogne sono solitamente sulle lib che te le risolvi linkando anche la versione se proprio serve tanto bunble o link col versioning ti cambia poco ma risparmi spazio e tempi.

        • Samael

          ——

        • Samael

          ——

      • m&g

        Il Jar Hell si puo’ dire che sia stato risolto utilizzando Maven, si riuscisse a fare una cosa simile con le dipendenze delle applicazioni in Linux non sarebbe affatto male.

        • Samael

          Rispondo qui a Black_Codec in quanto Disqus modera messaggi privi di spam.

          h t t p : / / p a s t e b i n . c o m / 5 U P A Y V m 1

  • antonio

    Ogni versione nuova c’è sempre qualcosa di nuovo che non mi piace…speriamo che snappy non la implementano.

No more articles