In questa semplice guida vedremo come possiamo testare Ubuntu Snappy su pc o come macchina virtuale in VirtualBox.

Ubuntu Snappy
Tra le tante novità sviluppate / supportate da Canonical troviamo anche Ubuntu Snappy, una versione della famosa distribuzione Linux dedicata alle piattaforme IoT (Internet of Thinghs). Ubuntu Snappy fornisce un sistema operativo base creato per essere stabile e soprattutto sicuro, tutto questo è possibile grazie al nuovo gestore dei pacchetti (niente quindi apt o dpkg), ogni applicazione consiste in un tarball con 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.

Con Ubuntu 15.04 Vivid è approdata anche la versione stabile di Ubuntu Snappy, release disponibile che viene rilasciata con file immagini img solo per architetture 64 Bit o ARM. Ubuntu Snappy è un sistema base che richiede pochissime risorse, basta scaricare il file immagine ed estrarlo in una pendrive (da almeno 4 GB) utilizzando ad esempio dd da riga di comando o dd utility.

Ubuntu Snappy

Possiamo testare Ubuntu Snappy in VirtualBox, per farlo prendiamo la nostra distro Linux ed installiamo il tool qemu-utils digitando:

sudo apt-get install qemu-utils

a questo punto possiamo convertire l’immagine img di Ubuntu Snappy in una macchina virtuale vdi digitando:

qemu-img convert -O vdi ubuntu-*.img ubuntu-snappy.vdi

una volta effettuata la conversione basterà creare una nuova macchina virtuale e caricare il file vdi nella sezione archiviazione.

Per accedere a Ubuntu Snappy dovremo inserire le credenziali:

username: ubuntu
password: ubuntu

Home Ubuntu Snappy

  • LelixSuper

    Interessante, dato che porto il processore e scheda grafica Intel 😉

  • Ermy_sti

    per quei soldi mi aspetto un ottimo compilatore…bisogna poi vedere che linguaggi supporta..

  • TopoRuggente

    Relativamente interessante, una eccessiva ottimizzazione del codice è ottima se sei sicuro che poi il tuo software girerà sempre su quella piattaforma.

  • Simone Dedo

    Vieni a criticare Intel ancora una volta Barra, vieni ancora a dirmi che Intel sta offrendo solo un caffè per la comunità Linux

  • loki

    sono curioso di vedere se il risultato finale prevederà in qualche modo l’uso di librerie condivise, altrimenti rimango abbastanza perplesso

    • Fabio

      Qualcuno meno ignorante del sottoscritto mi può spiegare in parole povere quali sono attualmente i pro e i contro principali di avere librerie condivise?
      Grazie 🙂

      • Kim Allamandola

        Per esemplificare hai due programmi con un’interfaccia grafica, chessò Nautilus (file manager) e Gnome scheduler (front-end alle crontab utente). Se hai librerie condivise la loro GUI (GTk) è disegnata da un singolo pezzo di software installato sul tuo sistema, se sono linkati staticamente entrambi i programmi incorporano le GTk.

        Il risultato è che con le librerie condivise risparmi spazio disco, ram, tempi di caricamento ecc ma devi stare attento quando aggiorni a non rompere nulla e non puoi quasi gestire a mano le installazioni, hai bisogno di un programma che tiene traccia delle varie librerie (dipendenze) e si incarica di gestirle al tuo posto.

        Con le compilazioni statiche/bundle/portable-apps/* invece occupi parecchio spazio disco in più, più ram, maggior IO ecc ma puoi gestire anche a mano i singoli pkg (un po’ come avviene con Windows, almeno nelle versioni pre-WindowsStore) senza doverti preoccupare delle dipendenze e degli aggiornamenti.

        Dei due approcci ha sempre vinto quello delle librerie condivise, ma oggi con la complessità degli OS moderni si stanno cercando soluzioni alternative. Java né disegnò una molti anni (decenni) fa, in tantissimi non l’han ancora capita oggi, Go ha ripreso l’idea di Java e anche qui quasi tutti gli utenti Go non se ne sono resi conto, Python, Perl, LaTeX ed altri han fatto cose analoghe (CTAN, CPAN, PyPI ecc). In sostanza deve crollare la netta distinzione tra binario compilato e codice sorgente. Questo oltre a non esser molto compreso da un enorme fastidio a chi vive sul software proprietario……….

        • Fabio

          Grazie della risposta, è più o meno come credevo. Ma posto che fare una cosa richiedendo meno risorse è sempre una bella cosa, con la potenza dell’hardware attuale ha ancora un senso? Voglio dire, immagino che non essere legati ad una libreria predefinita dia maggior libertà e facilità di programmazione… o no? Scusa se è una domanda stupida ma non conosco la programmazione.

          • Kim Allamandola

            Sei legato in ogni caso ad una libreria, nel senso: se scegli di usare le GTk o le Qt per es. lo fai perché altrimenti per disegnare la tua interfaccia grafica al posto di 20 righe di codice ce ne voglio 2000000. Le librerie servono proprio a risparmiare, sono collezioni di “funzionalità” pronte all’uso.

            Ora se usi quelle dinamiche semplicemente quando fai un pacchetto devi controllare che le librerie che ti servono siano presenti nel package system altrimenti impacchettarle a parte, fatto ciò sei responsabile solo di mantenere il pkg funzionante via via che altri aggiorneranno le librerie. Se usi quelle statiche sarà compito tuo tener aggiornate queste ultime. In altri termini il “lavoro umano” è lo stesso, solo spostato su soggetti diversi, per le librerie dinamiche lavora più la distro, per i pkg statici lavora più il packager originale.

            Poiché il lavoro è lo stesso si è sempre preferita la soluzione più performante. Solo su Windows ed altri sistemi commerciali si è preferita una, parziale, soluzione statica per permettere un controllo maggiore al “venditore” di un dato pacchetto…

            Ora per l’IoT ovvero per sistemi tipicamente molto ma molto specializzati, ovvero con pochissimo sw installato poiché fanno solo una cosa, tipicamente semplice, l’approccio statico può rendere più comoda la gestione del sistema, per sistemi complessi come i desktop è semplicemente un fallimento (ed è il motivo per cui Apple ha fatto iThunes, Microsoft Windows App store ecc dopo decenni che GNU/Linux e tanti UNIX usavo i repo…).

            Il motivo per cui si cerca un sostituto ad apt non è per statico vs dinamico ma perché gestire un installato apt non è pulito né facile, risponde a bisogni di un’altra era. Oggi vogliamo poter configurare un sistema con uno o pochi file yaml/xml non un con fileone poco digeribile come preseed o uno limitato come kickstart, oggi vogliamo poter installare un os come 100 da una singola semplice app senza complicati installer da avviare, mirror per i pkg, server tftp per il boot ecc, tutto questo con i pkg system classici (apt ma anche yum, ma anche tutti gli altri) non è affatto facile…

            Cmq prima che Snappy o chi per esso arrivi su desktop non preoccuparti che passeranno anni, deve prima cambiare la mentalità della gente, poi deve svilupparsi una soluzione realmente usabile e solo allora, dopo qualche anno arriverà veramente 🙂

          • .

            leggerti è veramente un piacere per curiosità lavori alla nasa o al cern ? 🙂

          • Kim Allamandola

            A dire il vero stò emigrando (pare finalmente dopo 2 anni di tentativi e ritardi) in Francia (Sophia-Antipolis), settore turistico al momento 🙂

          • Samael

            Poiché il lavoro è lo stesso si è sempre preferita la soluzione più
            performante. Solo su Windows ed altri sistemi commerciali si è preferita
            una, parziale, soluzione statica per permettere un controllo maggiore
            al “venditore” di un dato pacchetto…

            Da premettere che io sono per la compilazione statica e non dinamica.

            Sinceramente, Kim, non so quanto realmente più performante sia l’approccio a linking dinamico.
            D’altronde, da un punto di vista tecnico dovrebbe essere esattamente il contrario, visto che l’approccio statico prevede che le funzioni demandate alle librerie esterne vengano linkate direttamente all’interno del codice oggetto rendendo quindi praticamente non necessario l’intervento del loader in fase di caricamento del software.

            Personalmente, al di là di questa roba per lo più filosofica e che interessa pochi, io vedo più un fallimento l’approccio dinamico che quello statico.
            E la presenza dello store in OSX, in realtà, è una conferma in questo senso.
            Mac App Store alla fine è uno store (repository lo chiameremmo noi) di bundle, ovvero applicazioni compilate staticamente.

            E mi pare che l’approccio sia decisamente più efficiente dal punto di vista dell’installazione e della manutenzione del sistema operativo.

            Un bundle lo rimuovi e tanti saluti. Nel sistema non rimane niente.
            Rimuovi un pacchetto classico e se non fai un autoremove o una rimozione a cascata le dipendenze ti rimangono orfane nel sistema.

            Io credo che l’approccio dinamico, proprio perché le architetture software attuali sono altamente complesse, sia ormai da mandare in pensione.
            Anche perché, parliamoci chiaro, Kim: la potenza di calcolo attuale delle macchine è talmente elevata da rendere obbiettivamente ridicolo risparmiare qualche kilobyte in ram.

            Era un discorso che andava bene vent’anni fa, ma ormai lo trovo francamente senza senso.
            Anche perché ormai i software non li ottimizza più nessuno dei big. Ormai è una corsa a chi è più bloat, quindi avere un binario di qualche KB più pesante è del tutto irrilevante.

            Senza contare che un binario statico lo usi praticamente dovunque senza sforzi: lo puoi usare senza problemi su Sackware, Ubuntu, Red Hat, Debian ecc. e con un range di versioni altissimo.
            Un binario dinamico, no. A meno che non fai una copia delle librerie e wrappi gli eseguibili con LD_LIBRARY_PATH.

          • Kim Allamandola

            Sulle performance bé ci sono secoli di discussioni, ad ogni modo in più o in meno sono differenze ben piccole. Sul non lasciare tracce, l’esser comodi ecc dubito, solo come comodità pensa alla possibilità di aggiornare una singola libreria vs n programmi statici che quella libreria utilizzano, pensa alla comodità di non doversi preoccupare di seguire lo sviluppo delle n librerie che usi ma solo di controllare che tutto vada bene ecc. Tracce ne lasci comunque perché i log sono centralizzati, le conf pure ecc

            Non è proprio un paragone scientifico ma guarda quanto spazio disco occupa in media Windows od OSX rispetto a GNU/Linux, guarda quanta ram usano OSX ed Windows rispetto a GNU/Linux, certo sono mondi diversi ma un’idea la danno… Diciamo che i Kb possono anche essere parecchi Mb!

            Sulla portabilità… Dicimo che ad oggi non interessa grossomodo a nessuno: chi sviluppa sw open sviluppa sulla su distro/OS preferita, sono i packagers delle varie distro a sistemare i path del caso, chi sviluppa sw closed ha come obiettivo o solo Ubuntu o Ubuntu e Fedora/RHEL quindi.

            Per dirla tutta da un po’ di anni più che di statico vs dinamico si parla di sconvolgimenti maggiori: la SUN all’inizio di IPS (che per certi versi assomiglia alle scelte di Android) aveva teorizzato e poi non realizzato per mancanza di risorse: ogni pkg come un volume zfs “leggero” montato opportunamente sul sistema e gestito a livello di blocchi sotto lo zpl.
            Altri spingono per la CI con una “gestione” quasi stile “go get” che non ho ben capito come gestisce le dipendenze. ‘Somma ben altro bolle in pentola 🙂

          • TopoRuggente

            Sui pochi Kb magari avrei qualche dubbio, un applicativo con interfaccia grafica si porterebbe sicuramente dei Mb (le kdelibs sono oltre 50mb).

          • Samael

            No, questo è un luogo comune sulla compilazione statica.

            Il linking statico non linka l’intera libreria all’interno del codice oggetto, ma solo il simbolo necessario che serve al codice oggetto per diventare un eseguibile standalone.

            Tra l’altro le toolchain moderne come quella di GCC e LLVM fanno deadcode elimination e linking-time analyzing che vuol dire in soldoni che in fase di linking viene fatto un controllo funzione per funzione nelle librerie date in pasto al linker, affinché venga linkato all’interno del codice oggetto solo le funzioni necessarie.
            Quindi non solo si ottimizza linkando solo il simbolo necessario, ma si ottimizza ancora più a fondo andando a linkare solo la parte di quel simbolo che serve all’applicazione.

            In sostanza il binario eseguibile risultante ha già diverse ottimizzazioni al suo interno, oltre quelle che vengono passate tramite compilatore.

            Paradossalmente, ad oggi è il modello dinamico che ti fa trascinare dietro kdelibs da 50MB perché è l’applicativo dinamico che necessita della dipendenza contenuta nel pacchettone.
            Motivo per il quale framework di grandi dimensioni sono stati in molti casi splittati in diversi pacchettini.
            Proprio per ovviare al problema derivato dal concetto di dipendenza.

          • TopoRuggente

            Infatti non dico 50Mb, ma qualche Mb.
            1Mb sarabbe il 2% delle kdelib, sicuramente considerando qualche altra dipendenza, direi che dipendendo dall’applicazione si vada da pochi Kb a qualche Mb.

            Nel caso di Boa un webserver
            “The
            compilation time is short. When linked against uClibc and stripped,
            the resulting binary is 60 KB in size when linked dynamically and 90
            KB when linked statically. When linked against glibc and stripped,
            the resulting binary is 60 KB in size when linked dynamically and 520
            KB when linked statically.”

            Nel caso migliore +50% nel peggiore quasi +800%.

          • Samael

            Infatti non dico 50Mb, ma qualche Mb.
            Ma anche se fossero 2MB, stiamo parlando comunque di cifre irrisorie.
            Specie se si considera che se da un lato hai un eseguibile più pesante ma avviabile senza bisogno di niente, dall’altro hai un eseguibile più leggero ma completamente incapace di avviarsi senza le sue librerie.

            Fai di nuovo il paragone tra il solo binario statico contro una directory che contiene binario dinamico+tutte le sue dipendenze che ti mostra ldd (che è quello che fa Snappy), e poi ne riparliamo su quale soluzione spreca meno spazio.

            Perché altrimenti è un giocare al ti piace vincere facile.
            Un binario privo di qualsiasi funzione sarà sempre più “leggero” di un qualsiasi binario completo.
            Peccato però che all’atto pratico il primo sia una roba inutile.

          • TopoRuggente

            Se lo fai su un unico programma sicuramente no, tra un software e le librerie e un software linkato staticamente vince il secondo.

            Ma fra 100 software e una libreria e 100 software linkati staticamente, e tra un migliaio?

            Le glibc sono 37Mb, quanto aumenterebbe di dimensione l’intero sistema GNU compilando staticamente essendo che glibc è quasi onnipresente?

            Se prendiamo Boa come esempio.
            100 boa shared = 60*100+37000=43000 (conto 1Mb=1000Kb)
            100 boa linked = 520*100 = 52000
            un 25% in più con una sola libreria.
            Se ipotiziamo 1000 software passiamo a 97Mb contro 520Mb
            Nel caso di librerie molto diffuse i numeri diventano corposi

            È tutto a verificare , ma se il buon giorno si vede dal mattino …..

            Sicuramente potrebbe essere una buona opzione per il futuro “mobile”, ma su server dove girando migliaia di processi ?

          • Samael

            È tutto a verificare , ma se il buon giorno si vede dal mattino …..

            Eh, non c’è molto da verificare.
            Quella comparazione lascia il tempo che trova anche solo per il fatto che hai conteggiato i 37MB totali e manca di riscontri sul campo.

          • TopoRuggente

            Ovvio che ho conteggiato i 37Mb total sono la dimensione delle librerie glibc che nel caso delle librerie linkate dinamicamente considero totale.

            I riscontri sul campo potrebbero essere anche peggiori, quanti applicativi conosci che si basano solo su una libreria? Quanti invece ne richiedono anche decine.

            Inoltre dimensione a parte, che in caso di un sistema completo io ipotizzo possa aumentare del 100%, ma con le dimensioni degli hd odierni non sarebbe grande cosa.

            Rimane, e secondo me gravissimo, il problema dei tempi di bugfixing in caso di bug di sicurezza in una libreria.
            Dinamically -> Attesa correzione Bug -> Soluzione
            Statically -> Attesa correzione Bug -> Attesa ricompilazione applicazioni ->Soluzione.

          • Samael

            Ovvio che ho conteggiato i 37Mb total sono la dimensione delle librerie
            glibc che nel caso delle librerie linkate dinamicamente considero
            totale.

            No, perché quando vai a deployare l’applicativo non ti porti dietro le glibc intere, ma solo la libc.so.6.

            Sulla questione riscontro sul campo, e sui i risultati che potrebbero essere peggiori. Ne sei sicuro?

            Tu per dimostrare che occupi meno spazio hai deployato una sola volta la libreria dipendente e 1000 applicativi.
            Ma questo è un metodo sbagliato, perché crea dependency hell.
            Ed è il motivo per cui lo si sta abbandonando con queste soluzioni come Snappy e Atomic.

            Il metodo sano per deployare applicazioni linkate dinamicamente è deployare tutto insieme.

            Quindi, 1000 directory con 1000 copie della stessa libreria.

            Ora, facciamo un calcolo un po’ più realistico usando più o meno i tuoi stessi numeri.
            37 MB sarà il totale delle dipendenze non del pacchetto intero della glibc che contiene header e altre cose a noi inutili oltre il runtime.
            60KB sarà il binario eseguibile dinamico
            8MB sarà il binario eseguibile statico

            Ok? Pensa che vantaggio ti sto dando.
            60KB vs 8MB

            Facciamo 1000 software di questo tipo.

            (Il rapporto lo lascio 1:1000 come hai fatto tu)

            1000 app shared distribuibili:
            (60+37000)*1000 = 37.060.000 => 37GB

            1000 app statiche distribuibili
            8000*1000 = 8.000.000 => 8GB

            Mi pare che il risparmio sia più o meno del 78%.

            Ma bloatiamo ancora di più:
            Il software dinamico rimane uguale.
            Lo statico sarà di 20MB

            20000*1000=20.000.000 => 20GB

            In sostanza, per arrivare alla stesso spazio sprecato dalla controparte dinamica dovrei bloatare il singolo binario per farlo arrivare alla stessa dimensione delle sue dipendenze.

            Ma ciò è assai improbabile visto che il linking di una sola funzione (quindi non solo di una singola porzione) è molto più leggero di un portarsi dietro tutta la libreria.

            Ripeto: sei sicuro che sprechi meno spazio?

            Rimane, e secondo me gravissimo, il problema dei tempi di bugfixing in caso di bug di sicurezza in una libreria.
            Dinamically -> Attesa correzione Bug -> Soluzione
            Statically -> Attesa correzione Bug -> Attesa ricompilazione applicazioni ->Soluzione.

            No, questo non è esattamente così.
            I binari statici non è detto che siano vulnerabili come le controparti dinamiche, in quanto le vulnerabilità sfruttabili tramite linking sono attacchi che non li colpiscono nella stragrande maggioranza dei casi.
            Perché? Te l’ho appena spiegato: i binari statici linkano una o più funzioni, non la libreria intera.
            Quindi se la vulnerabilità colpisce una zona non usata, la tua applicazione non è nei fatti vulnerabile.

            Se la porzione di codice è la stessa allora la questione cambia, in quanto vanno ricompilati.
            Ma attenzione: sicuro che anche i dinamici non vadano ricompilati?
            Non è sempre detto: se il fix di una libreria porta a cambi di funzione, in quanto questa aveva una vulnerabilità allora la ricompilazione ti tocca anche nei dinamici.
            E quindi perdi il vantaggio.

            Anche perché con i binari statici potrai deployare solo una patch binaria per fixare tutto il pacchetto.

            Quante patch binarie ti ci vorranno per la controparte dinamica?
            Assumendo i numeri di prima e assumendo che il problema stia nella libc.so.6 ti toccherebbe deployare tante patch quanti sono i binari (librerie ed eseguibile) inclusi nella directory.
            Che è la situazione attuale.

            Il linking dinamico non si è diffuso per rendere i tuoi applicativi più sicuri o più leggeri.
            La SUN portò le librerie dinamiche su UNIX per permettere una maggiore flessibilità nel cambio di codice senza ricompilare ciò che dipendeva da esso.
            Ma il suo era un semplice studio non un’implementazione da usare in produzione, che si concluse dicendo che il linking dinamico spreca spazio ed è anche più lento della controparte statica.

            E anzi, ci sono casi in un cui i binari statici sono anche più piccoli dei singoli binari dinamici.

            Leggi qui:
            h t t p : / /harmful . cat-v . org/software/dynamic-linking/

          • TopoRuggente

            No rileggi il mio post perche non hai letteralmente capito.

            Shared
            60 (dimensione applicativo) * 1000 (numero applicativi) + 37000 (dimensione glibc) = 60000+37000 = 97.000
            Static
            520 (dimensione applicativo) * 1000 (numero applicativi) = 520.000

            Ossia (matematicamente parlando) un aumento del 436% …

            Questa è la differenza usando il webserver boa (un applicativo che oscilla fra i 60 e i 520Kb quindi piccolino) come esempio.

            Sicuramente contare 1000 volte lo stesso applicativo non è un metodo scientifico, ma parliamo di un applicativo di piccole dimensioni e della compilazione linkando solo le glibc.

            Credi di avere 1000 applicativi in un pc che si appoggino sulle glibc?

            Comunque sia in un solo applicativo si passa da 60 a 520Kb, sono pochi Kb, ma anche un aumento di quasi l’800% dell’applicativo

            Se ipotizziamo che effettivamente la media sia di solo la metà, un sistema linux linked sarebbe 3-4 volte più pesante di uno shared, a colpi di pochi Kb siamo già a qualche Gb

          • Samael

            No rileggi il mio post perche non hai letteralmente capito.

            Eh? Guarda che il tuo post l’ho capito benissimo.
            E ti ho rifatto gli esempi usando i tuoi stessi numeri allo stesso posto.

            Forse sei tu che non hai capito il mio.

            Difatti ti ho risposto che:
            1) 37MB è un dato fasullo perché in deploy non ti porti dietro tutta la glibc.
            Al massimo se vuoi usarlo come esempio, puoi usarlo come la somma delle dipendenze (che è quello che ho fatto io per rendere più realistico lo scenario).

            2) Non puoi fare il confronto tra 1000 statici self-contained e 1000 dinamici con una sola libreria deployata, perché è un metodo errato che si sta eliminando.

            3) Che se proprio vuoi fare un calcolo usando i 37MB devi moltiplicare per 1000, perché devi deployare sempre il binario+la dipendenza.

          • TopoRuggente

            Allora proprio non ci arrivi, non sto parlando di deployment, problema totalmente relativo, ma di dimensioni di un binario compilato con shared o statically linked libraries.

            Parte del codice di librerie molto utilizzate cone glibc, kdelibs (per kde), GTK (per mezzo mondo), sarebbe linkato nella maggior parte delle applicazioni presenti nel tuo HD.
            Le librerie condivise nascono proprio per evitare che parte di codice estremamente comune (le librerie c) sia ripetuto all’eccesso .

            Ora tu dici che si trattano di pochi Kb, sul sito di un programma di 60Kb dicono che diventa di 520Kb (magari loro sbagliano o sono contro Snappy).

            Se per aver linkato staticamente glibc ogni binario presente in /bin (circa 4000 files), /usr/bin etc si gonfiasse in questo modo …
            quanto sarebbe la dimensione di un sistema linux?

          • Samael

            Allora proprio non ci arrivi, non sto parlando di deployment, problema
            totalmente relativo, ma di dimensioni di un binario compilato con shared
            o statically linked libraries.

            Sei tu che non ci arrivi. Il problema non lo puoi analizzare se non metti in mezzo il deployment.
            Non ha senso parlare di shared vs static se poi non metti in mezzo la distribuzione dell’infrastruttura.
            Rimangono solo numeri sparati a caso che non hanno alcun valore pratico.
            Non puoi analizzare la situazione usando come metro di paragone solo il tuo computer.
            Non quando parliamo di sistemi distribuiti come UNIX.

            Nessuno fa questi paragoni senza parlare di deploy quando parla di strato applicativo.
            Soltanto tu lo stai facendo, per ovvi motivi.
            Perché finché ti limiti al tuo computer il tuo calcolo ti dà ragione. Quando esci fuori ti smentisce, perché il vantaggio che tanto predichi non è derivato da una soluzione obbiettivamente più intelligente, ma da una infrastruttura precaria.

            Le librerie condivise nascono proprio per evitare che parte di codice
            estremamente comune (le librerie c) sia ripetuto all’eccesso .

            Le librerie condivise non nascono affatto per quello, come non nascono per la velocità o la sicurezza.
            Sono nate come esperimento mal riuscito per cambiare codice on-the-fly.
            Mal riuscito perché si era visto che in caso di API breakage si creavano problemi di runtime.
            Lo stesso problema che ha oggi Windows.

            E si è risolto con il versioning delle librerie.
            Una porcheria ancora più grande per mascherare un’altra porcheria.
            Tipo un tizio che fa un debito in banca per saldarne un altro.
            Difatti quando si è messo in mezzo il versioning si è perso il vantaggio di cambiare codice on-the-fly perché veniva linkata una specifica versione e non più la libreria, e si è arrivato ad usare symlink ed LD_LIBRARY_PATH che sono soluzioni poco sicure.
            Per mitigare la scarsa velocità accentuata dalla relocation poi hanno creato LD_PRELOAD che è un’altra voragine in termini di sicurezza.

            UNIX da che mondo è mondo è sempre stato linkato staticamente.
            Solo quando sono arrivati aborti come X11 e compagnia si è parlato di linking dinamico.
            E infatti stiamo parlando di due mostri che oggi stiamo cercando di eliminare.

            Ora tu dici che si trattano di pochi Kb, sul sito di un programma di 60Kb dicono che diventa di 520Kb

            A casa mia, a parità di binario, 60KB vs 520KB è una differenza infinitesimale.
            Poi a casa tua non so.

            (magari loro sbagliano o sono contro Snappy)

            Loro non hanno sbagliato per niente e nessuno l’ha messo in dubbio.
            Difatti ti ho detto fin dall’inizio che a parità di singolo binario lo statico è generalmente più pesante del dinamico.
            Ma è un paragone forzato, perché lo statico è self-contained mentre il dinamico no.
            Infatti sei stato tu stesso a darmi ragione quando ti ho detto che se fai il calcolo statico contro dinamico e dipendenze la situazione cambia.

            E lì lo statico batte un dinamico sano a qualsiasi livello.
            Persino con una differenza di 20MB.

            La questione delle ragnatele di dipendenze è una lama a doppio taglio.
            Risparmi sullo spazio ma crei infrastrutture di merda.
            Non puoi paragonare infrastrutture solide e sicure basate su binari statici contro infrastrutture non solide e vantare che queste ultime siano meno onerose.

            Altrimenti è come dire che un’impresa che risparmia sulla sicurezza degli operai è più furba di una che non lo fa.
            E prima che ti alzi a dire che il paragone non c’entra, ti rispondo: il paragone è lo stesso.
            Sono entrambi casi in cui si è scelto una soluzione poco sicura per risparmiare.
            Difatti le aziende dell’IT mi danno ragione, perché da sempre distribuiscono binari per linux in archivi self-contained e oggi stanno sviluppando soluzioni centralizzate che fanno la stessa cosa.

            Se per aver linkato staticamente glibc ogni binario presente in /bin
            (circa 4000 files), /usr/bin etc si gonfiasse in questo modo …
            quanto sarebbe la dimensione di un sistema linux?

            Peserebbe sempre meno di una infrastruttura dinamica sana basata su pacchetti self-contained.

            I pacchetti a ragnatela non fanno testo.
            Creano dependency hell, quindi il risparmio di spazio è soltanto una delle tante conseguenze di un modello sbagliato.

            E anzi, da che mondo è mondo lo userland del sistema (/bin ed /sbin) dovrebbe essere sempre compilato staticamente, perché dovrebbe essere una piattaforma da mantenere sempre in piedi e priva di potenziali problemi di runtime.
            UNIX ha funzionato così per 40 anni, linkando staticamente tutto.

            Tra l’altro il problema del gonfiare all’eccesso è un problema di glibc.
            Il link che ti ho dato mostra esattamente come lo userland Plan9 statico sia persino più piccolo a parità di binario rispetto a quello FreeBSD che è dinamico ed usa una libc più sana di quella GNU.

            Quindi la soluzione migliore non dovrebbe essere quella di non usare lo statico, ma al massimo di mandare a cagare la GNU libc.

            Inoltre normalmente il deployment in ambito OpenSource è fatto dalla distribuzione e non dallo sviluppatore

            E che significa questo?
            Non è che se c’è dietro Red Hat anziché Samael e TopoRuggente allora il problema si risolve, eh?
            Il dependency e i problemi di deploying ci sono per tutti.

            O forse sei uno di quelli che ragiona con l’idea: sul mio computer non ho problemi quindi il problema non esiste?

            Infatti non mi pare sia un problema molto frequente di installare un
            pacchetto dalla repository ufficiale e scoprire che usa una libreria
            diversa da quella presente nello stesso repository.

            LOL
            Beh certo se ti limiti al repository ufficiale, no.
            Peccato che il problema parte dall’uso dei repo di terze parti.
            E prima che mi rispondi con: cazzi tuoi che usi roba non ufficiale, ti rispondo subito.
            Il problema dei repo ufficiali è che nel 2015 leghiamo il software alla piattaforma, quindi lo strato applicativo non è mai aggiornato.
            Infatti hanno inventato i PPA e i repo di terze parti apposta.
            Tuttavia, essendo che non tutti gli sviluppatori seguono le regole dell’ingegneria del software riguardanti il feature freeze, oggi ti ritrovi librerie che cambiano API nello stesso minor trunk anche a distanza di pochi mesi, vedasi GTK+3 in cui i dev stessi hanno asserito che la stabilità delle API non è una cosa che a loro interessa.
            E quindi ti ritrovi software che se usano le API di libpippo 3.5 non funzionano su sistemi che hanno libpippo 3.4, e devi ricorrere a mezzi sporchi che ho già spiegato più e più volte.

            Oppure fai come fanno gli idioti e sostituisci i pacchetti ufficiali.
            E il 90% dei casini di Ubuntu con i PPA sono derivati proprio da quello.

            Il principio su cui vertono queste soluzioni è di slegare lo strato applicativo dal sistema sottostante, in modo da permettere aggiornamenti più sicuri sia dell’uno che dell’altro.
            Ma si vede che io, Canonical, Red Hat ecc. ci sbagliamo.

            ma così su due piedi dubito che gli utenti Slackware vedrebbero di buon
            occhio binari statici precompilati da entità non ben specificate.

            Perché, un pacchetto dinamico compilato da un tizio a caso sarebbe più sicuro?
            I dinamici non sono mai stati più sicuri degli statici.
            Questa è solo una favoletta che possiamo raccontare per far addormentare i bambini.

            Gli utenti Slackware a parte AlienBOB, rworkman, Willy Raharjo, Slacky e qualche altro repo binario, scaricano solo SlackBuild.
            Ma il problema della differenza di librerie è comunque parecchio sentito.
            Tanto che lo stesso Alien sta cercando soluzioni di questo tipo per Handbrake.

          • TopoRuggente

            Inoltre normalmente il deployment in ambito OpenSource è fatto dalla distribuzione e non dallo sviluppatore, quindi si supponde che la distribuzione sia a conoscienza di quali librerie stia disponibilizzando e di quale versione.

            Infatti non mi pare sia un problema molto frequente di installare un pacchetto dalla repository ufficiale e scoprire che usa una libreria diversa da quella presente nello stesso repository.

            Capita a noi utenti slack di scoprire che il software che stai installando richiede nuove librerie e quindi spesso tocca compilarsi tutte le dipendenze, ma così su due piedi dubito che gli utenti Slackware vedrebbero di buon occhio binari statici precompilati da entità non ben specificate.

          • Agostino

            Un bel esempio molto semplice sono le estensioni di gnome e la shell di gnome stesso. Basta un banale avanzamento di una frazione infinitesimale di versione del secondo per mandare all’aria tutto l’ambaradan connesso di prima. Con la necessità repentina di continui aggiornamenti per tutte le estensioni che non vogliono correre il rischio di rimanere disattivate. Semplificando, la condivisione implica parecchia instabilità per tutti i software che mutano molto nel corso di tempi brevi (es per evoluzione). Non a caso TUTTI ma proprio TUTTI i software professionali quasi MAI tentano la strada della condivisione a meno che la condivisione non sia tenuta sotto “stretto controllo ravvicinato” vale dire al guinzaglio da chi genera gli stessi software.

          • TopoRuggente

            Dall’altro lato è anche vero che nel caso di un buco di sicurezza (ad esempio in OpenSSL), nel caso delle shared library devi solo aggiornare la libreria, nel caso delle statically linked library devi aspettare che tutte le aplicazioni che la usano vengano aggiornate e scaricare tutti gli aggiornamenti.

      • TopoRuggente

        In soldoni.

        Diciamo che o gestisci tutto a livello server, quindi l’app ne richiama un’altra per chiedere un servizio (disegan una finesta ad esempio) o ogni applicazione duplicherà lo stesso codice.

        Ad esempio la libreria che include il codice della finesta “Apri file” delle librerie GTK, adesso è condivisa fra tutte le applicazioni, in futuro potrebbe essercene una in ogni software.

        Vantaggi delle shared library, è più semplice mantenere una certa omogeinicità, ma in caso di problema in una libreria ovviamente il disastro è generalizzato.

        Di contro le librerie linkate staticamente creano applicazioni più corpose e complicano l’aggiornamento.

        Dico complicano l’aggiornamento nel senso che in caso di aggiornamento delle GTK dovresti aggiornare tutte le app per vedere i cambiamenti in tutto il sistema, dall’altro lato però l’applicazione non aggiornata potrebbe ancora funzionare con la versione non attualizzata della libreria.

        Nel caso di correzione di un bug (di sicurezza) in una libreria ovviamente il problema sarebbe grave, invece di risolvere aggiornando la libreria saresti costretto ad aspettare di aggiornare tutte le applicazioni che la utilizzano prima di poter giudicare il problema risolto.

  • Hombre Maledicto

    “ogni applicazione consiste in un tarball con tutti i file necessari per eseguire un’applicazione

    Parliamo di bundles mi par di capire.

    • Sì più o meno una porcheria simile.

      • Hombre Maledicto

        Non mi sento di sbilanciarmi sulla faccenda, avendo si e no una magra conoscenza a livello teorico e non conoscendo l’implementazione di snappy, ma la cosa è affascinante. Possibile (probabile) si traduca in qualcosa di meno performante rispetto alle soluzioni attuali, ma potrebbe finalmente “aggiornare” il paradigma ad una soluzione più versatile.
        Comunque i commenti su questo articolo restano molto interessanti (e alcuni istruttivi), sia i pro che i contro. E’ un argomento che trovo affascinante, dicevo.
        Credo che Poettering già da tempo stesse pensando ad una soluzione simile ( http://www.phoronix.com/scan.php?page=news_item&px=MTc3NzU )

      • Mohammed Al Maktum

        in base a cosa ritieni i bundles una porcheria?

  • jboss

    ubbundu rovinerà il mondo desktop di tutte le altre distribuzioni,almeno che tutte non andranno sotto i suoi piedi.

    • loki

      devi spararle più grosse, altrimenti nessuno ti prende sul serio

      • jboss

        mo t spieg na cos: mark è un imprenditore e perciò ragiona da imprenditore, frutta la comunità ed allo stesso tempo vuole distinguersi dagli altri creando software tutti suoi senza contribuire, invece red hat è un pilastro della comunità open ed e la prima azienda a contribuire allo sviluppo del kernel.

        • loki

          red hat? ah sì, quella società (non sono mica imprenditori eh, ci mancherebbe) che decide senza possibilità di obbiezione vita, morte e miracoli di mezzo ecosistema linux… proprio un bel esempio

    • Kim Allamandola

      Se Ubuntu “rovinerà” le altre distro lo farà (come stà facendo) nella stessa misura in cui Google “rovina” i concorrenti ovvero facendo prodotti nettamente migliori nonostante si basino quasi interamente su tecnologie note e diffuse.

      Ubuntu è la “miglior distro” sul piano del far la distro: integra e sviluppa solo quel che gli serve. Purtroppo tanti non lo vogliono comprendere e continuano su un percorso oggi privo di futuro.

      Red Hat? È stato un ottimo pilastro, oggi è, proprio per il suo peso, una zavorra per l’intera comunità come un domani lo sarà Ubuntu perché il male non è aver successo ma essere i soli ad averlo perché tutti gli altri lavorano peggio di te. Il non aver scelta è un male.

      • jboss

        invece il problema è la scelta, non metto in dubbio che la scelta sia una cosa buona è giusta, ma se linux non si da degli standard almeno a livello di sistema quest’OS non decollerà mai, e penso che red hat lo stia facendo nel modo migliore aprendosi è proponendo il loro software è contribuendo al kernel pilasto di tutto ciò.
        Poi riguarda systemd secondo me non è un male dipende da che lato si osserva.

        • Kim Allamandola

          Hum, dove deve decollare scusa? È solo il kernel e l’os (con GNU) più diffuso al mondo, quello che copre l’area più vasta in tutto l’IT, quello scelto per tutti i compiti più critici sempre più spesso a scapito di UNIX storici…

          Come standard c’è la LSB e non mi dire che tra RH ed Ubuntu ci sono le differenze che puoi trovare tra AiX, HP-UX e Solaris! La mania del “dev’essere tutto uguale” è il rant di quegli sviluppatori di sw proprietario che non vogliono cambiare business model: su GNU/Linux lo sviluppatore sviluppa sulla distro che vuole, i packagers delle varie distro sistemano le differenze contribuendo notevolmente alla revisione del codice, alla scoperta di bachi altrimenti difficili da trovare ecc. Ovvero trasformando un progetto da qualcosa di pochi a qualcosa di tanti. È proprio grazie a questo processo che la qualità del sw open è superiore a quella ti tutti i modelli closed.

          Per systemd, no, non è un male, è solo un upstart fatto peggio che si prepara a diventare l’ennesimo mostro sulla piazza, uno di quei tanti che fecero scappare molti verso *BSD e Opensolaris dai primi 2.6 sino a 5-6 anni fa…

          • Samael

            Il problema è questa volta non ci sono davvero alternative.

            OpenSolaris è stata l’ultima spiaggia.
            L’unico sistema operativo UNIX alternativo a Linux usabile davvero, e non da tenere come soprammobile come BSD.

            BSD, o meglio FreeBSD (gli altri non li considero proprio, perché a parte qualche uso specifico come firewall o embedded sono praticamente inusabili), è un sistema bello sulla carta ma ingestibile all’atto pratico.

            I Ports usati in ambito desktop sono un inferno.
            Pensare di gestire una roba come Firefox+KDE+LibreOffice+OpenJDK+altre_app via ports è da pazzi o da gente che non ha nulla da fare nella giornata.
            I packages rimangono non aggiornati e non in sync col trunk dei ports.

            Il supporto hardware lascia a desiderare.

            Sono d’accordo con te che systemd si prepara ad essere un mostro, però questa volta non c’è veramente alternativa.

            In tutto questo dobbiamo solo ringraziare Oracle che ha ucciso OpenSolaris riducendo Solaris 11 ad un relitto acquistato da qualche cliente storico SUN o da qualche grossa banca, e illumos ad un progetto valido solo per sistemi ad usi specifici come SmartOS, ma completamente inadeguato ad usi general purpose.

            Anche se ad essere onesti le colpe le ha anche l’ex management SUN, che voleva l’open source ma non ha mai voluto una vera community.
            illumos sarebbe dovuto nascere già da prima, con SUN, Nexenta, Joyent e le altre ad innovare insieme abbattendo i costi di sviluppo.
            Mentre OpenSolaris alla fine è stato solo un “regalare” gratis codice al mondo accollandosi da sola lo stesso tutto lo sviluppo.

          • Kim Allamandola

            +1M! Nexenta, Joyent&c sono nate da ex SUN che (penso) all’interno di SUN spingessero per modernizzare Solaris… Purtroppo han avuto paura che il codice rilasciato sotto GPL venisse fagocitato da GNU/Linux togliendo interesse verso Solaris e si son dati la martellata sui testicoli da soli…

            Pensa solo a quanto rumore fa oggi Docker e quanto poco fa Docker rispetto alle zones… Quanto rumore fa Snappy vs IPS, i BE, Caiman e tutto quel che stava nascendo intorno allo zfs…

            È un altro pezzo di storia, dopo Irix, che se n’è andato, ma questo è anche naturale, quel che fa veramente rabbia è che in tantissimi non se ne curino proprio, abbian la prosopopea di dire Solaris è morto, tutto quel che avevan fatto è spazzatura, non ci interessa manco guardarlo. Per poi scoprire, con anni di ritardo, gli stessi problemi già scoperti e risolti meglio di quanto stan proponendo oggi…

          • Samael

            Quoto tutto.

            Specie questo pezzo:
            Pensa solo a quanto rumore fa oggi Docker e quanto poco fa Docker
            rispetto alle zones… Quanto rumore fa Snappy vs IPS, i BE, Caiman e
            tutto quel che stava nascendo intorno allo zfs…

            OpenSolaris aveva portato le branded zone per “virtualizzare” vecchie versioni del sistema operativo in modo da mantenere la compatibilità per le applicazioni che necessitavano di vecchi runtime, o virtualizzare Linux e risolvere eventuali problemi di mancanza di applicazioni native.

            Senza contare quanto potente fosse Crossbow.

            Ma la cosa più bella, Kim, era che la SUN aveva sviluppato tecnologie avanzate e complesse ma allo stesso tempo dannatamente facili da apprendere e da usare.

            Imparare a mettere su una zone, o virtualizzare lo stack di rete con crossbow era di una facilità talmente imbarazzante che quando guardo le controparti linux mi deprimo.

            La morte sia di IRIX che di OSOL non è stata una vittoria di Linux, come qualche fanboy potrebbe pensare.
            La verità è che ci abbiamo perso tutti.

            Specie perché ci siamo ritrovati ad avere a che fare con Btrfs che non vale un millesimo di ZFS, con SystemTap al posto di DTrace, systemd al posto di SMF ecc.

            Proprio l’altro giorno ho scoperto che con Btrfs non posso gestire opzioni di mount per subvolume, mentre con lo ZFS settavi compressione e tanto altro ad ogni singolo dataset, personalizzandone l’amministrazione.

            Così ora mi ritrovo il subvol 0, la ROOT della pool Btrfs, che eredita le opzioni da un subvolume figlio.
            Cose aberranti, Kim.
            Un subvolume genitore che eredita da un subvolume figlio.

            Meno male che almeno le quote le hanno implementate separatamente, altrimenti ci saremmo ritrovati con il subvol 0 che ereditava le quote di un suo subvolume.

            Mi vengono i brividi solo al pensiero.

      • Sim One

        Non sono al vostro livello tecnico, ma quoto questo intervento di Kim. Soprattutto nei passi “nella stessa misura in cui Google “rovina” i concorrenti” e “Il non aver scelta è un male”.
        IMHO, ovviamente.

  • E’ interessante eliminare l’uso del package manager giusto negli ambiti dove dà il meglio di sé: EPIC FAIL.

    • loki

      è un funzionamento simile a docker, applicato però all’intera distro. ti sembra forse docker un epic fail?

      • Inapplicabile. Snappy è a livello OS, docker è un container sopra tale livello, il primo rimanendo un epic fail. Scommessa?

        • Kim Allamandola

          Hai presente l’ambiente IoT? Non si parla di sistemi complessi ma di micromacchine praticamente monotask dove hai solo un os iper-strippato (kernel+miniuserland) e un’applicazione quasi sempre sviluppata “in casa” dal produttore del ferro.

          Che ti serve in questo scenario una complessa gestione dei packages?

          • Tra le altre cose, i PM gestiscono gli aggiornamenti in maniera puntuale, consistente e cifrata. Nessuna macchina sull’Internet può farne a meno.

          • Kim Allamandola

            Guarda che Snappy non è un formato di pkg, per capirci Snappy va insieme ad apt, yum, Pacman, Emerge, … NON VA insieme a rpm, deb ecc

            La discussione sul formato del singolo package è nata penso giusto per far notare quanto è semplice.

          • Samael

            E cosa ti impedisce di fare la stessa cosa con Snappy e Atomic?

            Ciò che cambia è il metodo in cui vengono deployate le applicazioni, non il metodo in cui vengono gestiti gli aggiornamenti.

            Semplicemente Snappy e Atomic fanno quello che si sarebbe dovuto fare già da anni: distribuire applicazioni self-contained separate dal sistema operativo e operanti in ambienti a policy ristrette (tramite Docker+SELinux in Atomic, e tramite AppArmor in Snappy).

            Il che si traduce in:
            – sistemi più sicuri, in quanto le applicazioni non hanno più accesso a TUTTE le risorse del sistema, ma solo a quelle che Docker o AppArmor mette loro a disposizione.

            – addio al dependency hell. Niente più applicazioni broken perché libfoo è stata aggiornata e i binari richiedevano la versione N-1.

            – addio a quell’hack ORRIBILE dei symlink alle librerie per ingannare il loader, in modo da cercare di mitigare il fenomeno descritto poco sopra.

            – addio ad usi sconsiderati di quello schifo di LD_PRELOAD, che è il male quasi quanto l’uso sconsiderato di eval.

            ecc. ecc.
            E potrei continuare ancora per molto.

            Il concetto di pacchetto come lo conosciamo noi è un concetto broken by design.

            Non è più possibile nel 2015 pensare di avere applicazioni di terze parti LEGATE ad una specifica versione di un sistema operativo.

            Non è possibile che un utente non possa avere una versione più recente di una applicazione se usa una distro LTS perché la prima richiede versioni specifiche di una libreria non fornite nel sistema.

            Ad esempio: non è possibile che io su Slackware 14.1 non possa installare l’ultimo Handbrake perché esso richiede GTK+ >= 3.10, mentre il sistema fornisce la 3.8.
            Non senza compilare il trunk specifico e wrappare l’applicazione con LD_LIBRARY_PATH o compilare il tutto staticamente per ovviare al problema, sempre se l’applicazione supporta il linking statico.

            La gestione pacchetto+dipendenza è una gestione che andava bene quando gli applicativi non erano complessi come quelli attuali.
            Oggi è semplicemente insostenibile.

            Basta guardare che soluzioni sono state create: PPA, OpenSUSE Build Service e i vari repo di terze parti.
            Tutti concetti belli sulla carta, ma mostri nella pratica, poiché se non usati con cautela possono compromettere la stabilità della stessa distribuzione in quanto vanno a sostituire librerie testate dai dev della distro con versioni custom compilate a volte ad hoc e potenzialmente incompatibili.

            Se vuoi vedere quanto “”bello”” sia realmente il modello attuale di pacchetti+dipendenze, installa Slackware e rimanici per un anno a gestire A MANO tutte le dipendenze delle tue applicazioni, anziché demandare al package manager.
            Così poi ti rendi conto di che razza di complessità c’è dietro ogni distribuzione e di che inferno stiamo parlando.

            Poi magari guarda cosa stanno cercando di fare Snappy e Atomic, e forse ti renderai conto che non sono poi tanto schifose come soluzioni.

            Il problema della comunità Linux è che spesso non si rende conto di avere un problema, e di conseguenza non capisce che evolvere molte volte è necessario.
            Ma soprattutto, che è necessario evolvere BENE, cioè tutto il contrario di soluzioni come systemd.

          • Sono anni che vado perorando (circa) le medesime idee, ma limitatamente ai sistemi desktop.

            I server (comprendiamo qui anche tutti i sistemi definibili IoT, altro, peraltro inutile, neologismo informatico per far apparire come nuove tecnologie vecchie come l’Informatica stessa, ma questo è un altro discorso) hanno bisogno di stabilità e di tutte le logiche sottese dai PM (dalla prima all’ultima), non certo di essere bleeding edge (P.S: avete letto il mio primo commento?).

            symlink alle librerie, compilazione statica (così addio aggiornamenti) ed altre porcherie semplicemente NON esistono sui server o almeno NON nei miei e nemmeno tra quelli ben configurati.

            Sui sistemi desktop in realtà è nato ben più di un tentativo di avere un “layer di app” sopra alla ragnatela dorata delle dipendenze dei pkg manager, ma ahimè sono falliti tutti.

            Ma quest’idea (Snappy) è broken by design se si pone di sostituire i PM “nel senso classico” circa la gestione del “layer” di sistema: il sistema operativo DEVE essere retto dai “PM classici”, e le applicazioni di “livello utente” dovrebbero essere rette da qualcos’altro.

            Se Snappy farà questa divisione vivrà, altrimenti soccomberà come tutti gli “innovativi” progetti made in Canonical. E anche tu rimarrai deluso: stando all’articolo, Snappy fa molto poco di quello che speri, se non incasinare le cose in maniera orripilante (presente quella cozza dell’OS X?).

          • Samael

            stando all’articolo, Snappy fa molto poco di quello che speri

            Veramente il fatto che Snappy sia un metodo di gestione self-contained monitorato da AppArmor è scritto nella stessa documentazione, eh.

            Tutte le considerazioni che io ho fatto sono semplici conseguenze di questa metodologia.

            (presente quella cozza dell’OS X?).

            Quale? Quel sistema in cui scarichi l’applicazione sul desktop e la esegui senza installare niente, per poi rimuoverla spostandola semplicemente nel cestino, lasciando pulito l’environment del sistema?

          • Questo Snappy è pensato per essere usato per il solo “app layer” oppure per l’intero sistema operativo?

            Nel primo caso, bene, se sarà decente speriamo di vederlo nei sistemi desktop.

            Ma in ambo i casi, sui server non serve(R) ad un caZo. Da cui il mio primo commento (e non lo spiegherò oltre perchè in tutta onestà mi pare chiaro).

            > Quel sistema in cui scarichi l’applicazione sul desktop …?

            Sì quel sistema usato nello 0% degli environment mission-critical, ove serva stabilità e sicurezza, esattamente quello (che poi è quello da cui ho la sfortuna di scrivere in questo momento).

          • Samael

            Ma in ambo i casi, sui server non serve(R) ad un caZo.

            Difatti Docker ed lxc non servono a niente, vero?

            E OSX non è usato negli ambienti mission-critical non per i bundle ma perché

            1) è un OS orientato al desktop

            2) manca di tecnologie specifiche come i container, virtualizzazione dello stack di rete, hypervisor integrato ecc., in quanto non necessarie al target a cui fa riferimento.

            3) è legato a macchine Apple.

            Poi se vuoi fare l’hater a prescindere, OK. Chiudiamo qui la discussione.

          • No i container NON sono usati per aggiornare il sistema operativo, in caso contrario deduco che non hai mai gestito un server.
            E allora la domanda sorge spontanea: perché stiamo a parlare di server?

          • Samael

            No i container NON sono usati per aggiornare il sistema operativo, in caso contrario deduco che non hai mai gestito un server.

            Dove ho scritto che i container li si usano per aggiornare il sistema operativo?

            I container sono sistemi di isolamento di applicazioni, con lxc che è orientato alla replica totale dell’environment e docker che è orientato all’uso per-applicazione.

            Conosco molto bene cosa siano i container visto che ne ho sei attualmente in piedi.

            Snappy e Atomic fanno lo stesso, basandosi sulle medesime tecnologie, in modo da

            1) Facilitare i rollback
            2) Blindare le applicazioni
            3) Ridurre la complessità delle infrastrutture

            E tra l’altro, sì. I container sono anche pensati per permettere aggiornamenti più facili del sistema operativo host, senza intaccare la compatibilità delle applicazioni che possono girare su runtime guest più vecchi.
            Vatti a documentare sulle branded zone di Solaris.

          • loki

            e per quale arcano motivo non puoi usare i container per gestire l’intero sistema?

          • Kim Allamandola

            Hai presente l’architettura Power (IBM)? Bé li i container sono addirittura in hw. E non mi dire che ad oggi le P-series sono desktop!

          • Samael

            Aggiungo una piccola cosa:

            I server (comprendiamo qui anche tutti i sistemi definibili IoT,
            altro, peraltro inutile, neologismo informatico per far apparire […] (P.S:
            avete letto il mio primo commento?).

            E pensa che Atomic lo stanno sviluppando proprio perché anche i server sono affetti dall’eccessiva quanto inutile gestione complessa degli applicativi.
            Sul sito di Project Atomic vedrai che si parla proprio di problematiche del mondo IT.
            Soprattutto in termini di sicurezza.

            compilazione statica (così addio aggiornamenti)
            Dove hai letto questa stupidaggine?

            Mai sentito parlare di diff binario?
            xdelta3, tanto per dirne uno.

          • Se qualcuno convincerà il Debian o Red Hat ad usare queste porcherie per i suoi server, allora ne riparleremo. Al momento rimangono sparute porcherie.

            > Mai sentito parlare di diff binario.

            Oh sì, circa gli aggiornamenti di enormi file compilati staticamente dev’essere un ottimo modo per gestire i server nella maniera peggiore possibile. Sbaglio?
            P.S.: fai sul serio?

          • Samael

            Se qualcuno convincerà il Debian o Red Hat ad usare queste porcherie per
            i suoi server, allora ne riparleremo. Al momento rimangono sparute
            porcherie.

            Project Atomic sta venendo sviluppato proprio da RH con RHEL, CentOS e Fedora come target.
            Fai un po’ te.

            Oh sì, circa gli aggiornamenti di enormi file compilati staticamente
            dev’essere un ottimo modo per gestire i server nella maniera peggiore
            possibile. Sbaglio?
            P.S.: fai sul serio?

            Tu dici?
            Dimostralo.
            Dimostra come una gestione basata sui diff sia controproducente.

            Renditi conto che gli snapshot dello ZFS erano basati sullo stesso principio.
            Quindi anche ZFS è inefficiente sui server?

          • Stiamo parlando di aggiornamenti dei sistemi operativi server. Dai su, rimani in tema, a meno che tu non sappia (da dietro le quinte) che il prossimo RH userà questi metodi-underdog, chiaramente. Allora mi arrendo, ma in caso contrario finiamola di andare OT, vediamo come si evolveranno le cose, e ho paura che non saranno proprio come speri (per fortuna). E qui chiudo.
            Che cosa c’entri un filesystem con gli aggiornamenti di pacchetti rimane un mistero, ma è altra storia (OT) sulla quale non mi dilungo…
            Peace.

          • Samael

            Che cosa c’entri un filesystem con gli aggiornamenti di pacchetti rimane
            un mistero, ma è altra storia (OT) sulla quale non mi dilungo…

            Infatti gli snapshot dello ZFS erano nati soprattutto per gestire gli aggiornamenti del sistema operativo tramite cloni avviabili chiamati Boot Environment.

            Ed era un principio nato proprio perché il diff è più efficiente del rollback intero del pacchetto.

            Non sono io che sto andando OT, Buratto. Sei semplicemente tu che stai giudicando senza sapere.

          • Samael

            Rileggendomi ho dimenticato un passaggio importante:

            pensa che i diff binari sono così poco efficienti che li usano RH e SUSE con rpmdelta (che è il metodo di aggiornamento attuale), li usa anche FreeBSD con freebsd-update e li usava per le patch la SUN fino a Solaris 10 e con IPS che fa il diff diretto in Solaris 11.

            Proprio inefficienti sui server, vero?

          • Quindi stai argomentando contro i PM portando un esempio di PM? Non male come dialettica! P.S.: basta OT!!!

          • Samael

            Quindi stai argomentando contro i PM portando un esempio di PM? Non male come dialettica!

            No, ti ho soltanto dimostrato che quando dici che il diff binario è inefficiente sui server stai dicendo stupidaggini, come in tutto il resto.

            E comunque non è un OT, visto che di package manager si parla.

            PS: degli esempi riportati solo zypper (SUSE), yum (RHEL) e IPS (Solaris 11) sono package manager.
            Il resto no.

          • Questo è ciò che ho detto: “Oh sì, circa gli aggiornamenti di enormi file compilati staticamente
            dev’essere un ottimo modo per gestire i server nella maniera peggiore possibile”.
            Il resto è un po’ come chi se la fa e se la dice da solo (e gli altri, attoniti, lo guardano sbigottiti).

            L’argomento è la gestione degli aggiornamenti dei server, non come vengano scambiati i dati. Se vuoi ci mettiamo a parlare di tecnologie di trasmissione dati a livello di comunicazioni elettriche (problemi nessuno), ma non credo rimarremmo comunque in tema.

            Detto questo, se Snappy saprà fare ciò che si prefigge SOPRA il SO, allora ben venga, in caso contrario speriamo di non sentirne più parlare, per lo meno in ambito SERVER.

            Avendo ripetuto per la duecentesima volta il mio pensiero (sul quale NON ho ricevuto risposte dirette), chiudo.

            Ciaoo.

          • Samael

            Oh sì, circa gli aggiornamenti di enormi file compilati staticamente
            dev’essere un ottimo modo per gestire i server nella maniera peggiore possibile

            E difatti io ti ho risposto chiedendoti di dimostrare come il diff binario renda inefficiente la cosa.
            E mi pare che tu non abbia detto nulla al riguardo.

            Non me la sto cantando da solo.
            Stai semplicemente dimostrando che non sai quelli di cui stai parlando.
            Lo stai facendo fin dall’inizio.

            Odi così tanto Canonical che
            1) Dicevi che tutte le mie aspettative non erano soddisfatte da snappy, quando le sue caratteristiche erano ben descritte nel sito ufficiale

            2) Hai definito Atomic una porcheria dubitando del fatto che RH l’avrebbe implementata, ignorando il fatto che Atomic lo sa sviluppando proprio RH.

            3) Hai sparato a zero sui diff binari dicendo che la gestione è inefficiente sui server, quando
            1) vengono già impiegati in questi settori
            2) sono più efficienti del singolo rollback
            3) non fa alcuna differenza se il binario è statico o dinamico. Stiamo parlando di diff.

            4) Non sai cosa siano i container e a cosa servano.

            E in tutto questo hai avuto persino la faccia tosta di dirmi che non sapevo nulla dell’amministrazione di un server, quando sei tu che non ti informi sugli argomenti di cui spari a zero e non ti informi nemmeno su come funzionino le tecnologie.
            Salvo poi venire qui e fare figure barbine implorando di finire con gli OT perché evidentemente il tuo odio insensato per Canonical ti ha portato a dire boiate talmente plateali che non sai più come uscirne.

            Beh, mi dispiace per te, Buratto.
            La prossima volta fai meno l’hater e usa Google.
            Magari impari qualcosa di nuovo.

          • Chiunque legga potrà vedere che stai ancora una volta rispondendo a questioni che non ho sollevato (te lo scrivo chiaro? Mai parlato di efficienza, magari la finisci di attaccarti a cose che stanno solo nella tua mente – e, credimi, non è un bel segno).

            Per cosa io sappia e cosa no (e quanti soldi mi faccia guadagnare cosa so) non ho idea di come tu faccia a esprimerti, bah. So solo che ne rimarresti deluso.

            Come vedi ora ho risposto OT agli OT ma questo sarà pure l’ultimo mio post al riguardo.

            Ah, per inciso, non odio Canonical.

          • Samael

            Mai parlato di efficienza

            Ah sì? E allora definisci meglio l’argomentazione, no?
            Dato che non parli di efficienza, però metti in mezzo la dimensione dei binari statici, spiega a tutti quanti cosa intendi.

            Così ti si risponde nel merito.
            O forse devo dedurre che ti stai arrampicando sugli specchi?
            E per una volta rispondi, non girarci attorno.

            Per quanto riguarda il non sapere le cose, ti ricordo che sei stato tu a fare il gradasso dicendomi che non sapevo come si amministrassero i server.
            Il fatto che poi tu sia stato smentito dai fatti è un tuo problema.

            Io ripeto non me la canto da solo: io semplicemente mi informo e poi parlo.
            Tutto quello che non hai fatto tu fino ad ora.

          • Kim Allamandola

            È un mistero presto detto: c’è uno stretto legame tra fs, pkg-man ed installer. I pkg-man servono a gestire files di un certo tipo, la stessa cosa che i “fs” fanno.

            Lo zfs per esempio aveva permesso i BE (boot environment) ovvero la possibilità di avere un os installato in un volume zfs, poterlo “clonare” per aggiornarlo e provarlo, per fare esperimenti, tornare indietro ecc. Il tutto ovviamente integrato con il pkg system. Altri (Nexenta) han fatto la stessa cosa con zfs-apt, altri ancora da anni parlano, senza far granché, su GNU/Linux di integrare gli snapshot (che di fatto sono cloni) del btrfs nei pkg system…

          • Samael

            Attualmente mi pare che l’unica che abbia implementato una soluzione BE-like sia OpenSUSE con Snapper, che crea snapshot bootable.

            Su Arch Linux (AUR) è presente grub-btrfs (o simile) che mette uno script nella directory di grub affinché cerchi gli snapshot btrfs e li inserisca nella lista delle entry quando si genera il grub.cfg, ma è comunque un lavoro manuale.
            Pacman non ha la benché minima integrazione con Btrfs.

            Però come soluzione out-of-the-box a parte SUSE non mi pare che si sia mosso qualcuno.

            Siamo tuttavia lontani dalla soluzione presente in OpenSolaris, dove non c’era un demone chiamato Snapper a gestire la cosa, ma si era preferito integrare direttamente IPS e ZFS, in modo da evitare l’uso di strati e substrati di layer e fornire un’infrastruttura pulita ed efficiente.

            Tra l’altro manca ancora un’alternativa a quella meravigliosa funzionalità che era Time Slider.

          • Kim Allamandola

            Mai provato freebsd-update?

        • loki

          scommessa. gusto a titolo informativo: sai che anche fedora sta facendo la stessa cosa?

No more articles