di  -  martedì 27 luglio 2010

In quasi tutti gli articoli che ho postato riguardo al desktop GNU/Linux è sempre apparso qualche commento, anche fuori dall’argomento trattato, che addita come fattore frenante della diffusione del pinguino il sistema di gestione dei pacchetti software.

Come prima cosa bisogna analizzare qual è lo stato dell’arte delle distribuzioni più diffuse:

L’approccio comune è quello del deposito centralizzato (repository). In poche parole una selezione di software viene compilata e mantenuta dai distributori stessi. L’utente potrà tranquillamente utilizzare svariati strumenti (grafici, da linea di comando etc…) per interfacciarsi al deposito centrale e ottenere il software desiderato.

Tale approccio porta con se diversi vantaggi ma anche qualche svantaggio:

Vantaggi:

  • Semplicità di installazione di software presente nel deposito centrale
  • Sicurezza garantita grazie all’utilizzo di un sistema di firme digitali
  • Aggiornamenti automatici su tutto il parco software (non solo il sistema base ma anche le applicazioni)
  • Efficienza sia rispetto allo spazio occupato su disco che alla memoria occupata (in realtà questo non è dovuto all’utilizzo di un repository centralizzato ma alla pacchettizzazione separata di librerie e programmi con le prime che possono essere condivise tra più applicazioni)

Svantaggi:

  • Difficoltà nell’installazione di software esterno al meccanismo del deposito centralizzato
  • Scarsa flessibilità rispetto ad esigenze particolari (mantenere un pacchetto libreria ad una versione vecchia potrebbe bloccare a catena l’aggiornamento di altre componenti a causa della fitta rete di dipendenze)

Quello che si è sempre cercato di fare è mitigare gli svantaggi mantenendo inalterati i vantaggi. Questo obbiettivo è stato perseguito con approcci molto diversi ma tutti interessanti.

Prendiamo per esempio Ubuntu. Molti utenti di vecchia data si ricorderanno come pochi anni fa per installare applicazioni più aggiornate o che non erano presenti nel deposito principale si finiva per aggiungere una selva di depositi di terze parti potenzialmente dannosi sia per quanto riguarda la sicurezza che per una mera questione di consistenza. Spesso tali repository non disponevano nemmeno di una firma digitale.

Per evitare questa tendenza Canonical attraverso la piattaforma Launchpad ha messo a disposizione la possibilità di ospitare i PPA (Personal Package Archive) attraverso cui sviluppatori ufficiali e non possono fornire aggiornamenti o nuovo software in maniera semplice e più sicura.

Approccio alternativo che ho apprezzato molto è quello di Arch Linux. La piccola distribuzione che fa della semplicità il suo punto di forza affianca ai classici repository centralizzati AUR (Archlinux User Repository). AUR in realtà non è un contenitore di software ma di script (PKGBUILD) per la creazione di pacchetti (per capirci in maniera simile agli ebuild di gentoo o i ports BSD).

Da una selezione dei PKGBUILD più utilizzati e votati vengono poi creati dei pacchetti binari mantenuti nel repository “community”. La semplicità nel creare pacchetti e la gestione molto lineare degli stessi fa sì che si riesca a padroneggiare molto bene la gestione del software installato sulla propria macchina. Purtroppo tutto questo viene con un costo: la cosa non è assolutamente alla portata di tutti gli utenti. Le conoscenze richieste per la gestione di un sistema del genere non sono assolutamente conciliabili con la classica utenza desktop (e non hanno dichiaratamente nessun motivo per esserlo).

Tutte e due le soluzioni presentate risolvono in parte il primo svantaggio presentato ma servono a ben poco per il secondo dovuto come già detto alla scelta di mantenere un repository con componenti molto piccole dalla grande interdipendenza per favorire l’efficienza.

La via “storica” utilizzata per risolvere il secondo problema è quella di fornire dei semplici archivi con dentro tutto il necessario per l’esecuzione del programma in maniera indipendente dalla distribuzione. Tale strada viene per esempio seguita dagli sviluppatori di firefox che rilasciano la propria versione precompilata del celebre browser con queste modalità.

A rendere ancora più interessante questa possibilità sono le varie tecnologie di bundling che ciclicamente si ripresentano nel panorama aperto. Tali tecnologie permettono in maniera simile ai file DMG (Apple Disk Image) ben noti agli utenti MacOSX di contenere un’applicazione e tutte le sue dipendenze in un unico file.

Ultimamente si fa un gran parlare di una di queste tecnologie appena uscite: AppImage.
Tecnicamente una AppImage è un file ELF contenente una iso. Tale iso contiene tutto l’albero di directory e file necessari (dipendenze comprese) all’avvio del programma.
Al doppio click sul file AppImage tale iso verrà montata attraverso l’utilizzo della libreria FUSE in una directory temporanea e da lì l’eseguibile del programma verrà chiamato con variabili d’ambiente opportunamente settate per fare in modo che vengano utilizzate le librerie inserite nel bundle piuttosto che quelle di sistema. In questo processo non ci sarà quindi una installazione persistente con il piacevole risultato che la disinstallazione del programma coincide di fatto con l’eliminazione del file.

Come avrete ben capito, se da una parte tale soluzione risolve molti problemi ne riapre molti altri che con il sistema a repository non erano in discussione. Nello specifico sicurezza, facilità di aggiornamento ed efficienza sono sacrificate sull’altare della maggiore flessibilità.

Bisogna però dire che nelle intenzioni degli sviluppatori di questo progetto non c’è quella di soppiantare il sistema a repository ma di fornire un alternativa per la distribuzione di software aggiornato. Il progetto è giovane e molte migliorie possono e devono essere fatte (mi viene in mente la difficoltà nel garantire un unico bundle per applicazioni compilate per diverse architetture o la mancanza attuale di integrazione nei menu dei vari ambienti desktop delle applicazioni distribuite in questo modo) ma secondo me ha spunti molto interessanti che potrebbero migliorare di molto l’esperienza dell’utente medio del desktop linux. In definitiva mi sento di accogliere tale tecnologia come un interessante aggiunta da affiancare all’ottimo e rodato sistema basato sui repository. Adesso bisognerà aspettare alla finestra per vedere come sarà accolta dagli sviluppatori.

Se volete testarne il funzionamento potete scaricare qualche AppImage dal sito portablelinuxapps.org. Per adesso le distribuzioni su cui sono stati testati i pacchetti sono quelle maggiormente diffuse (Ubuntu, Fedora e OpenSuse) quindi se non gira sulla vostra Slackware non prendetevela con me. :P

27 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    goldorak
     scrive: 

    Emanuele Rampichino ha scritto :

    \nelle intenzioni degli sviluppatori di questo progetto non c’è quella di soppiantare il sistema a repository ma di fornire un alternativa per la distribuzione di software aggiornato\

    In verita’ gli unici che traggono vantaggio dall’avere tutto incluso, senza dipendenze esterne sono coloro che sviluppano software proprietario. Perche’ ora come ora due sono le strade percorse, o si fa come Red Hat e Novell che ogni morte di papa fanno uscira una versione stabile delle loro distro enterprise (e quindi con API e ABI stabili) per svariati anni dando la possibilita’ a software terzi (proprietari e non) di potersi installare senza alcun problema. Ma chi vuole sviluppare software proprietario per distribuzioni popolari (vedi ubuntu e compania….) allo stato attuale ha moltissime difficolta’, perche’ l’ecosistema sottostante e’ sempre in evoluzione. E l’unico modo per superare queste difficolta’ e’ l’uso di pacchetti all-in-one.

  • # 2
    Emanuele Rampichini (Autore del post)
     scrive: 

    @goldorak
    Ovviamente c’è un vantaggio anche per chi distribuisce software proprietario, mi sono dimenticato di citarlo. Però considero molto più pulita questa soluzione a quella degli installer alla “loki”.

  • # 3
    goldorak
     scrive: 

    @ Emanuele Rampichini : certamente, una soluzione del genere e’ sicuramente piu’ pulita dei vecchi installer Loki-style. E questo puo’ essere un vantaggio sopratutto per chi avra’ il coraggio di vedere videogames sotto linux, perche’ come ho gia’ scritto in passato non vedo francamente altre tipologie di software proprietari avere successo nel settore “consumer”.
    Se pero’ parliamo del open source, una soluzione del genere e’ meno versatile, piu’ ingombrante e piu’ legnosa da gestire. Pensa ad esempio ad un progetto open source che si sviluppa rapidamente. Ha senso chesso’ ogni settimana fare una immagine iso e metterla in download per tutti ? Che si fa se il progetto e’ di 400 MB ? Ad ogni piccola versione si riscarica tutto daccapo ? Non ha senso, lo avrebbe soltanto se il codice fosse closed source. Ma altrimenti e’ una soltanto una soluzione in cerca di un problema inesistente.
    E l’avere accesso ai sorgenti che consente al ecosistema open source di evolversi rapidamente. Se cambia l’infrastruttura sottostante via di una ricompilata e sei apposto. Se qualuno sistema un bug in qualche libreria, non devi aspettare che qualcuno dall’alto rifaccia una nuova immagine iso da scaricare.
    Ricompili la libreria e sei apposto. E nei casi peggiore, ricompili l’applicazione. Se poi tutto questo e’ avverso all’utente comune, entrano in gioco in mainteners delle repository il cui compito e’ proprio questo.
    Gestire e aggiornare applicazioni e’ molto piu’ difficile sotto windows che non sotto linux. E questo nessuno lo puo’ negare. Quindi perche’ cambiare un sistema che funziona, e funziona davvero bene ?

  • # 4
    Emanuele Rampichini (Autore del post)
     scrive: 

    Quindi perche’ cambiare un sistema che funziona, e funziona davvero bene ?

    Infatti non si tratta di cambiare il sistema ma solo di affiancargli una alternativa. Mi viene pensato ad un software più aggiornato in cui gli sviluppatori hanno utilizzato libpng1.4.3 mentre nei repo delle maggiori distribuzioni è presente libpng1.4.2. Essendo la libreria molto diffusa bisognerà aspettare che tutte le applicazioni dipendenti da essa si adattino alla nuova versione della libreria prima di poterla includere nei repo. La soluzione del bundle permette di poter gestire con un arma in più queste fasi di transizione.

    Mi vengono anche in mente altri scenari in cui un sistema a repository affiancato da quello a bundle può portare notevoli vantaggi, magari ne palerò in un altro articolo.

  • # 5
    Z80Fan
     scrive: 

    Sono veramente interessanti queste AppImages; pensandoci un po’, non c’è questo grande problema dei repository: c’è sempre il gestore principale (es. Synaptic), che si affida ai repository ufficiali (che potranno essere condivisi tra tutte le distribuzioni), dove si può scegliere se installare le applicazioni selezionate “per tutti gli utenti” o “solo per l’utente attuale” (nel primo caso bisogna essere amministratori oppure far parte di un certo gruppo). In questo caso, il gestore sà già quali app sono installate e le può aggiornare. Se uno scarica un’app che non c’è nel rep. ufficiale, la può provare anche tenendola sul desktop, ma se decide di tenerla definitivamente, può fare un’operazione di “installazione”, dove semplicemente il file viene copiato nella cartella apposita (sempre distinguendo tra “tutti” o “solo io”), e il programma che gestisce gli aggiornamenti controlla (con l’aiuto di un file all’interno dell’applicazione) se viene fornito un sito dove si può aggiornare l’applicazione (come un repository di terze parti).
    Certo, non si può garantire la sicurezza di questo repository, ma in questo caso (scaricare app da siti non troppo in regola), si sà che il problema è tra la tastiera e la sedia ;)

  • # 6
    saidone
     scrive: 

    “Che si fa se il progetto e’ di 400 MB ? Ad ogni piccola versione si riscarica tutto daccapo ?”

    Esistono anche le diff binarie (come vengono distribuite le patches di firefox & co. ad esempio).

  • # 7
    Marco Antonio
     scrive: 

    Un po’ come la visione delle applicazione sotto MAC.
    All-in-one; tu vedi una singola applicazione da lanciare mentre in realtà si parla di cartella con i relativi subfolders, dati, binari,ecc.
    Sarebbe una bella semplificazione.
    Spero, in un futuro, di vederla affiancare il sistema attuale di Ubuntu.

  • # 8
    L
     scrive: 

    [quote]Mi viene pensato ad un software più aggiornato in cui gli sviluppatori hanno utilizzato libpng1.4.3 mentre nei repo delle maggiori distribuzioni è presente libpng1.4.2. Essendo la libreria molto diffusa bisognerà aspettare che tutte le applicazioni dipendenti da essa si adattino alla nuova versione della libreria prima di poterla includere nei repo.[/quote]

    per questo basterebbe poter tenere entrambe le versioni della libreria, e ogni programma fa uso di quella di cui è compatibile (dichiarata in qualche modo, es. con le dipendenze o con un file apposito). oppure fare API retrocompatibili, ed eliminare quelle obsolete solo ai cambi di major version…

  • # 9
    Giove
     scrive: 

    La diffusione di un sistema come questo porterebbe diverse persone verso Linux…Un Ubuntu Mac Style (ma molto meno expensive) farebbe gola a molti…

  • # 10
    Daniele
     scrive: 

    Sono interesanti, ma nulla più. Le Appimages sono utili per provare nuovo software senza installarlo (es. provare FF 4 Beta senza incasinare la versione attuale). SOno ancora più utili per creare delle applicazioni \portable\, da mettere su una chiavetta USB per lanciarle all’occorrenza da qualunque distro Linux. Ma secondo me i vantaggi si fermano qui. Non capisco come si possa criticare il sistema attuale dei repository. E’ semplicemente fantastico, uno dei motivi per cui non tornerei mai ad usare un OS diverso. Il funzionamento è lo stesso dell’Appstore di Apple o del market di Android.

  • # 11
    degac
     scrive: 

    In effetti l’utilizzo dei repository è una (se non la principale) cosa che mi è piaciuta del mondo Linux. Ti serve qualcosa? La cerchi con un ‘trova-programmi’ che ti offre anche alternative… click e si installa senza tanti casini.
    Ovvio se il programma è fatto con i piedi questo è un altro discorso.
    Ed è altrettanto palese che AppStore & Co hanno preso ‘ampia’ ispirazione da questi concetti!

    Per le AppImages sembrano utili per le applicazioni in BETA senza dover per forza di cose creare troppi casini oppure per gli sviluppatori, per l’utenza finale penso che i repository siano una delle idee più geniali (migliorabili sicuramente, ma difficilmente sostituibili).

  • # 12
    The Solutor
     scrive: 

    Più carino e più radicale l’approccio di gobolinux (che non so ch fine abbia fatto) con il rivoluzionamento della struttura delle directory.

  • # 13
    Rocco
     scrive: 

    Fiko.
    Non ho capito un cosa pero’.
    Da utente MAC un applicazione e’ un folder con tutto il necessario per l’esecuzione della stessa, mostrata all’utente da OS X come singola icona, tuttavia le preferenze dell’applicativo e le impostazioni vengono salvate in un folder diverso (tipicamente /preferences/.plist)
    questo permette di “sostituire” l’applicazione con una versione piu’ recente mantenendo tutte le impostazioni del caso.
    inoltre installazione e disinstallazione si limitano ad un semplice drag&drop nel folder applicazioni o nel cestino.

    Qui le impostazioni dove sono mantenute nel bundle stesso dell’app ?

  • # 14
    Nicola
     scrive: 

    Si potrebbero importare alcuni “approcci” di MS, per risolvere i conflitti di librerie: SxS(Assemblies side-by-side) ed Isolated Applications. Integrate con il sistema dei repository, a mio avviso, andebbero a pennello.

  • # 15
    Emanuele Rampichini (Autore del post)
     scrive: 

    @Rocco
    Il comportamento di default è quello di salvare i settagi nella home utente ma con qualch hack si potrebbe fare in modo di salvarli all’interno del bundle (tutto sommato si tratta soltanto di cambiare la variabile di ambiente $HOME)

    @The Solutor
    Gobolinux è assolutamente interessante. Se non altro perchè riesce a mantenere una struttura del filesystem user frendly con il solo utilizzo di link simbolici mantenendo sotto al cofano la struttura classica. Tempo fa l’avevo virtualizzata e probabilmente ci rifarò un giro in futuro.

    @Nicola
    Assemblies side by side è un approccio molto interessante ma sostanzialmente coincide con quello che su linux viene già fatto con il nome della libreria dinamica (senza l’utilizzo del manifest). E purtroppo ne condivide anche alcuni difetti:

    http://www.ives.fr/index.php/blog/post/19

    Alla fine chi vuole la sicurezza finisce sempre per linkare staticamente le librerie nel progetto.

  • # 16
    Nicola
     scrive: 

    @rampichini

    beh ovvio, se proprio vuoi essere sicuro sicuro, ficchi tutto dentro ad un binario e ti passa la paura. Niente è perfetto. Comunque dal link che hai postato mi sembra di capire che sia un problema abbastanza isolato e comunque evitabile con alcuni accorgimenti. A chi interessa capire cosa sono le due tecnologie che ho mensionato e come interagiscono, fornisco un link ufficiale MS

    http://msdn.microsoft.com/en-us/library/ms235531%28VS.80%29.aspx

    è un buon punto di partenza

  • # 17
    densou
     scrive: 

    Provate rPath/conary e magari vi piacerà più di quanto non avreste mai immaginato. :p

  • # 18
    Giulio
     scrive: 

    Il problema dei repository è l’aggiornamento, non so come stiano messe esattamente le varie distribuzioni, ma la maggior parte dei pacchetti viene aggiornato praticamente scaricando quello nuovo da 0… un difetto non da poco, dato che spesso ci si ritrova a scaricare centinaia di mb anche quotidianamente.

    Mi sembra che su Arch (IMHO la migliore in assoluto che ti fa capire anche il funzionamento generale del sistema :D) usando un wrapper apposito nella configurazione di pacman si possa risolvere a questo difetto.

    Comunque non sarebbe tanto un problema di sicurezza se i pacchetti fossero comunque firmati.

    D’altro canto ci sono dei programmi che non prevedono installazione in Windows, semplicemente c’è un unico file, che si auto-scompatta con il necessario, lancia l’applicazione e al termine cancella i file temporanei, lasciando magari in %AppData% solo eventuali impostazioni.

    Si tratta di “pratiche di buon senso” più che altro, purtroppo il problema di Win è l’esistenza di una varietà di installer che per altro se non correttamente programmati portano ai classici problemi che tutti conosciamo (file residui, residui nel registro e quant’altro…).

    Fossi in MS penserei seriamente a migliorare Windows Installer e a renderlo l’unico programma in grado di apportare cambiamenti al registro applicazioni.

    Inoltre ci sarebbe una separazione più netta tra .MSI e .EXE, che di fatto potrebbe rendere migliora l’intera gestione del processo di installazione.

    Allo stato attuale quando installi un programma in Windows sono necessari i privilegi Admin, ma tuttavia i privilegi Admin sono anche troppo, dato che comunque puoi apportare modifiche al sistema o leggere tutte le cartelle utente ad esempio dando luogo a possibili violazioni.

    Usando un installer unico si possono dare direttive affinché il processo di installazione possa essere più sicuro (quindi niente modifiche alle impostazioni del sistema, niente accesso alle cartelle dei documenti e quant’altro possa compromettere il sistema…).

    Eppure non credo sia così difficile, già oggi Windows dispone di un meccanismo euristico per rilevare i molteplici installer esistenti.

  • # 19
    JPage89
     scrive: 

    Non funziona sulla mia Slackware!
    Ma solo perchè è a 64 bit
    Gira solo su 32, a quanto posso vedere
    è una cosa che per me può avere senso fino ad un certo punto, solo con alcune app
    l’ideale sarebbe che possano contenere anche le impostazioni e quant’altro (in maniera simile alle portableapps su win)
    li avrebbe senso un firefox portable, per esempio

  • # 20
    D
     scrive: 

    Sinceramente non riesco a capire dove sta la novità di questa soluzione. Si è sempre saputo che se un programma necessita di determinate librerie per funzionare, in un modo o nell’altro bisogna fargliele trovare anche a costo di realizzare un mega pacchetto.

    E’ quello che si fa dalla notte dei tempi quando si programma: o si include di peso la libreria o la si fa richiamare “da fuori” con tutti i pro ed i contro di entrambe le visioni.
    Gli installer di windows da sempre si portano dietro all’occorrenza dei runtime o delle librerie (vedi directX per i giochi) per aggiornare quelle presenti se necessario.

    Alla fine gira e rigira, cosa dovrebbe cambiare con questo “nuovo” sistema ?

    L’unica vera soluzione che però non si vuole chiamare in causa sarebbe quella di creare una selezione unica di librerie comune a tutte le distribuzioni così si sarebbe certi che ci sarebbe sempre il necessario, ma sulle ragioni (economiche, da orticello) del rifiuto di questa possibilità si sono già sprecate innumerevoli pagine.

  • # 21
    amsoft
     scrive: 

    Mai sentito parlare di PC-BSD?
    da wikipedia:
    Il sistema di gestione dei pacchetti di PC-BSD ha un approccio differente a molti sistemi operativi Unix-like: invece di utilizzare un adattamento del sistema di FreeBSD, PC-BSD utilizza pacchetti precompilati con l’estensione .pbi che installano immediatamente il software, senza bisogno di comandi dal terminale ma con un’applicazione grafica similmente al DesktopBSD. Esiste un gestore grafico dei pacchetti molto efficiente. Attualmente sono più di 240 le applicazioni precompilate con l’estensione .pbi.
    Tutti i pacchetti di software vengono installati nel ramo /usr/local, diminuendo così drasticamente il numero di luoghi in cui cercare un eseguibile installato. Il sistema dei pacchetti si occupa anche di creare un collegamento nel menu KDE e nel desktop. Lo scopo di questa gestione è di facilitare l’utenza proveniente da sistemi Microsoft Windows.
    Il difetto di questo sistema è di non poter utilizzare con questo metodo tutti i programmi esistenti per FreeBSD ma di dover riadattare, e perciò in un certo senso duplicare, tutto il software già disponibile sulla versione del sistema padre.

  • # 22
    giacomo
     scrive: 

    ottime argomentazioni, idee e capacità espositive.
    Purtroppo anche l’ortografia ha la sua importanza, e per me gli errori sono come un dito in un occhio.

    Passi “qual’è” con l’apostrofo
    Passi “far si” senza accento

    ma a “da li …” senza accento, ho smesso di leggere.

    Senza offesa,Giacomo

  • # 23
    marcello
     scrive: 

    Il vero problema della gestione dei software tramite repository e’ che ti sporca il sistema, perche’ installa una tonnellata di dipendenze che non vengono poi rimosse quando si elimina il pacchetto installato; questo e’ un problema per chi tende a provare molti software per trovare quello piu’ congeniale alle proprie esigenze.
    In gentoo si puo’ fare un bel emerge –depclean e si riesce a mantenere il sistema in uno stato quasi decente, ma per altre distro no, con il risultato che poi il sistema si appesantisce inutilmente…
    Una cosa che poi trovo assurda e’ il continuo cambiamento delle API e ABI con la conseguenza di dover ricompilare in continuazione, ma mantenere un minimo di retrocompatibilita’ e’ cosi difficile? E’ ovvio che in una situazione di questo genere l’unico modo per avere pacchetti commerciali e’ linkare staticamente, anche se non e’ una soluzione molto efficiente e rappresenta IMHO un grosso limite di Linux per ora.
    Diciamo che la cosa ottimale sarebbe avere una soluzione simile a quella di PC-BSD o Mac Os X, che rende veramente facile la gestione delle applicazioni.

    Sarebbe bello avere come nei sistemi Windows e Mac la necessita’ di ricompilare tutto solo per le major release, d’altronde se le API son progettate bene il software non necessita di essere modificato se il codice interno alla libreria cambia, basta una semplice ricompilazione.

  • # 24
    Emanuele Rampichini (Autore del post)
     scrive: 

    @giacomo
    Mi dichiaro colpevole… questa settimana mi sono fermato ad una sola rilettura. Mi dispiace se gli errori ti hanno fatto smettere di leggere il contenuto. Concedimi almeno le attenuanti generiche (caldo torrido e voglia di mare) :D.

    Mi auguro comunque che continui a leggere i miei articoli segnalandomi gli errori così che in futuro possa migliorare.

    @marcello
    Per debian puoi fare qualcosa di simile con deborphan. Anche pacman (di arch linux) è un grado di trovare ed eliminare eventuali dipendenze orfane.
    Sul discorso API e ABI stabili posso essere d’accordo in linea di principio. Ma poi la linea di principio si scontra con l’enorme ecosistema aperto in cui nessuno impone (secondo me giustamente) tali obblighi.

  • # 25
    Switch
     scrive: 

    Scusate ma non vedo la novità…
    Esisteva già un progetto che si muoveva in quella direzione: http://klik.atekon.de/

    Quale è la necessità di farne una copia?

  • # 26
    Emanuele Rampichini (Autore del post)
     scrive: 

    @Switch
    Infatti ho scritto:

    A rendere ancora più interessante questa possibilità sono le varie tecnologie di bundling che ciclicamente si ripresentano nel panorama aperto

    Klik è una di quelle. tra l’altro tra gli sviluppatori dell AppImage se non sbaglio c’è qualche nome del team che ha sviluppato klik.

  • # 27
    GoboLinux
     scrive: 

    GOBO linux la soluzione

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.